Complexity

On the political challenge of IT system acquisition

August 9, 2023October 28, 2023 emlandreLeave a comment

My April 2023 On failed IT projects post did not address the political aspects of large scale IT system acquisition’s. The post is inspired by Dr. Brenda Forman’s chapter on the political challenge found in the book The Art of System Architecting, third edition, a book that is highly recommended.

The book addresses architecting of systems, and since a firms information technology, it be in the private or public sector is a system the systems architecting approach is applicable. For information technology to make any sense its structure must support the firm’s overall mission.

Politics as design factor

The bottom line is: If the politics don’t fly, the system never will. This is the case for any kind of system or technology program that require government funding. From a Norwegian perspective the National Transport Plan is a good example. Projects are moved up and down dependent of political climate. No project on the plan is safe before the funding is in place.

Architects must be able to think in political terms. According to Dr. Forman this mean to understand that political processes follows an entirely different logic than the logic applied by scientists and engineers. Scientists and engineers are trained to marshal their facts and proceed from facts to conclusion.

Political thinking is different, it do not depend on logical proof, but on past experience, negotiation, compromise, and perceptions. Proof is the matter of having the votes. If the majority of votes can be mustered in the parliament the project has been judged to be worthy, useful and beneficial for the nation.

Mustering the votes depends only in part of engineering or technological merit. These are important, but to get the votes on a regular basis depends more on jobs and revenues in electoral districts than technological excellence. It might be more important for an elected representative to have a project that keep local construction contractors engaged for the next five years than the value from the traffic on the road when its completed.

To help architects navigate the rocky political landscape the following heuristics or as they are called in the book, The facts of life:

Politics, not technology, sets the limits of what technology is allowed to achieve.
Cost rules.
A strong, coherent constituency is essential.
Technical problems become political problems.
The best engineering solution are not necessarily the best political solution.

Another observation is that political visions don’t fly without feasible technology and adequate funding. Example: In 2007 Norwegian prime minister Jens Stoltenberg uttered the following in his new year’s speech:

Our vision is that within 7 years we will have in place the technology that make it possible to capture carbon from a power plant. This will be an important break through for Norway and when we succeed the world will follow. This is a big project for the country. It’s our moon landing.

Sixteen years later; the technology does not exist and nobody talks about it. In the end there were no constituency, no funding and no politics to make it happen. The problem with such political dreaming is that it diverge effort and resources from things that could have been done, the small steps of improvement that over time could make a difference.

More troublesome are funded initiatives where the political accepted solution does not solve the operational problem at hand. My first encounter with such situation was back in 1990. A part of Norwegian government should spend a billion NOK (a heck of a lot of money) on computers without having a clue about the software to be run on those computers.

Enterprise information systems find themselves in an ill-structured and even complex problem world. Ill-structured problems are problems where the users don’t understand their needs before they see a solution. Complex problems implies that its deduct a solution from an analytical process. The only practical way to solve such problems is by experimentation. More on that can be found here.

Systems architecting in political sensitive environments is an act of balancing conflicting complex systems. Political processes are complex in their own way and the same said about the operational context shown in figure 1 below.

Figure 1: Systems architecting – an act of balancing conflicting interests

Be aware that the end-users who live their lives in the operational context are not the same as the client paying for the solution in the political context. This is definitively the case in the public sector and its often the case in larger enterprises. To showcase the point lets explore a real world case that has run into trouble.

Case

Helseplattformen, is a large scale, highly complex health care IT project that according to the press suffers from cost overruns, delays and severe quality issues. Helseplattformen decided to acquire a commercial product from Epic Systems for what under any circumstance is a ambitious functional scope. A shared patient record across hospitals, general practitioners, specialists and municipal institutions in one of Norway’s health regions.

Reported problems included lost data, record lockings, cumbersome user interfaces and general instability, all leading to patient safety concerns. The fact that users in Denmark, UK and Finland had faced severe problems priory to the Norwegian acquisition make the situation even more dire. It shows that political processes might be ignorant to the facts on the ground. As the old proverb states:

Wise men learn from other mens mistakes, fools from their own.

The timeline (below) tell a story about a classical waterfall approach where potential issues are pushed to the end of the project, to first use when the cost of change is at its highest.

