Complex and Complicated Systems: The Wedge They are Driving between IT and OT

The connotations that have been given to these terms differ from person to person, but there are actual mathematical definitions for each.

To explain…

In a simple system, the inputs, transformations, and outputs are well understood. Numbers with +'s between them and a = at the end is a great example of a simple system. When you add many simple systems together the system gets complicated.

Similar to an equation, everything in a complicated system is understood, but scale makes things difficult.

The best way to think of a complicated system is through the analogy of a 2000 piece puzzle. At first, you don’t know where each piece fits, but there are clear steps to simplify the problem. You can begin by sorting the pieces, connecting the sides and concentrating on areas with distinguishing details. With every piece that finds its place, the puzzle gets easier until even your two year old can put in the last piece.

Many network switches, different models, and each with many lines of configuration code, is an example of a complicated system.

Complex systems are more like traffic jams. You can try to change routes but its likely that everybody has that same idea. Inevitably, congestion moves wherever you move. The only way you can get to your destination faster is if you have reliable intel in the form of traffic reports or traffic enabled apps.

The inherent problem with complex systems is they are not, and cannot be, well understood. They contain things like feedback loops and ‘contagion’ which cause some inputs to have an outsized impact on the system, while others have no impact at all.

Software start-up companies are an example of a complex system. Who would have thought that a messaging service that limits each message to 140 characters would become the dominant political application that Twitter has become?

How to tell if your systems are complicated or complex.

Eating the elephant

The goal in creating fit for purpose solutions, whether it is complex or complicated, is the same. You need to ‘simplify’ the solution and break it up into steps so that the elephant can be eaten one day at a time.

Industrial civilisations have a long history of simplifying complicated systems. It's called engineering and we have it integrated into our education systems and many engineering companies are listed on our stock exchanges. Eating complex elephants is a new thing.

The taming of the complex

Silicon Valley and millions of start-up companies across the globe have gone a long way to tame complex software development systems. ‘Agile’ developers stopped using the planning tools that served them so well with complicated systems and started to use the feedback systems inherent in complex systems to their advantage. Feedback cycles were shortened, and the scope of ‘testing’ activities moved closer and closer to the end-customer. The focus on responsiveness meant the features that customers preferred received a lot of development work, while others were quickly canned. These developments had a positive effect on software effectiveness and overall long term quality, but it means that the code that goes into production tends to be pretty raw and buggy – at least compared to what it used to be.

In addition to a tolerance of buggy code, tamers of complex systems have a different attitude when it comes to the network and computer infrastructure that their software runs on. Bigger is better and no constraint to responsiveness is tolerated. Fuelled by cloud computing, infrastructure is seen as a tap that can be opened as needed.

The clash of worlds in resource and manufacturing

Resource and manufacturing facilities are not complex. They are complicated and so are their operation technologies nerve centres. OT engineers follow engineering approaches and are operating in environments with a very low tolerance for risk. Afterall, some of these systems do have the potential to blow things up and cause fatalities.

On the other hand, at these same companies you have corporate IT adopting tools and mindsets to deal with the complex systems associated with software development.

Understanding real-life system mismatches

The clash of worlds implied by the term ‘IT OT convergence’ is clear. One organisation, but different (and sometimes opposing) systems, tools and risk mitigation techniques. At Denver, we are constantly speaking with clients who are experiencing this complex/complicated misalignment and how these challenges play out in the resource and manufacturing sectors.

Take bulk rail systems as an example. Complicated rail signalling systems predates the electronic age and have been largely responsible for reducing employee injuries per million train miles by ninety percent since 1980*. Into this well understood OT world enters the complex systems of Remote Operation Centres (ROC) and Machine Learning (ML) condition monitoring systems.

How do you meet ROC network requirements that include things as unpredictable as video conferencing without compromising signalling systems? Where do store the millions of pictures used in the Hot Box Detectors (HBDs) ML models?

Denver helped our rail customers to segregate their network infrastructure so that complex and complicated systems do not compete for bandwidth. We went through detailed cataloguing exercises to determine the nature of all systems and put in roadmaps to ensure each system is dealt with appropriately.

This includes both Business As Usual (BAU) and project activities. For BAU it is important to ensure the OT teams own the safety critical complicated systems and IT owns the complex systems.

With project activities it is important to use the right planning tool. For example, using agile methods to correct a complicated network problem may lead to under planning or not enough FEL (front end loading) planning. Or during development, a wrongly applied waterfall model causes resources to spend more time adjusting the plan and less on solving the problem. In this case, an agile approach would be a better fit, allowing teams to focus on the problems that need to be solved first, not managing the process.

The Denver approach to complex and complicated

At Denver, we see the opportunities for resource companies to bring together disparate approaches, teams and technologies into a common language to ensure the right organisational outcome is achieved. By pursuing opportunities of integration and alignment, we simplify the complex or complicated to ensure successful, optimised outcomes for all stakeholders.

Our specialist teams can perform extensive assessments, giving you the clarity you need on where your systems currently stand and where you need to go next.

* Bureau of Transportation Statistics (2022), Fatalities and Injuries of On-Duty Railroad Employees [ONLINE]. Available here.