From the Newsgroups: Safe Pay and Absolute Value of all Documents

Welcome to another edition of From the Newsgroups, where you will find real life cases of everyday issues. This edition comes courtesy of the Microsoft Dynamics GP Partner forum:

Q: I have setup Safe Pay Configurator. I am having issue with the overall [file] total, which I assigned as a Standard field, Check Amount, and then Amount type, Net Total. When we were testing for the trailing record, the overall document amount is coming out as Issued - Void which is correct because it's a net total, but the issue is our voids are coming without the negative sign so the value is off. Below is the example:

Issued: 1,000

Void: 100

Overall total: 900

Our bank is requesting absolute value [Ed: Checks + Voids] so overall total should be 1,100.

I exported the configurator and imported it to Fabrikam and it works/calculate correctly. Only thing we have different from Fabrikam is Multicurrency is not activated. When I tested it in Fabrikam, here's the result:

Issued: 1,000

Void: -100

Overall total: 1,100

Why is my format working in Fabrikam but doesn't on our production company?

Please advise.

Interestingly enough, it turns out this issue is related to a missing chunk file. Here is the answer from the support engineer.

A: In order to get the absolute value, you will need to install a .cnk file into the GP code folder. The .cnk file would need to be installed on all workstations that generate the Safe Pay file. The file updates the code that generates the file and adds a function that gives the total of the checks and voids. Unfortunately I can't explain why it works in Fabrikam and not in the live company. It does not work correctly in my Fabrikam install so maybe it was the way you generated the transactions for your testing.

If you are experiencing a similar situation or simply need to submit the absolute amount of all documents in the file (checks + voids), please open a support incident with the Microsoft Dynamics GP support team.

Until next post!

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

Read More

Microsoft Dynamics GP Architectural Foundations Series - Conclusion

This is article 6 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.

---

Conclusion

A typical architecture white paper will usually babble on about the popular technologies of the day like Client/Server, SQL Server, Thin Clients, Browser Clients, Stored Procedures, FRx, Office Integration, Report Writing, 2-Tier, 3-Tier, ODBC, Internet, Transact SQL, Windows NT, etc.

This document operates at a more strategic level, primarily because the endless list of technologies are changing constantly. In short, technologies come and go, but architectures are built for the long term. Any meaningful discussion of product architecture must be based on principals or philosophies that are technology independent.

The eEnterprise product architecture is based on a single fundamental premise, with four supporting philosophies:

The value of the business management system is contained in the Business Logic.

• The business logic must be Built to Last
• The business logic must be Built to Grow
• The business logic must be Built to Leverage
• The business logic must be Built to Fit

This document has been dedicated to describing these philosophies in detail. When a specific technology like C++ or VBA has been mentioned, it is only an example of how current technologies are being used to support these long-term philosophies.

While I've tried to avoid mentioning specific technologies in order to focus on the long-term architecture, keep in mind that eEnterprise is the industry leader in technology support. Client/Server, SQL Server, Thin Clients, Browser Clients, Stored Procedures, FRx, Office Integration, Report Writing, 2-Tier, 3-Tier, ODBC, Internet, Transact SQL, Windows NT... Yes, eEnterprise supports them all!

But in the end, never allow a laundry list of technologies from any vendor cloud your vision. Always keep in mind that today's "must have" technologies will quickly become tomorrow's "must replace" technologies. Great technology is not enough. Great functionality is not enough. You need a product that has an established track record of sustained technology and functionality leadership that only a superior architecture can deliver. I hope you'll agree the eEnterprise architecture has the solid foundations you can trust to take your business into the future.

---

In the next article Tim Brookins offers his insight.


Until next post!

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

Read More

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/

Read More

Welcome aboard MVP Ian Stewart!

All I can say to the folks with the Microsoft MVP Award Program is, it was just about time! I take a break from the Microsoft Dynamics GP Architectural Foundations Series to welcome MVP Ian Stewart! Ian is a very knowledgeable and tireless contributor the the Microsoft Dynamics GP Community. Ian is a fine talent from Ireland and operates his own consulting organization.

The overall Microsoft Dynamics GP community is certain to continue benefiting from Ian's vast knowledge and for him, nothing more rewarding than doing it with his new MVP badge. You can learn and read more about Ian on his blog at DynamicsGP.ie.

Until next post!

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

Read More

Microsoft Dynamics GP Architectural Foundations Series - Built to Leverage

This is article 4 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 Leverage

The previous two philosophies (“Built to Last” and “Built to Grow”) have ensured a feature-rich business management system that is ever growing. Each release builds upon the previous release, adding new functionality and technology. As functionality builds, the Dynamics product becomes a true asset to the business.

Our architecture needs to recognize the incredible value of this business asset and allow the business software engine to be used not only by Dynamics, but also
throughout the enterprise. As you will see, this is not a new idea. In fact, it’s been a goal of our architecture since the very beginning.

The diagram below shows the Dynamics’ business logic (the asset) in the large central box. The box on top labeled “Dynamics” represents the basic Dynamics user
interface. Of course, the standard Dynamics user interface leverages the Dynamics business logic to accomplish the required processing.

The whole “Built to Leverage” value is centered on expanding this usage of the Dynamics business logic to other non-Dynamics sources. The boxes labeled “Solution Developer” on the top are a great place to start. Since the first release of Dynamics, our toolset has allowed other applications to leverage the Dynamics business logic. For example, Solution Developer-produced vertical application could call the Dynamics posting routines. For the first release back in 1993, those Solution Developer products had to be written in our C++-based toolset (Dexterity). While this was a great start, we had a vision to extend this same ability to leverage the business logic of Dynamics to other non-Dexterity-based applications.

The box labeled “Continuum” on the left side is an example of how we’re delivering on this vision today. Our Continuum series of products allows an application written in any COM-compliant development environment to leverage the Dynamics’ business logic.

