NIH in the SOA.

by Robert Cooper

Vincent Pardington has a good post up on DZone beginning an SOA pitfalls series. His first post, on NIH in the SOA world is a good one, but I think misses one important point:

First of all, the idea of a SOA is to reuse existing services. If department A builds a get_personal_details service, there's not much point in department B building a get_address service. Assuming the get_personal_details service returns the full address.

Of course, there may be multiple reasons why department B would do this:

  1. They don't know about the get_personal_details service. In this case there is no proper service registry, a point we will discuss later.

  2. The way they design their application does not cause them to think about reuse. This is one of the things that can happen when applying Big Design Up Front. Something we will also discuss in a future blog (way to build up the suspense, not? ).

  3. They've known about the get_personal_details service but they decide not to use it. Maybe they don't know what it does exactly, maybe they don't trust department A to get it right or keep it right, or maybe they'd rather have full control over the implementation. In this case, you have some classical NIH hitting you. This is the time to discuss the ownership of the services and allow both department A and department B to feel in control.


I think there is one more here that is organizational. In my experience, services in the enterprise tend to be developed as part of an application. The problem is, they aren't staffed as standalone products after the application for which they were originally designed goes into maintenance mode. Let me set up a #3 to Vincent's storyboard:


Team B knows about the get_personal_details service, but the address returned doesn't include the shipping code for the address. They would love to use it, but Team A is now working on the next project. Team A's boss doesn't want to spare resources to amend expand the service, and Team B's boss doesn't want to take ownership of the service.


The problem is one of perspective. In reality, Team A built TWO applications: One for the end user and one for developers and they should be slotted to do ongoing enhancements to either one of those. I know at Manheim there was an earnest effort to establish a product ownership system fro the "Services" products. The problem there was, nobody in management wants to own them.

I know there was a great article in ACM Queue a little over a year ago about the services infrastructure at Amazon. Their solution was to treat the services products as a profit center: every call back to underlying services was "billed" to the application group making the call. This has the effect of encouraging the service owners to add value to the services infrastructure, as well as encourage upstream applications to be frugal in their stress to the back end. I found this to be a really compelling structure, but I can also see how it might lead to some... poor... software decisions in a less disciplined organization.