Todd distinguishes between two kinds of service, which he calls request/response-style and event-driven 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."
But surely a request is an event? The EA team may have many conflicting demands on its time and attention, and so there is always a decision (perhaps driven by some policy) whether and how quickly to respond to a given request.
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 - rcKP - services at the edge.)
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.
One interesting question here is how the event-driven EA actually works. The EA team must have some view of a complex and dynamic world to which it is attempting to add value, that allows it to organize its work. In other words, it needs a model (possibly implicit, but preferably explicit). But what model is this? Not just the enterprise model itself, not just the enterprise architecture framework (TOGAF or what have you) but something else as well.
No comments:
Post a Comment