Enterprise technical architecture management (ETAM) is a topic I’ve probably written too much about already. That’s the price you pay for not paying for your reading material.

Let’s start here: Even atheist programmers know how God was able to create the entire universe in only six days: He, she, or it (KJR takes no position on deistic gender) didn’t have an installed base to worry about.

Same coin, opposite side: Clayton Christensen, in his milestone book The Innovator’s Dilemma, recommends that any company wanting to launch a new venture that falls outside its current comfort zone should incubate it as an entirely separate business, in a different location, with a different infrastructure, success metrics … everything.

Entirely irrelevant to this discussion, but it just occurred to me and I’m feeling impulsive today (see “price you pay for not paying,” above): A common mistake in mergers-and-acquisitions circles is ignoring the obverse of this point. When large corporations acquire small entrepreneurships, they often move them over to the large-corporate systems and infrastructure. It’s a seemingly logical move — a step toward achieving the acquisition’s so-called synergy targets.

It’s a great example of the Great Theory But syndrome. This really should work out best for everyone. But what happens all too often is that the acquiring company’s information technology, designed to scale up to mega-proportions, doesn’t scale down very well.

The result: The once highly-profitable entrepreneurship, now loaded down with chargebacks paid to the mothership for overkill systems that cost two or more times what they’re used to spending for whatever-it-is, becomes an unprofitable subsidiary.

All in the name of an improved enterprise technical architecture.

Waddaya know? I guess it isn’t entirely irrelevant to this discussion, because the second great law of management is the first great law of enterprise technical architecture management (ETAM): Form follows function. In context, it means the most elegant, highly integrated, cleanly designed architecture is the wrong architecture if it imposes an unaffordable burden on the business.

Enterprise technical architecture management (ETAM)

Companies have two choices for building, integrating, enhancing and maintaining their applications portfolio, and the information repositories and underlying platforms and infrastructure that support it. The first is for every project team to face the world as if it was God and the universe hadn’t yet been created. Lacking both omniscience and the necessary budget to do anything else, though, what they and the other teams that are also operating in isolation will be contributing to will look more like a big pile of stuff than a clean, well-organized system.

That’s the first choice. The second is to make every project team responsible for fitting its work into the existing set of structures as cleanly and elegantly as possible, which is to say, for every project team to be responsible for technical architecture management.

It goes further. For any number of reasons, starting with companies choosing option #1 because it’s cheaper and ending with mergers and acquisitions, in most businesses, leaders wake up one morning to discover that whatever the cause, the information technology they rely on has become a big pile of stuff. (If you want a more refined version of “big pile of stuff,” see “9 warning signs of bad IT architecture,” InfoWorld, 5/24/2012.)

Now they have three choices. They can (1) shrug, tell IT that gee, that is too bad and we expect you to get the job done anyway, “the job” defined as “get projects done quickly and cheaply even though the architecture mess makes that impossible.”

Or, they can (2) write IT an enormous check to charter an expensive, multi-year clean-up-the-mess program, during which IT won’t be able to accomplish very much else, because everyone who might help the business accomplish it is fully committed to the clean-up effort.

That leaves (3) nibbling away at the problem: Defining what “good” means (what architecturally sound solutions look like) and requiring every software change effort to clean up some of the mess as part of the software change while also making sure to avoid adding to the mess that already exists.

Oh, by the way, the nibbling-away-at-it option looks exactly like what the avoiding-the-problem-in-the-first-place option looks like, except for not having a problem to nibble away. In both cases, the enterprise gets to a clean architecture and stays there because every technology-related project does its part to make sure of it.

In case it isn’t obvious by now, knowing how to nibble away at the problem on a project-by-project basis without adding to the mess is one of IT’s 18 critical success factors.

Only “ETAM integrated into delivery methodologies” sounds a lot more impressive, doesn’t it?