Everyone, Given that this discussion has wandered around for a while and in several different directions, I wanted to put together a response. I chose to remove the history of the discussion since there were several different sets of includes with different depths and just start with a clean slate for the reply.
Issue 1 -- ITIL is a set of guidelines not an absolute Step one in any discussion -- not unique to this discussion -- is to remember that ITIL is a set of guidelines and is not absolute. It does not have an answer to everything. In the real world, there are things that are simply not practical and it is important to interpret and allow for deviation. It is a good set of guidelines and the goal is to follow the basic principles and directions that it encourages. However, there are also times to deviate. Let's take a specific example with the CMDB. In ITIL v2, the CMDB specs said that things like Trouble Tickets and SLAs and the like all belonged within the CMDB. The problem is that these things are not configuration items (well, we could talk about SLAs, but for sure Trouble Tickets). BMC decided that the CMDB was for CONFIGURATION data and did not model Trouble Tickets in the CMDB and insisted that they did not belong there. I know we ran into a number of customers with "ITIL police" who insisted that we were doing things wrong because Trouble Tickets did belong in the CMDB. "It says so right here.....". I was involved in many discussions around this topic. Well, it turns out, that by the time ITIL v3 came along, there was an understanding that Trouble Tickets really didn't belong in the CMDB and you will find that they are not items that ITIL v3 advocates are in the CMDB. There is now the CMS which BMC always called the Extended CMDB and Trouble Tickets are there but stored in a Trouble Ticket data store. This interpretation of what a CMDB is and is about is what BMC had advocated from the start and as it turns out ITIL agreed and adjusted where if we had just followed the ITIL rules at the time, it would have been the wrong direction. Now, I am not indicating that there is the same issue going on in this situation (and in fact I don't), but I always want to start any conversation with this note whenever there is a battle that forms up along the lines of "ITIL SAYS". Yes, but. Issue 2 -- What are we trying to accomplish? Now, let's return to this situation. What are we trying to do? What is the problem we are trying to solve? -- Need to request, plan, and have the steps to execute a change to the environment -- Need to request, plan, and orchestrate a set of changes and other activities in the environment If I take these things, there is a difference in scope and process in these two goals. The first is about making a very specific change. To interact with the environment and change the configuration in some way. There are a specific set of steps that need to be performed. You may need to be aware of other changes to the same object and want to coordinate them. But, in general, you are worried about a point change to a specific object and not about the bigger picture of coordination of the entire environment or infrastructure. The second is about really more complete planning and coordination of one or more changes and potentially other things in the environment to have a larger scope process. You many need to make a series of changes and have things like training or data conversion or any number of other things involved and scheduled and synchronized. There is the concept of a rollback plan (not part of change by the way) if there are problems. There is a concept that you may or may not get all changes and what to do about that (if one thing out of 50 is not done are you OK or is that a failure). Notice that the second item here is "bigger" than the first. There is an entire layer of planning and coordination that is not part of the first. They don't intermix. One is about "performing" the update. The other is about "coordinating" the update(s) and other activity. If there is not some distinction between what is going on, why would there be a need for different processes and flows -- whether ITIL or not. There seems to be agreement that there are two different things going on here and there needs to be a clear line between what is going on and why I would want to use one process or the other. Issue 3 -- What has BMC done? With the distinction between the roles of the process above, it is pretty clear that there is a hierarchy in the two items -- one is about "performing" and the other is about "coordinating the performing". So, there needs to be two different processes because they are doing different things. Performing is Change Management Coordinating is Release Management Note that BOTH solutions are tied together into the single overall concept of managing change within your environment. This is much like the processes of incident management, problem management, known error are all part of the overall concept of responding to user/system issues/failures. So, for the overall topic being this is involving the "change process". Yes, this is the change process which has two components that you can use each involving a different aspect of change. When looking at the ITIL definitions, we argue that there is agreement between what ITIL says these processes are and what BMC has done and how we divide the work. This belief is supported by the fact that we are rated ITIL-compliant in both the Change Management and Release Managment diciplines. If you look at the ITIL "Mission Statements" (as Chris referred to) -- stolen from the ITIL site. Change Coordinate and control all changes to IT services to minimize adverse impacts of those changes to business operations and the users of IT services. Release Implement changes to IT services taking a holistic (people, process, technology) view which considers all aspects of a change including planning, designing, building, testing, training, communications and deployment activities. Notice that in these definitions, the Release definition is "bigger" (no, I am not talking about more words, I am talking about more inclusive and all encompasing) than the Change definition. It includes a lot of things AROUND change. Change is the mechanics of the change itself. Release is all the things that need to be done to get it done. Singificantly, Changes happen within a Release but Releases don't happen within a Change. So, Release is a layer above Change. This is exactly how BMC has implemented it and we argue it is exactly what ITIL intends and describes. Again, don't confuse the idea of an overall Change process with the creation of a change or release ticket. Both are part of the Change process. Each have their role. I compare this to building a house. Changes are things like the framing, the plumbing, the electical (actually, I would argue that each of these is a whole set of changes). The release is the overall process of all the changes and the permits and the hiring and the trips to the store to chose which color tile you are going to lay and the ..... In the middle of the release process, changes are occurring. Finally, as for names. We didn't pick the names. We used the names that ITIL selected for these things. We implemented the flows and interactions based on the model that ITIL set down. So, we wouldn't be following our own rules and suggestions of follow the standard applications (except where there is clear business value in deviating rather than just using the standard flow) where the name chosen does not add business value to be different (and in fact adds confusion) over what ITIL advocates. Hopefully, this note has been useful. Doug Mueller _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
