What should be a service? Not what API should be exposed or what function of the application should be exposed. At the higher levels of SOA maturity when we actually begin to architect pieces of business functionality as services, what should a service be? From the analysis perspective, from the business perspective, and that ultimately becomes the actual IT modules and blocks of code.
I had to give a presentation on that exact question. It was surprisingly challenging, as almost every situation I’ve been in finds either organizations exposing application level functional API’s as services – and sometimes combining/composing those into wider services or enterprise services – or wrapping various blocks of IT functionality to offer more business flexibility (in theory from the IT perspective), as services.
Suddenly someone was asking, “ok, assuming we’re going to build a real Service Oriented system from scratch, at what level of granularity do we plan the services?” Good question!
A little architecture research led me to create this presentation, which is mostly a wholesale rip-off from an architecture website (credit is given in the presentation). However, while I believe this presentation has good conceptual information, it was a FAILURE in smoothly getting the ideas across.
I welcome feedback on how to make it better and/or other sources for these concepts.