2015 – pre-project started
2017 – acquisition project started
2019 – contract signed with Epic Systems after tendering
2020 – lab module implemented but postponed due to Covid-19 pandemic
2021 – municipalities joining after political decisions
2022 – first use set to April, problems materialise
2023 – problems continue

The project stand out as a schoolbook example of how to fail, leading to the question what could have been done differently? Firstly, capture the essence of the problem in a context map (figure 2) and develop a firm problem statement. Secondly develop alternative options and assess them. Finally, choose the best option, typically the one that is least intrusive and risky to implement.

Assessment

Given that electronic health care records has been used for decades, all parties have working solutions today. The problem on the table is to create a EPJ that is shared across all parties. Such EPJ can be achieved in two principal ways.

Acquire a new integrated system and enforce it on all parties
Isolate the shared EPJ and integrate applications using API’s

Helseplattformen opted for alternative #1 by choosing an integrated solution from a vendor. Alternative #2 can be realised in two principle ways. By using a federated model according to the EU Data Spaces approach, or by using a centralised model according to the library model. Alternative #1 is tightly coupled and intrusive. Alternative #2 is loosely coupled and nonintrusive.

It is understandable that an integrated system from one vendor looks tempting for decision makers. From 35000 feet Epic Systems with a 78% US market share feels as a safe bet, but transporting a product made in one operational context to a complete new context driven by a complete different vision is most often a painful exercise. The only available approach to dig out the differences between is by paid up-front testing and evaluation of the product before any decision is made.

Products

Products, commercial or open-source is the key to cost efficient realisation of enterprise information systems. Products come in three forms. Large scale integrated products as Epic Systems and SAP. End user productivity tools such as MS Office and Google Docs, and technical components, libraries that are used by developers, they being in the enterprise or in the product space.

The crux with any product is the context that created them in the first place. A product developed for a specific context might be very hard to transport to a similar context in a new market. The larger and complex the product is, the worse it becomes. Therefore the only practical approach is to test before any decision is made. This is time consuming and expensive, but there are no short cuts when dealing with the complexity of mission critical enterprise information systems.

Conclusion

Politics rule information system acquisition processes and the only way to balance out political ambitions with operational excellence is systems architecting. Helseplattformen shows that enterprises need to strengthen their information technology system architecting capability and make it part of their business strategy function. As digitalisation become more and more important the need for digital savvy board members become evident.

Enterprise architects must move out of IT and start serving the business. To do so the enterprise architects must develop design skills and master richer modelling tools and approaches as described in my previous blog post on Object-Oriented Enterprise Architecting and in the next post titled on the essence of system design. It also mean to to work the political and technical realms equally.

An to help us remember why up-front systems architecting is important, lets quote Plato, 400BC.

All serious mistakes are made in the first day.

If the assumptions are wrong, the result ……

Object-Oriented Enterprise Architecting

July 11, 2023August 3, 2023 emlandre1 Comment

Object-Orientation

Object-orientation a.k.a object-oriented thinking / modelling / programming is a way to explore real world complexity by turning real world elements into interacting “objects”. A restaurant, as an example can be modelled as a set of interacting objects representing concepts such as guests, tables, waiters, cooks, orders, bills, dishes, payments and so on. Object-oriented modelling can be conducted by rudimentary tools as as illustrated in figure 1.

Object-orientation goes back to the late 1950ties, but was first made available for broader usage with the Simula programming language in the mid 1960ties. Simula inspired new object oriented languages such as Smaltalk, C++, Java and many more.

Object-oriented programming lead to the development of object-oriented analysis and design, and more formal and powerful modelling techniques and languages such as UML (Unified Modelling Language), SYSML, ArchiMate and AKM (Active Knowledge Modelling) to mention a few. It can also be argued that EventStorming, a collaborative workshop technique is object oriented.

On the dark side, object-orientation does not protect agains poor practice. Poor design practice leads typically to tightly coupled systems, systems that become expensive or even impossible to adapt and enhance as technology and business change.

Design Patterns

Design patterns is one way to enhance design practice by provision of tangible abstractions and concepts that help practitioners to create more healthy structures. Patterns originate from civil architecture and is attributed to Christopher Alexander and his work on pattern languages for buildings and cities.

