Enterprise Architecture

Defining EA is a tall order, since there is little agreement on what exactly EA is. Some come from the technical-side of things, where everything is developer-centric and otherwise revolves around cool tools and subsystems to play with. Others take a more holistic approach, preferring to operate and a major system/subsystem-level, with still others taking it all the way to a business-process and IT integration level. Of course, we also have the various EA frameworks (Zachman, TOGAF, FEAF, etc.).

I'll share my definition (actually, definitions) of EA with you in an upcoming post. Before that, let's think about a few things:

• The use of the word enterprise lends itself to an authority and scope that is much more than just IT, or just "the business."
• Architects that operate at the developer/coder-level are not "enterprise" in scope, but more "system" or "application." So, I would call them System or Application Architects more than I would EAs.
• System Analysts have similar issues, but they are more business-facing, so I would refer to them more as Business Analysts or, a term I fancy lately: "integration-ist." Yeah, I know it's not word...yet.

What one sees in various EA literature is the term bandied about for everything from systems analysis to development and the project management of development. That is particularly annoying and confusing to some because there are two major sides to EA: the technology side; and the business side. As we will see, you cannot skimp or gloss over one and concentrate on the other exclusively if an EA project is to succeed.

Here's a short list about what isn't EA:

• Development and developer-centric philosophies that largely exclude the business-side. This stance goes a long way in explaining why technical people largely 'don't get it' in terms of the business their organization is in.
• Business-centric philosphies that ignore the technology part of the architecture. This is a primary driver of the attitude of business-types that IT is just a cost center.
• Ignorance of the "as-is" business and technology states of n organization and only concentrating on the 'to-be' or goal state.
• Ignorance or oversight of business and technical processes - automated, workflow, compliance, financial, etc.

We've got a lot of ground to cover. Stay tuned.