In terms of holding interest, enterprise technical architecture management (ETAM) ranks somewhere between watching paint dry and grass grow, with the additional disadvantage of being intellectually demanding. The less technical your audience, the more ETAM serves as a side-effect-free alternative to Lunesta.
The news gets worse: ETAM is the one subject where IT needs to engage business leaders on a technical level -- a conversation about the enterprise technical architecture that's limited to metaphors and business terms won't get the job done.
[ Find out the 10 business skills every IT pro must master and beware the 9 warning signs of bad IT architecture. | Get expert advice about planning and implementing your BYOD strategy with InfoWorld's 29-page "Mobile and BYOD Deep Dive" PDF special report. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]
ETAM is strategically vital, an essential aspect of competent IT management, and intellectually challenging and satisfying besides. But is there any easy way to interest business executives in it? Sadly, no.
One alternative is resorting to threats. I once told a client's CEO he had two choices about this: He could trust me, or I'd explain it to him. He caught a glimpse of my first slide and said, "I think I'd rather trust you."
It isn't that the business case is complicated -- quite the opposite. But proving it is excruciatingly difficult, even to a technical audience interested in the topic. Making the case for ETAM to someone who would rather have his pancreas eaten by ferrets? Good luck with that.
The business and politics of ETAM
Here's ETAM's business case in one sentence: We need to spend more time, effort, and money on everything we do now, so we won't have to spend a lot more time, effort, and money a few years from now on everything we do then. It's very much the same as the case for preventive maintenance.
If the business case is that simple, why do most enterprises have a hard time making ETAM happen? Call it the altruism obstacle. ETAM asks everyone in the business to spend more and wait longer now so that someone else in the business will benefit in the future. And it asks the CEO to accept higher costs and smaller profits this year, so profits a few years from now will be better than they otherwise would.
It's even worse if the company charges back for IT services. If it does, ETAM's overt costs and deferred benefits aren't just a matter of image damage ("Why do your projects cost so much?"). It actually hits business budgets.
The ETAM political anticlincher: If it delivers its promised benefits, there will be no way to prove it. Successful prevention is, after all, indistinguishable from absence of risk.
In trying to sell the business on ETAM, you're best served by following a double-barreled approach: Limit your discussion to the ETAM decisions that are truly business-driven (most aren't), and present the anti-ETAM political case bluntly, in all its unsavory glory.
Non-business-driven ETAM decisions
That IT must be business-driven is a truism, and like so many other truisms, it's mostly false. When the subject is enterprise technical architecture, business strategy and tactics have little impact on most of the choices IT has to make. Even the business architecture is often irrelevant.
For example: IT needs a way to manage structured data and the transactions that feed it. As explained last week, that's the services-level description. That's followed by choosing the class of technology needed to provide that service. In this case, IT's alternatives are either an RDBMS, an RDBMS, or an RDBMS. When the subjects are transaction processing and structured data management, the solution is a relational database management system. All the business-driving IT in the world won't change that.
When the time comes to choose which RDBMS to build the company on, some business information can be handy. How fast the execs plan for the company to grow (measured in transactions per minute, if possible) will help weed out platforms that fail the Goldilocks Test. Though there may very well be more information that would help inform this decision, once you get beyond sizing, you won't find much connection between what the business is going to do and which RDBMS to buy.