Enterprise Architecture: Top-Down Makes My Head Hurt

By Deane Barker • April 8, 2003 •

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….

The author discusses the pros and cons of top-down versus bottom-up enterprise architectures, drawing parallels to their own experience with their old company. They argue that top-down architecture, where systems are planned and integrated into a larger system, often leads to unnecessary complexity and time-consuming integration. Instead, they suggest that businesses should use what they need, integrate when necessary, and let business units use what they need.

Generated by Azure AI on June 24, 2024

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.