When architecture doesn’t matter

Once upon a time there was a life insurance company that collected lots of information from applicants. Its underwriters used it to statistically predict applicant mortality so as to properly price each policy.

That was the business need, and so once the company either rejected the application or issued a policy, it purged most of the information. Storing it was an identifiable cost, with no business need to justify it.

Until quite a few years later, that is, when a change in business strategy meant the company wanted to understand its customers a whole lot better.

Oops.

Last week we introduced the uncomfortable notion that companies need to make important decisions about their enterprise technical architecture that aren’t driven by “business need,” or at least not any business need that’s discoverable without a time machine. Those are the decisions about business infrastructure … the components of enterprise technical architecture that will outlive the current business strategy.

The information life insurance companies collect on application forms is an excellent example. Because the company in question based its data-retention decision on current needs, and not on an evaluation of plausible scenarios about the future, not only its decision but its decision-making was flawed in a deep and fundamental way.

Here’s another once-upon-a-time, this time an episode early in my own career. My employer was planning a round of layoffs, of the we’ll-provide-a-generous-severance-package-to-volunteers variety. The team responsible for administering the program needed a system for keeping track of things, they needed it in five days, and in two months they would unplug it, never to need it again.

The result wasn’t exactly a paragon of engineering excellence. I delivered it on time, though, it did the job well enough to get everyone through the process, and no maintenance-programmer-of-the-future ever had to deal with its various shortcuts and design flaws.

Smart CIOs understand that investments in enterprise technical architecture management (ETAM) pay very large dividends in the long haul.

They also understand something more: That, as is the case with just about everything, ETAM is a means to an end, not an end in itself. It applies to a certain class of problem, not everything IT does. Had I been required to conform to IT’s programming standards back when I was building my little layoff tracking system, I couldn’t even have delivered a functional design spec in five days, let alone a functioning system.

Then there’s a little something I like to call the World Wide Web. Had the folks who, when it first came into existence, had to conform to IT architectural standards, by now we might have as many as 1,437 web pages to read.

Another example: A friend of mine works for a company that creates business dashboards for its customers. It delivers them more quickly than what internal IT can achieve, because it doesn’t bother with little niceties like building a robust data warehouse behind their dashboards.

In the long run, this would be a problem, except that in their experience, the long run never shows up. Most of their customers ask for entirely new and very different dashboards on a regular basis … less than a year; in most cases less than six months. An ugly-under-the-hood collection of extracts and temporary tables ends up being more than good enough.

This is what smart CIOs understand about ETAM: When it matters, and when to ignore it, depending on each system’s expected lifespan.

So here’s a thought: Incorporate this concept into your company’s project governance. Include a system sunset date in every proposal, with business sponsor sign-off.

Add one more piece to the puzzle, and it comes together nicely: The cottonwood-now-or-hardwood-too-late principle. That’s the principle adopted by the Southern Pacific railroad during construction of the transcontinental railroad. It decided to use soft, inexpensive, and readily available cottonwood for its ties. That let it lay enough track to start generating revenue, recognizing that in three years it would have to replace it all … better business engineering than failing to construct the track and going out of business.

The IT version: When you’re building core infrastructure, building the first release ugly can make sense, especially when the whole company has to “learn its way into” what it needs.

Well-run companies (there are some out there) can do this without its executives conveniently forgetting the need to invest in infrastructure-grade architecture for the second release.

The rest? They’re badly run companies. They’ll be gone before they have to pay the cost of bad architecture.