Building Systems is Difficult
Building systems that meet the needs and expectations of all the stakeholders isn't easy. In fact, to borrow a line from Chris Addison’s character Toby Wright from the film “In the loop” it’s “difficult, difficult, lemon difficult” [clip].
In their book “SysML for Systems Engineering 2nd Edition: A model-based approach” [ISBN 978-1-84919-651-2], Jon Holt & Simon Perry of Scarecrow Consultants build on the work of Grady Booch and others, by describing the main reasons for this difficultly as “the 3 evils”, namely; complexity, a lack of understanding, and communication.
Complexity
Complexity appears in several different ways. The first is in the number and nature of the relationships between “things” i.e. Systems, Subsystems, Components, People, Organisations, etc.
Consider the task of writing down the digits one to nine, nine times. Easy peasy lemon squeezy! Now consider completing a Sudoku puzzle, that’s not so easy, but why? In terms of the writing task, there’s actually less work to do because some of the numbers have already been filled in for you. The difference is that there are now rules that govern the relationships between the digits and their relative positions. You have to write them in a 9x9 grid for a start, each digit can only appear once in a row, column or one of the 3x3 sub-grids. What’s more, the rules are quite general, so that at the start of a puzzle, there are squares where any of the digits could be written, so we have to defer filling in those squares until we know more about the squares around them. Relationships between “things” means dependencies between “things” which mean they can’t be developed independently. Changes in one “thing” have a knock-on effect elsewhere.
The second way complexity presents a challenge to systems development can be illustrated by the “Brontosaurus of Complexity”. Here she is:
This (in Holt & Perry’s own words) “slightly bizarre analogy” represents how at the beginning of a project, shown by the dinosaur’s head, complexity is relatively low; everything looks straightforward and well understood. As things progress (moving towards the wider body) the complexity increases, until the project reaches its final stages (the tail), where the complexity is again relatively low and easily manageable. The transition from the head to the body represents divergent thinking, which results in many ideas and questions being generated, while the transition from the body to the tail represent convergent thinking, where the project focuses on a single solution. Divergent thinking is required to fully understand the problem, while convergent thinking is required to properly define the solution. Projects which don’t employ divergent thinking are prone to developing poor solutions, while projects which don’t employ convergent thinking seldom deliver solutions at all (sometimes called “analysis paralysis”). It’s therefore necessary to travel the whole length of the “Brontosaurus of Complexity” which means dealing with the high level of complexity in her rather plump middle.
A lack of understanding
A lack of understanding about the problem may lead us to develop poor or the wrong solutions. A lack of understanding about the solution may lead us to misunderstand its effectiveness or to miss any new problems that it may cause. A lack of understanding about the project may cause delays, unnecessary costs or even a complete failure to deliver. I was recently reminded by Jon Holt that this problem occurs "at any point in the life cycle, not just during the initial concept / requirements phases".
If that weren’t enough, to paraphrase Donald Rumsfeld “there are unknown unknowns. There are things we don't know we don't know”. But we'll leave that for another day.
Communication
Poor communication has long been identified as a barrier to project success.This problem is only magnified where projects involve multiple disciplines, organisations, cultures, locations, and world-views. Even when we use well defined spoken (ok drawn) languages such as SysML with domain specific languages (ontologies), there can still be issues with poor communication if both parties don't fully understand them. It would be easy to dismiss such problems as “simple misunderstandings”, however there are documented examples of complete system failures, such as the 1999 Mars Climate Orbiter (a metric-imperial mixup), which were due to poor communication within a project.
The vicious triangle
You may have already decided it's just too hard, in which case I recommend a lie down in a darkened room. If you are still with us, then the next issue is that each of the evils has a relationship with the others. Failure to mange complexity results in a lack of understanding. A lack of understanding results in poor communication and an increase in complexity, while poor communication in turn results in a further lack of understanding and an increase in complexity. It is therefore necessary to tackle all three evils at the same time.
The good news
Thankfully we have various techniques that can help us to overcome the 3 evils and deliver world class systems. In future articles I hope to explain how things like Model-Based Systems Engineering (MBSE) can help us do just that. But if you can't wait you can always buy the book!
P.S. Thanks to Jon Holt for lending me the “Brontosaurus of Complexity”
Founder & CEO of KYield. Pioneer in Artificial Intelligence, Data Physics and Knowledge Engineering.
8 年Nice work. While it's been said in many ways by many people, difficult to over-emphasize the importance. Improving upon functional simplicity of the type the world increasingly (desperately) needs--soon to be the universe as we migrate beyond our earthly shores, is a significantly more challenging life purpose than expanding complexity, and I think a higher calling at this juncture in history. Decisions must be made in the design process that require a humbling level of exposure. A recent discussion with a friend who is one of the world's leading theoretical thinkers in two interrelated disciplines exemplifies the challenge, when he asked me how we deal with a specific type of entropy in our system design. My answer was in multiple parts, most of which was pragmatic engineering of the type Vint and Bob employed in ARPANet -- combination of math protocols and breaking down physical components to a more manageable design. Before they could even get to that point each had no doubt been exposed to many of the most complex systems, which short of luck is required prior to designing functional simplicity at a scale necessary today.
Scientist behind Software for Mod, Sim and Vis using Converged HPC / AI
8 年The converse to "scope creep" is what Alistair Cockburn calls "Elephant carpaccio" - details so thinly sliced that one loses focus on what the original system was supposed to do in the first place.
Systems Integration Scientist - Start Integrated, Stay Integrated
8 年We can have brontosaurus with spiked tail, when we deploy the solution in multiple client sites, into diverse physical and cultural environments. Each deployed systems becomes a part of diverse systems of systems. Usually, that's the customer's problem so it is rarely considered in SE literature, but nevertheless this problem is very real and critical for the overall success. Does MBSE offer a solution?
Model-Based Systems Engineering Specialist
10 年Hi Julian, yes you're correct - not a great choice of phrase on my part (poor communication?). I would be interested to hear any other evils people suggest, although I suspect most of the "reasons projects fail" are secondary consequences of these 3 fundamental 'evils'.
quite a strong statement: "the three main reasons...". I wonder what a quick survey from experienced sys eng'ers would reveal as 'the three main reasons'?