Practical System Thinking Principles - Part IV

In this concluding part of a 4-part blog post series, I discuss the last 3 of 10 system thinking principles using practical examples highlighting the debate between standardization vs. unique system design, the importance of context, and robustness vs. optimality as applicable to diverse socio-technical systems. Let's explore......

Systems, interactions, emergence, complexities, and other related words are part of the new lingo of the increasingly interconnected and evolving personal, career, business, governance world around us. It is therefore important to not only get familiar with the lingo and its meanings, but to also be empowered with the right mindset, skills, and tools to navigate the complexities to deliver optimal value out of these systems. This enables the effective design of new systems, optimization of existing systems, and/or fixing of broken ones.

System Thinking allows us to manage complex systems by breaking them into manageable sizes while keeping sight of the whole; focusing on the behaviors that define such a system driven by the interactions within the system, and between the system and its environment. In this four-part series blog posts in which I discuss practical principles of system thinking, I explore 10 principles that are applicable to various types of complex systems. In the first 3 posts in this series, I shared 7 principles that are applicable across various types and levels of socio-technical systems as listed below:

Part 1

Principle 1: The System as a synergy of subsystems

Principle 2: Addressing key stakeholder(s) needs effectively is the basis for Good System Architecture

Principle 3: Solution Neutrality as a first step for robust system design

Part 2

Principle 4: Principle of Right Level of System Decomposition / Abstraction

Principle 5: Principle of System Interface Value Delivery

Part 3

Principle 6: Principle of structure-enabled system Functionality – ‘The How-enabled What’:

Principle 7: Principle of Unanticipated Emergence

.... System Thinking allows us to manage complex systems ............focusing on the behaviors that define such a system driven by the interactions within the system, and between the system and its environment....

In this final post of the series, I round off the discussions on the principles by sharing 3 additional system thinking principles leveraging practical day-to-day concepts and examples to make the concept more applicable to the relationships, personal development, business, and other systems that we engage with daily. The first principle in this post addresses the balance between standardization and unique creativity in system design, and the second highlights the need to understand the context of a specific system to truly evaluate or design the system. The last principle discusses the trade-offs between having a system optimal for a single scenario vs being robust for a range of scenarios.

Let’s explore principles #8, #9, and #10.

Principle 8: Principle of System Architectural Uniqueness – In designing a system, it is important that there is an appropriate balance between ‘not re-inventing’ the wheel (standardization) and the unique creativity of addressing new combinations of customer needs, scenarios and uses

There is a temptation to replicate designs that appear to be targeted at similar stakeholders or use cases especially as part of a portfolio of products or as a replacement for an existing architecture. However, even with similar or same customers, the specific needs and scenarios of a new system may be slightly different from those for which previous systems were built. Hence, while previous product/service architectures provide insights for new system design and development, they should only be utilized as a base and only to the extent that it does not restrict the ability of the product/service to fully address dynamic customer requirements of the new system.

A very basic example of this principle is from a group tour that I participated in, of the Massachusetts Institute of Technology (MIT) USA Campus as part of orientation into the System Design and Management (SDM) program. The activity was done in small teams and a team member led my team through familiar routes from previous campus experiences which while completed quickly, resulted in the team missing out on some key campus locations that would have been discovered if the tour had been explored as a fresh exercise using the tour map as expected (and as done by some other groups) rather than just deferring to experience. So, as other teams displayed pictures of their discoveries during the exploration, my team was wondering how come we missed those. This also meant that instead of learning those routes in a relaxed atmosphere during the tour, some of them had to be learnt later under duress when, for instance, I had a class in the building or had to carry out an urgent task in those locations.

.... previous product/service architectures ......should only be utilized as a base and only to the extent that it does not restrict the ability ...... to fully address dynamic customer requirements of the new system....

