indaField

You’ve probably all heard of Conway’s law. If not, check it here.

I’ve never been involved with a company where his law did not apply. It is shocking to see that in all these organizations the architecture indeed reflects that organization and communication structures.

The result is that you end up with an architecture that gets harder and harder to maintain. Especially when the organization and communication structures change, which often happens. Solutions that have been built a while ago, when waterfall projects were the norm and teams were working in silos, are now hard to grasp and maintain and evolve, because companies have transitioned to DevOps and Scaled Agile.

You first had a middleware team, a front-end team and a back-end team. Creating bottlenecks when developing multiple solutions with cross-dependencies. This is probably the hardest nut to crack. What to do?

First of all, having an architecture with front-end, back-end and middleware is not the issue. It becomes an issue when the middleware team starts to build all kinds of stuff to help get rid of issues in back-end and front-end systems. Building logic where it shouldn’t be. And having ownership of things the middleware team should not have ownership of.

So, make sure that you have teams in a Scaled Agile organization that work according to a number of strict principles. Especially around data ownership, service orientation, service ownership and business domain ownership. You most probably will still have specific teams in your release trains, that are specialized in hard platform stuff, related to data and integration. And keeping the underlying platform(s) up-and-running. But when strictly adhering to the (business-, information- and technology-) architecture principles chances are that better (maintainable) solutions will be built.

The issue also quite often lies in formal structures within organizations and the accompanying strict hierarchy. Instead of relying on specific functions within the organization, we should do our work based on roles. It’s much less worse when an architecture reflects the organization of roles than when it reflects the organization of functions. Transitioning to such a new organization paradigm is not something you can do overnight. So, during the transition, make sure to guide your teams. Both with regard to technology and principles and working together. This way you can keep them working strictly according to the core principles. In the end, we should be able to reverse our old practices and make sure we’re not bothered by Conway’s law anymore.