AuntMinnie.com is pleased to present the final installment of a three-part series contributed by Foliage Software Systems on managing and improving medical software systems.
Invisible dependencies in the organization and the product code base will intrinsically delay product release schedules, impair performance, or even prevent shipment of one product due to software problems in another. Clearly, this is an unacceptable situation irrespective of the potential upside of cost reduction.
So, even when a decision is properly made to utilize a product line approach, there are a number of reasons why the technology strategy of product line architectures and platforms fail. Some of the more common ones are:
Attempting to leverage a constrained existing architecture
Many companies try to adapt existing software to a new product. If the existing software does not have a clean modular architecture with appropriate variability constructs, or if the new product is too different, these efforts usually achieve poor results -- longer-than- expected time to market and quality problems that shorten the potential lifetime of the existing software.
Too much variability across products
Most software isn't designed to provide the right levels of explicit support for commonality and variability. In most cases, no forethought is given to how the software could be enhanced or modified. In other cases, too much flexibility is built in to support a wide variety of related products -- making the system too complex and error-prone, and frequently leading to reliability problems.
Lack of common architectural foundations
Some companies start with the observation that there are many common features in products (for example, all product types need to collect, store, and retrieve images) and form a corporate-level group with the charter to create product platform software for use across all product divisions. Many of these efforts fail due to the lack of common software foundation -- different operating systems, different programming languages, incompatible third-party software packages, incompatible component organization, and so on.
Organizational issues and process issues
Although this article does not attempt to address these areas, they do arise frequently in the medical industry. Poor communication and coordination across product divisions, as well as inadequate software development and quality processes, can limit the potential reuse of otherwise well-designed software.
For anyone who has been in the situation where the product line strategy is failing, the signs are quite evident that most failures are due to organizational conflict. Responsibilities for different product lines almost always rest with different individuals, and often, different groups. With this pattern, it is clear that any deficiency in the core technology will have ripples that will impact diverse parts of the organization differently.
One of the most prevalent indicators is when there are clear winners and losers in the product development arena. If, for a given product, the shipment dates always slip as the core software fails to meet the expectations of the various implementation groups, it is an indication of a mismatch between products and the product technology strategy. It can be much more time-consuming to extract components from a malformed system for reuse, rather than just building them from scratch.
Less prevalent, but more visible and of greater impact, is when products become linked. When one product is showing signs of instability or is missing a feature due to a problem in a different product development effort, it may be an indicator that an inappropriate level of integration or poor partitioning of features has occurred.
Another sign that the product technology strategy is under stress is when succeeding products cannot effectively leverage the core technology. Reasons for this may be traced to too much variability between the existing and new product offerings. More commonly it is reflective of an insufficient understanding of how to identify the proper architecture for the product line.
Software variability patterns
A critical, but rather detailed, concept required for product line frameworks to succeed is that of variability patterns. While evaluating a family of products, a variability matrix must be assembled, capturing the range of variability, in terms of not only which features and functionality are required, but also, of the various features, and the priority and utility of the features.
The architects must recognize that aspects of variability can combine in important ways. First, the aspects might have an inherent conflict with each other (as flexibility and simplicity do). Second, different products in the family may have different requirements thresholds, utility curves, and priorities for these aspects. Third, the architectural approaches that can be used to address these objectives may create some new tradeoffs.
In looking at variability, it is critical to look at three aspects of the system and the design:
- Deployment context
- Commonality and variability
- Variability mechanisms
First is the deployment context or where different products will be used. Systems that are virtually identical in their fundamental features, but have different deployment contexts, can require significantly different software constructs.
An application's integration into the healthcare backbone of the hospital environment can often fundamentally alter the complexities of a testing device compared to the home market. Something as simple as changing the underlying hardware capabilities and operating system to meet a specific price point can cause real difficulties when architecting an effective solution.
Second is the requirement that a thorough analysis be performed to carefully identify all areas of commonality and variability. As we have seen above, product similarities are not always what they seem to be. Our white paper, Formulating Product Family Architectures: Techniques for Analysis & Strategy, available in the technology section of our Web site, describes in detail some approaches for performing this analysis.
The third aspect to review is the variability mechanisms required to design architecture with sufficient flexibility to perform well as the basis for all envisioned products. Take inventory of the variety of mechanisms that can be used to manage the variability in a software framework, and understand their strengths and weaknesses. Variability in product line architecture is a fine line, with either too little or too much easily setting the path for large downstream investments.
One final consideration re-emphasizes a point made in the beginning of this series. The variability matrix of products, objectives, and solution alternatives is not static. Over time the needs of products in a family evolve, and they don’t always evolve in the same direction or at the same rate. Product line architects must be aware of this evolution, comprehend the new challenges that it adds, and factor it into the architecture strategy for the product line.
As can be seen by this treatment, product line architectures and platforms have been driven into product plans by business realities. Fortunately, the evolution of software technologies can provide organizations with the tools required to meet these new realities. Product line architectures can aid product development companies as they drive to improve their efficiency in creating tomorrow’s products.
As in the past, the leap from yesterday’s to tomorrow’s techniques can be onerous, with significant risk of failure. The great benefit is that evolving your organization’s product development processes to include newly developed architectural analysis practices will allow for the implementation of stronger software system architectures that allow for rapid deployment of new products.
These days, embracing the multiplicative power of well-designed product architecture requires higher-level organizational planning than in the past. Individual products can no longer be free to invest and evolve on their own route. Product technology strategy must lead the process, clearing the path to be followed by an entire product family.
The criticality of this technology strategy is that it is the unifying vision that bridges the business and technology goals and ensures a consistent approach to the market across an entire product family. The danger of not having this vision is that development synergies will be overlooked, products will be late, and markets will be missed.
By Timothy Bowe, Charlie Alfred, and John CadiganAuntMinnie.com contributing writers
January 29, 2004
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
