Why Systems Engineering Still Struggles in Complex Systems
Systems engineering is often presented as a solved discipline. Frameworks such as INCOSE and ISO/IEC 15288 clearly define processes, phases, and expected outcomes.
However, in real-world complex systems, the challenge is not following the process. The challenge is sustaining consistency, traceability, and control of change as the system evolves.
As teams move from mission context to system analysis, then to functional analysis and logical architecture, the system grows not only in size but in interdependency. Commonalities among components emerge, components are refactored, and structures are reorganized. At this point, the difficulty is no longer conceptual—it becomes operational.
This is where most systems engineering processes begin to struggle.
Process-Based Systems Engineering (INCOSE / ISO 15288): Strong Foundations, Practical Friction
Process-driven systems engineering such as ISO 15288 provides discipline. It ensures that nothing important is skipped and that the lifecycle is covered end-to-end.
But when implemented in documentation-heavy environments such as Confluence, practical limitations appear:
a) Traceability becomes manual
b) Changes introduced at one level must be propagated across multiple artifacts
c) Refactoring (i.e., extracting common functionality into reusable structures) becomes difficult to manage
Over time, the system is still documented, but it becomes difficult to keep it coherent. The process remains intact, but the system representation begins to drift.
Documentation-Based Systems Engineering: Accessible but Fragile
Documentation-based systems engineering has a clear advantage: it works the way organizations naturally operate.
System thinking is captured in structured documents. Diagrams—whether SysML, UML, draw.io, or Mermaid—support understanding and communication. Stakeholders can review, comment, and align without needing specialized tools.
This accessibility is powerful. It enables faster reviews, broader participation, and clearer decision-making.
However, this flexibility comes at a cost. There is no inherent mechanism enforcing consistency. Traceability must be manually maintained. As the system evolves, the risk of divergence increases. What starts with good clarity gradually becomes fragmented and incoherent.
Model-Based Systems Engineering (MBSE): Structural Rigor with Practical Constraints
Model-Based Systems Engineering (MBSE) shifts the paradigm. Tools such as Capella, IBM Rhapsody, and Cameo Systems Modeler treat the model as the system itself.
This brings significant advantages. Systems engineering process structure is built in, relationships are explicit, and traceability is supported by the tools. Changes propagate structurally rather than manually. From a systems integrity perspective, this enables system components to stay coherent as the system and requirements evolve.
But MBSE tools have their own constraints. The team becomes dependent on the chosen tool and its methodology. Access is limited to users trained on those tools. More importantly, stakeholder engagement becomes difficult.
In practice, stakeholders review documents; they do not review models. As a result, models are exported into documents for review. These documents are often poorly structured for human consumption. The model remains the source of truth, but the document becomes the surface of decision-making.
This creates a practical disconnect between system engineers and stakeholders, as well as with the development team, and is widely experienced in organizations.
Hybrid Systems Engineering Approach: Documentation + MBSE Tools
Recognizing the limitation of both approaches—pure documentation-based and pure MBSE-based—another model emerges with the objective of benefiting from both: the hybrid model.
The hybrid model uses an INCOSE/ISO 15288-based process, an MBSE tool to help manage complexity, traceability, and refactoring, and documentation for reviews. The MBSE tool is used to store models and maintain relationships.
This hybrid approach follows structured processes, develops and maintains documentation for communication and reviews, and uses MBSE tools to model functional, structural, and behavioral relationships.
Using the hybrid approach, two parallel representations of the system emerge—one in the model and one in the documentation. Synchronization becomes a continuous challenge. Traceability, if not managed well, may become ambiguous. Over time, inconsistencies may appear.
At this point, a fundamental question arises: Where is the source of truth in systems engineering?
Where Systems Engineering Processes Break in Complex Systems
The systems engineering process breakdown does not happen in early phases. It happens when complexity increases. It becomes visible when:
- Requirements change and architectures evolve
- Common functionality is extracted and reused
- Architecture is refactored
Systems engineering processes need to be maintained despite these changes:
- Multiple layers must remain aligned (mission, system, function, logical architecture)
- Changes must propagate consistently across all representations
These are normal behaviors in evolving systems. And they expose the limitations of both documentation-based and hybrid approaches.
Stakeholder Reviews in MBSE vs Documentation
An important observation often overlooked is how organizations function.
Stakeholders—whether internal or external—do not operate inside MBSE tools. They review documents. They make decisions based on structured narratives, supported by diagrams and summaries.
Even in MBSE-heavy environments, the final alignment happens in documentation.
This has a critical implication:
Documents are the primary interface for human understanding and decision-making.
A Practical Hybrid Systems Engineering Direction
There may not be a perfect solution, but a practical direction is emerging. Instead of forcing a single system of truth, it is more effective to define clear roles for each medium.
System thinking lives in documentation. This includes mission context, operational scenarios, design rationale, and trade-offs. Documentation provides the narrative structure that enables understanding.
The model serves as the structural backbone. It manages relationships, enforces consistency, and handles traceability and change propagation.
The connection between the two should be controlled. Model outputs—such as views, tables, and diagrams—are exported and embedded into documentation, where they are interpreted and reviewed.
Benefits of a Hybrid Systems Engineering Approach
This approach allows teams to benefit from both worlds.
It preserves the rigor of process-driven systems engineering while leveraging the structural strengths of MBSE tools. At the same time, it maintains accessibility for stakeholders through documentation.
It does not eliminate all problems. Synchronization challenges remain. The risk of drift still exists. There is no perfect, unified source of truth.
But it aligns with how real systems are developed and reviewed.
Final Answer: Where Does Your System Actually Exist?
The debate is often framed as a choice between systems engineering, MBSE, or hybrid approaches. In reality, the more important question is:
Where does your system actually exist?
A practical answer may be:
- The system is developed and reviewed in documentation
- The system is structured in the model
- The connection between them is intentional and controlled
It is not perfect. But it is how complex systems can be made to work.