The campus tour example is relatable to more complex examples and systems including complex machinery projects and business design or remodeling. The potential downside of blanket standardization in that it results in frustrated or disappointed stakeholders or even costly changes later in the life of the system to adapt the ‘standard’ system to current needs which potentially creates new unanticipated emergent effect as the new change impacts other components of the systems that have been originally designed to interact with the components being changed. On the flip side, the con of full uniqueness or reinventing the wheel constantly is the waste of valuable resources re-doing what has been done so many times already, losing out on the benefits of the institutional learning growth and synergies. Hence, balance is critical as the specific system may not be 100% unique but then a one-size fits all approach is dangerous. Previous designs, where related, must serve only as base to facilitate the design of the new. This is translatable to the field of personal development where the experiences of mentors can accelerate an individual’s growth, but must be applied selectively due to inherent uniqueness in everyone’s paths.

Principle #1 anchors good architecture on the ability to meet stakeholder needs, hence each architecture must be unique to the current customer needs even when leveraging the structures of the past. Imagine the example of some large multinational businesses with a one-size-fits-all business model approach to multiple Business units despite unique stakeholders. Such an approach is a recipe for stakeholder issues with potential performance impacts. So, while the core principles and deal-breaker practices integral to the identity of that organization must be replicated, unique processes may be required in different business units/entities to adapt the ‘organization system’ to the needs of the unique stakeholders of those business units to ensure that the business model is beneficial to the overall multinational business performance.

In the choice of uniqueness vs standardization, the context of the system is a key driver, as it creates the unique scenarios that drive the characteristics required of the system. Principle #9 explores this some more………

Principle 9: Principle of Contextual System Design – The larger environment (Context) in which a system fits drives the value of the system and defines the order or criticality of decisions in arriving at an optimal system.

Context is the larger picture in which the system operates, and this drives the functionality and value proposition. The context helps to identify some of the implicit stakeholder needs discussed in Principle #1. A design that checks all the boxes for use on earth may fail miserably if taken outside earth’s gravitational field into space. A design of a production platform topsides for an offshore harsh environment would be different from one designed for a shallow-water environment even if all the system components functionalities are identical. The decisions that are critical for each architecture is driven by the specific interactions driven by the context. For instance, in infrastructural design decisions, compact designs are favored in deep offshore as the specific requirements of steel strength and other properties driven by the environmental conditions mean that any increase in size translates to significant increases in capital cost. Hence, weight is a critical constraint that drives architectural decisions in deep offshore versus a land-based platform where footprint constraint may not be as critical. Similarly, the same type of furniture designed for use in different locations will be evaluated differently based on the dynamic situation created by the context of use, such as the need for waterproofing for beach use, increased durability for public park usage vs limited house use, etc.

On a personal note, I was once caught between a power tussle between two leaders, in which an innocent comment from me was misconstrued because of the existing issues. Hence without the benefit of the specific context, I had stepped on a proverbial landmine without realizing, and was shocked at the response I received to my ‘little’ request for action. This lines up perfectly with a quote credited to Robert Penn Warren that "Reality is not a function of the event as event, but of the relationship of that event to past, and future, events”. Hence in the analysis of or design of a relationship system for example, an understanding of the context in which that relationship exists is critical for the sequence of decisions that must be made in the design or analysis of that relationship. A relationship in the context of a toxic larger society needs to include additional layers of ‘coating’ to shield the effect of the toxicity on the specific system which may be different from one where the prevailing context is one of family values, societal harmony etc. Hence, as Kenneth Noland said, “For me context is the key – from that comes the understanding of everything”. In analyzing systems, a great tool or analogy for discussing context is the iceberg model which indicates that specific events seen are layered on patterns/trends, structures and mental models as the progressive substructures that are not always visible at the first view but which must be understood to transform, design or anticipate a system performance as opposed to reacting to the top seemingly isolated event.

.... The decisions that are critical for each architecture is driven by the specific interactions driven by the context....

So, the advice from Eliel Saarinen is, “Always design a thing by considering it in its next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan”. Every business system design decision, personal development system upgrade, relationship system evaluation, governance system optimization must factor in context as a story is incomplete without the context in which it happens to ensure that the final system delivers optimal performance.

A critical requirement of systems is that it is optimal for the needs of the stakeholders. However, some systems are used in multiple scenarios which creates the question of which scenario should the system be optimal for. Principle #10 addresses system design entrenched in agility and flexibility to changing scenarios, stakeholders, inputs, etc. So, here goes….

