In order to understand what system thinking is, and how it can help development teams, we must first understand systems themselves: what they are, the problems they can have, and how different team members might interact with them.
The ‘system thinking perspective’, explains that because of their different points of view, each stakeholder involved in developing a system will have their own ideas on how one system might be best used. Here we find the definition of a system: it is something tangible — not a concept — which is interacted with by different users in different ways.
In the context of software systems, if the system does not achieve the goals set by those building it, it might be necessary to go back to step one and build the whole system again from scratch. This happens often when systems are built based on unrealistic expectations and requirements — the impact on time and cost can be huge.
To minimise the risk of this happening, the needs of every stakeholder in the system must be considered, and their requirements should be used to formulate an idea for a system which will deliver real value to its users. Without creating value for each stakeholder, the system is unsuccessful.
Emergence — how system properties interact
In order to be able to meet the needs of every stakeholder, we must first understand the properties of the system we are building and what happens when these properties interact. Take the idea of chopsticks for example — one stick (one developer’s perspective) and another stick (another developers perspective) are used together to create one system (chopsticks) for eating food, whereby the problem of being hungry is solved. This is known as emergence — the result of parts coming together to form new outcomes.
Each developer will have their own ideas on how to prioritise these properties. A team with the correct roles in place — product owner, SCRUM master, technical lead, etc — must then work together to ensure no requirements have been missed, and that they are clearly prioritised for development. Combining the right skills and perspectives helps build a 360-degree understanding of the system — two ideas about one system uses can solve many problems.
With a full understanding of how different systems work and interact, developers can recognise opportunities to use an existing system to tackle an additional problem, consequently saving money, or whether an entirely new system must be made. If the latter occurs, this will incur additional costs for the project, of both time and monetary value.
Holarchy — what systems are made of
To reap the maximum benefits of system thinking, we must know the concept of ‘holarchy’ — the idea that a system is made up of systems, which are also made up of systems. Take a building, for example (this is one system), made up of different floors (further systems), which are subsequently made up of rooms (even more systems). If a developer can recognise the boundaries of each system and how one relates to the others, they can develop with more assurance that things won’t break. Also, by understanding the limits of a system, we can also understand if it can be utilised for new purposes, or if a new one is needed.
The 4D World — how systems change
A system is a physical object — it exists on multiple planes and is affected by time. In a developer’s world, this means a system must be viewed as its servers, user interface and other physical components — not just code. Disregarding this can see developers work in a ‘tunnel-vision’ style, where they focus on code alone and disregard important factors like server speed or user experience.
These are elements that can fall under the responsibility of other team members like the DevOps engineer — but not always, and in every case a cross-functional approach where the developer thinks about their system holistically is best. Thinking about time, also, is important — a system needs to be set up to change easily in accordance to shifting external factors such as new requirements. The way to achieve this lies in agile development — making iterative changes to the system over time that can be easily fixed if needed.
Communication and System Thinking
When developing a system, explaining its functionality in a way that each stakeholder would understand is important. For example — you can talk cloud architecture with a DevOps engineer, but a Chief Operating Officer might only want to know the financial impact of cloud usage. With this in mind, you should work on learning to explain and define systems using different ‘languages’ to make it universally understandable for all those involved.
With a system thinking approach to building a system, there must be a clear plan in place whereby developers can pinpoint when they should be meeting requirements and achieving objectives. The plan should also clearly define the various functions, and the work which needs to be done to implement these functions. This, of course, requires a lot of time and effort. There are three main points which should be considered when developing a system:
1. Customer needs — What the client wants to gain through this work; targets which can be met with the help of the system, improved user experience, etc.
2. Opportunity — What opportunity does the project present to us? What is the business value? How will it benefit stakeholders?
3. The solution the system will deliver — how the teamwork will flow, based on the needs and interest of the stakeholders.
System thinking is not the easiest concept to understand because it does not only apply to software. However, it is vitally important in building resilient and successful systems. When the team involved in development can understand that systems are physical and have impact beyond just their sphere of development, they can build more holistically and deliver a better experience for all stakeholders.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.