The Evolution of Systems Engineering

Man working at largre compurter screen

The twenty-first century provides an exciting opportunity for systems engineering. New advances in our understanding of the traditional discipline continue to emerge. At the same time, new forms of systems engineering have developed to address the engineering challenges of systems-of-systems (SoS) and enterprise systems. Even at this point in their evolution, these new forms display their own principles, processes, and practices. Some are different in degree than engineering at the system level, while others are different in kind.

While it's impossible to predict how the traditional and new forms of systems engineering will evolve, however, a robust future lies ahead. Increases in technological complexity result in new challenges in architecture, networks, hardware and software engineering, and human systems integration. At the same time, the engineering scale for systems exceeds levels that could have been imagined only a short time ago. As a consequence, all forms of systems engineering will be needed to solve future engineering challenges, sometimes separately—yet increasingly—in combination.

What is Systems Engineering?

While the term systems engineering can be traced back at least to the 1940s, to this day no single, universal definition of the term exists. Frequently, systems engineering is defined by the context in which it is embedded. According to one definition of the classical practice, systems engineering is "an interdisciplinary approach to translating users' needs into the definition of a system, its architecture and design through an iterative process that results in an effective operational system. Systems engineering applies over the entire life cycle, from concept development to final disposal [1]."

Systems Engineering Life Cycle

Systems engineering models and processes usually organize themselves around the concept of a life cycle. Like the definition of systems engineering, the detailed conceptualization of life cycle is by no means unique across the communities that employ the discipline.

The International Council on Systems Engineering (INCOSE) systems engineering process is a widely recognized representation of classical systems engineering [2]. ISO/IEC 15288 [3] is an international systems engineering standard covering processes and life-cycle stages. It defines a set of processes divided into four categories: technical, project, agreement, and enterprise. Example life-cycle stages include concept, development, production, utilization, support, and retirement. The U.S. Department of Defense uses the following phases: materiel solution analysis, technology development, engineering and manufacturing development, production and deployment, and operations and support [4].

While the detailed views, implementations, and terminology used to articulate the systems engineering life cycle differ across MITRE's sponsors and customers, they all share fundamental elements, depicted in Figure 1 in the V-model [5]. This is a common graphical representation of the system engineering life cycle. The left side of the V represents concept development and the decomposition of requirements into functions and physical entities that can be architected, designed, and developed. The right side of the V represents integration of these entities (including appropriate testing to verify that they satisfy the requirements) and their ultimate transition into the field, where they are operated and maintained.

V-Model of Systems Engineering Lifecycle
V-Model of Systems Engineering Lifecycle

The model of systems engineering used in this guide is based on the "V" representation. Note, however, that the system life cycle is rarely, if ever, as linear as this simplified discussion might imply. There are often iterative cycles, skipped phases, overlapping elements, etc. Additionally, important processes and activities apply to more than one phase in a system life cycle, which are better envisioned as threading through or overarching the other building blocks. Risk identification and management is one example.

Numerous variations on the classical systems engineering life cycle can be found, including incremental or spiral developments that mitigate uncertainties in long-range requirements or funding of the system under development as well as evolutionary approaches for navigating uncertainties in enabling technology maturity.

Conditions for Effective Systems Engineering

As already noted, systems engineering is normally defined and shaped by the context or environment in which it is embedded. The classical systems engineering approach is tailored to and works best in situations in which all relevant systems engineering factors are largely under the control of or can at least be well-understood and accommodated by the systems engineering organization or the program manager. In general terms, this is when system requirements are relatively well-established, technologies are mature, there is a single or relatively homogeneous user community for whom the system is being developed, and a single individual has management and funding authority over the program. Even then, these conditions, while necessary, are rarely sufficient to ensure success. What is needed, however, are a strong government program office capable of a peer relationship with the contractor; effective architecting, including problem definition, evaluation of alternative solutions, and analysis of execution feasibility; careful attention to program management and systems engineering foundational elements; selection of an experienced, capable contractor; and effective performance-based contracting.

A Changing Landscape——Systems of Systems

