Microsoft Dynamics GP Architectural Foundations Series - Introduction

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

---

Microsoft Dynamics GP Architectural Foundations Series

Introduction

Business managers have an overwhelming challenge in evaluating new business management systems. Even a minimal evaluation of product functionality and technology can be a huge undertaking. However, as Chief Architect at Great Plains, I urge you to expand your evaluation past the basics of functionality and technology into the area of product architecture.

Product architecture describes how the various pieces of the business system are assembled and integrated with each other. You may be wondering: “Why should I care how the business management system is designed?” Architecture is important to your evaluation because a product with a solid architecture will move gracefully into the future, while a product with a poor architecture will be unable to move forward with advances in functionality or technology.

This document addresses not only the important area of product architecture, but also describes the basic foundations and philosophies of the architecture. In other words, we describe why the Dynamics architecture was constructed in its current form.

The importance of these three areas (existing functionality and technology, product architecture, and philosophies of the architecture) can best be described by way of analogy. Instead of buying a business management system, consider an example where your business was acquiring another company. Of course, you would spend a great deal of time studying the other company’s current sales, profitability, and general financial health. I would equate this to the basic evaluation of a business management system’s existing functionality and technology.

In addition, before the purchase you would want to examine more than the company’s existing financial health. You would want to ensure the company had the resources and organizational strength to overcome future changes in the market. Thus, I would equate the process of examining the target company’s organization to the examination of the business management system’s architecture. It is the product’s architecture that will determine its ability to react to future changes.

Finally, once you had studied the company’s existing organization you would certainly have questions about why the organization had taken its current form. Typically, a company's organization is constructed in an optimal fashion to meet its near- and long-term goals. To understand the organization, you must first understand the company’s goals. In a similar fashion, to understand why a product’s architecture takes its current form, you need to understand the goals of the architecture.


Dynamics Architectural Foundations

The Dynamics architecture has four foundational philosophies:

Built to Last

Business management systems are huge. Midrange business management systems have core functionality that takes hundreds of developers years or even decades to produce. You simply can’t afford to rewrite a business management system from scratch every few years. With this in mind, the product architecture needs to promote an environment where new technologies can be integrated into the product without “rewriting from scratch.”

This philosophy benefits customers by ensuring the products can easily respond to new technologies and business opportunities without facing obsolescence. Without this emphasis on “Built to Last,” customers may face a future of product discontinuations as the existing product is thrown away, and a new product is written from scratch.

Built to Grow

Once we have a robust product that doesn’t have to be rewritten every few years, we need to ensure the product architecture allows the product to grow, adding new functionality and technologies on every release. Product growth is fostered through a number of avenues. A quality foundation, mature development processes, and an investment in supporting systems are all enablers for system growth.

This philosophy benefits customers because it allows Great Plains to accelerate the inclusion of new functionality and technologies that improve the business success of customers.

Built to Leverage

The previous two philosophies have ensured a feature-rich business management system that won’t become obsolete prematurely. Each release builds on the previous release adding new functionality and technology. As functionality builds, the product becomes a true asset to the business. The product architecture needs to recognize the incredible value of this business asset and allow the business management engine to be used not only by the business management application, but also throughout the enterprise.

This philosophy benefits customers because it allows them to leverage the functionality of Dynamics not only within the traditional Dynamics application, but also in new presentations like web browsers. It also allows other applications to leverage the functionality of the business management system through technologies like COM, the Microsoft Component Object Model.

Built to Fit

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

No matter how feature-rich a business management system, each customer will have unique needs not covered in the basic software. A solid 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 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.

This philosophy benefits customers because it allows them to tailor the product to fit their needs, while maintaining their ability to grow their systems by upgrading at a reasonable price.

---

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


Until next post!

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