AuntMinnie.com is pleased to present the second of a two-part article on assessing, improving, and updating medical software systems.
By: John Cadigan, Jim Everett-Wilson, and Norm DelisleFoliage Software Systems
To understand what the target software architecture might look like, let’s look at the typical style of software architecture used for a contemporary image control system. Figure 5 shows the top-level components of the software architecture for such a system.
The typical imaging control system software architecture would benefit from a service--oriented style. In a service-oriented architecture, the primary functional components of the software are packaged as separate service implementations providing simple and well-known interfaces for use by other architectural components.
The benefit of such a style is demonstrated by the uses diagram below. A uses diagram depicts the dependencies between components in a system. By rigorously controlling the interactions between modules, the maintainability of the system is dramatically increased. Isolating the specifics of a service implementation behind a well-known interface is the key to achieving an incremental migration strategy (as discussed below).
 |
In addition to functional components, there is a special component often referred to as infrastructure. The infrastructure provides a set of common services needed by the service implementations of functional components. These services might include error and alarm handling, data and event logging, start up and shut down sequencing, and common reusable objects such as state machines, thread management mechanisms, and common user interface objects.
Additionally, the infrastructure can also include off-the-shelf middleware such as DCOM, J2EE, CORBA, or Web Services for data and event communications among the components. A rich infrastructure of common services is one of the greatest contributors to the ease of development of new functionality.
Since no single set of functional components can be expected to be the perfect partitioning for every type of medical system, how do you know that your new target architecture is a good one? The best approach is to use a formal architectural evaluation, as was done for evaluating the existing architecture. In this case, the ATAM (Architecture Tradeoff Analysis Method) process is recommended.
As shown in chart 3, ATAM is similar to SAAM (Software Architecture Analysis Method), however it is more suitable for evaluating new architectures. An ATAM evaluation includes an assessment of the quality attributes of a system that will determine its level of success -- as well as the external forces that constrain implementations that address these quality attributes. By using a formal process to uncover and enumerate these quality attributes and forces, an architect is aided in correctly identifying the dominant complexities of a system. It is these dominant complexities that should drive the central organizing principles of architecture.
The purpose of an architectural migration, as opposed to feature enhancement, is to ensure that the central organizing principles of the system do in fact continue to address the dominant complexities of a system as its requirements and environment change.
Migration approaches
Once the new target architecture is defined, a migration plan must be developed. The fundamental idea is to allow for incremental migration. If you try to replace all of the existing software components at once, you aren’t migrating; you are starting over from scratch. The incremental migration strategy is designed to reduce the short-term engineering investment, yet it provides a high return on investment over the longer term. At its core, incremental migration is a risk-mitigation strategy.
An incremental migration strategy requires a mapping from the existing software components over to the new set of software components. It is rarely the case that the mapping will be one-to-one. Typically, some existing components must be split or combined. In addition, the migration usually involves a move to new software infrastructure technologies.
Here are some of the key lessons learned from the migrations that we have performed:
- If the migration effort would require splitting up existing components, it is likely that migration will be prohibitively expensive. It is very difficult to accurately estimate the effort needed to split a large, complex, monolithic software component into a set of highly cohesive, loosely coupled components. So the risk is high too.
- A better strategy for dealing with large legacy components is to completely reengineer these components from scratch. If all of the software was architected as large complex components, then migration is not possible. If only a few legacy components are too big, then a hybrid strategy is possible: the overly complex components can be replaced and the rest of the software can be migrated.
- A rich common software infrastructure should be part of the new target architecture. Most legacy software systems lack conceptual integrity. Often, each component uses a different mechanism to implement recurring common operations or services. The infrastructure provides a single preferred mechanism for very basic capabilities such as communication and synchronization among components, error and alarm handling, data and event logging, and others.
- The lack of architectural or detailed design documentation for existing software poses a big risk for a migration effort (or any other kind of maintenance and enhancement effort). A thorough reverse engineering of poorly designed software can be prohibitively expensive.
- Training for the software staff is usually needed so that new habits and design practices will be used when working with the new architecture.
- Backward compatibility needs to be considered as part of the migration effort. For example, changes in protocols or database formats might require migration tools so that existing customer data and devices can be converted for use with the new software. If backward compatibility is not required, migration costs are typically lower.
- Generally, a software migration project adds some new features. However, most of the software requirements are basically to replicate the behaviors of the existing system. Some of these backward-compatibility decisions can reduce product appeal -- for example, a decision to retain the existing user interface paradigms might ease system acceptance by existing users, but living with the legacy paradigms can also reduce the system’s appeal to new customers.
- The most effective migration projects are performed over multiple increments. Attempts to do one big migration effort pose higher risk. Wrapping existing components with clean application programming interfaces (APIs) can facilitate incremental migration strategies. Replacing one component at a time can further reduce risk. At all times during the incremental migration, a complete operational system should exist.
- Complex software system migration requires buy-in from all the stakeholders. It is especially important to have adequate support from the current technical staff, because their detailed knowledge is critical to the success of the migration.
Return on investment
Once you have worked out some possible incremental strategies for migrating to your new architecture, a return on investment (ROI) analysis can be used to help select the optimal approach. The ROI analysis can help you trade off the pace of investment against the useful lifetime of the improved code base.
The steps leading up to the ROI analysis include the following:
- Determine whether your existing system is a good candidate for migration.
- Design one or more possible target improved architectures.
- Sketch out the sequence of steps for one or more alternative incremental migration scenarios.
On a recent migration project, our client had constraints on the first-year investment. At the same time, there was a significant backlog of enhancement and maintenance work to be performed. The overall return on the migration investment would be increased if the pace of the migration were fast because more of the enhancements would be made in the context of the new higher-productivity software base. However, a fast pace of migration would also increase the initial investment. An ROI analysis was used to help guide the selection of the migration strategy.
For this migration effort we analyzed four migration approaches: rapid and slow-paced migration, with different assumptions about how much maintenance work needed to be performed on the existing software base while the migration was in progress. Figure 6 shows the ROI for each of these approaches plotted against continued enhancement and maintenance with no migration at all.
 |
 |
