Lesson 133 - Stovepipe Architecture AntiPattern

The stovepipe architecture anti-pattern refers to a collection of ill-related ideas, concepts, and components that leads to a brittle architecture. In this lesson mark Richards shows you why this anti-pattern is so significant in today’s software world, and what factors lead to this anti-pattern. Through examples using both monolithic architectures and microservices, Mark illustrates how this anti-pattern emerges, and then finishes the lesson by describing techniques for how to avoid this all-to-common anti-pattern.

Reference Links:

Architecture By Implication AntiPattern

The Challenge of Architecture Teams

[KarimVite]

Yet another great lesson. My everyday challenge of preaching the re-balancing of the architecture after the requested changes. The issue is integration architecture is often seen as an overhead expense by managers. As Architects, we have to be sleek by predicting the true cost of the change in $$.

Hello from France Mark. In French, we call this "Usine à gaz" (gaz factory), from the idea that in a gaz factory there are pipes going everywhere with indiscernable logic.

[meenalsunil]

This antipattern is outcome of project budgets, timeline pressures. To avoid it, we need refactoring of existing services or monolithic. Many times delivery pressure overrides the right things to do. Specially with monolithic where we have legacy and any change costs to that big application will be pushed for later

[HemalVarambhia]

This sounds a lot like refactoring: first make the change easy (warning: this may be hard) and then make the easy change. I have found from experience that refactoring is key to avoiding that stovepipe anti-pattern and perhaps may be a way of paraphrasing you, Mark.

[asjjain]

Decide service granularity is very important in software architecture and design. But changing the granularity after service commissioned is very difficult. Deciding service granularity is art.

[Nick-dbzp]

This is actually quite scary. Since microservices may be split amongst multiple teams, this means maintaining a microservice amidst context-breaking changes (maybe more than one at a time) requires a LOT of communication in the organization.