<<On the subject of SOA and change management, how difficult is change management? Al Zollar: 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? Zollar: 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? Zollar: 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? Zollar: 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.>> You can read this interview in full at: http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1256276,00.html?track=NL-110&ad=589630&asrc=EM_NLN_1480713&uid=5532089 Gervas
