The Leaning Tower of Pisa, an otherwise unremarkable building, is famous for its bad foundation.

Some CIOs build their reputations on bad foundations, too. They insist on engineering shortcuts in the name of “business value” and “we don’t build technology for technology’s sake.” Some fail to understand that bad architecture creates a debt that will have to be paid off in the future, some do understand, and also understand that debt will be Someone Else’s Problem.

Others understand an important point about enterprise technical architecture management (ETAM) … one we’ll get to next week. But first …

The ETAM business case is that, as the first figure depicts, investing in engineering excellence and consistency now will pay dividends by reducing the cost of future projects.

It’s a perfectly reasonable premise.

If you’ve bought into the mirror-image concepts of federated architecture and buy-if-you-can/build-if-you-have-to application engineering, ETAM is a particularly big deal, because without it you won’t avoid the standard system interface progression — from “we need one,” to the familiar spiderweb, to the inevitable decent into the land of the hairball, where most of the effort in every applications-related project goes into making sure you don’t break anything.

“Federated architecture” sounds like an impressive solution. Sadly, though, while supporting technologies like EAI abound, no one has created an actual organized methodology for designing and managing system interfaces, with or without an EAI tool. If you’ve settled on a federated architecture, a large part of ETAM will be rolling your own.

The alternative to a federated architecture is building everything around a central software suite, usually ERP, that serves as the “source of truth.” Here, a lot of ETAM’s day-to-day impact will be making sure nobody touches the source code … that developers customize through either the configuration tools the ERP vendor has provided for that purpose, or through building satellite systems that hook into the core system through its defined APIs.

ETAM is like CapEx. Both are a matter of investing now to get a payoff in the future. In both cases what you invest in has to last long enough for its benefits to pay off the investment.

In the case of information technology, a lot of it does. “A lot,” though, is very different from “everything.”

Businesses don’t operate on a single timescale. In fact, they operate in four. As the second figure shows, they are:

• Marketing time, where change in a slow-paced company might be on a scale of about a year, and in most companies ranges somewhere from a season to next month.
• Product/service time: In many industries successful companies figure any product that’s been around more than three years is pointless; many operate as automobile manufacturers do, delivering new models every year.
• Strategy time; which lasts as long as a reasonable business planning horizon. Unless you have a better crystal ball or operate in a more stable marketplace than most of us, three to five years is about it — beyond that there’s no real point in planning. Or even hoping.
• Infrastructure time: Because most businesses have to invest significant amounts of capital in infrastructure … the physical plant, knowledge of the marketplace in which they operate, employee knowledge about how things really work (as opposed to managers’ knowledge about how they’re supposed to work), and its core information systems, their infrastructure has to last longer than their strategies. Much longer; ten years or more isn’t uncommon, as a look at your own legacy systems is likely to reveal.

Infrastructure creates an uncomfortable challenge for business planners. Those who create it have to make design decisions. These decisions will support some business strategies while placing significant constraints on others.

And because infrastructure lasts quite a lot longer than most business strategies, their design decisions cannot be “business-driven” in any serious way, no matter what platitudes business pundits like to utter about such matters.

Two more points about infrastructure and we’re done for the week. The first: Many additions to the infrastructure are unintentional.

Often, those who build these things expect them to be short-term improvisations intended to handle temporary situations. Then, temporary becomes business as usual, or they adapt and extend the improvisation for other, less temporary uses because that’s more expedient than the available alternatives.

The second: Even if you acquired every element of your infrastructure for free, that doesn’t make abandoning it for something else free, any more than moving out of a house someone gifted you to a better one is free.

Changing the infrastructure is always a costly proposition.