The Gang of Four (GoF) 1995 book Design Patterns – Elements of Reusable Object-Oriented Software was the first book that introduced patterns for object-oriented software development. The book is still relevant and highly recommended as an introduction to patterns.

Another seminal book that embrace patterns is Eric Evans 2003 book Domain-Driven Design: Tackling Complexity in the Heart of Software. Eric argues that business problems are inherently complex, ambiguous and often wicked, and therefor must the development team spend more time on exploring domain concepts, and to express and test them in running code as fast as possible to learn.

Eric argues also for the importance of a common language in the team, the ubiquitous language, a language that embraces both domain and technical concepts. OrderRepository is an example of such language that make equally sense for subject matter experts and developers alike. It enables conversations like: orders are stored in the order repository and the order repository provides a function for creating and finding orders.

EventStorming is framed around the discovery and capture of three design patterns: Commands, DomainEvents and Aggregates as illustrated by figure 2.

The model reads that the doctor diagnoses the patient and add the diagnosis to the patient record. Then a treatment is prescribed, before the effects are checked at a later stage. EventStorming begins with capturing the capturing the events, and from them the commands and aggregates are derived.

There are particularly three software design patterns that I think should be part of every enterprise architects toolbox.

Command Query Responsibility Segregation (CQRS) separates read operations from write operations enabling a clearer thinking on what those things mean in our architecture. Data Mesh is not possible without CQRS.
Data Mesh is an architectural approach to manage operational and analytical data as products. Its enabled by CQRS and it comes with its own suppleness.
Event Sourcing is based on storing changes as independent events. Bank accounts works this way as each deposit and withdrawal are stored as a a sequence of events, enabling the account to answer what was my deposits on a particular date back in time. Event Sourcing should not be conflated with Event Storming which is a workshop methodology.

The motivation behind the claim is that these patterns shape the architecture and the architects thinking. By knowing them the architect can make rational judgments with respect to their relevance in a given context.

Enterprise Architecting

Enterprise architects have used object-oriented concepts for years taking advantage of modelling languages such as UML, ArchiMate and others. Architects with interest and understanding of agile methodologies might also have explored EventStorming workshop techniques.

Independent of technical tooling enterprise architects face a growing challenge as enterprises digitalise their operating and business models. Take our healthcare model and scale it to a hospital or include multiple hospitals, the primary health services and elder care. In such environment you will have solutions from multiple vendors, solutions from different technical generations, and solutions that are outside your own control. Add then that sector is political sensitive and full of conflicting interests.

The catch being that this is not unique for healthcare but is the nature of the real world. Real world business problems are most often wicked or complex. Scaling up forces architects to slice the problem space into useful modules that can be managed independently. Such slicing must be done with care as coupling and lack of cohesion will haunt the chosen architecture.

The architectural crux is to get the slicing right. Sometimes this is easy as system boundaries follows natural boundaries in the domain. But this is not always the case as many enterprises have ended up with dysfunctional structures that leads to fragile and error prone handovers. Handover of patient information in the healthcare sector is a good example. The catch is that handovers are everywhere and its effects are loss of critical information and rework.

Strategic Design

Domain Driven Design offers a technique that help us model the slicing of a large model called Bounded Context and Context Mapping. Applied on our healthcare example we can create something like the diagram in figure 3.

Bounded Context are organised into a Context Map that captures the relationships between various bounded context. Adding to the complexity, each bounded context might need access to different aspects of the patient record. Example, pharmacies have no need for individual food constraints that are relevant for nursing homes and hospitals.

Making this even complex is the fact that all these contexts can be further decomposed as in figure 4. Add to this that in the case of an individual patient, specialists from different contexts need to collaborate to decide upon the path forward. It’s normal for surgeons, radiologists and oncologists to discuss a x-ray image of a tumor. Such trans-discipline collaboration is critical for problem solving, and its in these interactions balanced solutions to hard problems are shaped.

Figure 5 present two architectural alternatives, distributed and centralised. In the distributed architecture each bounded contexts is free to have whatever system they find useful as long as they are able to send and receive patient record update messages (events).

In the centralised architecture a new shared bounded context that manages the patient record has been introduced and the “operational” contexts accesses the shared and centralised record management system. Which one of those alternatives are “best” boils down to tradeoffs. Both come with strengths and weaknesses.

