Architect

This is probably the most commonly understood and agreed upon role within systems engineering. Typically this role is about the iterative and quantitative process of translating product stakeholder need into architectural design, including requirements definition and risk management. Long gone are the days of waterfall architecture, i.e., first detailed requirements, then architecture. Today’s architect must take a holistic view of the stakeholder needs and actively ensure alignment of the architecture to those needs while providing a level of flexibility in the architectural process that accommodates and embraces changes as a normal course of development.

Most organizations have learned the hard way that the product architectural process is not only about translating end user needs into design, but it also must account for and align the needs of all the product stakeholders. This includes not only customers, but also sales, marketing, management, development, service, quality, regulatory and manufacturing. 

Additionally, the architectural process must critically attend to elements such as:

1. Use of formal means of architectural assessment – e.g., ATAM or SAAM;
2. Effective system functional decomposition with clear allocation of requirements to each subsystem including clear interface requirements and associated data, control and sequencing flows;
3. Ensuring the system can accommodate not only happy path operation, but also error and fault conditions;
4. Effective  performance and error analysis, budgeting and allocation;
5. Support elements such as test fixtures, simulators, or emulators; and
6. Approaches for unit, component, integration, and system test and verification strategies. 

Technical Facilitator

While the baseline skills and experience required from engineers who lead systems engineering activities are typically broad, deep and embrace a wide diversity of technical knowledge, it is unrealistic to expect systems engineering to work in a vacuum.  No matter how skilled a systems engineer is, ultimately they must work collaboratively with all product realization stakeholders and players to realize the products. Systems engineers must employ active listening skills while monitoring and adjusting their verbal communication to ensure the message, not the way it is being said, is understood. Ultimately, they facilitate and resolve technical and programmatic group problem-solving and decision-making activities.

Planning and Coordination

While ultimately the project schedule is owned by the project manager and team, its structure, sets of activities and interdependencies and phasing are heavily influenced, if not driven by, the fundamental architecture of the system. For this reason, systems engineering must play a significant role in the planning and execution coordination aspects of the project. More specifically systems engineering provides the critical input for planning such elements as:

• What system components/subsystems need to be developed including simulators and emulators;
• The approach for development sprints or iterations;
• The approach for integrating and testing each component and component sets as the product is systematically developed and assembled into the final configuration;
• The approach for verification and validation activities including strategies for automation;
• How the product is to be built, assembled and tested in manufacturing including what test stands and support elements need to be developed; and
• What elements need to be developed to support servicing the product in the field. 

As with all modern development approaches, planning and ultimate execution coordination needs to be dynamic and embrace change. For this reason, systems engineering needs to be highly integrated with project management activities in order to provide the necessary technical and architectural focus to ensure effective change management and dynamic re-scoping of project activities as the issues, risks or changes occur.

Risk Management

As with any medical device product development program, risk management is a cornerstone activity that spans the complete product lifecycle. Because of the unique, holistic and system-level view provided by systems engineering, systems engineers must lead and facilitate the elements within this framework. Risk management encompasses two unique sets of activities centered on technical and programmatic risk.

Technical risk management encompasses the more traditional elements of IEC 14971, 62304 and 60601. These activities include ownership of the risk management file, driving top-down and bottom-up risk identification and mitigation activities utilizing FMEA or Fault Tree Analysis type approaches. Additionally, technical risk management includes ensuring the identified mitigation strategies and requirements are met through the architecture, development and verification activities.

Conversely, programmatic risk is about the risks associated with actual product realization. Often the role of systems engineering is to articulate the impact of technical risks as they are identified in terms of schedule or project cost. In this role, the systems engineer is the initial technical representative who works with the project manager in identifying and ultimately mitigating these risks.

Troubleshooter

Systems engineers, because of their unique knowledge of the system architecture, are typically the first line of defense as systems-level issues are identified. As issues are uncovered systems engineering’s role is to drive the issue resolution process through a combination of hands-on or group problem-solving activities. Based on past experience, I can say with certainty that the most significant product development issues typically occur at the interface layer between system components. While development teams are very adept at resolving issues within the framework of their component development activities, they often do not have the system-level perspective to take into account how changes they make can impact the overall system.

Additionally, systems engineering brings to bear not only the understanding of the internal construction of the system, but how it solves and meets the needs of all the stakeholders. Systems engineering plays a key role in supporting and providing first-level troubleshooting support for such activities as verification, validation, manufacturing pilot builds, and even clinical trials. 

Keeper of the Architectural Vision

Finally, one of the most critical roles and areas of responsibility for systems engineering is to actively ensure, throughout the entire product realization process, that all activities maintain alignment with the product architecture. Therefore, it is crucial that systems engineers participate in all design, development and testing activities. As most eloquently stated by Sarah A. Sheard, Software Productivity Consortium, “The systems engineer is the Owner of ‘Glue’ among subsystems, the seeker of issues that fall ‘in the cracks,’ the  ‘technical conscience of the program.’”