Designing and Implementing a Software Factory

Article
01/14/2009

by Mauro Regio and Jack Greenfield

Summary: In this approach to interoperability, we share the experience gathered in designing and implementing a software factory for health care systems based on the Health Level Seven (HL7) standard. We discuss the long-term vision and the scoped-down proof of concept developed so far. We also outline the challenges encountered in our project and the opportunities to widen the scope of the approach to different industries, and, in general, the opportunities to support business-to-business collaboration.

Software Factories
Factory by Template
Assigning Tasks
Broaden the Scope
Taking the Lead
About the Authors
Resources

The objective here is to share the experience gathered in designing and implementing a software factory based on Health Level Seven (HL7), a standard for interoperability among health care organizations. We started the work almost one year ago with the high-level specification of the factory, producing a first version of its schema and solution architecture (see Resources).

In its initial phase, the factory targeted the design of HL7 collaboration ports, which are systems designed to be deployed at the edge of IT systems of health care organizations, and enable health care applications to collaborate in conformance with business and technical protocols standardized in HL7 Version 3, using a Web service-based communication infrastructure.

Figure 1. The production context of an HL7 factory (Click on the picture for a larger image)

In the second phase, we implemented a first—scoped down—version of the HL7 factory specified in the first phase. The focus of this version is the subset of HL7 collaboration port capabilities necessary to enable communication among health care applications through Web service adapters, in conformance with HL7 Web service profiles (see Resources).

The full scope of the factory, as specified, also included development of enterprise application integration adapters to connect existing applications to collaboration ports and orchestration of business message exchanges realizing a particular collaboration on behalf of line-of-business applications that were not designed to collaborate.

Figure 2. The development context of an HL7 factory (Click on the picture for a larger image)

Our experience in designing and developing the HL7 factory has been valuable from two different perspectives. In developing the HL7 factory we encountered some challenges in developing the factory schema, managing the factory configuration, understanding how domain-specific languages would be used, and leveraging the tools available at the time in the development environment.

At the same time, we realized that the factory's scope could be widened from collaboration among health care applications based on HL7 to a more generic notion of collaboration among applications based on standardized (or shared) specifications.

Therefore, we are currently in the process of generalizing the approach proven in the initial implementation of the HL7 factory to design and build what we have called the business collaboration factory.

Software Factories

Software factories use specific domain knowledge, solution architectures, tools, and other reusable assets to help their users produce specific types of software solutions. A software factory is based on three key ideas: a software factory schema, a software factory template, and an extensible development environment.

A software factory configures an extensible development environment, such as Eclipse, Borland JBuilder, or Microsoft Visual Studio Team System (VSTS), using an installable package called a software factory template or guidance package. When configured in this way, the development environment becomes a specialized facility that accelerates the development of a specific type of software solution, such as a user interface or database access layer, or perhaps a whole application in a business domain like health care or homeland security. The software factory template is organized by a model called a software factory schema. The schema defines one or more viewpoints relevant to stakeholders in the production of the target software solutions. Each viewpoint defines the life-cycle artifacts produced or consumed by its stakeholders, the activities they perform against those artifacts, and the reusable assets available to support them in performing those activities.

The software factory methodology integrates model-driven development (MDD), component-based development (CBD), and agile development practices, including the use of patterns and pattern languages with models, frameworks and tools (see Resources).

To leverage models effectively for various forms of automation, software factories make heavy use of domain-specific languages (DSLs). DSL technology is much newer than most of the other technologies used in software factories, and relies on families of extensible languages. DSL development tools and frameworks have been under development for some time in academic circles, however, and have recently started to appear in commercial form (see Resources).

The HL7 factory automates the development of systems called collaboration ports, which enable interoperation among systems in the health care domain. Specifically, the solutions produced by the factory aim to:

Realize interactions defined by the HL7 standard as information exchanges that take place between application roles in response to trigger events. Collectively, these exchanges support the business goals of a specific use case, such as performing a laboratory observation. The factory automates the production of code that implements these interactions by mining information contained in the HL7 Reference Information Model (HL7 RIM).
Enable application-to-application business collaboration expressed in terms of these interactions over an open standards-based Web service infrastructure that is conformant to a subset of the HL7 V3 Web service profiles, namely the Basic, Addressing, Security, and Reliable Messaging topics (see Resources).
Enable integration of new or existing applications that were not designed: 1) for HL7, version 3; 2) to fulfill a business collaboration; and 3) to communicate over a Web service infrastructure.

Figure 3. System production viewpoint (Click on the picture for a larger image)

It is important to understand the HL7 factory from two different perspectives: production and development. In the production context the factory end products are HL7 collaboration ports. These ports automatically enable disparate health care applications to collaborate behind and across the firewall using Web services, provided that at least one of the applications participating in the business collaboration will deploy an HL7 collaboration port; the other applications may participate through other means, and all of the applications participating in the business collaboration will conform to HL7 V3 standards for message exchange, either natively, or with the help of an HL7collaboration port.

