AuntMinnie.com is pleased to present the second installment of a three-part series contributed by Foliage Software Systems on managing and improving medical software systems.
Developing multiple products based on a centralized technology pushes the implementation of product strategy down to the engineering organization. Most organizations employing a product line approach to development have implicitly accepted the fact that the engineering group will completely define the implementation strategy.
The engineering group has often been given the responsibility of determining the areas of product commonality and variability without much management visibility into the process and without a formalized methodology to ensure an alignment of the business goals with the engineering architectural drivers. Engineering must make these determinations for both current and future products, and from these decisions, design a product architecture that will support all related products.
The trade-offs made in this environment are, by their very nature, technical. However, without strong business interaction, decisions made in the formulation of the architecture can have serious effects on some or all of the dependent products. Worse, selecting an inappropriate architectural style can essentially preclude certain product types or features from ever getting to market.
Let’s return to the case study of the equipment company with the lab and clinical measurement products. Referring back to our definition of product lines, and from our initial review of the two products, it certainly seemed that they had strong commonality of purpose. The core technology and the core functionality are identical, all consistent with our definition for a product line. Our cursory inspection seemed to confirm the strategy to utilize a product line architecture approach.
Our first action was to methodically capture the business drivers of the two products, then see how these drivers were reflected in the underlying architecture of the software systems. Using an architectural analysis technique introduced below, it quickly became apparent that while the commonality of purpose certainly existed, the unique requirements of the two different market segments dominated. The difference in the usage patterns of the two markets was so extreme as to make any single approach unworkable by the second product.
This example strongly supports the critical point that the tools available to a team will limit any engineering process. Without a thorough understanding of how to decompose products that appear similar, the danger exists that superficial similarities will mask basic differences that prohibit a given approach.
In this case study, as in others we have seen, engineering leadership created the design for the product line architecture in a rather ad hoc manner. Decisions were based on personal experience with related products, and little understanding of the actual business and market needs that should have driven the product technology strategy.
This process usually results in an architecture that can be leveraged to a fairly limited degree and that meets only a subset of the needs of all the products in the product line. Additionally, it results in large amounts of development work being pushed downstream into each individual product development effort, which precludes much of the economy of the product line, and frequently adversely affects product development productivity.
Although we’re not attempting to cover the design of an architectural approach, the decisions related to that topic will have a strong influence on the organization that will be required to develop and support the subsequent products. Depending on the needs of a specific organization, a well-designed architectural infrastructure could result in a single development group utilizing variability constructs within the system to rapidly roll out different products.
A different organization utilizing a product platform approach could charter a centralized technology group responsible for the development of general-purpose core technology. This platform can then be fed out to technology groups within various business units, with a tremendous boost to product development productivity.
How to approach product line architectures more effectively
How should product line architectures be approached? The first facet on which to focus is the process by which architectures are formulated. Until recently, the analytical methodologies used to evaluate software architectures were very limited. However, new methodologies developed to support a rigorous approach to architecture design can be very helpful when formulating software architecture.
This paper does not attempt to present a comprehensive approach for designing software architectures. We assume that readers oversee staff that, either directly or indirectly, has responsibility for the actual creation of software architectures. However, to better understand product line architectures, some understanding of the formulation process is useful. For readers who would like more detailed information on software architecture design, please refer to the white paper Using Architecture Challenges to Formulate Software Architecture, available in the technology section of our Web site.
Briefly, solid software architecture formulation is driven by what are called quality attributes and external factors. The quality attributes can be thought of as the architectural requirements in that they are broader than the well-known end-user functional requirements.
Typically, they include specific testable objectives for reliability, availability, safety, security, modifiability, extensibility, subsettability, portability, performance, conceptual integrity, and functionality. External factors include industry standards, laws of physics, and hardware capabilities, as well as computer platform limitations of data bandwidth, computational power, storage capacities, and processing latencies.
By understanding how the system requirements contribute to these quality attributes, and by allowing for the main external factors, architects can then develop the architecture by identifying the areas of dominant complexity and formulating a unifying set of organizing principles to address the solution.
Because it is expected that various medical products will have a diverse pattern of these dominant complexities, and therefore, architectural solutions, it stands to reason that no single architecture can effectively support all types of medical equipment. Any attempt to address all dominant complexities is bound to end in failure.
Looking at the variety of equipment in the medical industry, it is clear that dominant complexities contain enough variation and conflict that satisfying one means compromising another. However, it is possible to achieve a modest level of software reuse across a variety of different products. To understand the distinctions between the product line approach and other forms of software reuse, let’s restate the distinction between product line software architecture and a reusable software product platform.
The product line software architecture or framework includes:
- Software that provides architecture-specific services and utilities.
- Common software tools and technologies.
- Generic, reusable software such as data structure and user interface libraries.
- Source control, build, test, and deployment support.
- A complete set of domain-specific software components with variability mechanisms that facilitate tailoring to support unique product features.
The reusable software platform includes:
- Common software tools and technologies.
- Generic reusable software such as data structure and user interface libraries.
- Reusable domain-specific components.
In essence, the difference between the framework and the platform is the degree of reuse that is possible. With the platform, the reused software might comprise about 40% of the total software for a product.
With the product line architecture, reuse levels of up to 80% might be possible. The secret to achieving these high levels of reuse is the common product line architecture.
Without the common architectural foundation, the reusable software platform can only provide support for generic software capabilities such as hardware interfaces, data storage, and communication constructs. With the common architecture as its basis, the product line framework can also provide architecture-specific software capabilities that directly address the dominant complexities for specific types of equipment. Software elements such as control and data flow, as well as certain user interface elements, can be included in the framework, thereby reducing the work for each individual product.
Let’s revisit the examples of the diagnostic device company and the laboratory measurement company. As stated above, in both engagements the first action taken was to perform an analysis of either the proposed or the existing architectures.
The methodology followed was the Architecture Tradeoff Analysis Method (ATAM) developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh (ATAM is described in Evaluating Software Architectures: Methods and Case Studies by Clements, Kazman and Klein, Addison Wesley, Boston, 2002.)
This process, which usually takes about two weeks, effectively draws out the relationship between the business drivers and architectural decisions.
In the case of the diagnostic device company, it was found that the dominant complexities were the same. All systems were focused on a data flow of collecting samples, analyzing the data, evaluating the results, and storing them off to a database. The types of data collected and processed were obviously quite different, but the commonality of purpose overrode these complexities.
The decision was made that an effective architecture using variability constructs could encapsulate the differences from a control software perspective. Not only was the goal of a product line confirmed by the ATAM process, but the basic drivers of a solid architecture were captured in a manner that made management understanding and interaction possible.
In the case of the laboratory measurement company, the ATAM process confirmed the deep conflict inherent in the systems. Using this process and the visual depiction that results, it was also easy to communicate this to product managers and executives. Architectural trade-offs made to support the flexible-usage modes found in laboratory environments rendered high-speed operation essentially impossible. Details in the user interface design showed decisions made to support the more streamlined operation required in a clinical setting precluded flexible interaction and workflow, a trademark of laboratory environs.
After only a few days of work, it was apparent that the entire product technology strategy was flawed. Rather than a product line, we were clearly dealing with product complexities dominated by the various target segments. Refactoring the software and changing the approach made it possible to develop a very effective product platform strategy.
In this approach, basic equipment functions of both products reside in a technology package that has few, if any, application-specific features. Each product development group now uses this platform as the starting point for building an application. In this case, about 60% of the software will be shared, with the final 40% developed by the product teams, an overall savings of about 30% from two independent development efforts.
By Timothy Bowe, Charlie Alfred, and John CadiganAuntMinnie.com contributing writers
January 28, 2004
Join us tomorrow for Part III: How product line architectures fail
Foliage Software Systems architects, designs, and delivers custom software and integrated systems for the medical industry. Foliage operates development centers at its headquarters in Burlington, MA, and in Campbell, CA. The company can be contacted in Burlington at 781-993-5500, in Campbell at 408-321-8444, or on the Web at http://www.foliage.com.
Related Reading
Managing medical product line architecture strategy, January 27, 2004
Medical system migration, Part II: New target-architecture design, February 4, 2003
Medical system migration: Developing a new software architecture, February 3, 2003
Copyright © 2004 Foliage Software Systems
