We all know the tale of Goldilocks and the Three Bears: the story of an interloper that seemed to want her chair, porridge, and bed just so, despite her invasion of ursine privacy. Just as one-size-fits-all food or accommodations could not sate Goldilocks, so too are early proponents of Service-Oriented Architecture (SOA) realizing that they must size their Services just so in order to meet their pressing business problems so that they can maximize reuse and minimize unnecessary expense. Not only that, these early adopters are realizing that they must tackle significant aspects of Service infrastructure and architectural best practices from the very beginning, even if they are deploying a small set of Services. After all, a successful SOA implementation requires not only the right Services, but implementing them in the right way.
One of ZapThink’s repeated refrains is that SOA is an aspect of enterprise architecture, which itself is not a technology, but rather a discipline. An essential SOA best practice, is understanding just how to create the right set of Services so that they solve the right set of problems. After all, IT is in the business of solving business problems, not simply implementing technology solutions in hopes that they will find some business problem to solve.
Identifying Problems of the Right Size
One of the keys to finding the right approach for identifying Services of the right size is to identify the appropriate scope of the SOA initiative — in other words, to solve the right business problems. There’s significant danger in tackling a SOA project by focusing on all the potential Services a company might want. This approach amounts to trying to boil the ocean and is an exercise in futility. After all, the purpose of SOA is to deal with the unpredictable and frequent changes that companies undergo. As such, it doesn’t make sense to try to solve too large a business problem by trying to identify all the Services a company might need from the get-go, since those Services will necessarily have to continue to change over time.
On the other hand, ZapThink has been misquoted advocating that companies should start with the “smallest problem” that they can successfully tackle with SOA. Now, it’s easy to misconstrue that statement as recommending that companies develop only fine-grained Services, or even worse, suggesting that people tackle trivial problems that no one really cares much about. Certainly some notable experts in SOA space have confused what we meant here, but their commentary on this point is right on the mark. Indeed, we actually agree with many of their points (especially James Governor’s comments at http://mainframe.typepad.com/blog/2005/11/soa_is_going_to.html). On the contrary, the last thing that a company should want is a large collection of finely-grained Services that serve such narrow business requirements that each individual Service is nearly useless. Companies need Services of the right level of granularity to solve business problems. But just how big should the business problem be? This question is different from asking how granular the Services should be, or even how much infrastructure, architecture, and planning the company needs to implement those Services.
It’s important to understand what’s wrong with building an SOA composed entirely of fine-grained Services (or entirely of coarse-grained Services, for that matter). We like using LEGO