Principle 10: Principle of System Architectural Optimality/Robustness: Where possible a good system design should enable functionality in a changing needs / evolving needs environment. However, a robust design that is adaptable to a wide range of scenarios may require some performance trade-offs. Finding the right balance between robustness (adaptability to change) and optimality (best performance) is critical

Nassim Nicholas Taleb, an author and distinguished professor of Risk Engineering is credited with the quote: “Recall that the fragile wants tranquility, the antifragile grows from disorder, and the robust doesn’t care too much”, emphasizing the importance of robustness for a wide range of scenarios. A design that is optimal for a single or limited range of scenarios may fail woefully in another or wider range of conditions. How much changes to the original conditions/assumptions can your system take before a need for a revamp, upgrade, or outright replacement? The answer is determined by the robustness of your system. Given how dynamic the operating and business environment of today’s systems are, there is the constant need to build robustness into the system design. So why then is there a debate around robustness? The flexibility that robustness offers often requires trade off of optimal(best) performance(s) in specific scenarios to allow for optimal coverage for a range of options - ‘Taking one for the team’. This can sometimes be a tough sell given that all the potential range of outcomes cannot be guaranteed at the time of design.

While most architectures are based on some assumptions, in the actual operating environment these parameters often have a range of potential outcomes, or the single outcome may vary by a slight margin. Given this reality, the system design must be robust to some set of agreed range of potential outcomes. In financial parlance, for an investor, a robust portfolio will likely not contain only the best performing stocks but will contain a mix of investment options with varying risk levels to allow the individual to adapt to the changing cycles of various investment types. In personal development instances, the choices of job roles, industry adventures, development choices may require trade-offs in some instances to provide the overall robustness that allows such as an individual to be adaptable to a range of industries or roles. The extent to which a ‘system’ trades off single-instance optimal performance for robustness should be a function of the risk-appetite of the system architect and the stakeholders for which the intended system is designed to serve.

.... The flexibility that robustness offers often requires trade off of optimal(best) performance(s) in specific scenarios to allow for optimal coverage for a range of options - ‘Taking one for the team’....

In conclusion, bringing it all together…….

Building on the previous 7nos. principles of system thinking, this blogpost principles enable key enhancement decisions on the quality of all types of systems to ensure that such system is built appropriately, with the right context in mind and takes into account the range of outcome scenarios and impacts on single-case optimality.

To reflect on the applicability of these principles in your personal, relationship, spiritual, business, governance etc. context, a few questions must be answered:

Do you understand the characteristics required of your ______________ system? Do you understand the unique needs of the stakeholders of the system? Do you recognize what might be a standard base and where to build off on the unique requirements? Do you recognize the resources that will provide the standard base (literature, mentors, policies, models, etc.) to ensure that other resources are freed up to focus on the unique bits? Do you understand the next higher-level and overall context in which the system operates? How does the context impact the priority of decision-making for your system design (what are the most critical performance indicators of your system for the context)? How robust is your system design for a range of scenarios, evolving customer base and/or customer needs? Definitive answers to these questions help guarantee the quality of your system and relevance for a long time to come especially in the volatile, uncertain, complex, and ambiguous (#VUCA) environment in which most systems increasingly exist.

If you missed out on any of the previous principles, I invite you to read Part 1, Part 2, and Part 3 of this series that leverages day-to-day examples to drive home the principles applicable to systems of varying complexities.

The goal of this series has been to ensure that more people leverage the principles of system thinking to transform their lives and business by understanding them in the first place. So please let me know if this blogpost system has addressed your need as a stakeholder. Let me know in the comments, what resonates with you and which principle you will be applying in the coming weeks and months. The world needs a growing community of system thinkers to address our complex socio-technical systems and emergent issues.

Wishing you a transformational journey ahead.

Funmilola (Funmi)

#funmilolaasa #SystemThinking #funmilolaasasblog #interactions #SystemBehavior #SystemPrinciples #stakeholders #SystemsThinking #systemform #SystemInterface #systemdesign #DynamicInteractions #robustsystem #optimalsystem #context #systemcontext #uniquesystemdesign #standardization #VUCA #icebergmodel