Todd Biske: Outside the Box

In a comment on my “EA and SOA Case Panel” entry, Surekha Durvasula asked me a couple questions. They didn’t come up in the panel discussion, so I thought I’d respond in a separate entry, as the topic should be of interest to many of my readers. She wrote:

Is “reuse” of a business service considered a valuable metric? How does governance influence the “reusability metric”? Did this come up during this SOA panel?

Specifically, I am wondering if service governance has any bearing in terms of not only promoting the usage of a service but also in ensuring that the enhancement of a service is in keeping with the enterprise-worthiness of the service. Often times it is the evolution of the service where cross-domain applicability is sacrificed.

Also, is there a trend in the industry in terms of promoting business service usage via the use of a “rewards program” or in tying it to compensation packages? Have some industries reached a level of maturity in terms of service reuse especially in those industry verticals that are hit with global competition forcing them to reduce overall operations costs and/or to offer novel product offerings?

Let’s take these one at time. On the subject of reuse, I absolutely think that number of consumers is a valuable metric. At the same time, when dealing with reuse, one must be cautious that it isn’t the only metric of interest. I’ve been in meetings with individuals that have made comments like, “If a service isn’t reused, why are you making it a service in the first place?” I strongly disagree with statements like this, as do most pundits in the SOA space. To defend this position, I frequently quote the oft-referenced Credit Suisse SOA efforts, where they stated that their average number of consumers per service was 1.5. This means that there will be many services that aren’t reused, and probably some that are used by many consumers. While reuse is important, we also have to be looking at metrics for agility, which loosely stated, is the ability to respond to business change. This will involve tracking the time it takes to develop solutions. The theory is that by breaking a solution apart into autonomous services, I reduce the number of touch points when the business needs change. In reality, it depends on the type of change. For example, most of us would agree that a separation of presentation logic from the core business processing is a good thing. That being said, there certainly are plenty of changes that will require touching both the presentation logic and the business logic. One of the most difficult parts of SOA is knowing where to draw service boundaries, because the rules are always changing.

Back to the subject- if we have reusable services, what role does governance play in ensuring that the service doesn’t fork into a bunch of one-off, consumer-specific variants? This is a very interesting question, one that I hadn’t thought much about in the past. My gut is telling me that the burden for this belongs with the service manager, not with a governance team. That’s not to say that there shouldn’t be any involvement from the governance group, but I see a much stronger role from governance in establishing the original service boundaries and assigning service ownership. For future versions, the service manager must be the one that can recognize when the service is getting outside of the boundaries that were originally intended, and this will happen. In some cases, boundaries may need to be redefined. In other cases, we may need to push back on the consumers. All of this starts with that service manager. The service manager must balance the needs of the consumer against the cost of service management. Measurements for determining that manager’s performance should include the number of versions currently being managed and the time required to respond to consumer requests. It is then in their best interests to keep the service focused on its original purpose.

Finally, regarding “rewards programs” or incentives, I don’t know that I’ve ever heard of a case study centered around reuse that didn’t involve incentives. SOA is about culture change, and it’s extremely difficult to change culture without incentives. One only need to look at a government to understand how change occurs. No one would be happy if the federal government mandated that all cars sold starting in 2008 had to get 50 mpg or higher. This is the “big stick” approach. I’ve got a big stick and you’ll get whacked with it if you don’t comply. In terms of IT incentives, one manager I worked with summed up the “big stick” approach well, “Your incentive is that you’ll keep your job.” More typically, the government takes a “carrot” approach, at least at the beginning. Tax breaks are granted to companies that produce high mpg vehicles and to consumers that buy them. These incentives may not even cover the added cost of that approach (e.g. does a $500 tax break for 4 years justify spending $3000 more on a vehicle?), but just the fact that they exist can often be enough to encourage the behavior. Only when enough momentum has gathered does the stick come out, essentially stating a policy that is what the majority of the people are doing already. Overall, I think that incentives should be viewed as a short-term tool to get momentum behind the change, but should always be planned for phase-out once the desired behavior is achieved. Have we reached that point with SOA? I’ve yet to see a company that has. Have we reached that point with reusable libraries? Partially. Most developers would not build their own low-level frameworks today. The problem, however, is that multiple frameworks exist, and there’s still strong resistance in many organizations to having a single solution coming from a frameworks team. I heard my first talk on reuse back in 1998, so it’s very clear that widespread culture change takes a long time to do.

One Response to “Encouraging Culture Change”