Radical Decoupling

I want to introduce the concept of what I call “Radical Decoupling”. My premise is that every interdependency in business process, policy, systems and data has an inverse correlation to business agility. In other words, as interdependencies increase, business agility decreases. The reverse is also true – no interdependencies provide the highest amount of business agility.

Premise – As Interdependencies Increase, Business Agility Decreases.

Of course, dependencies in business process, policy, systems and data are necessary in any business. I would not debate that. I would however argue that many businesses are overly complicated because of the unnecessary interdependencies that have found their way into process, policy, systems and data.

The goal of Radical Decoupling is the following:

·      Decouple processes

·      Decouple policies

·      Decouple data

·      Decouple systems

Radical decoupling requires that a company value simplicity over complex processes. It requires that a company acknowledge that complex, highly interdependent processes and policies are not a value-add differentiator for the business. It requires that a company understand the cost (sometimes hidden) associated with unnecessary interdependencies. It requires that a company understand that the downside of the interdependency is reduced agility.

Setting your strategy around Radical Decoupling and actually executing against it is extremely difficult. It requires a new mindset and rigor around your Enterprise Business Architecture. It requires a level of governance that rarely exists. It requires a cultural shift in IT and your other business functions.

The major change in mindset revolves around the following: we have been trained to believe that we should focus on making it easier to connect IT systems – instead we should be focusing on not connecting IT systems. Radical Decoupling is a significant difference in mindset especially. It requires a significant design and architecture approach. Just because you can connect process, policy, systems and data does not mean that you should.

As a matter of fact, we talk about SOA and loosely-coupling our IT systems. SOA is all about making it easier to connect IT systems. Loosely-coupling IT systems is a design rule that still leaves us with dependencies across multiple systems – the main advantage of loosely-coupling is being able to disconnect those dependent systems if it becomes necessary to replace a certain technology or respond to a changing business process. But, with both SOA and loosely-coupling the primary goal is connecting things.

Imagine if the first rule of design was “do not connect to any other system”. The typical response to this design principle would be “that’s impossible - we have to". We guarantee that our systems will be designed to have a cascading dependency on each other in most cases. If you determined that you had to connect to another system, it would be seen as an exception.

The negative affect of creating dependencies across IT systems includes, but is not limited to the following:

·      Changes to one system break other systems

·      Testing costs are higher

·      Creating environments for development/test/stage are higher

·      Disaster recovery is much more complex

·      Performance tuning becomes more complex

·      Trouble-shooting becomes more complex

As a result of these affects:

·      IT costs continue to increase

·      IT’s ability to rapidly respond to the business’ needs decreases

·      IT is perceived as slow and expense

·      IT’s fear of making changes affects new technology adoption and innovation

In my next post I will discuss 'How' you go about Radical Decoupling....