Revisiting Service Categories
Chris Haddad of the Burton Group recently had a post entitled, “What is a service?” on their Application Platform Strategies blog. In it, he points out that “it is useful to first categorize services according to the level of interaction purpose.” He goes on to call out the following service categories: Infrastructure, Integration, Primitive (with a sub-category of Data), Business Application, and Composite.
First off, I agree with Chris that categorization can be useful. The immediate question, however, is useful for what? Chris didn’t call this out, and it’s absolutely critical to the success of the categorization. I’ve seen my fair share of unguided categorization efforts that failed to provide anything of lasting value, just a lot of debate that only showed there any many ways to slice and dice something.
As I’ve continued to think about this, I keep coming back to two simple goals that categorizations should address. The first is all about technology, and ensuring that is is used appropriately. Technologies for implementing a service include (but certainly aren’t limited to) Java, C#, BPEL, EII/MDM technologies, EAI technologies, and more. Within those, you also have decisions regarding REST, SOAP, frameworks, XML Schemas, etc. I like to use the term “architecturally significant” when discussing this. While I could have a huge number of categories, the key question is whether or not a particular category is of significance from an architectural standpoint. If the category doesn’t introduce any new architectural constraints, it’s not providing any value for this goal, and is simply generating unnecessary work.
The second goal is about boundaries and ownership. Just as important as proper technology utilization, and probably even more important as far as SOA is concerned, is establishing appropriate boundaries for the service to guide ownership decisions. A service has its own independent lifecycle from its consumers and the other services on which it depends. If you break down the functional domains of your problem in the wrong way, you can wind up making things far worse by pushing for loose coupling in areas where it isn’t needed, and tightly coupling things that shouldn’t be.
The problem that I see too frequently is that companies try to come up with one categorization that does both. Take the categories mentioned by Chris. One category is data services. My personal opinion is this is a technology category. Things falling into this category point toward the EII/MDM space. It doesn’t really help much in the ownership domain. He also mentions infrastructure services and business application services. I’d argue that these are about ownership rather than technology. There’s nothing saying that my infrastructure service can’t use Java, BPEL, or any other technology, so it’s clearly not providing guidance for technology selection. The same holds true for business application services.
When performing categorization, it’s human nature to try to pigeonhole things into one box. If you can’t do that, odds are you’re trying to do too much with your categories. Decisions on whether something is a business service or an infrastructure service are important for ownership. Decisions on whether something is an orchestration service or a primitive service are important for technology selection. These are two separate decisions that must be made by the solution architect, and as a result, should have separate categorizations that help guide those decisions to the appropriate answer.
2 Responses to “Revisiting Service Categories”
Leave a Reply
Todd correctly asserts that ownership and architectural constraints are important facets, and categories must be chosen wisely. On many architecture projects, an important contribution is to simply separate items into structured logical groupings. He incorrectly assumes that I was proposing a comprehensive categorization scheme in a short blog posting.
My intent is to expose readers to a limited number of areas where they may consider ownership boundaries, begin an inventory effort, and identify service candidates. Teams should not be paralyzed by the ‘what is a service’ question, and the scope of service initiatives can be expansive rather than restrictive. The short list should trigger thoughts about ownership and architectural domains. An inventory exercise is more readily understood when each team member is presented with a service definition that maps to their area of expertise. Security team members may inventory their infrastructure capabilities to propose security services. Data architects may review schemas to define and propose data services. While business owners may analyze business processes to define business application services.
Thanks for your comments Chris, I appreciate your followup. I actually didn’t assume that your categorization was comprehensive, but in reading my own entry, I can certainly see where someone could come to that conclusion, which was not my intent. As is more often the case than not, we are in agreement on the core principle which is to have a purpose behind the categorization being done.