Blog post

Describing EA Services (those offered by an EA team/program)

By Bruce Robertson | July 02, 2009 | 3 Comments


Defining EA as a set of services are a new way to describe what EA does and what the outcome or result or deliverable of EA activity will be.  Using the service term certainly gets a useful clarifying discussion going about who the consumer and provider are, and what is provided by the provider to the consumer.  This is a fresh way to think through what EA is (particularly if you ask some of your EA consumers to participate in the definition exercise!), rather than just describing it as a set of processes.

Gartner’s starter kit for EA Services (Gartner clients can read about this more here: starts with these 5:

  1. EA Creation
  2. EA Consulting
  3. EA Compliance
  4. EA Communication
  5. EA Research

Other people I’ve talked with this about like these but suggest adding Lab and Reporting to this list.  But, if you have too many, you’ve defeated the purpose!  Maybe indeed 5 is a realistic limit to the base list.

The simplest attributes or metadata I’ve started with in planning these are these attributes (which I have in a table in the note referenced above):

  1. name (including alternate names)
  2. description
  3. deliverables
  4. EA team roles
  5. SME roles (subject matter experts — EA people do not alone provide all the horsepower)

Basically, this is: what do I get (consumer) and what do I do and produce (provider).  I do actually find the consumer / provider thinking VERY useful in making things clearer to key stakeholders.  This is what makes many clients move from just a process view of EA to a service view of EA.

In discussing this with clients, I’ve found many that are thinking the same way.  For example, Todd Biske here:  He’s also suggested ( an addition to the attribute list: trigger.  Some EA services are provided on request (consulting), while others are provided on a more event oriented (and not by human request) way: scheduled refreshes and/or process calls.  Maybe though, all of these are events (requests) of one kind or another — some human (PM requests EA consulting), some machine (all the new projects have been documented, so get them into the EA repository), some long running repeated requests (CIO: give us these reports regularly), some immediate (CIO: tell me about why we need EA again?).  So, is this a good add to the EA service attribute list?

What are your EA Services?

Comments are closed


  • Todd Biske says:


    Thanks for the links back. Something else that I think is critical is that these services must be put into context for the consumer. One way of doing this is to create a process model that captures how the service gets executed by EA, but also enough of the key consuming processes to show where the various EA artifacts are involved. While there’s a fine line between dictating those consuming processes and merely providing suggestions, there are some mandatory points where processes must integrate. We need to describe the service in enough detail so those pre-conditions are clear, but only provide suggestions on how to integrate EA artifacts into the consuming processes to ensure those preconditions are met.

  • Yes, each service has something going on inside it (process, people, automation) to turn the crank to take the request and churn out the response. EA services are no different — perhaps more human than automated, but I’ve seen clients have web sites to have projects fill out EA forms for input into EA for compliance testing, and so on.

    Maybe this service view allows it to more easily be seen to have a plug (an interface) to connect it to other processes. A classic one I model with clients all the time is EA to SDLC (or PM) linkages. Now that we have two key project centered EA services (that is: the customer is the project), you can plug those into various stages of the SDLC (by stage gate or elsewhere) as needed. The process that consumes the service knows what it needs to supply and what it gets back in return.

    On what level of detail — we ALWAYS start with this principle: “just enough architecture, just in time.” Do first something simple, conceptual level detail only. Use it, and iterate it to be better and/or more detailed over time if needed — ONLY IF NEEDED. Things do NOT have to get more complex. Even if they are complex, they will still need to be understood at the simple / conceptual level anyway, so you need to do the simple conceptual view in any case.

  • Very interesting use of the structure in different scenarios.