Systems Thinking in Products & Platform design
Most of the time enterprises socialise themselves as a product development organisation, but do they develop products or a platform? What do they need? Why are Systems thinking important in developing products or platforms?
Before we move further let us see what is product and platform
Products: If you just need a feature to solve a problem you develop a product. Maybe a microservice to manage users, user profiles etc.
Platform: When you want to create value through interactions (multiple products/services interacting with each other). Amazon, and Netflix are typical examples of platform. It should be flexible for any business change and built for the long term.
Irrespective of products or platforms, before it is developed we need to know the purpose, who will be end-users of it and how failures are handled gracefully. Often this is missing, teams develop products under an impression that the end-users or consuming applications need to accustom to what is built or handle edge cases in their systems. This will not improve the product experience, causing failures, and increased error rates in the systems chain.
Let us analyse this furthermore with industry context, connected vehicles are popular nowadays with remote command & control functions, when you trigger a button in your mobile app the vehicle in a remote place has to ignite the engine. These will be platforms and the request flows across multiple applications each has its functionality to validate, process and send the request forward. Failure in one system due to release and deployment will fail the remote command and the engine will not be ignited. This would be a common scenario if applications are developed as products in a siloed way and are not ready to change need. The result is poor consumer experience and low remote command success rates. The reason for such occurrences is a lack of systems thinking and culture.
What are Systems Thinking?
Systems thinking is a way of making sense of the complexity of the IT Systems/ Solution by looking at it in terms of wholes and relationships rather than by splitting it down into its individual applications. It has been used as a way of exploring and developing effective solutions in complex contexts.
Often when developing microservices, Systems thinking has been missed due to the naiveness of the involved parties.
Adopting a Systems Thinking habit clearly helps to understand important connections between microservices and encourages a wide perspective, rather than just a focus on specific events from each of microservice. The Iceberg Model used in Systems Thinking provides a valuable framework to assist.
- At the tip of the iceberg — is an event or a happening. This is easily seen and recognised. For example, remote command failure.
- Below the waterline, not visible to observers are patterns or trends that happen over time. In the systems thinking example of command failure may be due to various reasons, system unavailablity, TPS more than anticipated, failures in other dependencies (apps, other services, DB, etc)
- Deeper under water are the underlying structures — the causes of the observed patterns. What could be cause, SLA breach, HA and DR not considered, DB Outage, etc?
- And finally, deepest of all are the mental models — the attitudes, beliefs and assumptions that allow structures to persist. In this example of systems thinking, SLA is not agreed to same level across all involved components (services, DB, apps) and / or HA/DR is not enabled across all involved services.
‘Zooming out’ (or looking ‘deeper’ under the water) is a powerful approach when seeking to understand how one thing influences another.
How to Apply Systems thinking in Platform & Product Design
Teams and stakeholders has to collaborate more, and should be flexible to listen and incorporate on what their internal and external consumer needs. Product teams / Microservice developers should embrace changes, look for opportunities continously to improve the system.
Most often I have seen Enterprise Architects and solution architects support in this aspect, and to nurture and incorporate systems thinking the teams have to work closely and aligned with those architects.
Few Things which will aide in Systems thinking
- Cultural change across the organisation — People, Process and Product.
- Ask 3Ws — when? what ? why ? — Then decide on How.
- Stringent monitoring tools for individual features (not for individual app) which cuts across multiple component.
- Agreed SLA, HA/DR across all the involved components in the platform.
- Graceful failure and Error Handling