What matters is how we choose to pursue implementation. The crux i distributed architectures boils down to message standardisation and the establishment of a transport mechanisms. Centralised architecture can be realised in two principle ways.

By using an old school integrated application with user interfaces and a shared database. Then force everybody to use the same solution. Integrated means tight coupling of user interfaces and the underpinning data / domain model into something that is deployed as one chunk.

By developing a loosely coupled application or platform based on API’s that can be adapted to changing needs. Loos coupling means that the data management part – the record keeping is separated from end user tools along the lines described here.

Making the wrong choice here is most likely catastrophic, but beaware that all alternatives comes with strengths and weaknesses. To understand the alternatives feasibility a bottom-up tactical architecting endeavour is needed. Such endeavour should take advantage of battle proven patterns and design heuristics. In the end a claims based SWOT (Strengths, Weaknesses, Opportunities and Threats) analysis might prove its weight in gold.

Tactical Design

Tactical design implies to dig into what users do, what information they need for doing what they do and to develop the information backbone that shapes the sector’s body of knowledge. Evaluation of implementation alternatives require tactical level design models as the devil is in the details.

Tactical design is best explained using a practical example taking advantage of the capabilities provided by the AKM (Active Knowledge Management ) modelling approach. What make AKM different from other methods and tools is its dynamic meta models. The example model in figure 6 exploits the IRTV (Information, Roles, Tasks and Views) meta model. A deep dive in AKM modelling and meta-modelling will be addressed later.

The example builds on our healthcare case, and the purpose is to highlight the main modelling constructs, their usage and their contribution to the model as a tool for enlightened discussions, and future tradeoff analysis.

Healthcare can be thought of as stories about patients, diseases and treatments and that is what we will try to demonstrate by our toy model. Take note of the fact that some Information datatypes and Views have suggested types that can be used to create a richer and more domain specific language.

Be aware that diseases might have multiple treatments, and that a treatment can be applicable for more than one disease. This is by the way a good example of the “muddiness” of the real world where everything one way or the other is entangled.

Figure 6: AKM Enterprise Architecture Model

The model in figure 6 captures two stories. The first story present a patient consultation session where the GP diagnoses a patient and updates the patient’s medical record. The second story shows how a researcher updates the treatment protocol.

At this point the sharp-eyed should be able to discover a pattern, and for those who don’t please read Reinventing the Library before you start studying figure 7 below. Here the model from figure 6 is restructured and simplified so the key points can be highlighted.

Figure 7: Simplified Enterprise Architecture with Bounded Contexts

Firstly, the sector’s body of knowledge is structured around three concepts that are managed in a “library”. Such library could of cause be extended to include infrastructure components such as hospitals, caring homes, and even staffing. It all depends on what questions the enterprise want to answer and accumulate knowledge about.

Secondly, the design of functional domains by grouping related tasks into what DDD defines as bounded contexts. This design task should be guided by the key design heuristic; maximise cohesion, minimise coupling while reflecting over what can be turned into independent deployable’s if the architecture should take physical form as software applications.

Lastly, views as the key to loose coupling and as artefacts that need to be rigorously designed. Views are the providers of what AKM call workspaces. The model above contain two types of views. The first type is used to separate roles from tasks within a bounded context. This view is typically visual and interactive in nature as its designed to support humans. For those familiar with multi-agent design such view could be seen as an agents environment as explained here.

The second type of view are those that bridges between cohesive functional domains and the underpinning library. These views can also be used to create interaction between operational bounded contexts as can be seen in the case of the Diseases View in figure 7.

View would benefit from being designed according to the CQRS pattern, basically separating commands from Queries as shown in figure 8. In addition to queries and commands can views be the home for transformation, event processing and communication. In a software context views exposes domain specific API’s, they represents bounded contexts and they can be deployed independently as architectural quanta’s. Again the sharp-eyed should see that views might be the key for those who want to think in terms of data mesh and data products. A data-mesh boils down to transforming data so the data can be served to fit the consumers needs.

For those of you who are still here a couple of words about knowledge and the theoretical framework that motivated this post – constructor theory.

Constructor theory

