The Six Principles of Systems Engineering

IBM's Rational Rules Developed Over 10-Year Period

Here's a specific example: Typical printing system architectures include a single subsystem to transform input data into the format required by the marking (imaging) engine. This subsystem normally resides in the printing system's control unit (a single locality). Early in a particular printing system's development, prototype testing revealed that there was insufficient processor, memory, and data bandwidth available to meet specified page printing targets. Based on computing technology available at the time, the only way to meet the bandwidth requirements was to spread the data transformation across three computers and manage the work division with another subsystem. In this case, a technical constraint uncovered with a prototype led to the addition of three localities, associated new connections between localities, new interfaces, and changes/additions to the logical subsystems within the printing system's control unit.

Similar technical considerations apply to many different types of products that require designers to choose where and how to implement function. Thermal constraints could well force design decisions in computers, game consoles, and the like. Geometric constraints (shape and volume) clearly affect design decisions for devices like cell phones; each new product generation has packed more function into ever smaller forms. Physical constraints (mass and density) may also require modifications in machines such as automobiles and airplanes.

Addressing these constraints and others that manifest themselves as system development proceeds is a discovery process. As design decisions are made, it is important to capture their essence, including what effects they will have on the product under development and its model-based representation.

Systems and components collaborate; so should development teams
The first three principles outlined above provide technical guidance for system development teams. They direct us to decompose the system structurally, examining it from multiple viewpoints representing significant areas of concern. They also provide mechanisms to re-integrate the system as a whole, while recognizing that specifications will certainly be discovered not just in the planning and concept stages, but also in design and construction as well. These discoveries will lead to design decisions that may affect more system elements than those contained in the view in which the specification was initially determined, leading to changes up, down, and across the architectural levels.

As systems increase in complexity, greater demands are placed on components and subcomponents. Services are grouped logically to meet both functional and supplementary demands, and the interactions between system entities must be adequately described to allow the system to meet its intended purpose. As the model moves from abstract to concrete elements, functions are allocated to software, hardware, firmware, and workers, and the collaborations between elements are finalized.

In hardware/software codevelopment efforts, collaborations between development teams take on greater importance. Many enterprises align engineers and developers by expertise; software engineers focus primarily on software system elements, hardware engineers may be aligned with functional components (an automobile's engine or chassis, for example), and so on. This alignment can lead to stovepiping; that is, narrow bands of specialized knowledge with little interaction across the bands. Although the alignment itself may be a good practice, stovepiping is not. Hence our systems engineering principle: Systems and components collaborate, and so should development teams. This often requires direct management focus, both to encourage and facilitate development team collaborations and to determine the appropriate amount of cross-domain and higher-level resources. An example of this extra management focus might be an enterprise-level systems architecture group encompassing product architectures.

Such an MDSD framework and methodology can aid management in facilitating development team collaboration, as can software tools that automate and enforce the collection and management of system development artifacts. The latter are key to capturing design decisions and provide traceability for requirements derivation and allocation across system elements.

Whenever possible, communication and collaborations should be assessed and realigned as needed to support clear, effective, and timely exchange of knowledge and artifacts. One way to do this (which has been implemented across IBM development) is to form integrated product teams composed of key product development stakeholders, and to hold regular team meetings to report status and ensure key stakeholder needs are discussed and addressed throughout the development lifecycle.

Development organizations should reflect product architectures
The previous principle of systems engineering focuses on collaborations between development teams to ensure that interactions between system elements can be fully addressed from pertinent multiple viewpoints.

The next principle is related and clarifies a best practice for optimizing collaborations and communications. It states that development organizations should reflect product architectures.

Development organizations aligned to product architectures are both efficient and effective. The alignment naturally optimizes the communication paths between development teams, and it groups specialized sets of engineers, programmers, testers, and other development personnel together to provide in-depth skills and a deep bench of resources.

Our premise is that successful enterprises with successful products likely have succeeded in this alignment, either implicitly or explicitly. However, over time, markets and products change. When the change involves important shifts in product content and function, the enterprise must react and realign to the changing product architecture. If it doesn't, the required collaborations and communications begin to suffer and lose their effectiveness.

Consider the automotive industry. Until recently, automobiles were largely composed of hardware. Engines and drivetrains, braking systems, chassis, exterior, interior, and safety features like lights, windshield wipers, and emergency brakes were key components and subcomponents. This led to development organizations with bodies of expertise in these areas. When a new product was considered, product teams were formed by picking resources from each of these areas of competency. However, currently software is assuming greater importance in automobiles and contributes heavily to new product content. As more function is implemented in software, increased collaboration and ongoing communication between product teams, hardware domains, and software engineers is needed. This change in content hopefully will be accompanied by refinements in development organization structure to properly reflect software's growing influence.

Base the lifecycle on removing risk and adding value
The above principles collectively address the three key aspects of systems engineering: systems architecture, organizational structure, and process. The three are held together by appropriate governance: program and project management, executive steering, change and configuration management, contractor and business partner management, and so on. The governance team is responsible for ensuring the highest risks are removed first and that product or program value can be measured regularly as development progresses. This leads to the final system engineering principle: Base the lifecycle on removing risk and adding value.

For complex systems, uncertainty is usually the biggest risk a program faces in the early stages of development. A second major risk area is not validating assumptions early in the development process (which may prove to be invalid when the system is in integration testing, leading to significant rework). A third risk area is committing too early to a specific implementation of hardware, software, and firmware, resulting in brittle systems that cannot be easily extended.

How is value measured? Before the methods can be determined, a prerequisite assessment is needed to determine what "value" means on a given program or product. If the measure of value is providing a system that meets stakeholder needs, one approach is to demonstrate the developing system to key stakeholders at regular intervals. This approach is included in both RUP and RUP-SE. Systems are developed iteratively, regularly increasing in capability. The development teams solicit stakeholder review and feedback with each iteration and make appropriate system adjustments in response.

These six principles and the approach they embody are intended to remove risk and provide a framework for complex hardware/software systems codevelopment

More Stories By Murray Cantor

Murray Cantor is a member of the IBM Rational CTO team, taking the lead for Governance and Systems. Cantor formerly lead the IBM Rational field services group, promoting and extending Rational best practices, and working closely with customers on innovative ways to build and deliver systems more efficiently.

More Stories By Gene Roose

Gene Roose is a senior systems engineering consultant for IBM Rational, concentrating on model-driven systems development methods. He assists clients with solution analysis and design, architectural derivation and validation, and overall project management.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.