There seems to be some clear trends when you look at those building SOAs: They either break out way too many services or not enough. Let's back up a bit.
The core notion of SOA is to break your architecture down to information and information bound to services -- thus, the idea behind SOA, with the "S" being "services." However, many are taking service decomposition too far or not far enough. Perhaps I can help.
[ Keep up on developments in SOA with InfoWorld's Technology: Architecture newsletter. ]
If service decomposition appears to be new with SOA, it's really not. The fact is that decomposition, as a design technique, has been around since the structured programming days when we did process decomposition to better define systems before we turned the design over to programmers.
Service decomposition, in essence, is breaking larger, coarser-grained services down to smaller, finer-grained services. Depending on the objectives of the architecture, many decomposition criteria can be created and applied. This criteria has a huge impact on the architecture, including:
- Development time
Thus, you have to know when to stop decomposing services, no matter if the services are abstracted from an existing system or systems or built from scratch. But how? Here are Dave's quick and dirty tips for service decomposition:
- Make sure to establish architectural criteria around service decomposition, considering the items listed above. Make sure to write it down and share it among the other architects. For instance, somebody needs to determine how coarse- or fine-grained a service needs to be to provide both the required performance as well as the reuse.
- As a rule of thumb, a service should provide a single bit of functionality that would typically take less than 500 lines of 3GL code (e.g., C++). For instance, Verify_Customer_Credit_Rating, which is directed to a discrete function, versus Process_Customer_Credit_Application, which is more about many functions combined. Again, just a rule of thumb.
- Make sure to include the developers in the service decomposition process. They should be capable of letting you know what a usable service is and what it's not, and thus, when you're over- or underdecomposing.
That reminds me, what was Beethoven doing in his grave? Decomposing. Forgive me.