Dr. Dobb's Journal October 2006
Sage is a supplier of business management software and services to both small and midmarket businesses. Within the Sage Small Business Division, we have a number of product development teams, each of which develops a number of applications targeting common business processes—accounts, payroll, and the like.
In the past, each of these development teams had full responsibility for the entire development model of its application—from the underlying database and development framework/tools, to the user-interface design. A number of components were shared among the teams, but these were typically limited to simple user-interface controls.
Two problems arose from this development model. For one thing, there was duplication within the product teams throughout the various layers of the application architectures. A second problem was that, from a company and branding point of view, each time we released a new or updated application, we would typically update the UI to match the style of the moment; for example Office 2000, Windows XP, Office 2003. This meant that the applications being released at a later date would have to play catch-up with the UI of the last released application. This could then involve a significant amount of reengineering work within each application, depending on the development tools and technology used within the application, and the architecture of the application.
These two problems were absorbing a significant amount of the development teams' time—time that could be more profitably spent on core feature development. Consequently, the Sage Small Business Platform team was put in place to develop common frameworks, components, and services that could be reused within the various product development teams.
The primary purpose of this team is to limit the amount of duplication that occurs within the product teams, thus allowing the product teams to focus entirely on the business process requirements of their applications. In addition, the Platform Team provides a consistent development framework for the product teams that will eventually cover all aspects of an application development framework, including:
Of course, if we had the luxury of being able to reengineer all applications from scratch, we could define a development framework that would satisfy the architectural requirements of all Sage Small Business applications. However, in a commercial environment, this isn't always possible because of:
Our challenge was to develop a framework that would eventually satisfy all existing product development requirements, while being extensible enough to support future requirements. Furthermore, the framework had to be suitable for incremental implementation due to the factors listed earlier.
In short, the key requirements that the Sage Small Business Development Framework had to meet included:
Recall that our first challenge was to implement a development framework that could host applications and provide access to common services and components.
One of the key decisions behind the development of this framework concerned the choice of technology. The technology selected had to support the variety of development tools and technologies used with each of the product teams. At the start of development, Microsoft .NET was discounted for a number of reasons, including the need to provide effective support for earlier Microsoft operating systems such as Windows 98. Moreover, shipping .NET with the existing applications was perceived as adding an unacceptable risk for applications that commonly ship in quantities of tens of thousands in the first few days of availability.
Therefore, the decision was made to develop the framework based around COM interfaces because this is a widely supported technology in the software industry, and it is supported by the development tools used by the product teams. An additional advantage of using COM is that the product teams would then be developing against an abstract object model, which would let us (if the need arose) change the underlying implementation of any shared service without requiring the product teams to reengineer any of their existing code.
With this in mind, the first step was to define the application hosting interfaces, including the interfaces that provide the hosted applications with access to the shared services and components. Once these interfaces were defined, we could then develop the infrastructure components that would host the registered applications and services, and provide the hosted applications with access to the registered services.
These components were developed using Microsoft Active Template Library (ATL). The reasoning behind choosing ATL as the implementation technology for these components was that we required a lightweight framework for implementing and exploiting COM components. ATL was developed for those exact reasons and was, therefore, the ideal choice.
Once these infrastructure components were developed, we moved on to developing the shared services for the hosted applications.
The first service to be developed was the User Interface Service (known as the "Sage Small Business Desktop"). This service would provide the front-end UI for the applications. This service was selected for early development for these reasons:
The first step to implementing the User Interface Service was to define an abstract model that applications could use to describe their integration into the Sage Small Business Desktop. The term "integration into the Sage Desktop" defines how an application registers its UI commands; for example, a "Customer Record" command can be registered that lets an end user invoke the Customer Record Form in the Business Accounts application.
The next step was for the hosted applications to hint as to how these commands are grouped and presented to the end user; for example, menu options, buttons in a toolbar, buttons in a stacked toolbar, and web links.
In the initial implementation of the Sage Small Business Desktop User Interface Service, these command-presentation hints map to the visible UI elements exactly (menus, toolbars, stacked toolbars). But in a later implementation these could change dramatically, depending on the style of the leading UIs at that time. This could again be accomplished transparently to the hosted applications, as the application communicates through the abstract User Interface Service interface.
Once we defined the interface to the UI Service, we then needed to begin the actual implementation of the User Interface for the Sage Desktop. Again, the choice of .NET was removed from the equation, so we needed to look at other development tools and technologies for implementing the UI.
Many influences had to be taken into account with regard to the development tools and technologies that we would use for implementing the User Interface Service, including the footprint, cost, support for COM, and availability of compatible third-party UI components.
We removed Visual Basic from the equation early on, because of its footprint and the amount of overhead and inflexibility caused by using Active X controls. Because most of the software developers within Sage are C++ professionals, the two choices at the forefront of the list were MFC and the native Windows API.
The choice was determined mainly by:
After a period of investigation into third-party UI components, we settled on CodeJock User Interface controls (www .codejock.com). We found that the CodeJock controls provided a modern-looking UI and included lots of features we required within the User Interface Service. They were developed in MFC, which we were proficient in, so they became our primary choice.
A number of important factors had to be taken into account before we could commit to using the CodeJock controls, including stability, support (for bug fixes and Knowledgebase articles), functionality, ease of use, flexibility, and availability of source code.
To satisfy our concerns before committing to the CodeJock controls, we developed a number of test applications to ensure that they would be satisfactory. From the initial tests, we were sure that the CodeJock controls were the right choice: They provided enough functionality to meet our UI requirements, they provided a modern-looking UI, and they were stable enough for commercial development.
An added benefit was that we could also gain access to the source code, so that if we did find any problems, we could trace the problems to find workarounds, or to at least identify if the problem was in our code or the CodeJock code. Over a six-month development period, we were extremely pleased that we did not find a single problem with the CodeJock controls. Access to the source code still proves to be invaluable though, when we need to extend a few of their controls to provide additional functionality.
DDJ