Our “Built to Leverage” architectural value has also allowed us to gain strategic advantage in the area of the Internet. For example, our support for electronic
commerce is enabled by allowing Microsoft Site Server to leverage Dynamics’business logic by exposing those business objects via COM. As we move into the future, additional components of the Dynamics business logic will be exposed to the Internet as Microsoft Transaction Server-based COM objects.

---

In the next article Tim reviews "Built to Fit".

Until next post!

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

Read More

Microsoft Dynamics GP Architectural Foundations Series - Built to Grow

This is article 3 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 Grow

We began our discussion with the premise that the true value of a business management system is in the product’s functionality. Our “Built to Last” architectural value allows us to “plug in” new technologies, giving end users access to leading edge technologies while also protecting the functionality from changes in technology.

We have established an architecture that allows our product to be “Built to Last,” which allows us to turn our attention to the task of ensuring we can add new functionality to the product. We call this value “Built to Grow.” At Great Plains, we ensure our product is built to grow in three primary ways.

Solid Foundation
A software developer can’t add new functionality if they are always busy fixing the old functionality. Dynamics has exceptional product quality levels. This high-quality
product gives a solid foundation on which to base new functionality.

Best Practices
Great software doesn’t happen by accident. This is especially true for very large and technically complex software like business management systems. You can’t simply
throw hundreds of developers into a room and expect robust, high-quality software to come out.

Great software requires a comprehensive strategy from requirements gathering at the beginning to testing and product shipment at the end. With this in mind, Great Plains has a corporate commitment to promoting the best practices for software development.

Great Plains bases its process effort on the Capability Maturity Model (CMM). Pioneered by the Software Engineering Institute at Carnegie Mellon University. The Capability Maturity Model provides a framework to guide and measure software engineering improvement efforts by enabling organizations to assess their software
engineering capabilities. You can learn more about the work of the Software Engineering Institute on the CMM at http://www.sei.cmu.edu/

Supporting Systems
Established processes are a must for great software development, but a “paper process” is only the beginning. Companies must act on those best practices by investing in supporting systems. Great Plains has a long history of making these important investments. Let’s begin by taking a look at just one area where Great Plains has invested in supporting systems: testing.

Since the first day Dynamics shipped back in 1993, Great Plains has committed to test each and every product feature. Before any feature is implemented, the SQA
staff defines a paper-based test plan. This plan is then put into action by recording an automated test (called a macro). As the Dynamics product has grown over the years, the test cases have also grown. Today the testing suite has grown to more than 4,000 unique cases, all backed by automated macros.

If performed by hand, this suite of test cases would take an estimated minimum of 3,000 hours of testing time to complete, equivalent to two months of work for a 10-person team. Because we’ve recorded these tests as macros, we’ve reduced the workload by a factor of 100, to around 30 hours of machine time.

But we want to be able to test our product even faster, more often, to make the code as clean as we possibly can. In response, Great Plains has increased its investment in supporting systems to build a distributed testing environment. Before development team members go home for the evening, they indicate that their machines may be used for testing by running a small application. This application communicates with a central testing server, and the result is that hundreds of machines can be used for testing. The testing server automatically downloads the version of Dynamics to be used for testing to the team member’s machine, enabling us to run tests all night on hundreds of machines simultaneously. At 7:00 am, the tests automatically stop running, the results are uploaded to a central database, and the copy of Dynamics is deleted from the team member’s machine. This distributed testing environment allows us to test many features in Dynamics in a single evening.

You may be thinking this is nothing special. “Of course all business management system vendors fully test their software.” I can assure you this is not the case. Customers cannot simply assume their business management vendor fully tests the product. Due diligence during the product evaluation phase should absolutely include
an evaluation of the vendors’ testing methods.

When you perform this evaluation, you will be shocked to find out that some vendors have no formal testing process. The product is tested by throwing a few support
people into a room and letting them “play with the software” for a few days before the new version is released. Other vendors rely on Beta releases to customers to
ensure product quality. At best, this is the vendor making the customer test the product. In reality, most customers don’t really exercise a Beta product, and the
product is simply not tested.

Some vendors have begun to realize the disastrous consequences of releasing products that are not fully tested. These vendors are engaged in a “catch-up” phase where they are trying to retrofit automated testing into an existing product. Keep this in mind when evaluating a vendor. If they tell you, “We use automated testing,” you need to follow up and ask them how much of the product is tested with these automatic tools. In reality, many of these vendors have just started, and only a few tests are actually in use. This perspective shows what an impressive asset the 4,000 existing Dynamics macros are to the customer’s productive use of the software. It has taken a software quality assurance staff of more than 50 people working for over seven years to build this test base. During this time, the testing staff also has continued to grow to support new initiatives and technologies. Vendors who are starting from scratch today will never catch up.

---

In the next article Tim reviews "Built to Leverage".

Until next post!

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

Read More

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 two
vendors’ 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.

Now let’s look at Visual Basic. Visual Basic is only available from a single vendor (Microsoft) and it is definitely not a standards-based product. It should be clear the potential negative impacts this could have on “Built to Last.” This is far more than theory. In fact, other vendors who use Visual Basic have been significantly impacted several times. For example, one vendor wrote its entire product using Visual Basic 3.0 VBX controls. (VBX’s were Microsoft’s preferred method of creating controls on a Visual Basic window). This vendor created every control on hundreds of windows as VBX’s. When Visual Basic 4.0 shipped, Microsoft decided to simply remove support for VBX’s, and declare a new preferred method of creating controls: OCX’s. This forced the vendor to start from scratch and rewrite its entire user interface to support OCX’s. The result: untold hours spent rewriting interface code instead of adding value to their customers’ solutions.

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/

Read More