Complex, Complexity, Complicated
Glen Alleman MSSM
Vietnam Veteran, Applying Systems Engineering Principles, Processes & Practices to Increase the Probability of Program Success for Complex Systems in Aerospace & Defense, Enterprise IT, and Process and Safety Industries
The popular notion that?Cynefin?can be applied in the software development domain to discuss the problems involved in writing software for money needs to include the profession of?Systems Engineering. From Wikipedia, Cynefin is...
The?framework?provides a typology of contexts that guide what sort of explanations or solutions might apply. It draws on research into?complex adaptive systems?theory, cognitive science, anthropology, and narrative patterns, as well as evolutionary psychology, to describe problems, situations, and systems.
While Cynefin uses the term Complexity and Complex Adaptive System, it is applied from the?observational?point of view. That is, the system exists outside of our influence on the system to control its behavior - we are observers of the systems, not?engineers?of the?solutions?in the form of a?system that provides needed capabilities to solve a problem.
Read carefully the original paper on Cynefin,?The New Dynamics of Strategy: Sense Making in a Complex and Complicated World.?This newsletter is NOT about those types of systems but the conjecture that software development is, by nature, Chaotic. This argument is used by many in the agile world to avoid the?engineering?disciplines of?INCOSE-style Systems?Engineering.??
There are certainly?engineered?systems that transform into complex adaptive systems with emergent behaviors that cause the system to fail. Example below. This is likely to be different when?engineering?principles are applied in the domains of Complex and Complicated.
A good starting point for the complex, complicated, and chaotic view of?engineered systems?is?Complexity and Chaos -?State?of the Art: List of Works, Experts, Organizations,?Projects, Journals, Conferences, and Tools?There is a reference to Cynefin as organization modeling. While organizational modeling is important - I suspect Cynefin advocates would suggest the only important item - the?engineered aspects??of applying Systems Engineering to complex, complicated, and emergent systems is mandatory for any organization to?get the product out the door on time, on budget, and on specification.
For another view of the complex systems problem,?Principles?of?Complex?Systems for Systems Engineering?is a good place to start, along with the resources from INCOSE and AIAA like?Complexity Primer for Systems Engineers,?Engineering Complex Systems,?Complex System Classification, and many others.
So Let's Look At the Agile Point of View
In the agile community, it is popular to use the terms?complex, complexity, complicated, complex?adaptive?system?many times interchangeably and many times wrongly - to assert?we can't possibly plan ahead,?know?what we're going to need, and establish a cost and schedule because the?systems?complex, and emergent.
These terms are often?overloaded?with an agenda used to push a process or even a method. In the agile community, claiming that we have no control over the system is popular, so we must adapt to its emerging behavior. This is likely the case in one condition - the chaotic behaviors of Complex Adaptive Systems. But this is only the case when we fail to establish the basis for how the CAS was formed, what sub-systems are driving those behaviors, and most importantly, what are the dynamics of the interfaces between those subsystems - the System of Systems architecture - that create the chaotic behaviors.?
It is highly unlikely those working in the agile community actually work on complex systems that evolve AND at the same time are?engineered?at the lower levels to meet specific capabilities and resulting requirements of the system owner. They've simply let the work and the resulting outcomes?emerge?and become?Complex, Complicated,?and create?Complexity. They are?observers??of the outcomes, not?engineers?of the outcomes.
Here's one example of an engineered system that actually did become a CAS because of poor efforts of the Systems Engineers. I worked on Class I and II sensor platforms. Eventually, FCS was canceled for all the right reasons. But for small teams of agile developers, the outcomes become?complex?when the Systems Engineering processes are missing. Cynefin partitions beyond obvious?emerge?mostly when Systems Engineering is missing.
First Some Definitions
– Complex behavior
– Complex mechanisms
– Complex Situations
– Complex systems
– Complex data
One more item we need is the types of Complexity.
And Now To The Point
When we hear complex, complexity, complex systems, complex adaptive system, pause to ask what kind of?complex?are you talking about. What?Type?of complex system. In what system are you applying the term?complex. Have you classified that system in a way that actually matches a real system. Don't take anyone saying?well the system is emerging and becoming too complex for us to manage?Unless in fact that is the case after all the Systems Engineering activities have been exhausted. It's a cheap excuse for simply not doing the hard work of?engineering?the outcomes.
Using the terms complex, complicated, and complexity interchanged is common. And software development is classified or misclassified as one, both, or all three. It is also common to need to understand their meaning and application to toss around these terms.
We need to move beyond buzzwords. Words like?Systems Thinking.?Building software is part of a system. There are interacting parts that, when assembled, produce an outcome. Hopefully, the desired outcome. In the case of software, the interacting parts are more than just the parts. The software has emergent properties. A Type 4 system, built from Type 1, 2, and 3 systems. With changes in time and uncertainty, modeling these systems requires stochastic processes. These processes depend on estimating behaviors as a starting point.?
The understanding that software development is an uncertain process (stochastic) is well known, starting in the 1980s [1] with COCOMO. Later models, like?Cone of Uncertainty, clarified that these uncertainties evolve with time. The current predictive models based on stochastic processes include Monte Carlo Simulation of networks of activities, Real Options, and Bayesian Networks. Each is directly applicable to modeling software development projects.
[1]?Software Engineering Economics,?Barry Boehm, Prentice-Hall, 1981.
Executive, Supervisor, Actuary, Innovator, Adviser
1 年This is what ChatGPT 3.5 concluded ?? https://chat.openai.com/c/975f7f76-668c-4c53-b192-a09218eaa083
Glen, great post. Would be interested in your views on how Cynefin could work in with what Goldratt designed in his theory of constraints, particularly with complex environments and how he also uses terms such as Simple (Obvious), Complicated, Complex and Chaotic (p984) to define organisational (and project) complexities, to then align appropriate tools and thinking for each.