Systems Thinking
Systems thinking has now become so popular that there is not only debate about what it means, but also debate about its origins. Did systems thinking start in the fields of science as a way to understand complex chemistry and physics problems? Did it start in the mid-20th century to predict weather? Or was it part of early computer science research out of MIT?
While these origin questions are intellectually interesting, for me the much more urgent and important questions are around how we define systems thinking and how we use it. I think some of the common understandings, or definitions, of systems thinking are inadequate and can create big problems for the people that follow them.
What does systems thinking mean and how should we use it?
At its most basic, people see systems thinking as connecting boxes to understand the interdependencies in a system. While focusing on the interdependencies is a good start, it’s not enough. For me, systems thinking needs to include not only the interdependencies (as well as the processes, structure and nature of each interdependency), but also:
Perspectives – individual stakeholders and their roles and how they change in a system
Borders - the purpose, what is contained or impacted and what decisions should be made in or out of the boundary
Why is this important?
Because if we take a simplistic view of systems thinking, it can lead to an inadequate understanding of exactly how systems and their component parts operate and inter-relate. This often causes us to waste time and money with fixes or remediation further down the track and/or it means we don’t get the full value of whatever we were trying to implement.
Why basic systems thinking is inadequate for a cloud migration
We can very clearly see how a more sophisticated systems thinking approach is beneficial when we look at a very common project these days, assessing the suitability of moving an application to the cloud. Often when companies do this, they look solely at an individual application and its interfaces. They will churn each application through the chosen application assessment framework and determine what is required to move that application(s) to the cloud.
This type of approach brings several risks:
You get almost no understanding of how end-users or operations staff are using the system and the various roles they take within the system (perspectives).
There is no attention to ‘edge cases’ the people using the system you need to actively engineer against to avoid security issues (perspectives).
It usually gives you only a rudimentary understanding of the data in each system and whether the system is the master of that data (borders).
And, my biggest bugbear, there is no focus on capabilities and where borders have been ignored or blurred as the system has grown. This often means there are duplicate capabilities across systems or hard dependencies between applications (borders).
The end-result of this interdependency-focused assessment is usually an application (or group of applications) are moved to the cloud, but the migration runs late as the issues with borders and perspectives are only identified during the migration. When the migration is finally finished, the business (and each individual user) doesn’t get all the benefits it could have. If, instead of only thinking about interdependencies, you had also thought about available perspectives and borders between system elements then you could have avoided these problems.
Don’t start with systems or applications, start with users
To avoid these traps, instead of starting with the application technology, instead start with the different users and their capabilities – a user-centred approach. A user or customer focus will naturally identify the different perspectives across a system and will also draw out their capabilities and the borders (or lack of). Then, with some additional work and the help of a good data architect you can drill down to understand the data and the way it flows.
This will require some additional investment, and extra time, up front as you will naturally have to untangle more of the system’s complexity. However, the earlier in a project that you identify a problem, the quicker and cheaper it is to fix. IBM’s 2010 research found that if you find and fix a defect in design it’s 6.5 times cheaper than finding it in implementation and 15x cheaper than finding it in testing.
Which systems thinking assessment framework to use?
When you do lift the lid on the individual applications and delve into the code you can make your life much easier if you choose the right industry standard assessment framework. There are many different ones to use, and they all have their merits, but in particular we like using The Twelve Factor methodology. The great thing about using The Twelve Factors is it allows us to assess the readiness of the application for cloud and then draw out tight or loose interdependencies the application has to supporting services or other applications. This helps identify quick wins, areas of risk, and importantly will also build a pipeline of applications for assessment as you work your way through the system.
Consider Security
With the way we work changing, and remote-working omnipresent, I like to pay particular attention to how a malicious actor could exploit existing user processes or actions. David O’Brien provided some great guidance on how to start with zero trust, including the various roles developers and team leads take on when using specific applications. While segregation (or separation) of duties has been around for more than 20 years, I can assure you that there will be a developer or business team lead who has amassed roles they shouldn’t have or don’t need.
Software supply chains have become a hot topic these days, not just because of the high-profile hacks but also because the explosion in open-source use has made the supply chain, and composition of the software being used, so much more complex. There is a lot to say on software supply chain risks (so we’ll explore it in a future blog) but simply put it’s a big risk and one you need to actively manage.
As a first step (if you haven’t done so already) you should:
Have software composition analysis in place to review the code for all of your applications
Actively manage the supply chain with your vendors
If you don’t have the above in place yet, then a cloud migration project, or application modernisation project (or any large software project) is a great time to start!
Don’t forget edge cases
Lastly, always spend some time, whether a full sprint or just a series of focused sessions to consider edge cases – those cases which aren’t included in the main body of work, but which could throw your whole project off track.
There’s a number of different ways of doing this, but here’s three ways to consider:
I often find that the operations team has a wiki page of common issues or work arounds that I should be aware of.
A dump of recent problems from the Service Management System is often a gold mine. These will mostly identify edge cases with interdependencies you need to consider.
Think about what is the least used function or component in the application? For example - that annual audit that only takes one day per year. Is that why there is a printer attached to one of the servers or that user role that is only used once a year?
Systems thinking is growing in importance and popularity which I think is great for all of us. Any methodology which gives us a greater understanding of how different systems and their component parts interact and inter-relate can only help us to achieve better results (for both businesses and users) more quickly and more cheaply. But while systems thinking has grown in importance, the general understanding of what it is and how we use it hasn’t necessarily kept pace.
If you think systems thinking is just about connecting boxes to understand the interdependencies in a system, then I think you’re likely to run into problems. But if you take a more rigorous approach, where you consider the interdependencies, perspectives and borders, you’re much more likely to get a good result.
Please get in touch if you’d like some systems thinking on a project you’re working on, or simply a sounding board to bounce your ideas off.