ROI for alternative migration approaches
The break-even point of each of the strategies is the intersection with the "No Reengineering" curve. For this system, break-even could be achieved as fast as two years with fast migration, or at about 5 five years with slower migration. Over the lifetime of the new software base, all of the migration strategies achieved significant return, with the highest-yielding strategies producing over 60% cost savings.
The chart in figure 6 exposes a commonly held fallacy concerning software reengineering. Many medical software systems developers believe that delaying the investment in improvement or replacement of a software platform saves money. In reality, delaying that investment -- in the context of actively enhancing and maintaining the software base -- reduces the potential ROI. As described below, the reality is even worse than this chart suggests.
An existing software base has a limited useful lifetime. If it is well designed and well maintained, medical software might have a useful lifetime of as much as 10 or 15 years. However, the useful life could be as short as five years or less. There are two aspects of this lifetime:
- The number of years that the software base can be actively modified at reasonably high productivity levels: As software is maintained over the years by many different programmers, it becomes more brittle. Each programmer understands only portions of the overall software. One change is likely to break others. Every defect fix will tend to introduce more defects (actually, they tend to expose defects that were already in the code, but not yet apparent). The time needed to make a simple change gets longer and longer.
- The number of years in which the software base is the preferred platform for new product designs: Most equipment software is designed to support a family of similar products. Using a common software platform across a family of products yields huge savings in software development costs. However, the new product must be supported in the field for at least five to 10 years; so the software platform must have lots of life left when it is adopted for a new product.
So far, our ROI analysis has ignored what is perhaps the most important benefit of successful software migration: the ability to quickly respond to new product opportunities. Most medical systems support a family of related products, whether they are a POCIS (point-of-care information system), a device, or a control system.
In some cases, the software was originally designed for one specific product, but the software was enhanced as closely related product opportunities emerged. In other cases, providing a common software platform for a family of related products was one of the original design goals. No matter how you got there, the ability to quickly respond to a new market opportunity by enhancing your software base is critical.
To quantify the portion of ROI for potential new product opportunities, think back over the past couple of years and how many times you were late meeting customer commitments with major enhancements to your software. Or, how many times you had to cancel a software enhancement project because you would have missed the market window.
Most medical systems developers have been forced over and over again to leave their customer’s money on the table because they could not make needed product enhancements quickly enough. So the ROI for software migration is potentially a lot more than implied by reduced software maintenance and enhancement costs. Architecture migration will most likely enable a level of business growth that would not have been possible with the existing software base.
Therefore, it is important to make decisions about software platform investments carefully. Resist the temptation to go with instincts -- they are frequently wrong and costly. The thorough migration analysis described in this paper can be performed with a small investment -- typically just a few person-months of effort. That is a small investment that can make a big difference in the profitability and time-to-market for major product upgrades and new products.
Summary
Over the past several years, software architecture has emerged as one of the most important elements of software engineering. Good software engineers have been creating software architectures for a lot longer than that. However, there is a good chance that if your software is 10 or more years old, it no longer has a solid architectural foundation.
Experience has shown that it is frequently possible to incrementally migrate information system software to an improved architecture. There can be huge payoffs for this investment -- both in reducing ongoing maintenance and enhancement costs, and for providing a suitable software platform for new products.
Many existing software systems are good candidates for incremental migration. However, in some cases it is less costly and risky overall to replace the software base from scratch. Therefore, any migration effort must start with an evaluation of the existing software and a migration suitability assessment. We recommend that a formal architectural evaluation process, such as SAAM, be used.
Software architectures used in contemporary medical systems typically use a service-oriented style. The software is decomposed into a set of cohesive, loosely coupled software modules called services. Each service provides simple APIs for use by other services. A rich infrastructure of common facilities eases the development of new services. This service--oriented architecture serves as the typical target architecture for migration. It is the goal of the migration effort to reengineer the existing software to incrementally move to this target architecture. The new target software architecture should be evaluated formally -- we recommend the use of ATAM.
Once you know the target architecture, you can devise an incremental migration strategy. The pace of the migration should be driven by potential ROI.
There are lots of potential pitfalls for a migration effort, so a careful engineering process should be followed. The benefits of incremental software migration can be huge. You can significantly reduce software maintenance and development costs. In addition, having an improved software platform that is designed for modifiability can facilitate business growth by allowing you to quickly respond to new product opportunities.
By John Cadigan, Jim Everett-Wilson, and Norm DelisleAuntMinnie.com contributing writers
February 4, 2003
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: Developing a new software architecture, February 3, 2003
Copyright © 2003 Foliage Software Systems
