Todd Biske: Outside the Box

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.

2 Responses to “What exactly is a service provider?”