Philip Allega

Okay, my Mother doesn’t really have a definition for EA; but, there’s nothing in the way of her doing so.  Sometimes, I secretly wonder if she’ll develop her own framework, stoke up a marketing engine, start up a journal, and then blog to others about how cool she is.  Once you get her going, my mother is a force of nature to be reckoned with; but, luckily, she’s not coining EA frameworks or new definitions at this time.

It’s true that EA can bring many benefits to many people and many organizations given differing requirements, desires, perceptions and cultural, political, and stakeholder beliefs. As a result, it’s easy to define it in many ways that serves these contraints and belief systems.  The latest definition I’ve read came from South Africa stating:

Enterprise Architecture (EA) is the continuous practice of describing the essential elements of a socio-technical organization, their relationships to each other and to the environment, in order to understand complexity and manage change. 

If they’d only add a framework/approach to this definition I could notch my list of EA frameworks/approaches I’m tracking up by one (note: if you’re curious, I’m at 77 right now and if you’ve got one, please let me know).  For those of you who aren’t used to reading with a sarcastic voice, please try using sarcasm when you say (out loud):

The world really needs yet another definition of enterprise architecture

<large, tired, shoulder shrugging sigh>

It’s extremely frustrating that, 23 years after Zachman’s seminal article that we’ve found ourselves in a state of “my definition/framework/approach to EA is better than yours”.   However, the rules behind market commoditization suggest that it has always been thus.  EA is, after all, very new to both IT and business.  Most IT professionals are aware of something that is a “<fill in the blank> architecture”, where <fill in the blank> can be anything, or mean anything, according to how a person in the IT department wishes to qualify the term “architecture”.

Over the last year there was a long set of entries, now mysteriously missing, on a LinkedIn Group for EA in response to a solicitation to resolve EA definitions.   Nick Malick had an interesting discourse on that experience and the results of the South African work referenced earlier.  Brenda Michelson also weighed in with support for a canonical defintion of enterprise architecture.  The results of the LinkedIn experience have, unfortunately, disappeared into the ether; however, the responses themselves (for those of us paying attention to the exercise) reinforced the reality that defining EA is a “slippery business”.

I always think about the activity of defining EA for a particular organizations current iteration of EA as an exercise not too dissimilar to when Rocky was chasing the chicken (if you’ve never seen this, here’s a link to that scene here: http://www.youtube.com/watch?v=AoEEPoBwf7Y).  It’s difficult, but not impossible, and you learn a lot from having gone through the exercise.

DEFINING EA COMES DOWN TO YOU

Hopefully, at the end of such an exercise, you’re in a position to defend your current stance as to what EA means to your organization at this point in time given the cutural and political realities plus the needs of both your business, at large, and the needs of specific stakeholders across your organization.

I am not saying that definitions are not helpful.  They are extremely helpful.  Indeed, the act of re-defining something helps bring clarity to what you mean by a particular phrase.  Indeed, words change meaning over time as well – some leave the lexicon and others provide new meaning. 

Sometimes, though, this act of definition by various groups may be similar to the introduction of a neologism.  My boss, Richard Buchanan, often asks us if we “grok” something.  The term “grok” came from a science fiction writer, Robert A. Heinlein.  I’m not sure if this is six degrees of separation, but I was in junior high school with a “Heinlein” whose family claimed a close family relationship with the author. Regardless, “grok” is a neologism and I hope that “EA” doesn’t become one – can you “grok” that?

It may just be that all of these definitions conflate the desire to qualify something in the vernacular (the common tongue in which the words are used) and the desire to create a lingua franca definition (one that everyone can share regardless of their mother tongue or, indeed, regardless of the vernacular of a particular profession).   I’m not saying that this is good, or bad, I’m just wondering out loud on this blog.

HEY, DOESN’T GARTNER HAVE A DEFINITION?

Of course we do.  We have to have a definition by which we can advise clients and judge how well practitioners, vendors and consultancies are engaged in the creation, delivery and execution of EA.  This allows us to understand, research, and comment upon the state of EA and its continuing evolution. Stretching back to my days as an analyst at META Group, I’d count this as revision 3 since 1998.

Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution. The scope of the EA includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment. Enterprise architects compose holistic solutions that address the business challenges of the enterprise and support the governance needed to implement them.

A mouthful, to be fair.  And, to be honest, a big stretch for most practitioners.  As a result, we are able to gauge the market against this definition. 

I’d suggest that there are more fundamental truths than exacting definitions.  We’ll be exploring these fundamental truths in further research this year.

Definitions are an excellent heuristic against which to judge, and define, your own EA program.

I think that it’s important for EA programs to not get hung up on particular definitions or specific frameworks but to make certain that they define EA for their organization, at this point in time, and get an EA Charter (note: link for current Gartner clients to toolkit) to qualify what EA means to you, for this iteration.

Next iteration?  Re-define what it means to you the next time around. 

As we all get back to work and step away from this blog, let’s be careful not to get caught up in the hype surrounding another definition or YAEAF (Yet Another EA Framework). 

DOES THIS MEAN THAT A CANONICAL DEFINITION IS NOT NEEDED (OR POSSIBLE)?

My hypothesis is that an aggregated, high-level, definition that encompasses many variations will, eventually, bubble to the surface.  I suspect that this will come out of academia and not from a particular consultancy or other type of EA market vendor (note: that said, vendors should take note to get past this hype and solve point solutions as I noted in this blog).  That would, indeed, be helpful.  Yet, I’m not of the belief that today’s practitioners have to wait for that time to arrive.  Indeed, Gartner has predicted that much of the marketplace competition over commercialized versions of EA definitions (note: please seriously consider if your favorite framework is making someone money when you consider what’s commercial and what’s not) will take >10 years to unravel.

Oh, and let’s not get my mother all riled up about EA or we’ll all wish we hadn’t done so.

3 Comments »

Category: Enterprise Architecture     Tags:

Share

Tweet