Factory by Template

For a business collaboration between a hospital and a laboratory system, Figure 1 shows where HL7 collaboration ports sit in relation to the systems hosting the interoperating applications. Note that collaboration ports are meant to be highly configurable to enable general dispatching, while also allowing complex message-flow orchestration. Thus, ports like those shown in Figure 1 are configured both in terms of the technical details for a specific implementation and deployment and in terms of HL7 domain definitions and conformance levels.

Figure 4. Software contract design viewpoint (Click on the picture for a larger image)

In the context of development, the purpose of the software factory is to accelerate the specification and implementation of collaboration ports. The factory combines problem domain knowledge supplied by the HL7 Reference Information Model and Web service pro- files, with knowledge of the platform technology, solution architecture, and development process supplied by platform documentation and by the factory developers (see Figure 2).

As suggested by the illustration, this knowledge is packaged into numerous assets, which collectively form the factory template. Simply stated, the factory template provides everything required to build an HL7 collaboration port, including reference data and artifacts, such as message schemas; tools, such as adapters generators; and process guidance. The factory template must be installed into an integrated development environment (IDE), namely Microsoft Visual Studio 2005 Team System, before it can be used to produce and deploy HL7 collaboration ports.

As noted previously, the purpose here is to describe what we learned in specifying, designing, and implementing the HL7 factory. We have grouped the information into two categories. The first classifies lessons learned about factory development and usage in general; the second contains insights gained regarding the target domain and with how the factory might be generalized to address a broader set of target domains.

The development and management of the factory schema were the most significant challenges from the inception of the project through to its completion. Producing an initial version of the schema was relatively easy (see Resources). A grid-based approach can be effectively used in this phase, organizing relevant viewpoints into a two-dimensional matrix with level of abstraction on the vertical axis and life-cycle phase on the horizontal axis.

However, we quickly realized that the two-dimensional matrix was a fairly inadequate representation of the schema, especially for the fully scoped version of the factory because a) the schema was naturally multidimensional, b) a matrix representation does not capture relationships among nonadjacent viewpoints, and c) the graphs of viewpoints were of different types and depths and unfold into nested graphs of different types and depths.

Figure 5. The Configuration wizard's use case selection (Click on the picture for a larger image)

Nonetheless, working with an amorphous, graph-based representation of the schema required tools that were not available. Therefore, we implemented the factory schema as a set of two-dimensional projections of the relevant viewpoints. Each of these projections—a graph in its own right—details a specific aspect of the factory, effectively projecting it from the multidimensional schema in the same way that a set of tuples is projected from a multidimensional data store to form a two-dimensional view.

For example, Figures 3 and 4 show two viewpoint examples, namely the System Development viewpoint and one particular aspect of it: the Software Contract Design—at a lower abstraction level.

Assigning Tasks

This approach allowed us to produce a version of the factory schema that we deemed complete, that is, it comprehensively specified all the artifacts and tools required in the factory template to produce the products of the factory. However, it left verification of the schema to human inspection and did not allow us to use the schema as metadata to drive the user experience within the IDE.

Configuration management was another challenging aspect of factory development, from two different perspectives.

First, we had to create a configuration XML schema, which would be complete in terms of allowing the expression of all valid combinations of supported features and/or implementation strategies. The XML schema was handcrafted and quickly became a maintenance burden, as it was highly sensitive to changes in the factory schema and template. Second, we had no tools within the target development environment to support the configuration of a specific instance of the factory, or the validation of such a configuration, during product development.

Specification of the product development process was also a challenge in developing the factory. We had no satisfactory way to formally express the process in the factory template, and most importantly no way to inject the process as prescriptive guidance into the development environment.

Although the target development environment did support the creation of tasks, and the assignment of tasks to members of the development team, we had to rely on natural language documents to describe the development process because we had not yet determined how to apply the task-management features to a factory-based, product-development process. In particular, we had not yet determined how to associate tasks with specific assets supplied by the factory template, how to load the tasks from the factory template, or how to configure the tasks for a specific product.

We also found it quite hard to decide whether or not to provide a fully fledged domain-specific language (DSL) for the requirements- gathering phase of product development, especially given that Microsoft has published a set of DSL tools under the umbrella of its Software Factories Initiative.

We knew that a full DSL was not strictly necessary because the relevant use case specifications were already available to us in the HL7 repository. What we really needed was a sophisticated wizard that would help the user choose specific use cases (see Figure 5), application roles, service-interaction patterns (see Figure 6), and other standard data elements and navigate through the repository.

Also, the DSL designer technology from Microsoft was very immature when we started the project, and adopting it would have added significant risk to the project. Although we knew we were missing out on the opportunity to provide more sophisticated automation, and that the alternative—a wizard-based user interface—would be not relevant outside the scope of the factory, we decided not to use the DSL technology in this phase of the project.

