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.

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.