Constructor theory or the science of can and can’t is a rather new theory in theoretical physics developed by David Deutch and later Chiara Marletto at the University of Oxford. The essence of constructor theory is that physical laws can be extended to cover what transformations are possible or not. This implies that Physics can be used to define concepts such as information and knowledge.

A constructor is a “machine” that can perform transformations in a repetitive way and to do that transformation it needs a “recipe”. A factory that create airplanes or cars are examples of constructors. Its the institutionalised knowledge in those entities that make it possible to mass produce samples over time with quality.

If we now revisit figure 7 and 8 it should be obvious that what we have architected could be understood as constructors. An that should not come as a surprise since constructor theory defines information by using two counterfactuals; the possibility of copying and of flipping (change state). Knowledge is defined as self preserving information.

My advice to enterprise architects is to read The science of can and can’t – enjoy as it is the perfect vacation companion.

On change management

April 10, 2023April 10, 2023 emlandre1 Comment

Change management is used as a collective term for all approaches to prepare, support, and help individuals, teams and organisations to change. I was challenged by a colleague to put forward my thoughts after she had read my previous post on digitalisation as a complex undertaking.

Change implies that something go from one state to another as water during its phase shifts from ice to floating to gas. Change management boils down to the management of the phase shifts, the transitions, the in between’s than the end states. How difficult this can be can be tested at home by boiling milk. Be prepared to clean up or pay attention to what takes place in the kettle.

The history of change management goes back to Kurt Lewin‘s work on group dynamics and change processes in the first half of the 20th century. At the time of his death in 1947, Lewin was seen as on of the foremost psychologist’s of his day. Today is Lewin best known for his three step change-model, also known as the unfreeze-change-refreeze using using an ice block as metaphor (fig. 1).

Fig 1. Lewin’s Unfreeze-Change-Refreeze model

The challenge with this model is that enterprises pay to much attention on the as-is and the to-be, while ignoring that success or failure is down to the nature of the phase shifts themselves. How this take place is best illustrated by the anatomy of a typical enterprise change process:

A problem or assumed short coming has been identified and the board of directors establish a project that is tasked to find solutions and propose alternative course(s) of actions.
The board of directors decides to implement one of the proposed solutions and kicks off an implementation project tasked to implement the recommended changes.
The implementation project create new organisational units, move people around while people do as best they can to make the wheels turn around.

I know I am tabloid here, but the most important takeaway is that such plan driven approaches does not work. The documentation is overwhelming, and still enterprises stick to the practice. What has proved to work are initiatives founded on lean and agile principles, principles that take into account that the challenge is the transition, not the end states.

Timing change

One reason old practices stick for to long can be found in Clayton Christensen work on disruptive innovation and product lifecycles where a product follows overlapping S-curves. Enterprises with profitable products are almost resilient to change. How Apple’s iPhone knocked Nokia out of business is one good example. Same is how the minicomputer industry was eradicated by the micro-processor in 1989-91. What was perceived as a healthy industry was gone in 18 months.

Dave Snowden has taken this understanding to a new level with his flexuous curves and the liminal moment (the yellow zone in figure 2) that marks the opportunity window. It shows that the change window is when your product is dominating. This is also a reason why changing is so hard.

Fig 2: Credit to Dave Snowden and the The Cynefin Company

Many enterprises stick to old practice despite that the evidence for change is overwhelming. This does not stop with products, but is applicable to work practices as well.

Leading change is hard

Disruptive innovation and flexuous curves can help us to better understand why and when change might be favourable, but they offer no help when it come to leading change efforts. Carl von Clausewitz might be one of the first who put words on the hardship of change in context of a complex system in his seminal 1832 book On War where he state:

“Everything is simple in war, but the simplest thing is difficult. These difficulties accumulate and produce a friction, which no man can imagine exactly who has not seen war.”

War, or battle to use a word that is more representative of 19th century reality can be understood as the dynamic state transition from pre-battle to post-battle that consists of timed and coordinated movements and counter movements of competing agents (armies). The competition ends when one or both sides have had enough. Each force being a interlinked hierarchical network of units built from individual agents and equipment.

There are two main takeaways from the war analogy.

