Todd Biske: Outside the Box

In a SearchWebServices.com article, Rich Seeley asked the question, “Who owns the SOA business case?” I think this is asking the wrong question. The business case should not be for SOA, but for the services. While some may read this and simply think that I’m nitpicking on semantics, I think it’s an important distinction. If the business case is for SOA, what’s the scope of that SOA? Is it an application architecture? An architecture that encompasses a line of business? An architecture that encompasses the entire enterprise?

The business case should provide the justification for what gets built. The services are what will be built. The article used the term “SOA project” numerous times, which is a pet peeve of mine. I don’t think there should ever be a “SOA project” as you can’t build a SOA. So, the reality is that we have business projects, which probably had an owner assigned the same way that it’s always been done for all business projects.  As part of the project, one or more services are going to be constructed. This equates nicely with Miko Matsumura’s analogy, where he described the interaction between an electrician and a home owner. The electrician likely knows more about the electrical system than the home owner, but the home owner is the one picking the actual light fixtures. Location may be a joint decision, as the home owner may not understanding implications of particular locations. The decision on what goes on in the walls is probably exclusively the responsibility of the electrician (based on the local building code). There are always exceptions. My father was an electrician in the Chicago area, so he and I have a preference for wires flowing through pipe rather than the use of romex, and may choose to have more say in that decision. The same may hold true for a tech-savvy business owner.

Both Tony Baer and Dana Gardner have posted blog entries in response to the article and get closer to the notion of what the right thing to own is. Dana suggests that ownership should reside at the business process level. This is one way of slicing it, but it’s not the only way, and therefore, it’s probably not the right way. In my opinion, ownership comes into play at many levels. A service can be shared across multiple applications. A service can be shared across multiple business processes. If ownership of the shared service is assigned to a single application or business process owner, there’s risk. The right way is to draw a line between business ownership of a service and business ownership of service consumers. You’ll probably need both. Now the risk associated with this approach is the number of individual owners may grow quite large. While I do think that an organization should try to make some determination up front on the potential for a service to be shared, I also know that whatever direction they go, things will change. So, it is important to have an idea on how to change ownership of a service after the fact. Just as a commercial organization may begin with “bundling” and eventually converge multiple products into one, so may be the case with services. If this makes sense to you, then you’re grasping an aspect of the problem that hasn’t been discussed yet, which is, “What does a service owner actually do?” The owner of the business case, and ultimately, the service, is not simply the source of funding and scope decisions for the project that builds version 1.0, but must be the owner of the whole service lifecycle from version 1.0 to the decommissioning of the last version, handling the onboarding of new consumers, “service” to existing consumers, etc.

4 Responses to “Business Case defines the Services, not SOA”