AuntMinnie.com is pleased to present Part I of a three-part series contributed by Foliage Software Systems on managing and improving medical software systems.
Whether the product is an imaging system with different capabilities intended for large hospitals, small hospitals, and physicians' offices, or a medical device targeted at office and in-home markets, the pressure to more effectively develop product lines is increasing.
Coupled with these market pressures are the financial realities associated with the process of developing complex products. Companies are looking to regain control of software development costs and increase the speed with which new software-based products can be introduced to the marketplace.
In order to meet these dynamics, companies have been stepping back to re-evaluate their overall product development strategies. While the concept of product line architectures has been in existence for some time, its increased importance over the past few years has made it the recipient of significant attention.
Historically, creation of the development strategies for product lines has been left to engineering departments, often resulting in strategies that are not always optimized for business efficiency. If proper analysis of the products is not performed before a development effort begins in earnest, the very real likelihood exists that the product line architecture will fail, with the result of a large impact in schedule and costs, with enormous lost opportunity.
In this series, we discuss the development of product line architectures from the perspective of executives and managers. We look at what does and does not constitute a product line, and we show how ineffectively executing a product line architecture strategy can have serious and long-term ramifications for the organization.
We also explore new techniques, with solid academic underpinnings, that have recently been developed to bring more control over the architecture design process. These techniques permit a more rigorous approach to the creation of product line architectures, resulting in significant improvements in efficiencies and a commensurate drop in development risk.
Software is a major investment for medical equipment companies. The development of a new software-based product can easily represent an investment of 10-20 person-years or more. With this level of investment, the product technology strategy of software development must specifically address two distinct business realities:
- Software systems for single product lines must achieve a long life in order to generate a sufficient return on investment and meet customer expectations. These systems must support thousands of changes over a product’s lifetime.
- Software systems must also support the development of a family of similar products and must support accelerated movement into related product niches.
While the two problems are different, the solution many medical product developers are adopting is one of product line architectures. In some cases, this strategy has worked fairly well. However, most organizations find that software issues continue to emerge as the major bottleneck that impedes the timely delivery of new products to market.
The main reason for these problems is that the software continues to be stressed beyond its capacity to accommodate change. In most cases, the software was never designed to support a wide range of product features or product types. In others, an attempt was made to design the software with these needs in mind, but the processes were not in place to ensure the result.
Two of our recent engagements serve as good case studies for the pitfalls associated with the development of product line architectures and some of the different approaches to overcoming them.
In the first example, the client was a supplier of a family of diagnostic devices. Over the previous few years, the product line had grown, mainly through acquisition, to the point that supporting the variety of software platforms had become an operational challenge.
A corporate decision was made to develop core software architecture for both existing and anticipated products. The objective for the next-generation control software was to provide a flexible basis for the development of a product line, which was to extend from the hospital to medical offices and then into the in-home environment.
The second example is an equipment company that had developed a sophisticated laboratory measurement system. Over a six-year period, working with their research customers, the engineering staff had evolved a software system with tremendous flexibility for the research user.
As the uses of the technology were demonstrated, the market for an automated product grew. Since these products had similar underlying capabilities, the decision was made to evolve the control software into product line architecture. By grafting new features onto the old laboratory platform, both products were to be supported from the single code base.
Very quickly, the conflicts between the needs of the two products became apparent. The flexibility designed into the laboratory system made the clinical system very cumbersome to use and too slow. The requirements to limit the capabilities of the clinical system made the laboratory system too constrained.
Rather than having a synergistic relationship, both products struggled to gain acceptance. After two frustrating years, a decision was made to separate the products into two independent code bases and to develop them separately, albeit very redundantly.
In both of these cases, we were engaged to create a practical product technology strategy, based on an effective product line architecture, which would provide the anticipated benefits of a shared technology base.
What are product line architectures and product platforms?
Before continuing, it is useful to provide a working definition of a product family, a product line, and a product suite:
A product family is a set of related products, manufactured by a single organization, with commonalities in purpose and target market segment.
An important goal of any product family is to gain operating leverage by exploiting inherent commonalities among the products in the family. In other words, costly technical resources are better utilized by avoiding the duplication of efforts across many products. This focusing of effort can help improve quality and shorten time to market for the individual products, as well as reduce product support and upgrade costs throughout the product life cycle.
A product line is a product family where the commonality of purpose is dominant.
A patient monitoring product line would be one example. Patient monitors have a range of features that lend themselves easily to the product line architecture development approach. All of the differences between a high-end system for an ICU or surgical ICU in a large hospital and a low-end ambulatory monitor are essentially contained in a single feature set.
Both products may monitor noninvasive blood pressure (NIBP) and ECG, but, for example, only the high-end monitor requires systemic venous oxygen saturation (SVO2) monitoring. By utilizing product line architecture, the same underlying software, properly envisioned and constructed, can support all related products in the product line.
A product suite is a product family wherein each product in the suite satisfies the needs of a different application (i.e. market segment), and typically interoperates in some way to create additional value for one or more market segments.
Keeping with our patient-monitoring example, this occurs when a related analytical system such as a cardiac catheterization lab hemodynamic analysis and monitoring product is required to augment a patient monitoring product line. These systems share many of the same monitoring system requirements such as ECG and invasive pressure monitoring, but differ significantly in their target market and use model.
Patient monitors are typically used in a hospital’s monitoring unit, where they are configured and left unattended. The catheterization lab monitoring and analysis product, however, is used interactively during a cardiac catheterization diagnostic procedure to monitor, acquire, and analyze information.
Due to the stresses of different market focuses, product suites should be supported by product platforms, not product line architectures. A product platform is an assembly of software modules developed to address the generic needs of a product suite, but does not necessarily meet any of the product-specific requirements.
In the above example, potential platform modules that would be leveraged across a patient monitoring product line and an example of a catheterization lab monitoring and analysis product would be ECG processing, such as signal acquisition, filtering, lead transformation, and heart rate calculation. The same is true of invasive pressure processing to acquire, filter, and calculate systolic and diastolic numbers.
Clearly there are economies to be gained in the reuse or leveraging of components across the patient monitoring product line and the catheterization lab monitoring and analysis product. However, because of the different focuses of the products, the latter would likely require its own architecture.
Why are product line architectures becoming more common?
The concept of product line architectures is not new, so why is it now the focus of such attention? The answer may not be what you expect. Often, technology advances are excoriated as driven by technology itself. Engineers find new ways to do the same old thing. Technology fads are identified as they work their way through industry after industry. However, product line architectures represent a step forward in technology process.
As is the case in virtually every step forward in technology process, the improvement is mostly driven by business need. Just as with previous technology process revolutions, such as object-oriented software development (driven by the need to increase productivity in the development of larger, more complex systems) and capability maturity model processes (driven by the need to have the repeatable delivery of high-quality software products), the impetus to evolve product line architecture processes is driven by business needs.
Markets in general -- and the medical equipment industry specifically -- continue to evolve rapidly and, as a result, new product niches emerge that must be addressed quickly. Technological changes have moved sophisticated equipment outside of its original environment, from hospitals to the physician’s office, and now the move to the in-home market is accelerating. Developing a product line with a single underlying code base that can effectively address disparate needs and allow a dynamic reaction to new business opportunities can obviously have enormous pay-offs.
The rapidly changing medical industry has also led to substantial consolidation through mergers and acquisitions. Organizations regularly inherit new product lines, and they need to quickly integrate these lines into an existing corporate product portfolio. To effectively execute this integration, it is vital to have a sound technology strategy. The lack of a clear integration strategy will lead to a decrease in operational efficiency and an undermining of the value of both the developed and acquired product lines.
Another, not insignificant, business driver is the cost of development and support of software for medical equipment. By limiting the amount of code written, and simplifying its extension to new products and markets, properly implementing a product line approach to software can result in development savings of 50% or more over a line of several products.
By Timothy Bowe, Charlie Alfred, and John CadiganAuntMinnie.com contributing writers
January 27, 2004
Join us tomorrow for Part II: Effective approaches for product line architectures
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
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