That business and change processes can be understood as timed and coordinated movements of resources and therefore face “friction”. Today we would not talk so much about friction but that businesses and enterprises are examples of complex systems.
That the Prussian general staff under the command of General Helmuth von Moltke developed a new leadership style called mission command that is still used, a leadership style that emphasis subordinates to make decisions based on local circumstance in their strive for fulfilling the superiors intent. Stephen Bungay explains how these principles are relevant and can be repurposed for business in his book The art of Action.

To conclude, leading change processes is hard because they come with friction (things does not work out in practice as planned) and need a different leadership style than bureaucratic top down linear plans to succeed. This also challenge the way leaders are identified and trained.

An individuals leadership practice is an emerging property that is shaped by the context, and therefore can’t be copied. This breaks with the idea that a good leader can lead anything. This mean that its most likely different personalities that succeeds in operational contexts versus say a product development context. As individuals climb the corporate leadership stair this become crucial. To put an individual who have excelled in one context believing that he/she will succeed in a completely different context is dangerous.

How to succeed with change

The literature is crystal clear on how to succeed with change processes. Initiatives that empower individuals to drive change as activists, initiatives where individuals are invited to contribute, and initiatives that move from managed to organic has the best probability to succeed.

To move from managed to organic is most likely the most important of the three. Kurt Lewin’s three step change model still guides how leaders think about change, the problem being that there is no room to be frozen any more. According to McKinsey we need permanent slush that enables constant experimentation with new operating models, business models and management models, adopting the practices required when dealing with complex systems.

A complex system has no linear relationships between causes and effects and can’t be managed by linear measures. This leaves us with three principles as pointed out here:

Initiating and monitoring micro-nudges, lots of small projects rather than one big project so that success and failure are both (non-ironically) opportunities
Understanding where we are, and starting journeys with a sense of direction rather than abstract goals
Understanding, and working with propensities and dispositions, managing both so that the things you desire have a lower energy cost than the things you don’t

Be also aware that its the alternatives with lowest energy cost that will win in the long run. Thats the reason point #3 is so important. We need to make what we will like to see more off cheaper than what we will like to see less off. These things must be anchored in the stories or narratives told by those who experience the existing reality and who in the end owns and lives with the changes.

Summing up, literature is crystal clear on what is the best way to approach change process. It boils down to knowing where you are, move in small steps and maintain a direction. Given the facts, why do enterprises stick to their old failed practices. To answer that question we must address some of the counter forces in play.

Counter forces

Counter forces come in many facets.

Old habits are hard to change, as everybody knows who have tried to change a undesired behaviour. Enterprises are structures with internal friction and change resistance that take many forms. Not invented here might be one. Short term energy expenditure might be another.
Lewin’s original model is linear, easy to grasp and leave senior leadership with the illusion that change is a final game that can be managed top down. I personally think it feels better from an ego’s point of view as well. Last but not least, its an easier sell for management consultancies providing case studies and best practice.
Procurement processes. Many change processes related to introducing new digital capabilities involves procurement of new technology. Procurement processes require that you know what you need. One thing is to buy 100 car’s or 5000 meter with drill pipes. Digitalising a business process something completely different.
Perceived senior management risk. Executives seek ways to reduce the perceived risk. One such way is to have contract. In the 1980ties nobody was fired for having signed on with IBM. My theory is that this boils down to psychology. Late sports psychology professor Willy Railo stated back in the 1980ties that “you don’t dare to win if you don’t dare to loose”. In other words its the fear of failure that trigger the behaviour that leads to failure.
Approaching business as a finite game. Business and change processes are infinite games, but due to various factors leaders behave as their finite. A finite game is a game with fixed rules and time (football). An infinite game is a game that never ends and enterprises that acknowledge that their in it for the long run will benefit. To learn more check out this link. The main problem might be that funding might be finite as in the case of public sector initiatives that are run by budget allocation.

As we can read, there are many factors and counter forces in play. Some of these are most likely unconscious such as fear, others boils down to ignorance and laziness.

Synthesis

Change management has been with us for a while and literature is clear on what it take to succeed with change. Experiments, involvement, empowerment, small steps, continuous adjustments based on feedback and so om.

Despite this many enterprises stick to plan based approaches with failure in the end. There are many forces that leads to this, one being the finite nature of budgets, and particularly budgets that are managed by political processes.

