Loading field map
For the first half-century of systems engineering, the practice was document-centric. Engineers produced paper-based specifications, interface control documents, requirements lists, and design drawings. Each artifact was a static snapshot, and keeping them consistent across a large project—a missile system, an airliner, a telecommunications network—required enormous manual effort. A change in one requirement meant tracking down every downstream document and updating it by hand. Traceability was fragile, and errors multiplied as systems grew more complex. By the 1980s, practitioners recognized that the document-based approach was a bottleneck: it could not scale to the integration demands of modern systems, and it made early validation of design decisions nearly impossible.
Model-Based Systems Engineering (MBSE) emerged in the 1990s as a direct response to the limitations of document-centric practice. Its central commitment is to replace paper artifacts with a single, integrated system model that serves as the authoritative source of truth throughout the lifecycle. Instead of writing a requirements document and then separately creating a design drawing, MBSE practitioners capture requirements, structure, behavior, and parametrics in a coherent model from which multiple views can be generated automatically. The International Council on Systems Engineering (INCOSE) formally defined MBSE in 2007 as “the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.”
What does this mean in practice? A systems engineer using MBSE builds a model that connects functional flows to physical components, links requirements to test cases, and propagates changes automatically when a parameter is updated. The model becomes the single place where the system’s specification, design, and analysis live. This eliminates the manual synchronization that plagued document-centric projects. Early adopters in aerospace and defense—companies like Lockheed Martin and Boeing—reported significant reductions in integration errors and rework. Yet MBSE also introduced new challenges: modeling tools were expensive, the learning curve was steep, and organizations had to invest in training and methodology development.
MBSE needed a common language to become practical across different engineering domains. The Systems Modeling Language (SysML), first released in 2003 by the Object Management Group (OMG), provided that language. SysML is a graphical modeling language derived from the Unified Modeling Language (UML), which was originally developed for software engineering. SysML adapted UML’s notation for systems engineering by adding constructs for requirements, parametrics, and system structure while removing software-specific elements.
SysML defines nine diagram types organized into four pillars: structure (block definition diagrams, internal block diagrams, package diagrams), behavior (activity diagrams, sequence diagrams, state machine diagrams, use case diagrams), requirements (requirements diagrams), and parametrics (parametric diagrams). A practitioner uses these diagrams to build a model that captures the system from multiple perspectives while maintaining a single underlying repository. The standardization of SysML reduced fragmentation: before SysML, each MBSE tool had its own proprietary notation, making it difficult to share models across organizations or supply chains. With SysML, a model created in one tool could be understood by engineers using another, and the language itself became a common reference for methodology development.
SysML did not replace MBSE; it provided the infrastructure that made MBSE adoption scalable. The language continues to evolve—SysML v2, currently under development, aims to improve precision and usability—but its role as the de facto standard for system modeling remains central to the subfield.
Alongside MBSE, the Vee Life Cycle Model became a dominant framework for structuring systems engineering work. First formalized in the 1990s, the Vee model organizes development into a sequence of decomposition phases on the left side (from user requirements down to detailed design) and integration and verification phases on the right side (from component testing up to system validation). The “V” shape emphasizes that each level of decomposition has a corresponding level of integration and testing.
The Vee model paired naturally with MBSE because the model could serve as the thread connecting each level. A system model built during the decomposition phase could be reused during integration to verify that lower-level components satisfied higher-level requirements. However, the Vee model’s sequential structure also attracted criticism. Its rigid phase gates assumed that requirements could be fully understood upfront, an assumption that proved unrealistic for complex, novel systems. This rigidity set the stage for a lasting tension with Agile approaches.
Agile Systems Engineering emerged around 2000, borrowing principles from Agile software development. Its core practices—short iterative sprints, continuous stakeholder feedback, adaptive planning, and early delivery of working increments—directly challenged the Vee model’s sequential phases. An Agile systems engineer does not wait until all requirements are documented before beginning design; instead, the team builds a minimal viable system, tests it with users, and refines the requirements based on what is learned. This iterative cycle can conflict with MBSE’s emphasis on a comprehensive, upfront model. Practitioners have developed hybrid approaches: using MBSE to maintain a coherent system architecture while using Agile methods to manage detailed design and integration sprints.
Lean Systems Engineering, also emerging around 2000, brought a different critique. Lean focuses on eliminating waste—anything that does not add value for the customer. From a Lean perspective, MBSE’s drive to model every detail can lead to over-modeling: creating diagrams and specifications that are never used for analysis or decision-making. Lean practitioners advocate for modeling only what is necessary to answer specific questions, and they emphasize value-stream mapping to identify where modeling effort actually reduces risk. Lean and Agile often combine in practice, sharing a skepticism of heavyweight upfront processes. Together, they represent a living tension within MBSE: how much modeling is enough?
Model-Driven Engineering (MDE) developed in the software engineering community around 2000, with the goal of raising the level of abstraction in software development. MDE treats models as primary artifacts from which executable code can be generated automatically through model transformations. The key techniques—metamodeling, model transformation languages, and code generation—were pioneered in tools like Eclipse Modeling Framework (EMF).
MBSE adapted MDE’s techniques for system-level concerns. The metamodeling approach that MDE used to define domain-specific languages was applied to create SysML and other system modeling languages. Model transformation, which MDE used to generate code from platform-independent models, was repurposed in MBSE to generate analysis views, simulation inputs, or interface specifications from the system model. However, MBSE’s scope is broader than MDE’s: MDE focuses on generating software, while MBSE must integrate hardware, software, human operators, and physical processes. The relationship is one of absorption and adaptation: MBSE took MDE’s technological foundations and extended them to cross-domain system problems that MDE did not originally address.
Digital Engineering, formalized by the U.S. Department of Defense around 2010, represents the most recent major shift in the subfield. It absorbs MBSE’s core idea—using models as authoritative sources of truth—but broadens the scope in two critical ways. First, Digital Engineering replaces the single-model orthodoxy with a federated ecosystem of models. Instead of one monolithic system model, a Digital Engineering environment connects multiple models—a structural model, a performance model, a cost model, a logistics model—through digital threads that maintain traceability across the lifecycle. Second, Digital Engineering emphasizes continuous integration of data from manufacturing, operations, and sustainment, not just design and development.
This shift addresses a practical limitation of early MBSE: a single model could become unwieldy for large-scale systems, and it could not easily incorporate data from legacy tools or external simulations. Digital Engineering’s federated approach allows organizations to keep specialized models in their native tools while linking them through shared data standards. The digital thread—a linked set of data that traces a requirement from specification through design, production, and field performance—enables analysis that was impossible with document-centric or single-model approaches. Digital Engineering does not replace MBSE; it extends and recontextualizes it, making the model-based approach more flexible and lifecycle-spanning.
Today, MBSE, the Vee model, Agile, Lean, MDE, SysML, and Digital Engineering all remain active, and practitioners navigate a landscape of coexisting frameworks. There is broad agreement that models are superior to documents for managing complexity, that a common modeling language (SysML) is essential for cross-team communication, and that lifecycle integration—connecting design models to manufacturing and operations data—is the next frontier.
Disagreements center on three questions. First, single model versus federation: should an organization aim for one comprehensive model, or should it connect multiple specialized models through digital threads? The trend is toward federation, but the single-model approach still has advocates for smaller, tightly integrated systems. Second, upfront modeling versus iterative refinement: how much modeling should be done before building anything? MBSE and the Vee model lean toward upfront rigor; Agile and Lean push for just-in-time modeling. Hybrid methods that combine MBSE’s structural discipline with Agile’s flexibility are increasingly common. Third, modeling depth versus lean value: how much detail is worth capturing? Lean practitioners warn against over-modeling, while MBSE advocates argue that a sufficiently detailed model pays off during integration and sustainment. These tensions are not signs of weakness; they reflect a maturing subfield that is learning to apply model-based thinking across a wider range of contexts than its founders imagined.