What are your EA Services?

A week or so ago, I asked about defining on EA services on Twitter. My use of the term services here is in more of the ITIL/ITSM sense, not what typically comes to mind when discussing SOA, but I could have another blog post just dedicated to that subject. I’ve been working to define EA services at work, and it’s been a very interesting exercise, and I had hoped that other EA’s (or former EA’s) on Twitter would have something to contribute.

Something that is a bit surprising to me, is that many IT teams struggle to explain exactly what they do, especially those whose primary purpose isn’t project work. This doesn’t mean that the team isn’t needed, but it does put you at risk of having the team be defined by the individuals rather than by their responsibilities. Depending on who the individual is, you get a different set of capabilities, making it difficult to quantify and measure what the team, rather than the individual does. A conversation with my boss and another team member on a different subject brought up the term “define by example” and we all agreed that it’s usually a bad thing. Examples are very important in illustrating the concept, but they shouldn’t be the definition. The same thing goes for a team. Your team should not by defined by individuals on it, but rather the individuals on it should be providing the defined services.

Getting back to the subject, the initial list of EA services I came up with, and vetted by Aleks Buterman, Leo de Sousa, and Brenda Michelson are:

  • Architectural Assessment Services: The operations in this service include anything that falls into the review/approve/comment category, whether required or requested. Ad hoc architectural questions probably go here, but those are one that I’m still sitting on the fence about.
  • Architectural Consulting Services: The operations in this service include anything where a member of the EA team is allocated to a project as a member of that project team, typically as a project architect. The day-to-day activities of that person would now be managed by a project manager, at least to the extent of the allocation.
  • Architectural Research Services: The operations in this service are those that fall into the research category, whether formal or informal. This would include vendor conversations, reading analyst reports, case study reviews, participation in consortiums, etc.
  • Architectural Reference Services: The operations in this service are those that entail the creation of reference material used for prescriptive guidance of activities outside of the EA team, such as patterns, reference models, reference architectures, etc.
  • Architectural Standards Services: Very similar to reference services, this service is about the creation of official standards. I’m still on the fence as to whether or not this should be collapsed into a single service with the reference services. Sometimes, standards are treated differently than other reference material, so I’m leaving it as its own service for now.
  • Architectural Strategy Services: Finally, strategy services capture the role of architecture in strategy development, such as the development of to-be architectures. If there is a separate strategy development process at your organization, this one represents the role of enterprise architecture in that process.

Now, the most interesting part of this process has not been coming up with this list, but thinking about the metadata that should be included for each of these services. Thinking like a developer, what are the inputs and outputs of each? Who can request them? Are any internal services (e.g. always requested by the EA manager) only, and which ones are external services (e.g. requested by someone outside of EA)? What are the processes behind these services? Are these services always part of a certain parent process, or are they “operations” in multiple processes? How do we measure these services? You can see why this suddenly feels very much like ITIL/ITSM, but it also has parallels to how we should think about services in the SOA sense, too. Thinking in the long term, all of these services need to be managed. What percentage of work falls into each bucket? Today, there may be a stronger need to establish solid project architecture, leading to a higher percentage of time spent consulting. Next year, it may shift to strategy services or some other category. The year after that, the service definitions themselves may need to be adjusted to account for a shift toward more business architecture and less technology architecture. Adjusting to the winds of change is what service management is all about.

So, my question to my readers is, what are your EA services? I’m sure I’m not the only EA out there who’s had to think about this. Even if your EA organization hasn’t, the next time you fill out your time card, think about what “service bucket” your efforts fall into. Do my categories make sense for what you do each week or month? If not, what’s missing. If it’s unclear which bucket something should go in, how would you redefine them? A consistent set of EA service definitions can definitely help all of us.

10 Responses to “What are your EA Services?”

  • I fully support defining EA functions as services – However there is the problem that EA units are small which somewhat curtails the scale of their activity. A caveat needs to be made that EA services are embedded in the organisations processes and not just a function of one unit

  • Very interesting post, Todd!

    I contend that a “service” maximizes the consumer / provider metaphor and fully support a “service” in terms you prescribe (more ITIL centric).

    In my post (http://bit.ly/Oh7IG) I say that there is an interaction that bridges a service to a consumer to which a process reacts. So, I would be curious what interactions occur for these services.

    As well, I think it is important to think that some services in one service will be underpinning to process managing the interactions from another service. So within the EA domain of authority, there will be services that the majority of interactions are internally used.

  • Todd, I think this list is a great start. A couple things we focus on that _may_ not be currently included:

    1. Portfolio alignment. This involves working to ensure that each strategic initiative is aligned with the strategy and influencing execution to maximize effectiveness of the strategy. Typical concentrations within this service are: 1)Influence initiative prioritization (helping to score initiatives, analyze/document strategic contribution, etc), and 2) Modify initiative approach/architecture to create alignment and leverage.

    2. Tooling Affinitization. I suppose I could say standardization, but that’s not really the goal. This service helps to determine where tools add value to the organization and helps to narrow down the set of tools to maximize benefit. I’m thinking here of anything from IDE’s to portals to containers to ESB’s.

    3. Infrastructure Enablement/Support. Perhaps related to Tooling Affinitization, this service provides common infrastructure such as development labs, testing regions, etc. These environments come equipped with various value-add capabilities such as Continuous Integration, Test Data Management, etc, which increases adoption and efficiency.

    4. Frameworks/Patterns/Practices. This is very likely already spoken for in your “Standards” service, but here’s where we produce meaningful best-practices or even prescriptive guidance, AND reusable frameworks/libraries to simplify the work involved in applying/adopting the practices on strategic initiatives.

    5. Community Buy-In. This is all around communicating the vision/strategy, obtaining buy-in, and establishing goodwill throughout the execution community. Part of this service is often training (directly or indirectly) that helps to level-set the collective frame-of-reference.

    I can see where each of these may be included as part of one of your current services, so you may not feel compelled to call them out separately.


  • Jeff Schneider:

    Your services feel too ‘responsive’ – like someone has to pick up the phone and call you in order for EA to be valuable. Thoughts?

  • I agree that it is a good start, I covered similar ground from a slightly different perspective in my blog (http://tinyurl.com/6revsq).

    I share Jeff Schneider’s concern that this list seems a little passive. I would also add that my view is that name and description of the services should make it very clear to the consumer of the service what value they receive.

  • Todd:

    Yes, we are thinking alike. Gartner’s starter kit for EA Services (as we discussed last week) is indeed similar.

    We start with these 5:

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

    (Gartner clients can read about this more here: http://www.gartner.com/DisplayDocument?id=757437)

    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.

    PS: the simplest 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 expert)

    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.

  • […] clients, I’ve found many that are thinking the same way.  For example, Todd Biske here:  http://www.biske.com/blog/?p=653.  He’s also suggested (http://www.biske.com/blog/?p=655) an addition to the attribute list: […]

  • […] of EA Mike Rollings (Burton Group): Gartner wakes out of an EA induced coma… Todd Biske: What are your EA services? Steve Jones: Enterprise Architecture – a tool not a destination MWD: Real-world Enterprise […]

  • […] view of Enterprise Architecture. Previous posts focused on the actual service definitions (here and here) and a general view on communications, this one focuses on the actual management of those […]

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.