With the increased emphasis on capabilities and networking, MITRE's sponsors and customers are recognizing the criticality of effective end-to-end performance of SoS to meet operational user needs. While most government acquisition policies and processes continue to focus on the development and evolution of individual systems, their requirements are increasingly based on assessments of gaps in user capabilities that require integration across individual systems to be enabled. Increasingly, the role of systems engineering is turning to the engineering of SoS to provide these capabilities.

One working definition of SoS is "a set or arrangement of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities [6]." Both individual systems and SoS are considered systems since each consists of parts, relationships, and a "whole" that is greater than the sum of the parts. However not all systems are SoS. Rather, SoS systems engineering deals with, "[the] planning, analyzing, organizing and integrating of the capabilities of a mix of existing and new development systems into an SoS capability greater than the sum of the capabilities of the constituent parts [6]." SoS may deliver capabilities by combining multiple collaborative, autonomous-yet-interacting systems. The mix of systems may include existing, partially developed, and yet-to-be-designed independent systems.

SoS can take different forms, as shown in Table 1 [7, 8]. The Global Information Grid is an example of a virtual SoS. Communities of interest are examples of a collaborative SoS. The Missile Defense Agency Ballistic Missile Defense System is an example of an acknowledged SoS, and the U.S. Army Future Combat System is an example of a directed SoS.

Table 1. Types of Systems of Systems




Virtual SoS lack a central management authority and a centrally agreed-upon-purpose for the system-of-systems. Large-scale behavior emerges——and may be desirable——but this type of SoS must rely on relatively invisible mechanisms to maintain it.


In collaborative SoS, the component systems interact more or less voluntarily to fulfill agreed upon central purposes. The Internet is a collaborative system. The Internet Engineering Task Force works out standards but has no power to enforce them. The central players collectively decide how to provide or deny service, thereby providing some means of enforcing and maintaining standards.


Acknowledged SoS have recognized objectives, a designated manager, and resources. However, the constituent systems retain their independent ownership, objectives, funding, development, and sustainment approaches. Changes in the systems are based on collaboration between the SoS and the system.


Directed SoS are those in which the integrated system-of-systems is built and managed to fulfill specific purposes. It is centrally managed during long-term operation to continue to fulfill those purposes as well as any new ones the system owners might wish to address. The component systems maintain an ability to operate independently, but their normal operational mode is subordinated to the central managed purpose.

Increasingly, MITRE sponsors and customers are facing the challenges of acknowledged SoS, defined in Table 1. This calls for capability management and SE at the SoS level while maintaining the management and technical autonomy of systems contributing to the SoS capability objectives.

A typical strategy for providing end-to-end support for new capability needs is to add functionality to assets already in the inventory. In most cases, these systems continue to be used for their original requirements. Consequently, the ownership or management of these systems remains unchanged, and they continue to evolve based on their own development and requirements processes and independent funding.

The resulting dual levels of management, objectives, and funding create management challenges for both the SoS and the systems, especially when their objectives are not well-aligned. In turn, these management challenges pose technical challenges for systems engineers, especially those working on the SoS. Table 2 summarizes differences between systems and acknowledged SoS that have particular implications for engineering SoS.

Table 2: Comparison of Systems and Systems of Systems [9, p.13]

Aspect of Environment


Acknowledged System of Systems

Management & Oversight

Stakeholder Involvement

Clearer set of stakeholders

Stakeholders at both system level and SoS levels, including system owners with competing interests and priorities. In some cases, the system stakeholder has no vested interest in the SoS; all stakeholders may not be recognized.


Aligned program management and funding

Added levels of complexity due to management and funding for both the SoS and individual systems. SoS does not have authority over all of the systems.

Operational Environment

Operational Focus

Designed and developed to meet operational objectives

Called upon to meet a set of operational objectives using systems whose objectives may or may not align with the SoS objectives



Aligned with acquisition milestones, documented requirements, program has a systems engineering plan

Added complexity due to multiple system life cycles across acquisition programs, involving legacy systems, developmental systems, new developments, and technology insertion. Typically, they have stated capability objectives upfront which may need to be translated into formal requirements

Test & Evaluation

Test and evaluation of the system is generally possible

Testing is more challenging due to the difficulty of synchronizing across multiple systems' life cycles, given the complexity of all the moving parts and potential for unintended consequences.

Engineering & Design Considerations

