Systems of Systems (SoS): Complexity and Coordination

UPI Study › Courses › Software Engineering › Free lessons › Lesson 15.9 Free with a free account

Systems of Systems (SoS): Complexity and Coordination

Software Engineering · Chapter 15: Distributed Systems, Services, and Sociotechnical TopicsSection 15.9 · lesson 103 of 1037 min · free with a free account

← Managing Procurement in Software Projects

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

When the pieces are independently owned - and stay that way.

  • Explain what makes a system of systems different
  • Explain why independent operation makes coordination hard
  • Describe emergent behavior
  • Describe how complexity is managed without central control

Transcript

Everything said in the video, section by section (866 words). Read along, or search it.

Distributed Systems, Services, and Sociotechnical Topics

Systems of Systems: Complexity and Coordination

Every distributed pattern so far has assumed that the pieces, however physically separated, belonged to one designed whole. A system of systems breaks that assumption entirely. This final section covers what changes when it does.

A Different Situation

No 1 Designed Whole

Earlier distributed patterns generally assumed all the pieces were part of one system, designed and controlled together. A system of systems, or S o S, is different. It is a collection of independently operating, independently managed systems. They are combined or coordinated to produce a capability that none of them could provide alone. Its constituent systems belong to different owners. They were often built independently, for entirely different original purposes, and they keep evolving on their own schedules. The system of systems is a coordination layer, sitting on top of things that never stop being their own independent systems.

Figure 1

A Coordination Layer on Top

Here is the picture. Three complete systems, each with a different owner. They are connected only by interfaces, inside a coordination layer. This is not one designed whole, split across boxes. Each system would keep running, on its own terms, even without the others.

Worth Noticing

Not Just a Big Distributed System

Here is something worth noticing. A system of systems is not just a really big distributed system. The defining difference is that no single entity designed, or controls, all of its constituent parts. That is a genuinely different kind of complexity, than scale alone produces.

Independent Operation

Why Coordination Is Hard

Each constituent system has its own owner, its own priorities, and its own change schedule. So nobody centrally controls when a constituent system changes, upgrades, or goes offline, often for reasons unrelated to the S o S. The system of systems as a whole has to stay resilient to its parts changing, or becoming unavailable, on schedules its designers do not control. That is a fundamentally different reliability challenge from one where a team designs and controls reliability directly. Here, much of what shapes the overall behavior is outside anyone's direct control.

Emergent Behavior

When the Whole Does Something No Part Intended

When multiple independent systems interact, the combined behavior can include things that no constituent system's designers ever intended or anticipated. That is called emergent behavior. It is not necessarily harmful. But it is genuinely unpredictable, from studying any one constituent system in isolation. So an S o S's behavior has to be understood and managed at the level of the whole. It cannot simply be inferred by understanding each piece, and assuming the results will add up as expected.

Managing Complexity

3 Mechanisms, No Central Control

Since no single entity controls every constituent system, S o S management leans on a few recurring mechanisms. Clearly defined interfaces between systems. Each system's promise to the others has to be explicit, because there is no shared internal design to fall back on. Ongoing monitoring at the level of the S o S itself. Problems can emerge from the interaction between systems, not just from one system failing internally. And governance, for coordinating change across independent owners. Nobody can simply mandate a change. Coordination has to happen through negotiation and agreement, across genuine organizational boundaries.

Table 1

Challenges and How They're Managed

Here are the three challenges together. Independent operation means no central control over when constituent systems change. It is managed through interfaces and contracts, not shared internal design. Emergent behavior means the whole is not fully predictable from its parts. It is managed by monitoring at the level of the S o S, not just per system. And cross-boundary change means no single plan governs every system. It is managed through governance and negotiation across independent owners.

Apply It

A Partner Upgrades Over the Weekend

Let's apply that. A partner organization upgrades its own system over a weekend, for its own reasons. On Monday, the combined capability starts behaving strangely, even though every individual system passes its own checks. What was missing? An explicit interface contract that the upgrade had to honor. Monitoring at the level of the whole, to catch problems between the systems. And governance, to coordinate the change in advance.

Why This Matters

Every Thread, All at Once

It is worth stepping back here, at the end of the course. Interfaces and contracts, monitoring, and deliberate change governance have all appeared before. They are threads that run through this entire course. Here they reappear one final time, operating across organizational boundaries, instead of within a single team's control. A system of systems is where all of them have to work together at once, with no one in sole charge of making sure they do.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. A system of systems is a collection of independently operating, independently managed systems, coordinated to produce a capability none provides alone. A constituent system is one of the independently owned and operated systems that make it up. Emergent behavior is behavior of the whole coordinated system that no constituent's designers intended or anticipated. And S o S governance is the set of mechanisms for coordinating change across independent owners, without central control.

Key Takeaways

What to Carry Forward

To pull this together. A system of systems coordinates systems that stay independently owned and operated. No single entity controls the parts, so coordination is layered on top, rather than designed in. Constituent systems change on their owners' schedules, not on the system of systems' schedule. Emergent behavior has to be understood and managed at the level of the whole. And clearly defined interfaces, monitoring of the whole, and governance across owners are what hold it together.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Systems of Systems (SoS): Complexity and Coordination

What is a system of systems?
A system of systems (SoS) is a collection of independently operating, independently managed systems coordinated to produce a capability none of them could provide alone. Its constituent systems belong to different owners, were often built for different original purposes, and keep evolving on their own schedules. The SoS is a coordination layer on top of systems that remain independent.
How is a system of systems different from a large distributed system?
The defining difference is control, not size: in a system of systems, no single entity designed or controls all of the constituent parts. A distributed system, however large, is usually one designed whole split across machines. In an SoS, each constituent system would keep running on its own terms without the others, and its owner decides when it changes or goes offline.
What is emergent behavior in a system of systems?
Emergent behavior is behavior of the whole coordinated system that none of the constituent systems' designers intended or anticipated. It is not necessarily harmful, but it cannot be predicted by studying any one system in isolation. For that reason, an SoS's behavior must be understood and monitored at the level of the whole rather than assumed from its parts.
How is complexity managed in a system of systems without central control?
Systems of systems rely on three mechanisms: clearly defined interfaces and contracts between systems, monitoring at the level of the whole, and governance for coordinating change across independent owners. If a partner upgrades its system over a weekend and the combined capability misbehaves while every part passes its own checks, these mechanisms are what would prevent, detect, and coordinate the problem.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →