Tapping the Power of Systems Engineering

A thorough systems view facilitates adaptability to changing market conditions and enhances the adoption of seamless integration paths, leading to product development efforts that are on schedule, within budget and without latent defects. Conversely, an undisciplined systems engineering role, or the lack of one altogether, can contribute to a series of product development problems that manifest as performance issues, delays, or incapability of scaling—especially when product complexity and specialization increase. Featuring systems engineering as a central discipline can be a major step for improving effectiveness in product development efforts.

A Lack of Focus

While the medical device industry has generally embraced systems engineering as an early step in product development, many companies lose this focus as development progresses through the various engineering disciplines. When systems engineering is positioned as an important function to guide development throughout the product life cycle, however, the effect can be profound. A competent systems engineering approach is frequently the single-most important factor in product success and is often the most overlooked.

Medical device companies that succeed without a mature systems engineering process often share three characteristics:

Over time, product architecture decisions from the dominant engineering discipline become assumptions that are deeply embedded throughout the product and organization. But when market forces trigger a shift toward other engineering disciplines, problems can arise as new capabilities are thwarted by organizational culture, embedded assumptions, and past practices. For example, consider the medical device industry’s evolution from electrical to software-driven processes.

Many medical device products have fairly well-defined and homogeneous markets. Once a company releases a competitive product, subsequent versions offer add-on features and improved usability, reliability, throughput, or other attributes. Difficulties arise when market needs shift, or there is a major discontinuity in the solution space. The main determinant of a company’s ability to respond to these changes is the quality of the system architecture in its products. A patchwork design, with tightly coupled components, poor separation of concerns and functions, and inconsistent patterns of control, will be more difficult to change and much more costly to test than a system for which architecture is designed with principles of organization and operation that are well-aligned with the underlying problem.

Of course, there are also medical markets that aren’t so well-defined and homogeneous. Medical staff often use the same products in different ways and demand varying sets of controls, workflows, or reports. Consider how many different workflows and protocols are applied to imaging systems by various medical institutions. All the while, competitive products are entering the market that offer new, attractive features that threaten to erode a company’s market share if it is late in making new product introductions. Sometimes, development organizations underestimate the complexities of a product's features, encounter unexpected conflicts, or fail to see critical tradeoffs. The authors' experience shows that 60% or more of the total cost of ownership of even the best software-intensive products comes after the initial market release. When development teams make excessive compromises or create a product with a poor system design, this percentage escalates.

Frequently, market requirements are rife with risks, obstacles, and poorly defined assumptions. Requirements essential to one set of customers often clash with the requirements of others. To further complicate matters, some requirements can pose safety hazards, conflict with physical constraints, infringe on patents, or have unrealistic time frames. In organizations without effective systems engineering groups, these tradeoff decisions often fall to the project (or program) manager. People in these roles often have backgrounds that make them best suited for managing budget or schedule issues, and they may not fully comprehend the tradeoffs and risks that span other areas of expertise.

Every system architecture must change over time as new problems are uncovered and new technologies are acquired. When a new version of a product is planned, a fundamental question must be answered: Is it better to reorganize or build on top of the existing architecture? In product development, this is the ultimate “pay me now, or pay me later” challenge. In the short run, system reorganization takes some additional time and cost, but in the long run, an optimized architecture can pay huge dividends. In contrast, building on top of the existing architecture is more expedient, but it incurs technical debt. The amount of debt and its interest rate can vary depending on the suitability of the original architecture for supporting the new features.

Achieving Repeatability

To obtain successful, repeatable product development results, systems engineering must play a central role from the concept stage through deployment. The role entails decomposing the system into the optimal allocation of functionality across the various engineering disciplines. This can be a difficult transition for many companies. It is likely that certain groups or individuals have built a power base that they won’t want to relinquish.

Product development success means creating a product that responds to the market’s needs in terms of quality, cost, and timing. This means making effective product-wide tradeoff decisions, managing risks, and overcoming challenges. This process must be led by someone with customer insight, business acumen, and broad technical experience. System-wide objectives must be clearly communicated and translated for all stakeholders. In many organizations, the systems engineer is the one with the experience to fill that leadership role.

It is also important to remember that your customers have their own business problems. For them, buying products is only a means to an end. Creating value in the clinical environment requires understanding the structure, relationships, and dynamics of value chains. In addition, for any product that has multiple uses, a complex network of interconnected values will emerge. Making the most of complex and evolving systems is a central objective of systems engineering.

Modern products are the result of the interplay of many disciplines, such as electrical, chemical, mechanical, and software engineering, along with manufacturing, supply-chain management, distribution channels, field service, and product support. The time and effort required to become an expert in a single one of these areas can prohibit people from becoming an expert in more than one. Frequently, experts in one discipline undervalue the complexities and risks associated with related areas.

Good systems engineers communicate with domain experts and construct models of complex structures, interactions and dynamics, which enable them to understand key relationships, anticipate potential problems and continuously evaluate contingencies.

In less-effective organizations, customer value is translated into requirements by product marketing then handed off to engineering staff to be designed and implemented. When customer needs are translated directly into requirements, decisions often unintentionally limit the solution and sacrifice leverage. As is often said, a requirements document is as much a statement of the solution as it is of the problem.

Organizations that effectively use systems engineering involve systems engineers early in the product-planning process. They meet with customers and stakeholders, seeking to understand the root problems and product drivers. When solutions are presented, they drill beneath the surface to better understand the reasons why that solution is preferred. They also examine what will be required, in terms of investment, cost, time, and risk mitigation, to deliver this value.

System-level requirements should be clear, concise, consistent, and complete. While clear and concise requirements are relatively easy to verify atomically, consistency and completeness are systemic properties, and much harder to verify without having completed a reference system architecture to be used as an analytical baseline.

Similarly, when the systems engineer allocates system requirements to functional areas, each functional area develops its own detailed requirements, tracing each back to the system requirement that motivated it initially. If conflicts occur at the design level, the traceability between requirements and systems architecture decisions highlight the constraints, risks, and tradeoffs that must be considered to resolve these conflicts.

The value of the systems engineer does not stop with the initial design. Surprises often occur when system components don’t work as planned. For example, a key part from an external supplier might not meet specification, or a competitor could introduce a major new product that will force you to change your product for competitive reasons.

It is the system engineer’s breadth of knowledge about the system’s theory of operation, augmented by a detailed understanding of the systems requirements, that supports effective evaluation of alternative solutions. Good systems engineers use this understanding to anticipate unintended side effects.

Conclusion

Systems engineering is a powerful capability that is frequently underused by medical device organizations. Some companies suffer delays, cost overruns, and cancellations that can be attributed to a lack of systems engineering focus throughout the product development life cycle. Other companies have temporarily avoided these consequences, often by having a product that is dominated by a single engineering discipline, such as electronics or software development. This dominance, however, hampers their ability to rapidly adapt to market pressures.

Moving forward, it is quite likely that, as underlying technologies become more complex, software will become an increasingly important contributor to product value, and product interoperability and integration will also be critical. Each of these changes will only increase the need for effective systems engineering.

Charlie Alfred is principal architect at Foliage Software (Burlington, MA), Jesse Ambrosina leads the medical and life sciences practice at the company, and Tom Mariano is vice president and general manager at the firm.