Todd Biske: Outside the Box

Archive for April, 2006

A friend of mine, Fred Domke, blogged about using a B2B scenario as an SOA pilot. In a previous posting, I discussed my opinions on what constitutes a good pilot. The key item that I mentioned was choosing something that will expose the organization to the cultural changes associated with becoming a service provider.

In this case, I don’t agree that a B2B scenario makes for a good pilot. I agree completely that B2B scenarios are great applications for SOA, but I don’t think they’re going to introduce an organization to the cultural changes. The first problem is that a B2B integration may not involve the cross-organizational concerns that arise. Of the case studies/presentations I’ve seen, the B2B integration scenarios only involved one organization (at least on one end of the integration). That organization was already acting as a service provider, so there is no culture change needed. Yes, there may be some inefficiencies in the integration processes, but outside of some incremental improvements, will the use of standards-based integration technologies in this scenario provide the results for an adoption of SOA across the entire enterprise?

I think there are far more problems on the inside of the firewall that require the cultural changes associated with SOA for resolution. Companies that are doing business together already know that they must work together. Ironically, sometimes it’s easier to get two companies to work together than it is to get two departments within a company to work together. By all means, apply SOA to your B2B integration scenarios. You’d be nuts not to. But to really see the benefits, it needs to be applied inside the firewall.

Many pundits have compared the adoption of SOA to the adoption of object-oriented programming or other development technologies. One of the things that I don’t like about this is that these comparison are rooted in the technology side of things. While I enjoy new technology as much as the next engineer, I tend not to get excited over technology for technology’s sake.

My friends and colleagues know that I have a background in human-computer interaction, usability, and user interface design. The application of technology to the problems facing the end users has always interested me. It is precisely this interest that makes SOA so appealing to me. If I had to compare adoption of SOA to something, I’d compare it to an adoption of user-centered design and usability techniques based upon the work of Jakob Nielsen, Larry Constantine, and others. I was originally introduced to these concepts in 1994, and it’s somewhat disappointing that it never achieved the hype that SOA currently has.

As I see it, in the application focused world that we’re migrating from, a key differentiator is the ability of the user interface of those applications to meet the needs of the end user in a manner that was intuitive. This means that the context of the application needed to match the context of the business process being executed. Hmm… that sounds vaguely familiar. With SOA, we’re now extending that concept to the business tier. The truly successful service providers will differentiate themselves by providing business services that meet the needs of the service consumers. While usability techniques aren’t needed to do this, the concepts embodied in user-centered design will. The key to successful user interface design is the involvement of the user. Likewise, the key to successful service interface design will be the involvement of the service consumer.

Just as I felt that usability and user-centered design created an opportunity for companies to leap frog their competitors, I think SOA creates that same opportunity. They both have the common thread of trying to make our technology better match the needs of the end users- the business. The better understanding of the business, and the better we’re able to incorporate that knowledge into the design process, the more successful the SOA adoption will be.

So, you want to adopt SOA? What exactly will it mean to your IT organization? Previously, you were an application provider to your business customers. Now, you still need to provide those solutions, but in addition, you now need to provide services to the rest of IT. You have become a service provider.

This is part of the culture change that must occur to be successful in an enterprise wide adoption of SOA. In an era where IT projects can so easily spin out of control, we’re suggesting increasing the number of groups that need to come together to produce a solution. Nothing scares a project manager more than having to depend on something outside of the control, and that’s exactly what must happen.

Becoming a service provider is a big challenge. Your Enterprise Architecture group may have figured out what services you need, but who is going to provide them? This is not an easy question to figure out, because there are many different ways that things can be sliced and diced. Odds are, your current organizational structure may not map easily to the services that have been identified.

The best way that I’ve found to understand what it means to be a service provider is to ask yourself what you would expect if a third party was providing the service.

• Would you want a contract? Your legal department certainly does, and the contract would certainly have language regarding availability of the service, support structure, ongoing releases, etc.
• Would you want usage documentation? Absolutely. Would you need customization for your new requirements? Very likely.
• What about the relationship going forward? After that vendor provided the first production version, would you want them to disappear and pay no attention to you whatsoever?
• Do you think they’d be able to respond when you tell them you need modifications for your project with a production timeline 2 months from now?
• Would you want them to let you know that in one month, a new version goes live that another customer requested, and you need to upgrade or else your consumers will break?

All of these things apply to internal service providers as well. A typical application team that only had to deal with end users can get away with far more. Humans are much more tolerant to change than systems are. As you make the transition from internal application provider to internal service provider, you’ll need to change and mature your processes, changing the culture of your development staff right along with it.