Ever wanted to understand (like in really understand) why Dexterity? or what are the reasons for a dictionary-based architecture? Ever wanted to gain an insight (as in real insight) on the philosophical principles behind Microsoft Dynamics GP? Well, I pulled out all the stops for this and went to the guy who drafted it all up and architected most of it.

Back in 1997, I was first introduced to Tim Brookins at the Certified Installation Specialists Conference held in Fargo, North Dakota. Tim presented an opening session describing the Microsoft Dynamics GP…

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…

My good friend and co-presenter, the Dynamics GP Blogster himself, Mariano Gomez has managed to organise a fantastic series of posts about the architecture of Microsoft Dynamics GP

He is working with Tim Brookins (the father…

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

Unfortunately and due to Tim's various commitments, it was not possible to have him provide his final insight on the white paper reproduced on this blog. I will continue to work behind the scenes to bring this information to you as it becomes available.

For now, I leave you with a review of Tim's background and accomplishments.

---

About Tim Brookins

Tim Brookins is a Distinguished Engineer working in the Microsoft Entertainment & Devices Division.

Tim joined Microsoft in 2001 as…

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…

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…

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…

"GP DPS and DPM Can Be Useful Tools"

I just managed to finalize my new article on "Dynamics GP…

A lot of people have been using Microsoft Dynamics GP (formerly Microsoft Business…

Microsoft Dynamics GP 2010 Architecture Whitepaper is now available for download from Microsoft Download Center. Architecture is something dear to my heart so please be sure to download this document and read up. The document discusses the following topics:

• The structure of the Microsoft Dynamics GP application, which is composed of the Dexterity runtime engine, the Dynamics application dictionary, and the Microsoft SQL Server database.


• How Microsoft Dynamics GP efficiently uses system resources for both client workstations and servers.


• The customization tools that are built into the software and are accessible to all users,…