Given that we now have a much more consolidated and robust technology preview of DSL tools, we may start to experiment with DSLs in subsequent versions of the factory. Also, even if we did decide to create another wizard-based user interface, we would very likely design and implement it using the DSL tools, instead of developing it from scratch.

The Guidance Automation Toolkit (GAT), another piece of enabling technology under the umbrella of the Software Factories Initiative at Microsoft, proved quite useful.

Simply stated, GAT is an extension to the development environment that makes it easy to create rich, integrated user experiences around reusable assets like frameworks, components, and patterns. The resulting guidance packages are composed of templates, wizards, and recipes, which help users build solutions in keeping with predefined architectural guidance.

Broaden the Scope

In our project, we used GAT as the means of packaging and delivering the factory template. It provided an underlying model for the template that was much richer than what the development environment itself had to offer.

Recipes have been provided for activities like HL7 Web Services Adapter creation, execution of the configuration wizard, creation of Web services contracts, and automation of the code-creation process.

Figure 6. The Configuration wizard's service-interaction patterns specification (Click on the picture for a larger image)

Unfortunately, the GAT learning curve is quite steep. Its flexibility and customization options are limited and its integration with the IDE could have been better. Nevertheless, we believe that GAT adoption was a key decision that helped ensure project success and significantly reduced the factory development time.

Although we developed the factory to enable business-to-business collaboration among health care applications, it quickly became evident that we could apply such a factory to similar scenarios in other industries. We came to understand that the real scope of the factory should be business collaboration in general, using standardized or predefined specifications of interactions, application roles, events, Web service profiles, and other domain elements, not just business collaboration in the context of HL7.

In retrospect, the reason we initially developed such a factory for HL7 was that the HL7 standard provided a complete set of easily accessible and well-defined domain elements. Of course, many other standards organizations, such as RosettaNet and UNCEFACT have also invested a great deal of effort in specifying domain elements to be used by businesses that want to collaborate using standardized protocols. Interestingly enough, as far as the collaboration protocols and the information they exchange are concerned, these standards look very much alike.

We therefore concluded that it would be feasible not only to build standards-based collaboration systems for other industries, but also to build a collaboration port factory that can be customized using business collaboration specifications for other industries. Of course, there will be a need for various import mechanisms, adapters, and model conversions to work with the different concepts used to describe business-to-business collaboration by different standards bodies. Nevertheless, we think a generic specification could be used to bridge these differences through configuration in a generic business-collaboration factory.

At the same time, we recognize that a more generic factory may also be quite appealing to corporate developers constructing business- collaboration systems inside the firewall, and who want a more formal approach to specifying and implementing those systems to guarantee better alignment between business goals and a portfolio of resulting IT services. However, in this case we would need to provide enterprise architects with the models and tools necessary to support the specification process.

We realize that our factory must support the construction of collaboration ports for various technology platforms. We suspect that this could be accomplished using implementation patterns provided with the factory template to decouple the specification of the collaboration ports from platform-specific implementation details.

Taking the Lead

Our plans are to exploit the opportunity described here to generalize the HL7 factory to form a business-collaboration factory. We think most of the work required to achieve this generalization will reside in these areas:

Provide models and tools to support the specification of business collaborations, focusing on information schema, business document/ messages exchange protocols, and possibly business transactions.
Define mappings between relevant industry standards and our internal model of business collaboration, and possibly tools for importing the domain elements they define.
Introduce another level of configuration in the implementation of the collaboration port that will enable factory users to target a wider variety of technology platforms.

Our experience in developing a factory for HL7 collaboration ports has shown that we need to define better frameworks, tools, and processes to specify the factory schema, to manage factory configuration in a flexible and extensible way, and to better understand how and when domain-specific languages should be used. At the same time, initial implementations of extension mechanisms like GAT and DSL have proven their value, filling significant gaps in software factory infrastructure, and pointing to future innovation in that area.

We intend to continue to use and improve these tools in the next version of the HL7 Factory, as well as in the more generic, cross industry, version called the business-collaboration factory.

About the Authors

Mauro Regio is an industry solutions architect in Microsoft's developer and partner evangelism architecture strategy team, focusing on large-scale enterprise integration projects and software factories.

Jack Greenfield is software architect, enterprise tools, Microsoft.

Resources

"A Software Factory Approach to HL7 Version 3 Solutions,"
Mauro Regio, Jack Greenfield, and Bernie Thuman (June 2005)

Domain-Specific Modeling with MetaEdit+

Health Level Seven

"Advanced Web Service Profiles," Roberto Ruggeri et al.

Institute for Software Integrated Systems
"Model-Integrated Computing"

MSDN
Visual Studio Team System Developer Center
Microsoft Enterprise Framework and Tools Group
"Domain-Specific Language (DSL) Tools"

Microsoft Patterns and Practices Team
"Guidance Automation Toolkit (GAT)"

Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, Jack Greenfield et al. (Wiley, 2004)

"Web Services Enablement for Healthcare HL7 Applications: Web Services Basic Profile Reference Implementation," Mauro Regio (August 2005)

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.