EA Services: Part Two
Jeff Schneider posted the following comment to my previous post, “What are your EA Services?”
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 was hoping someone would ask a question along these lines, because it’s something I’ve thought a lot about. Services, by their nature, should seem very ‘responsive.’ After all, there should always be a service consumer and a service provider. The consumer asks, the provider does. In the context of an enterprise architecture team, or any other team for that matter, you do have to ask the question, “If no one is asking me to do this, why am I doing it?” Is that stance too theoretical, though?
When I think about this, I think services in this context (ITIL/ITSM) follow the same pattern that can be used for web services. There are services that are explicitly invoked at the request of a consumer, and then there are services that are executed in response to some event. In the latter case, the team providing the service is the one monitoring for the event. If some other team was monitoring for it, and then told your team to do something, then we’re back to the request/response style with one team acting as consumer and the other acting as the provider.
Coming back to the EA services, I think an Enterprise Architecture team will typically have a mix of request/response-style and event-driven services. It’s probably also true that if the EA team is closer to project activity, you’ll see more request/response services done on behalf of project teams, such as the Architectural Assessment Services and the Architectural Consulting Services I mentioned. If your EA team is more involved with portfolio management and strategic planning, then it’s possible that you may have more event-driven services, although these could still be request/response. Strategic direction could be driven by senior management, with direction handed down on areas of research. That direction represents a service request from that strategic planning group to the EA team. In an event-driven scenario, the EA team would be watching industry trends, metrics, and other things and making their own call on areas for research. It’s a subtle difference.
Anyway, I do think Jeff has a valid point, and as part of defining the services, you should classify the triggers that cause the service to be invoked. This will clearly capture whether they are event-driven or request/response. If your list is entirely request/repsonse, that’s probably something to look into. That may be what’s needed today, but you should be practicing good service management and planning for some event-driven services in the future if your team continues to provide value in the organization.
Thanks to Jeff Adkins for the good discussion about this on Twitter.
3 Responses to “EA Services: Part Two”
Leave a Reply
A kind of event that might trigger EA services is one that looks like “we think we might have a problem in such-and-such area”. (This is what Philip Boxer calls a P-type service. http://www.asymmetricdesign.com/archives/67)
In this example, “we” could be the EA team or the EA customer or both together. The service might include clarifying whether there really is a problem at all, not just solving a known problem.
The event triggering this kind of work is typically a weak signal. There are usually more possible problems than we actually have time to work on, so the existence of a problem is not a sufficient trigger for activity.
“Enterprise Architecture team will typically have a mix of request/response-style and event-driven services” — I agree. Also, your point about noting the triggers is valid. I’d also say some events are scheduled, not just out of the blue (such as EA creation tasks that are linked to the budget cycle).
[…] 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 services, […]