Microsoft Dynamics GP Architectural Foundations Series - Built to Fit

This is article 5 of 7 from the series Microsoft Dynamics GP Architectural Foundations Series - featuring Microsoft's Tim Brookins.

Tim's whitepaper was originally published in 1999 and it's reproduced here with his permission.

---

Built to Fit

Buyers in the midmarket require more than shrink-wrapped applications. It is imperative the system fit seamlessly into the customer’s overall business. The overall fit of the software is determined in two principal ways: customization and integration.

No matter how feature-rich a business management system, each customer will have unique needs not covered in the basic software. The Dynamics architecture must accommodate significant product customization as a basic part of the system. Additionally, the customized business management application must be integrated with all the other applications in the business.

The Dynamics architecture must also recognize that “Built to Fit” must not interfere with the “Built to Grow” philosophy. The process of customization and integration cannot modify the product in such a way that future upgrades are economically impossible. “Built to Fit” must work in a manner that allows cost-effective product upgrades.

Product Customization: What is VBA?

To understand the role of VBA in product customization, let’s begin with Visual Basic. Microsoft Visual Basic is one of the world’s most widely used rapid application development (RAD) environments. It is estimated over three million programmers know how to produce applications in the Visual Basic environment.

Visual Basic produces new, standalone applications. This does not meet the need for product customization. To enable customizations, we would need a special version of Visual Basic which, instead of producing new standalone applications, could “embed” itself inside an existing application. This special version of Visual Basic would allow customizations of the existing application without modifying source code.

It’s important the customizations are accomplished without modifying source code, because this greatly simplifies loading new versions of the business management system during upgrades. If the customization modifies source code, it becomes too expensive to reapply those changes to the new version. This defeats “Built to Grow.”

Microsoft Visual Basic for Applications (VBA) is designed to meet this need. Microsoft VBA is a special version of Visual Basic that can be embedded inside another application. VBA is included as part of the Office suite, and is the primary way end users customize Excel or Word.

In addition to the Microsoft Office products, Microsoft has allowed a select group of software vendors to license this technology. Some common names you might recognize are AutoDesk (AutoCad), Seagate Software (Crystal Reports), Adobe, Micrographix, Visio, and Cognos.

Visual Basic: Good or Evil?

At this point you may be confused. I spent significant time earlier in this document discussing Visual Basic’s weaknesses relative to C++. In this section, I am proudly proclaiming our support for this great Visual Basic technology, VBA. So is Visual Basic good or evil? The answer is both, and I intend to prove this is not just my opinion. Microsoft itself has come to the same conclusion.

The role of VBA in Microsoft Office

The diagram below depicts the role of VBA in the Office product. In the lower left, you see the block labeled “C++.” This demonstrates that Microsoft chose C++ as their base development environment for the Office products (Excel in this specific case). The block in the upper left communicates that the business logic and user interface of Excel is based on C++ code.

Note that the portion of the diagram to the left of the line represents the Microsoft “Internal” tools used to build Excel itself. To the right of the line represents the tools “External” users (i.e., end users) use to customize Excel.

This “Internal” vs. “External” differentiation is key to understanding the role of Visual Basic in Microsoft products. We can see Microsoft believed C++ was the best language to construct Excel. However, just because Microsoft chose C++ for its internal use doesn’t mean C++ was the best choice for external users. C++ is a powerful language, but it is complex and requires some intense training. As a RAD tool, Visual Basic is a much better environment for the public at large. Therefore, Microsoft chose to expose VBA as the primary customization tool for Office.

So is Visual Basic good or evil in this case? It’s clear Microsoft does not consider Visual Basic to be a good choice to build a complex commercial application. However, it is an excellent choice for allowing end users to easily customize the C++ built application.



The Role of Visual Basic in Dynamics

The diagram shown below should look very familiar. The role of Visual Basic in the Dynamics architecture is basically identical to the Office strategy.

The lower left quadrant indicates our choice of C++ as our primary development language. However, like Microsoft, just because we chose C++ as our internal language to build Dynamics doesn’t mean C++ is the best language for external users to customize Dynamics. For external purposes, we choose to support Visual Basic for Applications.

This is the perfect opportunity to deal with some other misconceptions other vendors may have about Dynamics. In some cases, you may hear: “Great Plains added VBA support to their latest release. They recognize Dexterity was a mistake, and VBA is just the first step of throwing out Dexterity and rewriting their whole application in Visual Basic.”

You should now have enough understanding of our (and Microsoft’s) strategies in this area to see how ludicrous this statement is. Because our strategies are identical, try substituting Excel into the same argument just for fun: “Microsoft added VBA support to the latest release of Excel. They recognize C++ was a mistake, and VBA is just the first step of throwing out C++ and rewriting the whole application (Excel) in Visual Basic.”

Of course, neither Microsoft nor Great Plains has any intention of moving away from C++ to Visual Basic as its primary development environment.

So is Visual Basic good or evil? As I promised, it’s both. We believe C++ is a great choice for building large, complex, high-performing commercial applications.We also believe Visual Basic is a great choice as a customization tool. When the roles are reversed, both products become “evil.” C++ would be a terrible choice for customization, and Visual Basic would be a terrible choice for internal development.



Will the real VBA please stand up?

Visual Basic has become a common customization tool for most business management software vendors. Several major business software vendors have released customization products based on some form of Visual Basic-like product. However, it’s imperative buyers understand these products vary widely in their level of Visual Basic support. There are three primary Visual Basic-like products in use today:

