Among the key advantages of a service-oriented architecture (SOA) is not only the ability to map business processes but also the ability to keep up with them as they change—that is, providing businesses with the flexibility they need in order to respond quickly to changing conditions and maintain a competitive edge. The downside is that just because SOAs are flexible doesn't mean that they rewrite the rules of application development and change management. But because services are smaller and more lightweight than applications, there's also more to keep track of.
In a new report, Rob Hailstone, IDC's European research director, Software Infrastructure and SOA, looks at the impact of SOA on the ability to accommodate change in IT systems and the impact of accelerated change on the management of the SOA environment. In this Q&A, he talks about the ramifications IT faces.
Q: Let's start by talking about what's good about SOAs.
A: SOAs allow people to change their minds. We've been through decades in which, irrespective of technology, you would analyze a problem to death before you started creating the application. Subsequently the problem would change, and then to respond, you were faced with a big bill for changing the application. SOA addresses the reality that the world is going to change in any case.
Q: And your report relates to keeping track of all that change. ZapThink's Jason Bloomberg wrote a very interesting piece recently, with a similar bent, looking at SOA development as it relates to chaos theory.
A: I saw Jason's piece, and I agree with the sense of it. You need an environment that thrives on change. Logic says that once you've gone through the first few projects, the lid's going to come off and change requests are going to come thick and fast.
Q: And that's where the chaos comes in?
A: Right. The problem about SOA is that it's been oversold as a simplification of IT. The architecture is simple, but you end up with a lot of small pieces, each with its own life cycle. Now, because the services are autonomous in an SOA, they're all likely to evolve at their own pace. The combinations thereof are going to be enormous. It's not just the services or how they are hooked together but also the different versions of the messages you pass between the services, the user authentication and identification, the permissions attached to roles, the disparate audit requirements, governance, billing requirements, and service level agreements. SLA management brings a real potential for extra complexity, because sites are starting to talk about giving each of their customers individual SLAs. You can see each of these business policies going through its own lifecycle in the same way as the services themselves.
In a couple of years' time, you'll end up with an amazing collection of pieces of the solution, each of which has multiple versions and each of which has a separate life cycle, and you'll need to manage and audit it. What were the rules that applied to this transaction last June? How quickly did you respond? This information needs to be kept in a coherent way. When you're implementing a pilot project for an SOA, you won't see this requirement until you're farther down the road. If you don't put into place a way to track this metadata, you're going to have a difficult time.
Q: So it's a question of metadata management?
A: Yes, all of these policies are just different kinds of metadata.
Q: Certainly there are vendors talking about this.
A: I don't think any vendor does everything yet, and that's part of the problem. All of the major platform players, such as Oracle and IBM, have a repository capability, but they've been developed piecemeal. There are also repository specialists such as Systinet, which was recently acquired by Mercury, and Infravio. Each of the metadata types needs a solution that handles it in a consistent way. I'm not singling anyone out for criticism. We just keep discovering new pieces of metadata that have to be managed. In the long term, we're going to need a federated repository, but we have no idea how to manage it.
Q: How huge is this problem?
A: It's really not that much different from problems we've had with corporate databases. Even if there were a way to create a single, comprehensive repository, you still end up with multiple products through mergers and acquisitions. With some movement on the standards side to allow multiple repositories to be viewed as a single one, it'll be OK, although that's quite a challenge.
Q: So you're optimistic?
A: Yes, but it won't happen all at once. Services have the UDDI standard. If service repositories are not federated, they should at least be replicated. The OASIS EBXML standard provides a partial solution, but it's already complex. So there are some pieces in place, but they're only biting off corners of the problem.
Q: What can IT do in the meantime?
A: Part of an SOA pilot should include the ongoing management of the SOA environment itself. Right now there are some tools in place, but others you'll have to build to handle procedures internally. People embarking on an SOA don't have the luxury to wait until the technology is stable and available at commodity prices. You have to create some internal procedures.
Q: What if you've already started on an SOA?
A: Then nail this down before the number of changes becomes a big issue. It depends on the rate of change in your organization, but you certainly want to go back and make sure you've captured the descriptions of all of these pieces of metadata. That may not be enough. If the services run within the firewall, it's not the same as dealing with external systems. For most people, SOA management won't be a huge issue. I'm trying to raise awareness. When you're going to a widespread deployment, you'll have more change requests, and the problems stemming from letting them get out of control will be that much more obvious to the outside world.
Feedback question: Tell us what you're doing to keep SOA change management from spinning out of control.
Q&A conducted by contributing Web editor Howard Baldwin.
