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/

Comments

Post a Comment

Popular posts from this blog

DBMS: 12 Microsoft Dynamics GP: 0 error when updating to Microsoft Dynamics GP 2013 R2

Image
Hello all! It's been quite a while since I've actually written anything of remote interest to anyone who follows my blog, but at the same time, you will be pleased to know that I've been quite busy in the consulting front, with upgrades, server migrations, complex multi-instance postings involving 10's of thousands of transactions, wrapping up some Field Service Automation projects, and the list goes on and on. This time around I want to bring to the forefront, an issue I encountered updating  from Microsoft Dynamics GP 2013 SP2 to Microsoft Dynamics GP 2013 R2 plus the latest service pack. Background My client requested a server migration to a new environment where they wanted to deploy Dynamics GP 2013 R2 web client (plus the latest service pack) and upgrade their relational database management system to Microsoft SQL Server 2014. This is something I'm absolutely comfortable with (for the most part) given also that my client was sitting at Microsoft Dynamics...
Read more

Do I have to use those "Z-" currency IDs in GP?

Image
I know this seems like a trivia question, but recently I have come across a number of clients who have been using Microsoft Dynamics GP for a number of years and have been told by their former partners that they *must* use the predefined currency IDs created after adding the sample company, with no real explanation to support these claims. Case in point, my new client in Saudi Arabia, has been struggling for years to understand why they were told to prefix all currency IDs with the "Z-". So they went ahead and setup "Z-SR" for the Saudi Real. If you are familiar with Microsoft Dynamics GP and the sample company, Fabrikam, you may have noticed by now that after adding the sample company (which is not a requirement by any means), you will get a number of predefined currencies such as Z-US$ (US Dollars), Z-UK (British Pounds), Z-C$ (Canadian Dollars), Z-AUD (Australian Dollars), and so forth, accompanied by a number of exchange rate tables. If you are not familiar wi...
Read more

Microsoft Dynamics GP Scrolling Windows and Line Sequence Numbers

Image
I thought I would write about something meaningless that no one really thinks about. However, I realized that this is a compelling topic since it makes for some interesting discussion around the ability to insert line items withinin most transaction scrolling windows. Let’s take some time to understand where Line Sequence Numbers come from. A Line Sequence Number is auto generated by Dynamics GP and uses a seed value of 16,384 as a basis for the first line. Each subsequent line in the scrolling window is incremented by this number, so line number 2 would have a Line Sequence Number value of 32,768, line number 3 would have Line Sequence Number Value of 49,152, and so on. Since most GP transaction entry scrolling windows allow inserting rows in between line items, the newly inserted Line Sequence Number value is calculated as an average between the previous and the next line item sequences, i.e., if you were to insert an item in between row 1 and row 2 in the scrolling window -- keep in...
Read more