IBM's redbook - wrong?

If you've been following this blog you'll know that my views on SOA usually do not "exactly" line up with those of the major vendors. It appears that IBM is continuing this tradition with their recent redbook "Patterns: SOA Foundation Service Creation Scenario". Right from the very beginning you'll see the difference in views, for instance, even in the definition of a service "A repeatable business task. For example, check customer credit; open a new account."

It appears that the prevailing views on SOA found in the red book are based on wrapping existing applications (see 1.1.4 SOA approach for building a solution). The main issue I have with this approach is that you, in essence, define you're new, supposedly business driven architecture on a portfolio of systems developed (again, supposedly) according to a technical driven architecture. I really don't see how this approach helps.

Of course you'll want to reuse existing assets in any new solution, but the solution itself should be designed and validated according to today's criteria.

Some of what's described reminds me of the problems originally encountered when Use Cases came out, but these same problems live on 'till today. The common anti-pattern "Use Case as a function" is exactly what these kinds of services embody. "Check customer credit" is, for all intents and purposes, a function. If you were to describe the system requirements with use cases, you might have a "Debit/Credit" use case. In SOA, have just that kind of service seems like a good fit.

Don't necessarily look to fit an entire business process into a single service, but if you can split up that process into several cohesive and loosely-coupled phases, expect each phase to be handled entirely in a single service. Moreover, when examining multiple business processes, if you find phases repeating themselves, you'll be well on the your way to a high quality Service Oriented Architecture.

Posted by Udi Dahan at 05:17 PM  Permalink