It is the nature—and, one should add, the responsibility—of the C-level executive to think conceptually, to deal in strategic visions and grand designs. Niggling details may fall to others, but, by God, real leaders revel in Big Ideas.
Why am I overselling this? Because the particular Big Idea up for discussion is not as sexy as string theory or as viscerally engaging as, say, politics or Mel Gibson movies. In fact, some executives might prefer to learn C++ or help the IT guys lug a few hundred CRT monitors out to the dumpster rather than talk about enterprise architectures.
That’s understandable. After all, in the world of IT, the term architecture is often used interchangeably with infrastructure, which is then equated with cabling diagrams, interface standards, and sundry other plumbing issues so arcane that one might be tempted to outsource it all if only to never have to speak of it again.
But enterprise architecture, or EA as its known (you could have guessed that), is worth a C-level discussion. The good news: you don’t actually have to understand it—much. And, better, a high-level grasp of EA may go a long way toward finally achieving that business/IT alignment that always seems to be on the horizon.
More to the point, EA just might save money. Consulting firm Meta Group Inc. says companies that embrace EA spend 30 percent less on IT, and are more adaptive and make better decisions. But Brian Burke, an analyst at Meta, readily admits that despite those benefits, EA doesn’t inspire many impromptu watercooler chats.
Burke recommends, therefore, that CIOs or “enterprise architects” (a position gaining in popularity) use a metaphor to make EA more palatable: urban planning. “We all want a house that’s fire-safe, connected to public services, and has doors high enough to walk through,” Burke says. In short, we welcome building codes, even though they can be complex and impose restrictions. EA is similar: it spells out the principles and standards that will shape a company’s technical, application, information, and business-process needs and goals. Fortunately, “CFOs certainly don’t need to know that their EA dictates that ‘all applications must use the MQ discard-after-expired option,'” Burke says.
Extending the metaphor, he compares change initiatives to building permits; that is, new IT projects are approved only if they meet the specifications set out in the EA. Taking a longer-term view, a company’s “future-state model” depends, at least in part, on extending the EA from a mere building code to a bona fide city plan.
EA is not a new concept, and the urban-planning metaphor doesn’t take it in a particularly new direction. But it does provide, as Burke says, a broadly understood analogy that may encourage non-IT execs to participate in discussions. CFOs in the Boston area, however, may require a different metaphor, given the massive cost overruns and delays associated with the Big Dig. Or did the city’s plan simply lack an EA?