EA Doesn't Have To Be 'All or Nothing'

by Jeff Tash, ITscout

I don’t know about you, but lately I’ve been feeling more and more like Howard Beale, that fictitious news anchor from the 1975 movie “Network” who ranted and raved, insisting that everyone go to their windows and start yelling, “I’m mad as hell and I’m not going to take it anymore.”

Why am I so angry?

Because I’m sick and tired of hearing enterprise architecture gurus continue to preach inexorably how EA has to be this comprehensive, top-down, massive effort focused almost exclusively on the end result. Their mantra warns that you’re going to fall flat on your face and fail unless you embrace a holistic perspective that emphasizes the need for a comprehensive process that integrates core IT management disciplines with business strategy planning. Is it any wonder then that, according to META Group’s figures, over 60% of Global 2000 companies have yet to embrace enterprise architecture? The mere mention of EA sends chills down the spine of IT executives afraid of expensive, high risk, long-term projects.

My critics view my anger as heresy. After all, how can anyone disagree with John Zachman, the undisputed “father” of enterprise architecture, who says that “thousands of years of history establish that architecture is fundamental to accommodating complexity and managing change?” On the other hand, how come I feel like I’ve been hearing John preach this same exact message for the past thousand years? Hasn’t the Zachman Framework been around since at least as far back as the 1980s, when John was still employed at IBM? Don’t get me wrong. I think Zachman is a terrific speaker. He’s evangelical. But he keeps delivering the same lecture over and over, telling all who will listen that there are no silver bullets, no quick fixes, no easy outs. According to John Zachman, salvation can only come after you adopt the guiding principles and logic of his framework with an enterprise-wide, coherent, integrated implementation.

How can anybody quarrel with enterprise planning and architecture strategy “experts” like META Group’s George Paras or Phillip Allega, co-chairs of DCI’s “Enterprise Architecture Conference,” when most of what they talk about involves commenting on the obvious? Everyone knows that, year in and year out, the #1 issue identified by CIOs as their most challenging problem is how to “align IT with business goals and strategies.” Pardon my cynicism, but it strikes me that EA is a consultant’s dream job, the kind of assignment that promises perpetual revenues forever, sort of like psychoanalysis but for your IT organization. You’re cured when you run out of money.

I strongly disagree with those who advocate taking an extended view of enterprise architecture whereby IT executives can somehow leapfrog past technology and jump directly to the cultural and political issues important to business leaders. I believe IT has to first and foremost be about overseeing the “management of information technology.” What makes this task doubly difficult is figuring out how to cope with the rapid rates of accelerating change fueled by exponential growth growing exponentially (i.e., Ray Kurzweil's “Law of Accelerating Returns").

Considering the unrelenting pace of technological innovation, it’s not an overstatement to suggest that implementing software solutions today often feels like learning how to ski in an avalanche. That’s why it’s so imperative that enterprise architects provide direction and guidance to software practitioners -- those people who build or use applications -- in order to help them be more effective in performing their jobs.

Let’s stop turning EA into a long complex ambitious quest dependent upon the actualization of a massive effort to comprehensively account for all technology implementation and usage within an organization. Let’s move beyond EA having to get it all done right on the first try. Let’s instead approach EA incrementally where value increases and risk decreases with each stage of development.

Every architecture effort, whether you’re building a house, or an office building, or a computer system, should begin by taking into consideration the “terrain” upon which the foundation will be built. From an EA perspective, this “terrain” analogy implies recognizing what you have to work with, not simply what you want as a result. In other words, enterprise architects should, above all, provide their user communities -- both IT professionals as well as business end users -- with an easy way of cataloging and describing their hardware and software “terrain.” This will serve as the foundation for all future EA initiatives. But initially, I recommend that enterprise architects concentrate on providing a navigable environment where people can quickly and easily explore, discover and learn. Help people understand what products IT management wants them to use. Explain what tools have been selected as corporate standards, and why.

Avoid the pitfalls of getting bogged down by the shear enormity of traditional EA projects. Otherwise, you’ll probably wind up grappling with either analysis paralysis, or worse still, have your entire EA projects get perpetually pushed aside because no one inside IT knows how to properly cost justify what is certain to be a complex, high risk, expensive effort.