Todd Biske: Outside the Box

James Urquhart brought to my attention the public review of SOA Patterns, as authored in the forthcoming book, “SOA Design Patterns,” by Thomas Erl. You can see the press release from Prentice-Hall here.

My first reaction when I received the email, prior to visiting the SOAPatterns.org site was one of skepticism. While I think patterns can add a lot of value, the immediate problem I saw stems from the fact that I’m very much a believer in business-driven SOA. In order to reach a broader audience across multiple verticals, you have to be more business agnostic. As we get more business agnostic, we naturally move deeper into the technology stack, and things at that level of granularity may not be the best service candidates, although they may be great candidates for reusable frameworks. If we’re talking about patterns inside of the service implementation, then we’re really talking about general design patterns, building on the original work of the Gang of Four, not really SOA Design Patterns.

So, with my bias set, I visited the web site. The first thing I hoped to see was some classification by business industries, such as “SOA Patterns for Insurance” or “SOA Patterns for Health Care” but I didn’t find them. Bummer, but I also didn’t expect this. Something like that would be of significant value as intellectual property to a consulting firm, and I think they’d make a lot more money keeping it to themselves and leveraging it on their engagements. What was on the site was four chapters: Basic Service Inventory Design Pattern Language, Architectural Design Patterns, Basic Service Design Pattern Language, and Service Design Patterns.< ?)>

In looking at the first chapter, Basic Service Inventory Design Pattern Language, my first reaction was again one of skepticism. The first page begins with “Inventory Context Design Patterns,” “Inventory Boundary Design Patterns,” “Inventory Structure Design Patters,” and “Inventory Standardization Design Patterns.” It also introducted a phrase- “service inventory architecture” -which I had never heard before. Looking at this page, nothing was making a connection with me. As I drilled into each section, I did find some goodness, but it could be argued that what is really being presented in this section is really a description of a step in a methodology, rather than a pattern. For example, one pattern listed is the “Enterprise Inventory” pattern, which lists the problem as:

Delivering services independently via different project teams across an enterprise establishes a constant risk of producing inconsistent service and architecture implementations, compromising recomposition opportunities.

The solution is:

Services for multiple solutions can be designed for delivery within a standardized, enterprise-wide inventory architecture wherein they can be freely and repeatedly recomposed.

This doesn’t feel like a “pattern” to me, but it’s certainly something that should be done. I don’t think anyone would argue that having an enterprise service inventory is a bad thing. Another pattern I looked at was the “Vendor-Agnostic Context” pattern. Again, what was presented in the “pattern” was goodness, however, it felt more like a principle rather than a pattern. This particular one did do a good job in demonstrating how this principle does lead to the use of specific techniques, such as leveraging the “Canonical Protocol” and “Decoupled Contract” patterns.

Overall, what did I think? Well, it certainly didn’t meet my original hope of seeing industry-specific business patterns. By that, I mean I didn’t find something that said “Order to Cash” with guidance on the types of services that should make up that process. I didn’t find something that said, “here are services that all organizations with an HR department should have.” Nothing business-specific whatsoever. Of course, I didn’t expect to see this, it’s just what I was hoping to see, just as I hoped the (defunct?) SOA Blueprints effort from OASIS a couple years ago might produce something along these lines.

Putting that bias aside, the more I dug into the site, the more I found things that provided good guidance, even though I’d say the use of the “pattern” moniker was a bit liberal. If you want to get an idea of what principles and factors should be considered in creating good services, versus just slapping WSDL or XML schemas in front of some existing logic, there’s a lot of good material here that is freely available. While some of the earlier pages read too much like a college textbook, a couple drilldowns brought me to things that were applicable to my daily work and made sense. So, based on that, I would recommend that people at least visit the patterns site, drill down into it, and see what nuggets you can leverage in providence guidance to your service development teams. If you really like it, then perhaps Thomas’ book can become part of your standard library for your developers.