To me this is at the stage where we know what to do, so its just go do it in ways we know work. Adapt agile practice and begin navigate the maze.

Two recommended readings are the EU field guide on crisis management and this article on Safety Interventions in an energy company. Teaser provided from it’s abstract

The paper describes a case study carried out in an electric utility organization to address
safety issues. The organization experiences a less than satisfactory safety performance
record despite nurturing a culture oriented to incident prevention. The theoretical basis of the
intervention lies in naturalistic sense-making and draws primarily on insights from the
cognitive sciences and the science of complex adaptive systems.
Data collection was carried out through stories as told by the field workers. Stories are a
preferred method compared to conventional questionnaires or surveys because they allow a
richer description of complex issues and eliminate the interviewer‟s bias hidden behind
explicit questions.

The analysis identified several issues that were then classified into different domains (Simple,
Complicated, Complex, Chaotic) as defined by a Sense-Making framework approach.
The approach enables Management to rationalize its return on investments in safety. In
particular, the intervention helps to explain why some implemented safety solutions
emanating from a near-miss or an accident investigation can produce a counterproductive
impact.
Lastly, the paper suggests how issues must be resolved differently according to the domain
they belong to.

Next post will be on failed IT projects.

Digitalisation; a complex undertaking

March 1, 2023March 8, 2023 emlandre3 Comments

Complexity is the result from something with many parts that interact in multiple ways, following local rules that lead to nonlinearity, randomness, collective dynamics, and emergence. Emergence represents the concept of being more than its parts, its unpredictable properties or behaviours created by the many interactions.

Human societies is one example of a complex entity or system. Both the Chinese Covid-19 protests and the 2022 Iranian turmoils are examples of how emergence can materialise from a state that at outset looks calm or stable.

Other examples of complex systems are traffic and traffic control, Earth’s climate and biological eco-systems, warfare, and firefighting. Of these traffic and traffic control are man made where safe and secure behaviour is maintained through simple rules. Earth’s climate is a different beast with its unknown and even unknowable relationships.

Digitalisation

What is less understood is that digitalisation is a complex undertaking. Digitalisation boils down to retrofitting human enterprises with new digital tools, tools made from computer software, tools enabling change of business and operating models.

There are several factors that contribute to the inherent complexity.

Firstly, digitalisation impacts the interactions in human organisations that are complex systems before the technology arrived on the scene.
Secondly, computer software captures and materialise human ideas and thoughts with the caveat that its impossible to predict the effect of an idea before its tested. The effect being that digital tools are shaped by their creation process and context.
Finally, the fallacy that buying a off the shelf solution makes the organisational implementation or retrofitting easy.

All digitalisation initiatives begin with a promise that the new technology / solution and new ways of working will be for the better. In most cases the opposite is true, most often large scale digitalisation efforts goes wrong or at least run into severe problems.

“Helseplattformen“, a Norwegian health care digitalisation effort that has ended up in the news lately due to problems. The scope is a new integrated patient record system across multiple hospitals, specialists and GP’s in one of Norway’a health regions. According to the news from January 2023 3.8 billion NOK’s have been spent and its expected that additional 900 million NOK is needed (who belive in that?). One thing is the costs, more important is the impact on the daily health service production for 720.000 inhabitants.

This is just one example out of many. I have personally witnessed several dosens failed digital or IT related initiatives during my career, leaving us with why. Why do these undertakings run into trouble and why are we not able to learn?

The simple answer is that digitalisation is a complex undertaking as enterprises are complex adaptive systems with non-linear and unpredictable cause-effect relationships. To explore what that mean in practice is it time to turn to Dave Snowden and his Cynefin sense making framework.

Cynefin

Cynefin, pronounced kuh-nev-in, is a Welsh word that signifies the multiple, intertwined factors in our environment and our experience that influence us (how we think, interpret and act) in ways we can never fully understand.

Cynefin divides the world in two, the ordered world to the right and the disordered world to the left each world divided into two domains separated by a liminal zone. In the clear domain there is a direct response from what is sensed and an appropriate response and the domain is governed by best practice. When best practice fails, we fall off the cliff into chaos. In the complicated domain the relationship between what is sensed and the appropriate response require analysis and expert judgment. There can be more than one solution to a problem and it requires good practice.