Visual Basic for Applications
VBA provides all the components needed to customize an application. The project window displays the objects you can customize. The property window displays object properties. You can leverage the MS Forms designer to add new windows, and then add ActiveX controls. Top this off with the full Visual Basic debugger and you get a powerful customization solution.














Visual Basic Script
Visual Basic Script is Microsoft’s solution for adding scripting to an application. You get the ability to write code (script), but there are few additional features. For example, there is no MS Forms support for adding windows, no ActiveX control palette, no project or property windows, and only limited debugging.















Mystic River SBL
SBL is a Visual Basic-clone product produced by a company called Mystic River Software. This product has a simple Visual Basic-like syntax in its scripting engine, but otherwise bears no resemblance to “real” Visual Basic. Programmers used to the modern Visual Basic environment won’t be familiar with this environment, since there is no forms support, a very basic editor, little or no debugging, no ActiveX control support, and limited COM support.

VBA: Separating the best from the rest
Now that we’ve reviewed the various products used in business management system customization, you are positioned to make an informed assessment of vendor capabilities in this area. However, be advised that vendors using other technologies will use the terms “Visual Basic,” “VBA,” or “VBA-compatible,” even if they are using proprietary, non-Microsoft products like SBL (which has no real Visual Basic code at all).

If a vendor tells you they are using VBA, be sure VBA is actually available in a shipping version of their software. Many financial management software vendors have licensed VBA from Microsoft (by paying a fee), but few are actually shipping software containing VBA. You may be wondering why Great Plains was the first vendor to ship VBA. There are two reasons for this. First, our “Built to Last” architecture allows us to quickly plug in new technologies like VBA without rewriting our business logic. Second, recall the previous section of this document entitled: “C++ vs. Visual Basic: Technology Support.” We discussed how C++ based applications are able to integrate new technologies quicker than products written in Visual Basic.

If you are wondering whether a vendor supports “real” VBA or not, simply ask for a demo. First open VBA inside Excel or Word (just hit Alt+F11 from inside either application and VBA will open). Compare the VBA environment from Office with the vendor’s version of VBA. You will be able to tell at a glance if the vendor’s VBA is the same as the real VBA in Office. Take a moment to look at the Dynamics VBA screenshot on the previous page: it looks just like VBA in Office because it is the very same application.

For an 18-page VBA white paper that describes Great Plains’ implementation of VBA in detail, we invite you to visit the Great Plains DynamicTools web page at www.greatplains.com/documents/downloads/vba_wp.pdf.stub. [Ed: Link Broken]

Built to Fit: Integration

Recall there were two components in the “Built to Fit” architectural value: customization and integration. We’ve covered customization in detail with our discussion of VBA, so we now turn our attention to integration.

Midmarket customers demand tight integration between their business management system and other parts of their business. For example, consider a business that has a custom-written order processing system that must integrate with the business management system’s receivables module.

To discuss our integration architecture, we’ll use a common framework that breaks down an application into three major components: User Interface, Business Logic, and Database.

Integrating at the database level

Integrating applications at the database level has become a very common approach. As the diagram shows, data is moved directly into the business management system’s database using integration standards such as Open Database Connectivity. This gives applications written in Access, Visual Basic, and PowerBuilder easy, standard ways of integrating at a data level. The Dynamics Import Utility also allows easy access to Dynamics tables:



There are some definite advantages to integrating at the database level (it’s typically very fast), but there are also some drawbacks. First, the end user must understand the structure of the database schema. There are usually hundreds of tables in a typical midmarket business management solution database. Compounding matters, a single “logical” document (like a receivables transaction) may need to be imported into several tables.

A second drawback to database level integration is once you have learned the datamodel and implemented your integration, the datamodel may change during a product upgrade. This is an impediment to product upgrade and goes against our “Built to Grow” philosophy.

Integration at the Business Logic level

To better support our “Built to Fit” and “Built to Grow” values, Great Plains introduces a second type of integration product: one that integrates at the business logic level. Called the Dynamics Integration Manager, this tool allows external systems to be quickly and easily integrated into the business management system.



Because the Integration Manager interacts with the business logic of the Dynamics application, no knowledge of the Dynamics database structure is required. Users simply point the Integration Manager to their external data via a graphical point and click interface, and the data is automatically imported into the business management system.

Any upgrade concerns are also eliminated with this product. Unlike database level integrations, which are susceptible to changes in table structure during a product upgrade, the Integration Manager never fails. When a new version of Dynamics is released, a new version of the Integration Manager is also released which automatically “knows” where to put the external data.

The Integration Manager contains a number of other invaluable features. For example, it is very common for external systems to use a different numbering scheme for identifiers like Account Numbers, Customer IDs, or Inventory Item IDs. The Dynamics Integration Manager can maintain translation tables and automatically translate the IDs during data imports.

Another useful feature is data synchronization. It is common for records like Customers to be tracked in more than one system. The Integration Manager allows these multiply defined resources to be synchronized. For example, if a customer address changes in an external system, that change can be automatically propagated into the Dynamics’ customer record.

In summary, the Dynamics Integration Manager is a key component of our “Built to Fit” architectural value. It allows nearly effortless integration of external data sources that will maintain their functionality across product upgrades.

---

You can download the original 18-page VBA white paper referenced in this article here.

In the next article Tim presents his "Conclusion".


Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/