How does change management and autonomic computing impact service-oriented architecture (SOA)? At IBM's Impact 2007 conference in Orlando this week, we asked Al Zollar, general manager of Tivoli software, about the role of management software in SOA. His answers focused on the need to automate management as much as possible to free IT professionals to do the more creative work involved in SOA.On the subject of SOA and change management, how difficult is change management?
Before we talk about the difficulty, let's talk about the importance of change management. If you have 10 service delivery failures, chances are eight of them were caused by a change that people swear they didn't make. So being able to know the source of changes is really critical. That's why in our change and configuration management database we have a capability called "change history." This is where you can take a configuration item, which can be a server, a network device, a component, a service, and query the change history. So when people swear they didn't make a change, you can say: "What about that one?" Then they'll say: "Oh yeah, maybe that had something to do with it." So that's the importance of change management.
The difficulty is the linking of process, technology, information and people. Most organizations have emphasized one of those, but few have put equal focus on all four dimensions. Our approach is to encourage customers to understand that they need to integrate people, process, information and technology around change management. We've got portal-based interfaces to connect people to processes. Our technology includes Tivoli provisioning manager, which can effect the change in an automated way for repeatable SOA services. How does server virtualization and versioning impact change management going forward as organizations adopt those technologies?
It's a dynamic in the infrastructure that can effect change management. If you've got virtualization going somewhere in the infrastructure, you don't know what logical partition an application is depending on. And if you don't know that, you don't know the impact of changing something that a specific business service is depending upon. I'll sound like a broken record here, but with our change and configuration management database there's a discovery server. It goes out and scans the infrastructure – it's an agentless approach, it's not an anti-virus kind of scanning – and sees what's actually running across a range of IP addresses, so we can compare that to what we expect to be running. If there are things running that we didn't expect to be running, you can ask why. Or if there are changes as a result of virtualization, where we've moved the workload from one partition to another, that could be reflected back into the topology that we report on for the business service. It's about integrating all these components and having capabilities like real-time discovery so that you can see the current state of the infrastructure. Do you see change management as an area that's ripe for autonomics?
Oh, yes. Our whole approach is based on what we call our matrix, autonomic computing. Monitor, analyze, plan, execute based on the knowledge base. That's the architectural principle we've been using as we've been building out our capabilities. How far along are you with that?
There are a couple of dimensions. We have products that can be completely autonomic. Our provisioning manager senses changes in workloads and automatically moves and re-provisions without human intervention. That is technology that is fully autonomic. What we look at also are the organizational capabilities. Putting autonomic capabilities in one little part of the infrastructure is not that valuable. How automated can you make the overall service delivery organization? If you look at the statistics, they would say we're a long, long way from being there. You may have heard Steve Mills say that 70 percent of IT budgets are labor. Within that 70 percent, another 70 percent is IT operations labor with 30 percent for development and maintenance. That could be partially offset by more and more applications based on autonomic principles.
It's the IBM Tivoli Composite Application Manager. SOA is a new set of technologies being deployed and like anything it has to be managed and secured. So the Composite Application Manager is focused on three manager functional capabilities. First, you have to be able to discover services that are in a registry, which is the official source of what are the services for an organization versus what are the services running in the infrastructure and resolving any differences that might exist there. The WebSphere registry/repository feeds the Composite Application Manager, so it knows the officially authorized services. The second thing it does is monitor and log the data from actual service usage, so it's able to monitor things like end-to-end response time. It's able to understand message flows and opportunities to redirect or mediate messages. Third, it provides reports for service level agreements and charge-back in accounting through a companion product the Tivoli Usage and Accounting Manager. All three of these are part of the theme of being able to manage an SOA environment. Does this fill a gap in SOA because there wasn't a way to do this previously?
It depends on your interpretation of a gap. There's always ways to do things, manual labor. So what we've done is provide capability that instead of having somebody FTP a bunch of files or try to copy and paste other things that might not only be manual but might be error prone, we can read directly from the repository. This is more integration, more automation. These things can be done in a variety of ways, but we think this is a much better way.