Then Try this.
Saturday, 28 March 2015
Systems Thinking - reading list
[this is a draft - to be completed soon]
The following seven books are my current recommendations for shifting your thinking into systems mode.
They are probably not what you expect. They are not the usual volumes on Systems Engineering, Systems Analysis or Systems Thinking, which can be easily found on the web. These are books that have changed my way of thinking.
I will eventually comment on the merits of each book, when I can find the time.
I have restricted myself to these seven (of about 100 books on systems that I have collected), as a realistic reading list for someone with a modest amount of time to spare.
The following seven books are my current recommendations for shifting your thinking into systems mode.
They are probably not what you expect. They are not the usual volumes on Systems Engineering, Systems Analysis or Systems Thinking, which can be easily found on the web. These are books that have changed my way of thinking.
I will eventually comment on the merits of each book, when I can find the time.
- John Maeda, "The Laws of Simplicity - Design, Technology, Business, Life", MIT Press, 2006
- Christopher Alexander (and others), "A Pattern Language - Towns, Buildings, Construction", Oxford University Press 1977
- John Gall, "Systemantics - How Systems Work and especially How They Fail, Wildwood House, London, 1975
- Jake Chapman, "System Failure - why governments must learn to think differently", Demos, 2002
- Henri Petroski, "To Engineer is Human - the role of failure in successful design", Vintage Books, 1992
- Herbert Simon, "The Sciences of the Artificial", MIT Press, 1984
- Robert Axelrod and Michael Cohen, "Harnessing Complexity - Organisational implications of a scientific frontier", The Free Press, 1999
I have restricted myself to these seven (of about 100 books on systems that I have collected), as a realistic reading list for someone with a modest amount of time to spare.
Monday, 23 June 2014
On Engineering and Art - Systems Thinking and Systems Practice
What is is that Engineers and Artists have in common?
They invent things. They create things. They make things.
This is not as prosaic as it sounds. Engineering and Art both involve the mastery of complex ideas, complex techniques and the application of one to the other so as to eventually reach a desired outcome.
Engineers could learn a lot from Artists. And the other way round.
[Education today misses this vital link. It has been the cornerstone of advances in civilisation since the renaissance and it fueled the industrial revolution in Victorian times. We should be putting Art back into Engineering education and vice-versa, encouraging STEAM, not STEM, but that's another story.]
Let me take two examples, one from Engineering, one from Art and then discuss their correspondence.
Engineering very large systems (Systems Engineering, so called) requires engineers to find the balancing points between conflicting requirements, normally from different disciplines or sub-disciplines. Designing and building a cruise liner, for example, means making something that is big enough, will float, will be a small town at sea and can navigate alone across the globe (i.e, it is a sophisticated electronic beast to boot).
So to design and build a complex system like a cruise liner requires an elaborate mix of engineering skills and an ability to see the whole as well as the ability to combine the parts to produce the whole and to participate in a creative and constructive way as a member of a team.
Where do Systems Engineers learn these skills. Well, today, they seem to learn them by osmosis. They start out in some engineering discipline, moving up over time to participate in larger and larger projects and are eventually anointed by their employer as a Systems Engineer. No training in Systems Thinking and precious little practice at the skills they need to reach a good and cost effective solution.
Engineers could learn a lot from Artists, not least in Systems Thinking. Moreover, Art provides a domain in which systems skills can be learned and practiced both effectively and efficiently.
In Art, an artist takes an idea from conception to completion by the application of a set of skills that they have learned over their career. Just like an engineer.
Consider a painter, faced with a commission (or just a longing) to produce a work expressing their love of trees (for example). They might be skilled in oil, or acrylic, or even digital expression. They will have to decide on a subject, a style, an overall size, a budget and all of the issues that go along with applying their chosen medium. They will have to try out various alternatives and select among them. They will have to make a best-reasoned choice, proceed and be prepared to backtrack. They will have to have developed skills that allow for mistakes and for corrections. And, in a realistic environment they will have to work to a set timescale that will include disciplining themselves to set aside all those brilliant ideas they have for innovative elaborations whose rightful place is in the next project, not this one. Just like engineers.
Artworks are seldom nowadays the work of an artist working alone. Sculptures, plays, performances, film, video and large scale images require teamwork ad compromise. They require engineering. They involve Systems.
Most artists, would, I expect, hate to been considered to be systematic. They think of themselves as intuitive, as emotional, as putting heart and soul into their work. They think of engineering as being heartless and soulless. But artists are Systems Thinkers as much as anyone and they work in mediums [media seems wrong here] that encourage creativity and innovation. Just exactly what Systems Engineers need if they are to improve their performance.
The two examples I have given suggest that Art and Engineering have more in common than they have in differences. Lets look at that a little more closely.
Systems Thinking is the ability to consider the whole along with a consideration of the parts. Somewhere, in the engineering of a cruise liner, someone has considered how the parts will work together to deliver the whole. Somewhere, in the production of a complex artwork, someone has considered how the parts will work together to deliver the whole.
Consideration of the whole requires compromise among the parts. It's when this compromise doesn't work out that things go wrong. Things need to be simple enough to be understood and sophisticated enough to achieve their goal. They don't need to be so sophisticated that they fail or so simple that they are of no use. Getting that compromise right is the role of the Systems Engineer and in that respect all makers are systems engineers.
[I could go on to say all Art is Systems Art, but that would be of little merit. It is only true in the sense that all made things are systems and are made by systems.]
Art, it seems to me, is a great place to practice Systems Thinking and to develop Systems Theory. It is a place that Systems Engineers could use to explore and develop their own skills. To do that would be to become more creative, more innovative and more broad minded as well as more disciplined.
They invent things. They create things. They make things.
This is not as prosaic as it sounds. Engineering and Art both involve the mastery of complex ideas, complex techniques and the application of one to the other so as to eventually reach a desired outcome.
Engineers could learn a lot from Artists. And the other way round.
[Education today misses this vital link. It has been the cornerstone of advances in civilisation since the renaissance and it fueled the industrial revolution in Victorian times. We should be putting Art back into Engineering education and vice-versa, encouraging STEAM, not STEM, but that's another story.]
Let me take two examples, one from Engineering, one from Art and then discuss their correspondence.
Engineering very large systems (Systems Engineering, so called) requires engineers to find the balancing points between conflicting requirements, normally from different disciplines or sub-disciplines. Designing and building a cruise liner, for example, means making something that is big enough, will float, will be a small town at sea and can navigate alone across the globe (i.e, it is a sophisticated electronic beast to boot).
So to design and build a complex system like a cruise liner requires an elaborate mix of engineering skills and an ability to see the whole as well as the ability to combine the parts to produce the whole and to participate in a creative and constructive way as a member of a team.
Where do Systems Engineers learn these skills. Well, today, they seem to learn them by osmosis. They start out in some engineering discipline, moving up over time to participate in larger and larger projects and are eventually anointed by their employer as a Systems Engineer. No training in Systems Thinking and precious little practice at the skills they need to reach a good and cost effective solution.
Engineers could learn a lot from Artists, not least in Systems Thinking. Moreover, Art provides a domain in which systems skills can be learned and practiced both effectively and efficiently.
In Art, an artist takes an idea from conception to completion by the application of a set of skills that they have learned over their career. Just like an engineer.
Consider a painter, faced with a commission (or just a longing) to produce a work expressing their love of trees (for example). They might be skilled in oil, or acrylic, or even digital expression. They will have to decide on a subject, a style, an overall size, a budget and all of the issues that go along with applying their chosen medium. They will have to try out various alternatives and select among them. They will have to make a best-reasoned choice, proceed and be prepared to backtrack. They will have to have developed skills that allow for mistakes and for corrections. And, in a realistic environment they will have to work to a set timescale that will include disciplining themselves to set aside all those brilliant ideas they have for innovative elaborations whose rightful place is in the next project, not this one. Just like engineers.
Artworks are seldom nowadays the work of an artist working alone. Sculptures, plays, performances, film, video and large scale images require teamwork ad compromise. They require engineering. They involve Systems.
Most artists, would, I expect, hate to been considered to be systematic. They think of themselves as intuitive, as emotional, as putting heart and soul into their work. They think of engineering as being heartless and soulless. But artists are Systems Thinkers as much as anyone and they work in mediums [media seems wrong here] that encourage creativity and innovation. Just exactly what Systems Engineers need if they are to improve their performance.
The two examples I have given suggest that Art and Engineering have more in common than they have in differences. Lets look at that a little more closely.
Systems Thinking is the ability to consider the whole along with a consideration of the parts. Somewhere, in the engineering of a cruise liner, someone has considered how the parts will work together to deliver the whole. Somewhere, in the production of a complex artwork, someone has considered how the parts will work together to deliver the whole.
Consideration of the whole requires compromise among the parts. It's when this compromise doesn't work out that things go wrong. Things need to be simple enough to be understood and sophisticated enough to achieve their goal. They don't need to be so sophisticated that they fail or so simple that they are of no use. Getting that compromise right is the role of the Systems Engineer and in that respect all makers are systems engineers.
[I could go on to say all Art is Systems Art, but that would be of little merit. It is only true in the sense that all made things are systems and are made by systems.]
Art, it seems to me, is a great place to practice Systems Thinking and to develop Systems Theory. It is a place that Systems Engineers could use to explore and develop their own skills. To do that would be to become more creative, more innovative and more broad minded as well as more disciplined.
Sunday, 23 February 2014
Systems Theory - Searching for the Systematic
What's in a name?
Systems Theory has had many incarnations since Bertalanffy's 1968 book on General Systems Theory. Wikipedia has a good summary.
My use of the term is a grossly simplified version of those original ideas. You could say that I am using the paradigm, if not precisely the same incarnation.
My objective is to be pragmatic. To constitute a set of guidelines which can be useful in practice to those of us who have to analyse Systems and those of us who have to design and build Systems.
----------------------------
I am primarily concerned with Artificial Systems, those built by people for use by people.
Systems appear throughout the literature on Science and Engineering as a paradigm that is useful in the organisation of ideas. In Science, Systems concepts appear in their analysis form, where scientists seek to systematise their thinking by enumerating (and defining) concepts and their relationships. In Engineering, Systems concepts appear in their synthesis form, where engineers organise the structure of the artifacts they plan to build.
Elsewhere (on the Systems Art website) I have applied the ideas to Art (primarily visual art) in both an analysis and synthesis sense. The reasons that I have done this is that I wanted a domain that was different from the usual domains used in describing Systems Theory. Art is a domain that I know reasonably well and one that I think is accessible to most readers. I hope to make that motivation clear here (and eventually on the Systems Art website). But first let me introduce the basic ideas of Systems Theory.
--------------------
Systems Theory, a gentle introduction.
Primarily Systems Theory suggests that we should look at the world through the concept of a System. But of course there are many Systems, so we need to scope our study.
This will involve choosing a Boundary and a Level of Abstraction. Our System will interface with other systems at the boundary. And we will choose a comfortable set of Concepts to work with that together will define the level of abstraction that we are using.
There is no single ideal description of a System. Indeed, it is often important to construct more than one description, to look at the system under consideration from several Viewpoints.
Take an automobile, for example. I can choose to describe that as a system to be designed, to be manufactured or to be used. To take the user's viewpoint, I would describe how to drive and maintain the vehicle. The concepts involved in the description would be those necessary to define the principal functions. These would be at a fairly abstract level, not for example describing how the throttle adjusts the engine speed, just that this is what it does.
For any System, there are two particular viewpoints that complement each other and have general utility. We can describe a System as a Structure, focussing on the components it comprises and their interfaces. Or we can describe a System as a Process, focussing on the behaviour that it exhibits.
In turn, there are two particular process viewpoints that are useful. Sometimes we need one, sometimes the other, sometimes both.
The first process is the behaviour of the systems itself (how the vehicle works). The second process is the behaviour of the system that produced our system of interest (how the vehicle is manufactured). Note the recursion here.
Whether we are analysing or synthesising a system, we encounter the same need to enumerate the concepts suited to our purpose. Either way, we are faced with a puzzle. As System Theorists, we are puzzle-solvers.
What are the components and behaviours we need to identify (then describe, then build or rebuild) and how do they, taken together, constitute a full understanding of the system of interest? This is the universal puzzle that we set ourselves in Systems Theory.
--------------------
Systems Theory, an example from Art
When looking at an artifact we can choose to view it as a structure or as the result of a process that might have produced it.
If I can describe something to you in terms of its structure, so that you can understand it without necessarily seeing it, then you will have one view of it.
A statue, for example: I might explain that it is a statue of a man, standing. A Roman man, in Roman attire, from two thousand years ago. He has one hand raised, as if to say something. I can walk all round him and see how how it might have been to be near the real man all those years ago. I can describe the statue to you as a structure.
Or, I can describe something to you by describing the process that might have made it.
That statue: perhaps it had been created by a craftsman, a sculptor. It's marble, not bronze. The sculptor used a chisel and hacked away at just the parts of the marble needed to reveal a Roman senator. The craftsman copied from a small model that had been made by an artist. Two models, in fact. One of the whole man, showing the stance and another more detailed likeness of the face, so that the real senator would be recognizable.
You can call these two descriptions complementary. You can note that they are not the only descriptions. What, for example, was the purpose of the statue? How much did it cost? When was it actually made? Is it a true likeness, or a re-imagined image? Is this a real senator? What did he do to deserve a statue?
You can make many descriptions. The more the better. But structure and process are essential viewpoints. And in searching for the systematic, it is important to use both.
Because, when searching for the systematic, there are many, many systems involved and each will play a part in determining our understanding of the system of interest.
Systems Theory has had many incarnations since Bertalanffy's 1968 book on General Systems Theory. Wikipedia has a good summary.
My use of the term is a grossly simplified version of those original ideas. You could say that I am using the paradigm, if not precisely the same incarnation.
My objective is to be pragmatic. To constitute a set of guidelines which can be useful in practice to those of us who have to analyse Systems and those of us who have to design and build Systems.
----------------------------
I am primarily concerned with Artificial Systems, those built by people for use by people.
 |
| Examples of Systems Theory applications |
Elsewhere (on the Systems Art website) I have applied the ideas to Art (primarily visual art) in both an analysis and synthesis sense. The reasons that I have done this is that I wanted a domain that was different from the usual domains used in describing Systems Theory. Art is a domain that I know reasonably well and one that I think is accessible to most readers. I hope to make that motivation clear here (and eventually on the Systems Art website). But first let me introduce the basic ideas of Systems Theory.
--------------------
Systems Theory, a gentle introduction.
Primarily Systems Theory suggests that we should look at the world through the concept of a System. But of course there are many Systems, so we need to scope our study.
This will involve choosing a Boundary and a Level of Abstraction. Our System will interface with other systems at the boundary. And we will choose a comfortable set of Concepts to work with that together will define the level of abstraction that we are using.
There is no single ideal description of a System. Indeed, it is often important to construct more than one description, to look at the system under consideration from several Viewpoints.
Take an automobile, for example. I can choose to describe that as a system to be designed, to be manufactured or to be used. To take the user's viewpoint, I would describe how to drive and maintain the vehicle. The concepts involved in the description would be those necessary to define the principal functions. These would be at a fairly abstract level, not for example describing how the throttle adjusts the engine speed, just that this is what it does.
For any System, there are two particular viewpoints that complement each other and have general utility. We can describe a System as a Structure, focussing on the components it comprises and their interfaces. Or we can describe a System as a Process, focussing on the behaviour that it exhibits.
In turn, there are two particular process viewpoints that are useful. Sometimes we need one, sometimes the other, sometimes both.
The first process is the behaviour of the systems itself (how the vehicle works). The second process is the behaviour of the system that produced our system of interest (how the vehicle is manufactured). Note the recursion here.
Whether we are analysing or synthesising a system, we encounter the same need to enumerate the concepts suited to our purpose. Either way, we are faced with a puzzle. As System Theorists, we are puzzle-solvers.
What are the components and behaviours we need to identify (then describe, then build or rebuild) and how do they, taken together, constitute a full understanding of the system of interest? This is the universal puzzle that we set ourselves in Systems Theory.
--------------------
Systems Theory, an example from Art
When looking at an artifact we can choose to view it as a structure or as the result of a process that might have produced it.
If I can describe something to you in terms of its structure, so that you can understand it without necessarily seeing it, then you will have one view of it.
A statue, for example: I might explain that it is a statue of a man, standing. A Roman man, in Roman attire, from two thousand years ago. He has one hand raised, as if to say something. I can walk all round him and see how how it might have been to be near the real man all those years ago. I can describe the statue to you as a structure.
Or, I can describe something to you by describing the process that might have made it.
That statue: perhaps it had been created by a craftsman, a sculptor. It's marble, not bronze. The sculptor used a chisel and hacked away at just the parts of the marble needed to reveal a Roman senator. The craftsman copied from a small model that had been made by an artist. Two models, in fact. One of the whole man, showing the stance and another more detailed likeness of the face, so that the real senator would be recognizable.
You can call these two descriptions complementary. You can note that they are not the only descriptions. What, for example, was the purpose of the statue? How much did it cost? When was it actually made? Is it a true likeness, or a re-imagined image? Is this a real senator? What did he do to deserve a statue?
You can make many descriptions. The more the better. But structure and process are essential viewpoints. And in searching for the systematic, it is important to use both.
Because, when searching for the systematic, there are many, many systems involved and each will play a part in determining our understanding of the system of interest.
Wednesday, 1 January 2014
Why large projects Fail
There are many reasons why large projects fail. Here are just some of them
- There is too much optimism as to the potential benefits the proposed system ... and to the cost of delivering those benefits
- There is too little investment at the beginning ...
- If sufficient investment is made eventually, it is too late ... so we lose even more money
- There is not enough technical know-how in the project team.
- There are opposing human factors aspects - including insufficient consideration of team working, project management and risks.
- The project does not plan incremental roll-out and fails to anticipate the effect of big-bang on the organisation.
- (for IT project) The project tries to match IT to the existing Business Processes of the organisation, rather than mandating that the Business Processes change to match those easily supprted by the IT.
- Initial under-investment leads to an investment legacy, where the project has invested in bad decisions and doesn't have the courage to retreat.
- There are many management disaster scenarios that can be to blame, such as
- the parent/child governance scenario, where authority within the project remains with senior management in the customer.
- the enthusiastic builder scenario, where the supplier has a vested interest in prolonging the project since payment is related to time-on-the-job rather than delivery of results.
- And of course, because of insufficient planning and because the project takes a long time from inception to completion, there is a requirements explosion during the lifetime of the project ... which means that what is eventually required is significantly different from what was originally anticipated
Monday, 30 December 2013
Whole Systems study
Whole System Effect
Errors in systems can have system-wide implications.
If my bank fails to correctly carry out the transaction that I have requested, it could affect my credit rating.
But the designer of the bank system probably gave little thought to that consequence.
Making subsystems composable but orthogonal is the key to keeping control over this whole-system effect.
Laws for Systems (published in 1998)
- A component, added to a system, may not disrupt the behaviour of that system.
- A component, using the services of another, does so at its own risk and must protect itself from damage.
- A component offering a service does so at its own risk and must protect itself from misuse.
Reading these laws today, substituting the word (sub)System for Component, they are even more obvious than they were 15 years ago. Talking about systems in terms of services was only just beginning then. Today, I prefer the use of the term interface and use it more or less interchangeably with the word system.
Being obvious, doesn't make them untrue.
The key message here is that a subsystem is responsible for both its own (bad) behaviour and any misuse that is made of it. If a subsystem fails as a consequence of misuse then that is no-one's fault but its own.
This can be used as a guiding principle when designing systems and when analysing them (typically, trying to understand a system designed by someone else).
Look at a whole-system through the faults that can occur as a consequence of bad design. Look at its failure modes. Look at how these can be (or should have been) mitigated. That's how you will see if the the modularity is right, if the orthogonality is right, and how that can be strengthened.
This is particularly true when looking at how a system should be changed or extended. It should have been designed so that extension is cheap and the possibility of damaging the existing system is nil.
Being obvious, doesn't make them untrue.
The key message here is that a subsystem is responsible for both its own (bad) behaviour and any misuse that is made of it. If a subsystem fails as a consequence of misuse then that is no-one's fault but its own.
This can be used as a guiding principle when designing systems and when analysing them (typically, trying to understand a system designed by someone else).
Look at a whole-system through the faults that can occur as a consequence of bad design. Look at its failure modes. Look at how these can be (or should have been) mitigated. That's how you will see if the the modularity is right, if the orthogonality is right, and how that can be strengthened.
This is particularly true when looking at how a system should be changed or extended. It should have been designed so that extension is cheap and the possibility of damaging the existing system is nil.
Friday, 12 July 2013
Systems 101
Everything is interconnected.
We are surrounded by Systems.
Our task is to make sense of these Systems.
Our task is to search for the systematic in the complexity that surrounds us.
To make sense of it.
To control it.
Before we can control Systems, we need to understand them.
There are many things we need to know about Systems.
The first thing to know about Systems is that there are lots of them.
We need to take them one at a time.
In reaching an understanding of a System we need to approach it systematically.
We need a systematic approach to Systems.
In general
When we understand all this, we will be in a position to Control the System.
Only then.
We are surrounded by Systems.
Our task is to make sense of these Systems.
Our task is to search for the systematic in the complexity that surrounds us.
To make sense of it.
To control it.
Before we can control Systems, we need to understand them.
There are many things we need to know about Systems.
The first thing to know about Systems is that there are lots of them.
We need to take them one at a time.
In reaching an understanding of a System we need to approach it systematically.
We need a systematic approach to Systems.
In general
- Systems are Modular
- Systems are Hierarchical
- Systems are composed of smaller systems that are (ideally) Orthogonal to each other
- To make bigger Systems from smaller systems the subsystems need to be Composable
- To be composable, they need to have understandable Interfaces
- Open Systems are the means to make Systems effectively composable
When we understand all this, we will be in a position to Control the System.
Only then.
Modular
An Open System will be a modular construction where the architects have specifically chosen the granularity of the decomposition and the capabilities of the components to realise an evolving family of solutions towards an eventual Vision system. Establishing this Vision system and choosing the granularity are key aspects of creating a long-life architecture with potential for innovative enhancement. This is the Architecture.Hierarchical
When we set out to explore a System, because we need to understand it to change or extend it, we immediately begin to think in terms of boundaries. What is in the system and what is outside it? What granularity of components (subsystems) do we need to consider? That is, we perceive a hierarchy of Systems and the System-of-interest is somewhere in the middle of this hierarchy. It itself is a subsystem of some higher system. And it is composed from subsystems, which are Systems to others. The boundaries of our System require us to define its parent(s), its siblings and its children.Orthogonal
When looking for the boundaries that segregate the children, we look for subsystems that are, by and large, orthogonal. This means that changes to one component can be carried out largely independently of changes to its siblings. A well-designed (or well-analysed) System has orthogonal subsystems.Composable
But it's not sufficient that subsystems have as little as possible interference with each other. They need to be able to be assembled in different configurations that are easily reconfigured to support evolutionary change. We describe such subsystems (or components) as composable. In an ideal world, all systems will be composable with as little effort as possible, so that they can participate effectively and economically in a larger system.Interfaces
Composable systems must have interfaces that are the points of interaction with them. Describing a system is tantamount to describing its interfaces.Open Systems
An Open System is a modular construction that has been designed in such a way that its modules have precisely defined and publicly owned interfaces, where these interfaces allow independent suppliers to provide improved capability by providing innovative, plug-compatible modules.This modular structure, made from modules with open interfaces, is referred to as an Open Architecture.
Subscribe to:
Posts (Atom)