In the disordered world we find the complex domain and chaos. In the complex domain there is no linear relationship between what can be sensed and the appropriate response. The only way to deal with the complex domain is to probe, then sense and finally figure out what to do. This is the domain of experimentation and its a domain that require exaptive (repurposing / innovative) practice. We discover that something we have can be used to solve something we never had thought about.

At the bottom we find the chaotic domain where the only way forward is to act, then sense and respond. When in chaos practice is made as we go.

The liminal zone is split in two; A – aporetic and C – confused. Being confused in context of Cynefin implies not knowing what domain we are in and therefore we end up using the wrong approach to the problem at hand. Addressing a clear problem as it was a complex problem by running experiments is not effective. The opposite is worse, addressing a problem in the complex domain as it was clear or complicate leads easily into chaos.

Being in the aporetic zone we know we deal with unknowns and even unknowables and choose to use that insight to our advantage by running parallel experiments. This is what agile software methods like Scrum do and it goes even further. Hackathons are structured visits to chaos where we do stuff and figures out what we learnt when finished.

By accepting that digitalisation is a complex undertaking that requires enabling constraints, exaptive (repurposing) practice and a probe-sense-respond approach is the key to success. We must stop approaching digitalisation as it is in the ordered world using linear processes and thinking.

Enterprise practice

Enterprises, they be in private and public sector trives in the ordered world. The beliefs in “ordung must sein” can be overwhelming. There are routines and processes for everything. That said, there are thousands of things that need to be done within an enterprise that fall into the clear and complicated domains.

Problems pile up when topics belonging to complex domain is approached and managed as it is complicated or clear. Digitalisation and software development are two such things. Some enterprises uses task forces when something serious have gone wrong. This is a wise thing to do when you have felt over the cliff into chaos and need to find a way back to order, but its reactive in nature and it will never prevent them from falling over the cliff next time.

The catch is that when a complex problem fails, the path toward chaos is linear. What and why it went wrong can be explained, but it can’t be prevented without deep change to the culture and governance model.

Enterprises must train their leaders and employees to work experimentally with digitalisation and improvement. Admiral Nimitz understood this 80 years ago, it should be within reach for todays enterprise leaders as well.

Enjoy the story and embrace complexity. Its a wonderful world of opportunities.

Nimitz

When the US Navy entered WWII in 1941 it was equipped with two new technologies, radar, and VHF radio. Technologies that were expected to enable better understanding of the battlefield and clarity in the decision making. It was the opposite that happened. The new technology contributed to confusion and disaster.

Admiral Nimitz and his staff understood that something had to be done and decided that each ship should have a new function, a Combat Information Center (CIC). Since once size does not fits all, he decided that each ship should experiment with how to implement the function allowing them to nurture what worked. For more details read the book [link].

The output from the CIC was a plot representing the ships understanding of the battlefield, own and enemy resources from interpretation of radar and radio traffic. There are many things that can be learned from this 80-year-old story. Firstly, that what Nimitz and his staff did was to use exaptive practice, they repurposed plotting that the Navy had used for decades. Secondly, he probed by running parallel experiment governed by enabling constraints e.g., that every ship should have a CIC, while its design was adapted to ship type.

During 1943 as the experimentation continued the CIC evolved from being an information system to becoming a system of distributed cognition. This evolution came from practical combat experience leading to the CIC being tasked to use weapons in given situations. All in all, the CIC both clarified and simplified the work of ship command.

Ultimately the CIC became a system of distributed cognition fully integrated with the ships command functions. The work of making sense of available information was shared across different roles that distributed the cognitive load, and allowed for rapid assessment, analysis, synthesis of incoming information using visual plots as a symbolic information system.

Conclusion

The US Navy’s CIC is an example of how to address a complex challenge using Cynefin’s recommended approaches. Nimitz use of safe-to-fail experiments, exaptive practice and enabling constraints unlocking his subordinate’s creativity enabled new unanticipated solutions to mange shipboard information. Nimitz deliberately avoided imposing solutions and instead created the conditions for a solution to emerge. He provided direction and used regular feedback loops to amplify useful approaches and dampen the less useful ones.

For those in doubt, this is the practice that digitalisation initiatives require.