Boundaries & Interfaces

Focuses on boundaries and interfaces for the single system

Focus is on identifying systems that contribute to the SoS objectives and enabling the flow of data, control, and functionality across the SoS while balancing needs of the systems.

Performance & Behavior

Performance of the system to meet specified objectives

Performance across the SoS satisfies SoS user capability needs while balancing needs of the systems.

The differences summarized above lead to differences in SoS engineering. Some are differences in degree, while others are differences in kind. These are briefly outlined below. The references provide a more detailed discussion.

SoS systems engineers must be able to function in an environment where the SoS manager does not control all of the systems that impact the SoS capabilities and where the stakeholders have interests beyond the SoS objectives [9, pp. 11-12].

SoS SE must balance SoS needs with individual system needs [9, p. 12].

SoS SE planning and implementation must consider and leverage development plans of the individual systems [9, pp. 13-14].

SoS SE must address the end-to-end behavior of the ensemble of systems, addressing key issues affecting the behavior [9, pp. 14-15].

The discipline of SoS systems engineering is still in its infancy. Nevertheless, a set of SoS systems engineering principles is beginning to emerge from a U.S. Department of Defense (DoD) initiative to understand and differentiate engineering of these complex, increasingly common entities from individual systems [10]. These guiding principles are briefly noted below, and are discussed in more detail in the reference section.

Address organizational as well as technical issues when making SE trades and decisions [9, p. 21].

Acknowledge the different roles of systems engineers at the system vs. the SoS level and the relationship between the different SE approaches taken at each of the levels [9, pp. 21-22].

Conduct balanced technical management of the SoS [9, p. 22].

Use an architecture based on open systems and loose coupling [9, p. 23].

Focus on the design strategy and trade-offs when the formal SoS is first established and throughout the SoS evolution [9, p. 23].

Engineering the Enterprise [11, 12]

MITRE's sponsors, customers, and the users of the operational systems we help engineer are in the midst of a major transformation driven by and deriving largely from advances in information technology.

The rate of technical change in information processing, storage, and communications bandwidth is enormous. Expansions in other technologies (e.g., netted sensors) have been stimulated and shaped by these changes. The information revolution is reducing obstacles to interactions among people, businesses, organizations, nations, and processes that were previously separated in distance or time. Somewhat paradoxically, future events in this information abundant world are harder to predict and control with the result that our world and our role as systems engineers are becoming increasing complex.

This new complexity is a consequence of the interdependencies that arise when large numbers of systems are networked together to achieve some collaborative advantage. It is further intensified by rapid technology changes. When networked systems are each individually adapting to both technology and mission changes, then the environment for any given system or individual becomes essentially unpredictable. The combination of large-scale interdependencies and unpredictability creates an environment that is fundamentally different from that at the system or SoS level.

Examples in which this new complexity is evident include the U.S. Federal Aviation Administration's National Airspace System, the DoD's Global Information Grid, the Internal Revenue Service's Tax Systems, and the Department of Homeland Security's Secure Border Initiative's SBInet.

As a result, systems engineering success expands to include not only that of an individual system or SoS, but of the network of constantly changing systems as well. To successfully bring value to these enterprise system users requires the disciplined methods and "big picture" mindset of the classical forms of systems engineering, plus new methods and mindsets aimed at addressing the increased complexity.

Since our customers' needs are driving the trend toward collaborative advantage and adaptability, we must evolve our methods to these changing conditions. This situation is characterized by several specific characteristics:

Our customers face extremely complex problems in which stakeholders often disagree on the nature of the problems as well as the solutions (i.e., technical and social).

Their missions are changing rapidly and unpredictably——thus systems must interoperate in ways that their original developers never envisioned.

Even without a predefined direction, the systems will keep evolving and responding to changing needs and emerging opportunities—the network is inherently adaptive.

People are integral parts of the network, and their purposeful behavior will change the nature of the network—individual systems must be robust to changes in their environment.

Thus, the systems that we help engineer are facing additional, fundamentally different challenges. Nevertheless, when a system is bounded with relatively static, well-understood requirements, the classical methods of systems engineering are applicable and powerful. It is the increased complexity of problems and solutions that has caused us to extend the systems engineering discipline into a domain we call enterprise systems engineering.

