Complexity in New Systems Engineering: What Do We Mean

Complexity in New Systems Engineering: What Do We Mean
Introduction
Every engineer faces complexity, yet few stop to ask what the word really means. At first glance, it seems to describe anything with many parts. A modern car has thousands of components, millions of lines of software code, and countless requirements—so we call it complicated. But simply counting parts does not capture the full picture.
True system depth is different from size. It is different from difficulty. Instead, it is about relationships. When parts interact in ways that create new, sometimes unpredictable, results, the system shows emergent behavior. This idea is not limited to engineering. Human organizations, financial markets, and even ecosystems all reflect this kind of interaction.
For the automotive engineer, interconnectedness is no longer a background condition. It defines the very nature of the work. Whether developing advanced driver assistance, designing electrical architectures, or writing safety requirements, these layers of interaction shape every decision. To understand them, we must start at the very basics: how this state differs from simple complication, the forms it takes, and the ways it can be created, measured, or contained.
Complexity vs. Complication
At the most basic level, people often confuse complexity with complication. The two words sound similar, but they mean very different things.
A complicated system has many parts, but those parts still behave in predictable ways. A mechanical watch, for example, contains hundreds of tiny gears and springs. If you understand the design, you can eventually explain how the watch works and why it keeps time. Complication requires effort to solve, but with enough time and knowledge, the outcome becomes clear.
In contrast, a complex system created of interconnected parts that influence each other in unpredictable ways. The relationships between elements matter more than the elements themselves. Traffic is a simple example: each driver makes individual decisions, but the flow of cars produces patterns that no single driver controls. The whole system shows behaviors that are not visible in the parts alone.
Therefore, engineers increasingly rely on virtual models to explore these emergent patterns, because simulations reveal system behaviors that individual parts alone do not explain.
This distinction matters in engineering. A wiring harness in a vehicle is complicated: it contains thousands of wires and connectors, but the outcome can be calculated with careful design rules. By comparison, an Advanced Driver Assistance System (ADAS) is highly interdependent: cameras, radar, software, and driver inputs interact in ways that create new, sometimes unexpected, behaviors.
In short, complication can be solved; system interdependence must be managed. This is the starting point for understanding why modern systems, and modern vehicles in particular, require both philosophy and discipline to handle their growing challenges.
Forms of Complexity
Complexity shows itself in more than one way. To understand it, we can separate it into a few basic forms. Each form highlights a different reason why a system becomes hard to predict or control.
Structural complexity comes from the number of parts and connections. The more components and interfaces a system has, the more opportunities for unexpected interactions. In vehicles, this appears in large wiring harnesses, multi-layer printed circuit boards, or electrical architectures with hundreds of electronic control units.
Functional complexity comes from the logic of how different parts work together. It is not about the number of components, but about the rules that link them. For example, lane-keeping assistance depends on steering sensors, camera data, map information, and driver input. Each rule connecting these signals adds new branches of behavior.
Organizational complexity arises when people and teams interact. Every project includes multiple stakeholders—engineers, managers, suppliers, regulators. Each brings their own priorities, which can pull the system in different directions. A simple software update may pass through cybersecurity, legal, and quality approval before release.
Dynamic complexity shows up when conditions change over time. A system may behave one way in steady operation but act differently under stress or over long use. Electric vehicle battery systems, for example, must perform in both hot and cold climates, under high load, and after years of wear.
Each form of complexity adds a layer. When combined, they create systems that cannot be reduced to one simple model. Recognizing these forms helps us see where complexity originates and how it might be shaped, rather than left unmanaged.
Creating a Multifunctional Assembly
Intricate systems do not always appear by accident. Often, we create them. Sometimes this creation is necessary and intentional. At other times, it is avoidable and even harmful.
Necessary creation happens when new technology or regulation demands added layers of design. Innovation requires added depth. Introducing advanced driver assistance, electrification, or cybersecurity functions all bring new elements and connections. Without these additions, the system would fail to meet safety standards, customer expectations, or legal requirements. In this sense, added intricacy is the price of progress.
Artificial creation occurs when extra layers enter the system without adding real value. This usually comes from unclear requirements, overlapping functions, or organizational silos. For example, two engineering teams may design separate infotainment features that compete with one another. Both systems work in isolation, but when combined, they confuse the driver and increase the validation burden.
In engineering practice, generating additional layers is not always recognized in the moment. A single requirement, a new sensor, or an extra line of software logic can look harmless at first. Yet each addition multiplies its effects as it interacts with existing elements. This is why small changes often carry large, hidden costs later in development.
The key is to distinguish between intricacy that enables progress and system bloat that clutters the design. Engineers cannot avoid creating new layers, but they can ask: Does this addition serve the system’s purpose, or does it only make the system harder to understand and maintain?
Statistics of Complexity
Complexity often feels abstract, but engineers need ways to measure it. Numbers do not capture every aspect, yet they give a practical sense of scale. By treating complexity statistically, we can see where it grows fastest and where it must be controlled.
One basic measure is the number of requirements in a system. A modern vehicle program may carry more than 20,000 requirements. Each one creates design tasks, traceability links, and validation steps. Poorly written requirements multiply the effort without improving the outcome.
Another measure is the number of interfaces or signals. Electrical architectures with thousands of connections become difficult to manage. Each new signal line adds test cases, documentation, and potential failure points.
The volume of engineering change requests (ECRs) is another indicator. A high rate of ECRs suggests that complexity is unstable. Each change can ripple across teams, triggering unexpected rework.
In safety analysis, FMEA and FMEDA branches offer a map of complexity. The deeper the branches, the more interactions must be considered in failure modes.
Software gives an extreme example. A modern car may carry over 100 million lines of code. The raw number is less important than the interdependencies within the code base, but it shows how complexity becomes unmanageable without strict discipline.
Statistics do not solve complexity. They provide a dashboard. Engineers must remember that the numbers only point to areas of risk. They do not capture emergent behavior, but they warn us where complexity may overwhelm design, validation, or even human understanding.
Requirements as the First Line of Defense
Complexity cannot be avoided, but it can be contained. The first tool engineers have for this task is the requirement. At the most basic level, a requirement is a statement of what a system must do or how it must perform. It defines boundaries for the work ahead.
From a philosophical point of view, requirements act as the contract between intent and realization. They express human purpose in a form that engineers can design and test. Without them, projects drift. With poor requirements, projects gain artificial complexity—functions that overlap, logic that conflicts, or safety needs that remain unclear.
In systems engineering, good requirements give structure to complexity. They allow traceability: every low-level detail connects back to a high-level purpose. This traceability makes complexity visible, and therefore manageable. When requirements are vague or contradictory, complexity multiplies without direction.
The automotive industry shows this clearly. Modern vehicles use the V-model to cascade requirements. At the top are vehicle-level goals: safety, performance, user experience. These break down into system-level requirements, and further into component specifications. Each layer constrains the next, keeping complexity from spreading without purpose.
A simple example illustrates the point. If an occupant safety requirement only says “detect the passenger,” two teams may design separate sensors with conflicting outputs. But if the requirement says “detect the passenger’s presence with one validated method,” the system grows in a controlled way.
Requirements do not remove complexity, but they define its limits. In this sense, they form the first line of defense—ensuring that complexity serves the system’s purpose instead of overwhelming it.
Conclusion
Finally, Complexity is not just about size or difficulty. Moreover, it is about relationships, interactions, and behaviors that cannot be reduced to simple parts. A complicated system can be solved with enough effort; a complex system must be managed with care.
We have seen that complexity appears in many forms—structural, functional, organizational, and dynamic. It can be created intentionally through innovation or introduced artificially through unclear requirements. It can be measured with statistics, such as the number of requirements, signals, or change requests. Most importantly, it can be contained through the discipline of well-formed requirements.
For engineers, especially in the automotive field, complexity is not an abstract concern. It is the daily reality of designing vehicles that combine mechanical systems, electronics, and software at unprecedented scales. Recognizing complexity, naming it clearly, and setting boundaries around it is the starting point for mastering it.
This first step leads directly into the next challenge: growth. Complexity does not remain static. Once present, it expands as new elements are added and new functions emerge. Understanding how complexity grows—and how it multiplies through interactions—will be the focus of the next article in this series.
References
-
INCOSE Systems Engineering Handbook – Overview of systems engineering principles, including V-Model context
www.incose.org/products-and-publications/se-handbook -
ISO/IEC/IEEE 15288: System Life Cycle Processes – International standard defining system development and verification processes
www.iso.org/standard/63711.html - 3. ISO 26262: Road Vehicles – Functional Safety – Automotive functional safety standard where the V-Model is often applied
www.iso.org/standard/43464.html
References to Complexity in Systems Engineering Series:
- What Do We Mean by Complexity? <—You are here
- The Growth of Complexity
- Counting Complexity – Why Interfaces Grow Faster Than Parts
- Propagation: How Complexity Spreads
- Complexity Reduction: The Discipline of Simplification
- Optimization: Improving the Existing System
- Requirements: The First Line of Defense
- Measuring and Managing Complexity
- From ppm to ppb – The Statistical Reality of Vehicle Defects
- Complexity in Practice: Case Studies & Critiques
Simulation and Virtual Models – Managing Complexity in Verification and Validation
Systems Engineering References
About George D. Allen Consulting:
George D. Allen Consulting is a pioneering force in driving engineering excellence and innovation within the automotive industry. Led by George D. Allen, a seasoned engineering specialist with an illustrious background in occupant safety and systems development, the company is committed to revolutionizing engineering practices for businesses on the cusp of automotive technology. With a proven track record, tailored solutions, and an unwavering commitment to staying ahead of industry trends, George D. Allen Consulting partners with organizations to create a safer, smarter, and more innovative future. For more information, visit www.GeorgeDAllen.com.
Contact:
Website: www.GeorgeDAllen.com
Email: inquiry@GeorgeDAllen.com
Phone: 248-509-4188
Unlock your engineering potential today. Connect with us for a consultation.