John Goodpastuer speaks about the difference between Simplicity versus Complexity. "Making things easier requires complexity." While the terms "Easy," "Simple,", and "Complex" all have dictionary definitions, none really have much use in the discussion of "systems."
For example Simple (\ˈsim-pəl\)
- lacking knowledge,
- free from secondary complications,
- a basic element.
But what do we mean actually when we say "simple." There needs be a unit of measure associated with the definition, for the "simple" reason that one man's simple is another man's complex. So how about (\ˈkäm-ˌpleks\) -
- A whole made up of complicated or interrelated parts (noun)
- Hard to separate (adjective)
- Comprise (a multitude of objects)
These definitions don't leave us with an units of measure either.
Let's Look At Complexity First
Complex systems is a field of study that is rife with “overloaded” vocabulary. Words like Enterprise and Architecture are given new meanings [Bredemeyer 2006] as understanding and technology evolve, and each new meaning develops a following. Eventually the followers collide in an interdisciplinary task or meeting. Those who hear other people using the same words tend to assume everyone means the same thing, but in this case, since it isn’t true, each group ends up thinking the other side is being stupid (or has a hidden agenda). It is unfortunately rare that such problems are headed off by a close examination of vocabulary and meanings.
As an example, let us look at a use of the term “complex systems”:
All systems that systems engineers work on are complex. If they weren’t, they wouldn’t need to be systems engineered. Why are you making such a big deal out of complexity when we all have worked with it forever? You must be trying to make money.
The answer is to use a very specific meaning. A meaning developed by scientists doing research in the area of complexity theory and its follow-ons. Not a meaning essentially "made up" to fit the needs of an author in a book of ancedotal experiences. One of my educational degrees is in Systems Engineering, so I'm biased here.
This domain (systems engineering) uses the word “complex systems” as follows:
Complex systems are systems that do not have a centralizing authority and are not designed from a known specification, but instead involve disparate stakeholders creating systems that are functional for other purposes and are only brought together in the complex system because the individual “agents” of the system see such cooperation as being beneficial for them.
A reasonable and short background in chaos and complexity theory for the systems engineer can be found in [Sheard 2005]. Other material from the INCOSE Systems Science Enabler Group, such as [Sheard 2006], is also supportive of any discussion around complex systems.
Here's a current (2011) definition of complexity in the systems engineering domain - the domain common to the development of software intensive systems:
Complexity is defined as the measure of the difficulty, effort, and/or resources required for one system to effectively observe, communicate, and/or interoperate with another system
[Simpson and Simpson, 2009b: 2].
So here's little story to show that one man's complexity might be another's
When the Hubble Space Telescope (HST) was stranded by the failure of the Columbia Space Shuttle, it needed some way to get fixed. The Wide Field Camera had failed and the NiH batteries were having problems, like all NiH batteries used in your phone and laptop. Frank Cepollina (Ceppie) "owns" the Hubble at Goddard Space Flight Center. The "in orbit servicing" of HST took place with a hands on process. Without the Shuttle, a robot was needed to perform the servicing. There was lots of discussion pro and con for this approach.
Ceppie had three "simple" requirements (mission statements):
- Do no harm to the telescope
- Change the WFC
- Connect an umbilical cord from a external battery pack to the internal DC bus of the telescope
That's essentially what was stated at the Broad Area Announcement during the Industry Days.
The answer - the winning answer - was a robotic servicing mission HRSDM.
Starting with those 3 "simple" requirements (mission concept of operations statement), a "complex" systems was propose, awarded, designed, and started to be developed. Many NASA programs get canceled at PDR (Preliminary Design Review).
Here's the Point
When there are no units of measure of "simple" and "complex," it's difficult to explore the meaning of those terms. What can be used as a starting point are some boundaries for these measures
- Coupling
- Cohesion
- Robustness
- Resilience
- Fault Tolerance
These definitions are of course Domain and Context sensitive. In the Low Earth Orbit business "complex" and "simple" mean something different than "complex" and "simple" in the e-commerce server platform business.
And this is the core problem in discussing nearly anything around these words. Without a Domain and a Context inside that domain, the use of overly-generalized language - language found in recent Agile Management books - is essentially meaningless.
At the risk of being blunt, without an established domain and context for the terms "complex" and "simple," their units of measure, and system architectural examples of these systems, it is pretty much a waste of time to have a meanigful discussion.
As an aside, tools like Lattix and Design Structure Matrix "measure" coupling, cohesion, and other "system" attributes around the complexity discussion.
Is your problem domain the HST and the HRSDM? Probably not. But there are many system exactly like HRSDM or very near, many times more complex. So try to establish the domain, context, measures of complexity in units meaningful to the decision maker, and avoid the simple - and many times simple minded - discussions like "simplicity requires complexity."
References
- [Sheard 2005] Sheard, Sarah. “Practical Applications of Complexity Theory for Systems Engineers”. Proceedings of the Fifteenth Annual International Council on Systems Engineering. (cd). International Council on Systems Engineering, 2005.
- [Sheard 2006] Sheard, Sarah. “Definition of the Sciences of Complex Systems.” INSIGHT (volume 9 #1). Seattle, Washington: International Council on Systems Engineering, October 2006, p. 25.
- The Growth of Complexity
- J.J. Simpson and M.J. Simpson, "System of systems complexity identification and control," Proceedings IEEE 4th Syst Syst Eng Conf, Albuquerque, June 2009b.
