Enterprise Architecture: Top-Down Makes My Head Hurt

By Deane Barker 2 min read
AI Summary

This post explores the concept of bottom-up architecture in software development, emphasizing its focus on building systems from individual components. The author advocates for a pragmatic approach, highlighting the benefits of flexibility and adaptability in design, while addressing potential challenges and the importance of alignment with overall goals.

My buddy Rob and I were talking the other day about top-down vs. bottom-up enterprise architectures. My last company attempted to implement a top-down architecture, where every system was planned out as to where it fit in the grand scheme and everything was on one big server under one language, etc. To my knowledge, they’ve never pulled it off and the project is going nowhere after two years of trying.

I’m more inclined to believe that for a lot of systems, bottom-up is the way to go. Let business units use what they need, then integrate them with XML and Web services. Obviously some things, like CRM or transaction processing, need to be large-scale stuff running on big iron, but how about the “glue.” You know, the hundreds of little systems that get built to handle one thing or the other?

In a perfect world, things would work out like my old company’s attempt at top-down – everything would fit seamlessly into a whole. But to bring this sharply back to the world of blogging, things like department intranet sites don’t need this kind of planning or attention, and to do so will result in more time spent on integration than on the actual use of the system.

Given that XML, SOAP, and Web services can bridge systems across technological chasms, why not just let people use what they need to use, be responsible for their own stuff, and integrate where and when you need to? This was the entire concept behind The Cluetrain Manifesto, and the promotion of this concept is almost tantalizing enough to get me back into the corporate world just to prove a point. Almost.

My old company spent months and months and months trying to work out an intranet strategy. Every time I thought we were close, the project would get bogged down in architecture-this and integration-that. In an effort to build the perfect system, we ended up with no system.

If I were to do it again, I’d give every department a Movable Type blog on a desktop box running under a desk somewhere. Architecture hounds would scream, but I bet the departments would be thrilled, would start using them right away, would overlook any “grand scheme” shortcomings, and would get ROI in the quadruple digits long before we’d get an approved requirements document for the “big” system.

That said, rant over.

Links to this – Generic Content Management Isn't Realistic December 4, 2003
As I work with content management more and more, I believe more and more in what this guy has written: Perls of wisdom in a sea of site mismanagement […] site management system vendors are creating generic solutions that actually increase the cost of running a site […] the vendors’ ideal of a...