The strong and weak forces of architecture

I definitely see these forces at work at my current gig. In our context the lines separating what should be domain-specific boundaries are blurry. The main system is a monolithic codebase which was developed with a "wild west architecture" for over a decade before engineering leadership realized the tech debt was interfering with feature development. We've tried to draw domain boundaries but that initial lack of discipline meant that things were too far gone to easily separate them, and senior leadership has never been willing to invest in paying down this debt.

The points about shared tech and infrastructure hit pretty hard because it's a single monorepo deployed to homogeneous application servers. When we do bump up against issues with infrastructure we almost always end up building one-off shims. Our architects call them Microservices.

Code contribution is messy too. For any given feature, core functionality is typically owned by one team along with some of the downstream effects. The rest of the downstream effects are owned by other teams scattered across different verticals and often continents. It's rarely safe to change the core functionality of a feature by itself. Dysfunctional politics leads to projects getting delayed because of miscommunication and different priorities, and we can't risk encroaching on someone else's fiefdom. I recently burned a lot of political capital doing just that because a critical deadline was at risk.

9 comments and all are about pedantry.

I found the article interesting, and I wonder if anybody with more experience could give their 2 cents.

That was a helpful read, thanks. My company (also in Melbourne!) is probably one stage of growth beneath this. We have “verticals” and “teams” but don’t really have the layer in the middle yet (“domains”).

As we’ve grown from only a few teams, to multiple verticals, we’ve tried to jump straight from unclear boundaries and implicit APIs to fully versioned services and packages.

Thinking about these as solutions to communication problems, where the problems differ in degree depending on the number of teams interacting with it, is a useful way of framing the discussions.

Hopefully it brings some clarity to discussions about when the light-and-loose methods are okay, and when the more heavy processes are justified.

The proposal seems to be that software design guidance correspond to existing hierarchical organization structure. A formalization of Conway's Law [0]. The more people in the hierarchy that coordination touches, the looser the coupling.

[0] https://en.wikipedia.org/wiki/Conway%27s_law