What do we mean by an enterprise? Enterprise refers to a network of interdependent people, processes, and supporting technology not fully under the control of any single entity. In business literature, an enterprise frequently refers to an organization, such as a firm or government agency, and in the computer industry, it refers to any large organization that uses computers. The MITRE definition emphasizes the interdependency of individual systems and even systems of systems. We include firms, government agencies, large information-enabled organizations, and any network of entities coming together to collectively accomplish explicit or implicit goals. This includes the integration of previously separate units. The enterprise displays new behaviors that emerge from the interaction of the parts. Examples of enterprises include:

A military command and control enterprise of organizations and individuals that develop, field, and operate command and control systems, including the acquisition community and operational organizations and individuals that employ the systems.

A chain hotel in which independent hotel properties operate as agents of the hotel enterprise in providing lodging and related services, while the company provides business service infrastructure (e.g., reservation system), branding, etc.

What do we mean by enterprise systems engineering? This domain of systems engineering concentrates on managing uncertainty and interdependence in an enterprise. It encompasses and balances technical and non-technical aspects of the problem and the solution. It fits within the broad, multidisciplinary approach of systems engineering and is directed toward building effective and efficient networks of individual systems to meet the objectives of the whole enterprise.

In performing enterprise systems engineering, we engineer the enterprise and we engineer the systems that enable the enterprise. In particular, we help customers shape their enterprises, aligning technology to support goals. We support their business planning, policy-making, and investment strategies. We also determine how the individual systems in the enterprise perform and how they affect each other.

At MITRE, we consider enterprise systems engineering as a domain that focuses on complexity in the broader practice of systems engineering. It is not a replacement for classical methods and often both classical systems engineering and enterprise systems engineering approaches must be applied in combination to achieve success.

We are learning and evolving enterprise systems engineering as we are doing it. There are several basic tenets in the practice that are apparent even at this early stage of its evolution:

  • Systems thinking: Seeing wholes, interrelationships, and patterns of change.
  • Context awareness: Being mindful of the political, operational, economic, and technical influences and constraints.
  • Accepting uncertainty: Acknowledging that some problems cannot be solved by prescriptive or closed-form methods.
  • Complex systems evolution: Drawing from the fundamental principles in the sciences of evolution, ecology and adaptation, e.g., considering variety, self-organization, and selection.
  • Matching practice to the problem: Knowing when and under what circumstances to apply prescriptive methods and when to apply complex systems principles and associated practices.

References & Resources:

1 - Committee on Pre-Milestone A Systems Engineering, 2009, Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective Review and Benefits for Future Air Force Acquisition, The National Academies Press.

2 - International Council on Systems Engineering (INCOSE), INCOSE Systems Engineering Handbook.

3 - ISO/IEC 15288, 2002, Systems Engineering——System Life Cycle Processes.

4 - Department of Defense Instruction Number 5000.02, December 8, 2008, Operation of the Defense Acquisition System.

5 - Wikipedia contributors, "V-Model," Wikipedia (accessed January 13, 2010).

6 - Department of Defense, October 14, 2004, "System of Systems Engineering," Defense Acquisition Guidebook, Washington, DC.

7 - Maier, M., 1998, "Architecting Principles for Systems-of-Systems," Systems Engineering, Vol. 1, No. 4, pp 267-284.

8 - Dahmann, J. and K. Baldwin, April 7-10, 2008, "Understanding the Current State of US Defense Systems of Systems and the Implications for Systems Engineering," IEEE Systems Conference, Montreal, Canada.

9 - Office of the Undersecretary of Defense for Acquisition, Technology and Logistics (OUSD AT&L), August 2008, Systems Engineering Guide for Systems of Systems, Washington, DC.

10 - Baldwin, K., June 28, 2007, "Systems of Systems: Challenges for Systems Engineering, INCOSE SoS SE Panel.

11 - The MITRE Corporation, August 2007, Evolving Systems Engineering, Bedford, MA.

12 - Rebovich, G., Jr., April 2006, "Systems Thinking for the Enterprise: New and Emerging Perspectives," Proceedings of 2006 IEEE International Conference on Systems of Systems.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team