Old John Zachman Had A Plan: EA-ea-Oh!

by Jeff Tash, ITscout

Enterprise Architecture (EA) is the brain child of John Zachman. It all began by his asking some very simple questions like: Who, What, Where, When, Why and How. Over time those basic questions have spawned an entire market for IT tools aimed at supporting enterprise architecture needs.

I realize I’m just a lonely voice calling out from the wilderness but something seems to have gone terribly awry. Somewhere along the way, the simplicity of Zachman’s child-like inquisitive questions have gotten hijacked by levels of abstraction and degrees of complexity that are simply beyond the comprehension and intellectual capacity of mere mortals. “Big EA” is in need of a good heavy dose of “little ea” -- or what I prefer to call “EA-Lite™.”

“Big EA” refers to the growing tools market that aims to support complex architectural frameworks intended to encompass diverse artifacts from multiple perspectives. Large amounts of information are collected and organized to describe everything about IT -- business processes, organizational structure, applications, data, interfaces, systems, technologies, etc. -- plus the myriad of relationships amongst all these artifacts -- all viewed from multiple different points of view, including “ballpark” views, “owner” views, “architect” views, “designer” views, and “builder” views.

Oh yeah, by the way, EA is also supposed to describe what’s called the “actual” view -- also known as the “functioning enterprise.” For “Big EA” these working systems are almost an afterthought. Not so for “little ea”.

“Little ea” thinks that “Big EA” has it ‘bass-ackwards’ (as they say). Before worrying about the enterprise’s direction and business purpose or rigorously analyzing and transforming business processes, it might be a good idea for IT to get its own house in order. Most large IT organizations don’t do a particularly good job of monitoring what applications, systems, or tools the various business units scattered across their enterprise are actually using. Even worse, the majority of CIOs have an absolutely dismal record when it comes to explaining and communicating IT architectures, standards, and strategies to their core constituencies -- those folks throughout the enterprise who use IT products and services.

Once upon a time, long ago, CIOs were referred to as “czars” -- back when they ruled over glasshouses. But PCs changed all that and no one’s ever going to put the genie back into the bottle. It’s important to remember that PCs were not introduced into enterprises by IT. It would be more accurate to say that PCs were purchased by users because of IT. If you go back to the early 1980s, in the heyday of DEC, DG, HP, Prime, Wang, and others of their ilk, you’d discover that the original definition of a minicomputer was any system installed without IT’s approval. Of course, minis gave way to micros and IT’s prominence diminished forever.

“Big EA” is loved by big government. Unquestionably, the most enthusiastic supporters of “Big EA” tools are Federal Departments and Agencies along with many State Governments. Uncle Sam has gone so far as to create what’s known as FEAF, the Federal Enterprise Architecture Framework. The private sector has been much more skeptical. The majority of Global 2000 companies still have not yet adopted “Big EA” solutions. The dearth of EA implementations by business enterprises sends a strong signal to those evaluating this technology sector -- proceed cautiously. Rarely, if ever, has the IT industry looked to government for technological leadership. I predict FEAF will soon be severely criticized. After spending billions of dollars of taxpayer’s money, I can almost guarantee these massive government initiatives will fail to deliver on what’s been promised. The reason is because supporters of “Big EA” have set the expectations of their sponsors unrealistically high. What do you think the government’s chances are that FEAF will succeed in systematically capturing and organizing actionable information about complex IT and business environments in a central repository that is easily accessed and automatically kept up-to-date?

How much is your business willing to bet that “Big EA” will deliver real business-oriented ROI? Personally, I’ve seen IT vendors and pundits make unrealistic promises many times before. Who remembers CASE, AI, Expert Systems, yadda, yadda, yadda?

The goals of “Big EA” are commendable. Who wouldn’t want a framework for organizing the myriad of artifacts produced by the multitude of IT tools used to build, deploy, and manage large complex information systems? But I question how anyone can formalize processes that continue to remain in a constant state of flux. The relentless pace of technological change defies the specification of a robust repository. This year’s “technology du jour” is SOA -- Service Oriented Architecture. Last year’s big buzzword was “web services.” Who knows what’s coming next year -- perhaps it’ll be the Semantic Web -- or maybe something else. The problem with today’s technology being still so immature is that early adopters of “Big EA” run a risk of institutionalizing processes that could soon become obsolete. It would be like standardizing on VCRs or 8-Track tapes. Adopting too early could be extremely costly and painful.

“Little ea” suggests you do what’s doable. Focus on achievable goals. Set realistic expectations. How? Strive for SIMPLICITY, STANDARDS, MODULARITY, and INTEGRATION. Those are the traits that enabled PCs to succeed. Those same characteristics apply to enterprise architecture as well.
 


Jeff Tash is CEO of Flashmap Systems, Inc. (www.FlashmapSystems.com) and creator of two free interactive sites: ITscout (www.ITscout.org), provides a formal way of organizing, classifying and categorizing the multitude of products within the computer industry in a way that both technical and non-technical people can easily understand; and the Architecture Resource Repository Site (www.ITscout.org/architecture) that provides information specific to IT architecture, including descriptions of products, consultants, concept definitions, glossary terms and more.  Jeff is a Microsoft MVP Architect and an IASA Fellow.