Decoupling organisations: the only way a product culture can thrive

This is a food for thought article and I hope you will see how this concept of "decoupling" extrapolates from IT and applications architecture to agile and product organisations, and maybe it will make you wonder (as I do) how can you have a real digital & product culture without this concept reflected in the company's organisation.

For those of you far from the IT world or without an IT background, let me introduce you (in non technical terms) the concept of "decoupling", mainstream practice since the mid 2010s for any new well designed application.

1. "DECOUPLING" IN APPLICATIONS ARCHITECTURE & IT

1.1 Definition

 A decoupled application architecture builds services and components independent from each other, autonomous and even to the point of being unaware of each other’s existence until interaction is required and performed in a standardized way (through APIs for example). You can see this logic in microservice architectures and any modern well designed cloud application.

We can distinguish 3 types of application architecture (for the IT guys: I am over simplifying here, the purpose is just to get the concept ??).

• Monolithic approach: all functions and services are mixed together and very tightly coupled. These are usually old legacy systems built around a single application "that handles everything".
• Layered approach: this is some first step towards decoupling, we create layers by some abstract logic like nature, instead of function, value, or product. Typical layers are "front-end", "back-end" and "storage".
• De-coupled approach (in this example microservices, but I will indistinguishably talk about services and components): each component is independent, autonomous and has all the required functions to work on its own (for example it might handle its own front, back and storage to function to work autonomously from everything else).

1.2 Advantages

 Some clear advantages emerge from a decoupled architecture:

• Agility for teams: being capable of quickly adapt to change handling the whole system, create autonomy in agile teams, reduce regression risks... a decoupled architecture helps agility in teams.
• Autonomy or isolation: isolated components are easier to maintain and evolve, avoiding the big regression problems in highly coupled architectures where changing a small thing can have a big snowball effect on everything else. Unavailability or problems in a component do not affect the normal use of the rest.
• Scalability: decoupled systems are easily scaled using elastic resources ( typically cloud based) that increase performance or availability just for the required service.
• Harmonious heterogeneity: components do not need to be homogeneous, each can use the best technology, language, stack... for its specific tasks. Homogeneity is relegated to interfaces and communication standards between services and components.
• Cost reduction (potentially): easier maintenance, controlled atomic availability (SLAs)... leads to cost control and optimization.

1.3 Drawbacks

 Decoupling is not a size that fits all, although its drawback are very well manageable with current practices.

• Architectural complexity: more autonomous components means harder to read overall architecture, a strong emphasis on interoperability needed to make it work is required. Handling errors and latency may suffer.
• Versioning complexity: each service/component will have its own lifecycle, versioning and release cycles, it might be harder to manage the overall product. Good practices around CI/CD and scaled frameworks like SaFe help on this topic: DevSecOps is crucial.
• Interoperability: as components/services are independent, interoperability and a common set of standards on how all communications should be handled is non negotiable. Think about API-first strategies.
• Data heterogeneity: data generated by each component needs to be easily accessible by others (particularly data teams and BI). Synchronization on data standards needs to be set.

2. WHAT ABOUT ORGANIZATIONS ?

Almost anyone starting a new well designed application will think about decoupling and most certainly today, try to set up a microservice architecture. This question seems a no-brainer for app architecture, yet, very few people actually question the organisation that is supposed to support this!

If we extrapolate to organisations from the previous concepts:

• Monolithic organisations are the ones with no clear roles, think about starting startups... Co-founders are tightly coupled and they are jacks of all trades...
• Layered organisations represent most traditional companies, usually around functions like: IT, marketing, legal, HR, business... or by abstract logics like channel or user type. Most traditional companies are even multi-layered (also known as "matrix organisations"), introducing the notions of projects and programs, or even products (but do not confuse them with true product-oriented organisations). Agile doesn't thrive here, with competing objectives, silos, lack of autonomy of the teams... You can read more in a previous article: Agile Management VS Matrix Organisations.
• Decoupled organisations are very rare (really decoupled ones), but most new organisations tend toward this model as Agile and Product (note the capital "P" for the culture) thrive in here. There are many frameworks gaining traction, some more mainstream than other (think about holacracy, or even more scaled agile framework like SaFe will go in this direction).

The big questions is: Why isn't decoupling a no-brainer for organisations as it is for the digital products (and their architectures) that they are meant to support?

At the heart of all transformation are people and they way they interact (= the organisation). You cannot have agility without decentralisation. You cannot have fast reaction times without autonomy. You cannot have a product culture without actual product teams...

And if you go back to the notion of feature teams or squads: these “2 pizza” teams (8-10 people) should be the building blocks of any agile and product organisation. We said Agile? That means: autonomous, self-organised, user & value-centered, adapting to change... Doesn't an agile and product team look much like a decoupled component?

And what about this "synchronisation" required on application architectures (the famous APIs)? Organisations and frameworks have artifacts and synchronisation events like "chapters", "guilds", "release trains" or even assemblies of somehow coupled squads into Tribes and Portfolios...

Digital transformation and product organisation transformation have been going on for years in traditional companies, and if we are honest with ourselves, with little rooted changes in the organisation and slow results for most companies. We wanted to change as seen from the outside, without actually changing much from the inside...

How many companies have really challenged the organisation in their transformation ? and I don't mean changing roles or department names, creating ad-hoc structures with exactly the same organisation or simply reshuffling leadership positions...

It makes me wonder... ??

Did you learn something or got inspired? Did it make you wonder? As always, don't hesitate to reshare, like and tell me what you think in the comments!