While working from home, I decided to clean up my document server. One of the documents laying around for years was my Master's Thesis
This thesis was written in support of a Master's Degree in Systems Management. Which at the time was a combination of Systems Engineering and Managerial Finance. In those days, defense contractors would fund education for the skills needed on the programs. Everything we did was Systems focused and they also invested in educating their staff on where money comes from and how to manage that money in the presence of uncertainty.
Two topics sorely missing from today's graduate school education in the technology and software development tracks.
This thesis was later turned into a submission to SINTEF and TÜV process safety management certifications of the product I was a software manager for - the Triple Redundant Process Control Computer system - the Tricon.
The thesis contains all the math needed to model high reliability and fault tolerant computing systems. With worked examples.
Since those days I've always worked on mission critical software intensive systems of systems, in a variety of domains, from Enterprise IT to manned space flight.
In our current software world, dominated by agile development, rarely do I come across people who have any consideration for the System's view of the work. Instead focusing on the small, incremental delivery of some small portion of the system. This is needed of course, but without the Systems View, those efforts result in what the Greeks knew in Ovid:
Pile a little on a little and you get a Big Pile
The agile community would be well served to explore the benefits of "systems thinking," not at the populist level, based on some vague nuanced notion of emergence and complexity, but at the hard core systems engineering level.
One critically important aspect of the "systems" approach is emergent "everything."
While the individual systems constituting a system of systems can be very different and operate independently, their interactions typically expose and deliver important emergent properties. These emergent patterns have an evolving nature that stakeholders for these problems must recognize, analyze, and understand.
The system of systems approach does not advocate particular tools, methods, or practices; instead, it promotes a new way of thinking for solving grand challenges where the interactions of technology, policy, and economics are the primary drivers. System of systems study is related to the general study of design, complexity and systems engineering, but also brings to the forefront the additional challenge of design.
| Systems tend to ... | System of Systems tend to ... |
| Have a clear set of stakeholders | Have multiple levels of stakeholders with mixed and possibly competing interests. |
| Have clear objectives and purpose | Have multiple, and possibly contradictory, objectives and purposes |
| Have a clear management structure and clear accountabilities | Have multiple, and sometimes different, operational priorities with no clear escalation routes |
| Have a single lifecycle | Have multiple lifecycles with elements being implemented asynchronously |
| Have clear ownership with the ability to move resources between elements |
Have multiple owners making individual resourcing decisions |
System of Systems come in several forms [1][2]
- Dedicated System of Systems - built and managed for a specific purposes. Operated and managed centrally to ensure goals are met. These systems retain the ability to operate independently, they can also accept their normal operational mode is subordinate to the central goals. A metropolitan transit system is an example of a dedicated system of systems.
- Acknowledged System of Systems - have objectives recognized by constituent systems, a designated manager, and dedicated SoS resources. Constituent systems retain independent ownership, objectives, funding, development and sustainment approaches. Unlike a directed SoS, changes are based on agreed collaboration. The Air traffic control is an Acknowledged System of Systems.
- Collaborative System of Systems - are systems which voluntarily choose to participate to fulfil some central purpose, which evolve based on collaboration between constituents of the system and System of Systems. The electrical grid is an example. Unlike acknowledged SoS, there is no overall directing authority. Constituent systems adhere to standards and regulations but can negotiate individually to evolve roles and working practices.
- Virtual Systems of Systems - have no central authority, nor explicit, recognized purpose accepted by all constituents. Virtual System of Systems exhibit large-scale emergent behavior, but rely on standardised formats or protocols. The internet is an example. The Internet Engineering Task Force (IEFT) publishes agreed standards and protocols. Independent service providers leverage these for new services or products. No management or governance is provided or accepted regarding usage, and there is no central purpose for all parties.
When designing and developing System of Systems, we start with Capabilities Based Planning
It's common in the agile community to conjecture
What in the beginning you thought you needed is never what you actually needed
This naive understanding of complexity fails to realize several critical success factors for project success...
- Without stating what capabilities we need from the project, we have no means to assess any value produced by the project are worth our investment. These capabilities aren't requirements - yet. They're the mechanisms to earn back the investment. Typical capabilities sound like...
- We need to process provider enrollment processes for $0.07 per transaction versus of current $0.12 per transaction.
-
I need the capability to move a brigade of 3,000 to 5,000 troops 100 miles up the coast in ten hours. — Gen. Norman Schwarzkopf
Capabilities decipher the intent of the leader (Commander)
- Requirements always emerge. But capabilities should not, without rethinking why we're doing the project.
- If we're changing our needed capabilities, we don't likely know what Done looks like in any meaningful way and therefore are wasting out money exploring.
- Exploring in a research and development domain is mandated, but we should do that with the full knowledge and participation of the people paying for work.
- Agile is an essential process to buy knowledge about things we don't know about.
- Ask before spending our customer's money experimenting, can we gain this knowledge in other, cheaper
[1] Dahmann, J., 2014. “Systems of Systems Pain Points”. Proceedings of the 24th INCOSE International Symposium. Henderson, NV, USA. INCOSE, June 2014.
[2] "INCOSE Systems of Systems Primer," INCOSE-TP-2018-003-01/0
