Microsoft Dynamics GP Architectural Foundations Series - Built to Last
This is article 2 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 Last
The paradox of functionality vs. technology
Business management systems are huge. The Dynamics product has more than 1,100 windows, 900 reports, and data stored in more than 500 tables. This robust functionality didn’t happen overnight. Several years ago, a staff of more 100 developers began work on Dynamics. The number of developers has steadily increased, and today more than 240 developers work on the product. That is a huge investment to achieve this level of functionality. This is not unique to Great Plains. In general, the most successful software vendors will be those who can build system functionality not just over years, but decades.
However, there is another equally important component in a business management system: technology. A product with great functionality will be of little value to customers if it is based on an outdated technology base.
It’s clear customers demand both functionality and technology. However, herein lies a paradox. As we’ve discussed, functionality is a valuable asset that needs to be nurtured and grown over years or even decades. Technology is very different. Technology changes constantly. In the modern world of client/server, Internet, and relational databases, the rate of technological change is rapid and accelerating every day. Today’s leading-edge technology can quickly become obsolete in only a few years.
With this paradox in mind, the single most important aspect of architecture is to reconcile these two very different, but required components. At Great Plains, we have chosen an architecture that seamlessly joins our functionality and technology while keeping them separate and distinct components.
The advantages of this architecture have been proven many times during the Dynamics product lifetime. For example, when Dynamics first shipped in 1993 the primary operating system was Windows 3.1. Of course, Windows 3.1 was a 16-bit operating system and all applications that ran in this environment were also 16-bit. Dynamics was no exception.
However, in 1994 Windows NT emerged as the first legitimate 32-bit operating system for PC’s. The customer benefits of this new environment were clear. No memory limitations, pre-emptive multitasking, threading, protected application memory space, and many other advanced features awaited customers who moved to the new 32-bit environment.
Clearly, the move from 16-bit to 32-bit software was a major technological change. The Dynamics architecture was ready for the challenge. Because all technology was separated from business logic, we were able to switch our technology level from 16-bit to 32-bit without rewriting a single piece of business logic. Great Plains Dynamics version 2.0 shipped in the summer of 1994 as a 32-bit application, years ahead of any competitor.
The transition from 16-bit to 32-bit is only on example of how the Dynamics architectural strategy of separating business logic from technology is benefiting customers. Another great example is Visual Basic for Applications (VBA). We’ll talk at length about VBA later in this paper, but for now it’s enough to understand VBA is a new technology from Microsoft that allows users to customize applications. Included as a basic part of Microsoft Office, VBA is also available to selected software developers.
By leveraging our “Built to Last” architecture, Great Plains was able to include Microsoft’s Visual Basic for Applications as part of the Dynamics product by inserting it into our technology layer. Once again, we were able to give customers the benefit of this important technology without impacting our business logic.
"Built to Rewrite"
The Great Plains strategy of separating business logic from technology may seem like an obvious strategy that every vendor would pursue. I can assure you this is not the case. Time and time again other vendors have pursued a strategy I call “Built to Rewrite.” Under this strategy, these components are allowed to freely intermix.
This results in disastrous product issues. Even the relatively straightforward task of converting software to 32-bit is an insurmountable obstacle for some. Many business applications developers are still struggling to get their customers the benefits of 32-bit software. Their intermixing of technology and business logic is forcing them to rewrite significant portions of their business logic to include a “new” technology like 32-bit.
Commonality between business management systems
All business management systems can be roughly categorized into three levels: base development environment, vendor-supplied toolsets, and business logic. At the lowest level, software vendors must choose a development environment on which to base their product. Examples of commonly used development environments would be Microsoft Visual C++ or Microsoft Visual Basic. However, no vendor finds the basic development environment to be sufficient to produce a robust, feature rich application. With this in mind, every vendor uses a custom toolset tailored to the unique needs of business management systems. This vendor-supplied toolset forms the second level. Finally, at the top level, the vendors use their toolset to develop their business logic.
Making the “wrong” comparisons
During sales situations, other vendors may try to coerce customers into making the wrong comparisons. They will incorrectly try to compare the Great Plains toolset (Dexterity) to the other vendor’s development environment (Visual Basic). Typically this comes across as a statement like: “Vendor X uses Microsoft Visual Basic, while Great Plains uses a proprietary, non-standard tool named Dexterity.” The diagram below exposes the flaw in this logic.
When comparing business management systems, we encourage you to compare the twovendors’ development environments, the vendor’s custom toolsets, and the vendor’s
business logic (functionality).
One important difference between Great Plains and many other vendors is our use of C++ rather than Visual Basic as our base development environment. We believe our use of C++ is a strategic advantage that delivers significant customer benefits.
C++ vs. Visual Basic: Standards Support
To understand standards, we need to look at three commonly used terms:
Proprietary - "Exclusively Owned"
Webster’s defines “Proprietary” as “Exclusively Owned.”
Industry Standard - "Exclusively Owned, but very popular"
While this is my own definition, I think you’ll agree it’s accurate. For example, Crystal Reports is considered by most to be an “Industry Standard” product. Of course, Seagate Software exclusively owns Crystal. In the end, the only difference between an “Industry Standard” product and a “Proprietary” product is popularity.
Standards-Based - "Open, Multi-Vendor product"
While most people use the term “Industry Standard” on a daily basis, many don’t fully understand the far more powerful concepts behind a “Standards-Based” product. No one company controls a standards-based product. Instead, a national (ANSI) or international (ISO) standards group defines the core product functionality.
Now let’s look at C++ and Visual Basic in the area of standards support and see how this might impact “Built to Last.” C++ is a true standards-based product, with both ANSI and ISO working together on the standard. The ANSI group working on the C++ standard is designated “ANSI X3J16,” and the ISO group is “ISO WG21.” If you’d like more information, the entire C++ standards document is online at http://www.cygnus.com/misc/wp/ [Ed: broken link].
Because C++ is standards-based, there are two important ramifications for “Built to Last”:
1. No single company can arbitrarily remove or change core C++ functionality
Today, we use Microsoft Visual C++ as our C++ development tool. Because C++ is standards-based, we can rest assured Microsoft will not remove or change C++ functionality we are relying on today.
2. There are multiple vendors that supply C++-based development tools
Even if something catastrophic happened (perhaps there was a terrible bug in Microsoft C++ that rendered the product useless), our investment in standard C++ would be preserved. There are many other vendors that supply C++ tools for the Windows platform.
C++ vs. Visual Basic: Technology Support
Getting the latest and best technologies to our customers first is critically important to Great Plains, and our architecture and design choices allow us to do this very effectively.
You may have heard other vendors claim that, since their product is “created” in Visual Basic, which is a Microsoft product, they therefore have an advantage in getting other Microsoft technologies to you first.
We’ve already demonstrated this argument doesn’t compare apples to apples, instead comparing one vendor’s custom toolset to another vendor’s development language. When we compare development languages, Microsoft Visual C++ to Visual Basic, we see both vendors are using Microsoft languages, and it becomes clear Visual Basic does not get the latest technologies first. In fact, there is typically a lag of several years before Visual Basic gets technologies. Consider the following diagram:
First, consider the fundamental technology of COM (the Microsoft Component Object Model), formerly called OLE in its early releases. COM is the “glue” that is the basis for all interapplication communication on the Windows platform. When first released as part of Windows 3.1 back in 1992, the only method of implementing this technology was via C/C++. Visual Basic did not gain this important technology until Visual Basic 3 shipped in early 1994, a two-year gap.
Next, consider 32-bit technology. When the first Microsoft 32-bit capable operating system, Windows NT, shipped in 1993, the only way to build a 32-bit application was using the C/C++ Software Development Kit from Microsoft. Visual Basic was not capable of producing a 32-bit application until Visual Basic 4 shipped in late 1995. Again, a two-year gap between C++ and Visual Basic.
Finally, consider Visual Basic for Applications (VBA). The first products using Microsoft VBA shipped in late 1996 using C++. You won’t see any Visual Basic bar on the chart because VBA, as shipped by Microsoft, is a technology that only C++ applications can integrate. One would expect, based on past trends, Microsoft will eventually create the ability for Visual Basic-based applications to directly integrate VBA. Meanwhile, C++ based applications like Dynamics have been giving customers the benefit of this new technology for over a year.
C++ vs. Visual Basic: Microsoft’s Actions Speak Louder than Words
Microsoft produces both Visual Basic and Visual C++. Because they produce both products you will rarely see statements from Microsoft positioning one product as “better” than the other product. However, to judge the suitability of using C++ or Visual Basic for producing commercial-grade, high-performing, scalable applications, one need only look at Microsoft’s actions to gain some insight.
The diagram below shows the major development tools Microsoft produces (C++, Visual Basic, J++, FoxPro, Access, etc…). Next we show the major products Microsoft sells, stacked on top of the development tool they use to build that product. The diagram shows C++ is clearly Microsoft’s “tool of choice” for building all of their commercial grade applications. In addition to the applications shown (like Office or SQL Server), many other Microsoft applications are also written in C++ (Exchange, SM, Internet Information Server, Site Server, etc.).
The large “NOT” sign indicates Microsoft does not use Visual Basic (or any of the other tools) as the base development environment for any of its major products.
As our last item on our comparison of the suitability of C++ vs Visual Basic for building large, mission critical, high-performing applications like business management systems, I’d like to quote “the man in the know,” Bill Gates, Chairman and CEO of Microsoft. At a recent public Q&A session Gates was asked the following question:
Q: "If someone wanted to be set for tomorrow, what tools should they be using from Microsoft’s perspective?"
Bill Gates: "For simple applications Visual Basic does very well. Even for some of the larger corporate applications, we’ve been able to scale that up quite a bit.
People who do heavy-duty development: they are using C today, and they are going to be using C five years from now... It just lets you get at a level in terms of managing memory, managing type systems, that other languages don't let you get at."
For information on C++ standards please visit http://www.open-std.org/jtc1/sc22/wg21/
In the next article Tim reviews "Built to Grow".
Until next post!
MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
Comments