Archive for November, 2006
I was talking to a guru in the change management space and sharing with him all these companies that came up in the search and asked for his opinion on this concept of the application view and he had a really great insight …
Software which starts with the applications, like Asset Management (for example, Mercury Asset Management…) and Relicore (Symantec), Collation (IBM), nLayers (EMC), Cendura (CA), Appilog (Mercury) all have one common characteristic … the need a white list.
Niether this guy nor I have used all these software, but a cursory look at their description seems correct … they all need a pre-configured list of things which they should track. If you think from an application point of view this makes a lot of sense … once you know it is Hyperion, you can enumarate all the files and configuration settings for example with Hyperion and track changes to that.
This clearly has several advantages and dis-advantages. First advantage, since most of the above software (except Relicore/Symantec) scan the system, this reduces the time and resources required for the scan. It also presents change data in an applicaiton context which is more useful for the end-user. The
The dis-advantages are same like with other white-list approaches, they need to be constantly updated, also may not be available for older/newer versions of the software. What do you do for custom software … user has to input all this stuff etc.
November 28th, 2006
HP, Mercury (now HP), BMC, CA, EMC, IBM, have been on an acquisition binge over the past few years to put together thier porfolio for ITIL/ITSM. Here are some of the recent acquisitions … are there others that you think are also related to ITIL?
| |
Dev.
Process |
Application Dependency
Map |
Service
Desk |
Provisioning
System |
Other |
HP
|
|
|
Peregrine (2005) |
Novadigm(2004), Consera(2004) |
Baltimore Tech. (IM) |
IBM
|
Rational(2003) |
Collation |
MRO (2006) |
|
|
Mercury
|
Kintana (2003) |
Appilog (2004) |
Vertical Solutions (2005) |
|
Systinet (SOA) |
CA
|
|
Cendura |
|
|
Netegrity (IM)
Wily (SOA) |
Synmantec
|
|
Relicore |
|
|
|
BMC
|
|
|
Remedy (2002), Magic (2004) |
Marimba (2004) |
Identify(IM)
Calendra(IM)
OpenNetwork(IM) |
EMC
|
|
nLayers |
|
|
|
November 17th, 2006
Yesterday I heard Cal coach Jeff Tedford on the radio talking about preparation for this week’s big game. Tedford said he would not prepare any differently this week than any other week in the season because 1-if he knew a better way to prepare he would use it every week and 2-if he changed something and something unplanned happenned in the game he would not know if the new practice plan was the cause or whether it was something else. It struck me that what Tedford was saying is that controlling and managing change is a key part of his plan-thus the tie back to key ITIL principles.
Go Bears!
November 15th, 2006
There are so many help desk tools out there, most of which now call themselves service desk — that I find it very confusing to understand all the nuances. I found this forrester report really useful (and it is avaliable for free, from the altiris web site).
It compares Altiris, Axios Systems, BMC Remedy, BMC Magic, CA, Front Range Heat, HP Peregrine, HP Openview Service Desk, Numara, Touchpaper and Unipress.
Here is an excerpt from the begining which I thought was simple and insightful …
“The organization formerly known as the help desk is growing up. Under the moniker of “service desk,” it is expanding its footprint and adding such functions as problem, change, and configuration management to its previous incident-focused role. The classic help desk was somewhat limited
in its scope and parochial in its focus: Users would call with a problem, and technicians would endeavor to fix it as quickly as possible. Help desk software would track incidents and open tickets as responsibility passed from one person to another. Once solved, reports would point out potential hot spots for further study and possible proactive action. Only rarely would the help desk have incidents opened directly from systems management utilities or be tied into any formal change management process.
As processes and procedures for ensuring the continuing health of the IT infrastructure developed, more complex workflows and organizational handoffs were required. Enterprise-class tools to support this service management followed. Common structures and practices added a framework for further refinements. Today, there is widespread acceptance among larger and more complex organizations of a structure following the Information Technology Infrastructure Library (ITIL) model for service management, and tool vendors have followed with products that assist in ITIL implementations.
Smaller organizations and those not ready to make wholesale change to structures and processes nevertheless want tools that are robust, simple to install and configure, and easy for technicians to use. For these organizations, incident and problem resolution remains a key focus, often with an additional emphasis on desktop life-cycle management, with (but not at the expense of) workflow, tracking, and reporting tools.“
November 15th, 2006
I was with the VP of Operations of a Global Fortune 500 company which had just deployed Opsware on thousands of end-points. Opsware is a provisioning system which can be used to push patches, updates etc. Like most other provisioning systems, such as BladeLogic, Radia (HP), it also keeps track of “known” good state and reports when deviations happen from it.
The company liked opsware as a deployment engine. It had simplified thier life considerably. But it had complicated thier life considerably when it came to reconciling change with the change tickets.
The VP mentioned that there was no easy way to integrate the two systems. Also the volume of change which was bieng reported by Opsware was so large that it made their earlier procedures which were manual just infeasible.
Opsware had taken them almost a year to rollout and they wanted to quick fix to this problem. Has anyone else seen this problem? Have any suggested solutions?
November 15th, 2006
One of the most puzzling aspects of the set of companies we found in Part II: IBM Rational, Sunview Software, Seapine, BMC, Pega, Solidcore, Opsware, MetricsStream, is several companies with development tools. Infact if you dig a bit deeper other companies who sold tools in the developer market — most notably Mercury Interactive (now HP) also seem to offer change management.
One explanation which comes to mind seems to be, that for a long time software developers have used source code management systems, which had versioning tools like CVS or SVN would naturally extend their value proposition to change management.
If you look at the vendors out there, it seems that there are two different directions people are coming after change management … one is starting at the Application layer and the other is starting at the system layer. The following picture from Mercury Interactiv
e’s web site provides a similar layering.
If you approach this from the application side, then the change cycle starts with a developer making some changes in response to a request by the busines unit. These changes are tested in staging and then put together in a release which is put into production. All of which fits neatly into ITIL Change Management/Release Management world. Mercury fits this point of view very well.
The next set of tools which view change management from the perspective of the application are the “application dependency mapping” folks. I guess they originated from the problem that companies face when putting things in production … changes interact with each other. Especially if you are in the Java world, there are a lot of files, classes, settings etc, which depend on each other. So knowing the dependency between one application and another and also having a preview as to what are all the things one change can effect seems valuable. Most of the major players in this space have been gobbled up by larger companies: Relicore (Symantec), Collation (IBM), nLayers (EMC), Cendura (CA), Appilog (Mercury).
It seems like most of the above companies discover the applications by doing a scan and then figure out the dependencies between them also. The scanning gives people the ability to determine what has changed.
I guess the application view has its benefits in the sense that it sits closer to the business user and the business use. The other companies which came up on google for change management start more at the systems layer … next next next.
November 14th, 2006
Some FIXED assets
- Swivel chairs with wheels
- Laptops
- Elevators
- SAP Implementors
- ITIL Consultants
November 10th, 2006
If you are a large IT organization, most likely there is a central IT organization and some IT in each business unit. Usually the relationship between the two organizations is somewhat strained. Recently I was on a panel with a CIO from the DC area and he mentioned that one of the best things he had done was to have one of his reports be part of each business unit (have dotted line to the BU head of IT). This increased information flow considerably.
When I think about this problem it is similar to the GM and the Auto workers Union (UAW) settlement. GM was asking for some really tough concessions from the UAW, so they brought a UAW representative inside GM and gave him access to all the financial infromation. He was not allowed to communicate this information, but he could see how serious and real the situation was. This helped GM and UAW engage in meaningful dialog.
Another CIO I met mentioned that if Central IT and the Business Units could see what each other was doing that would go a long way to build trust. If there was some way to have autonomy but visibility that would make the organization really efficient.
November 10th, 2006
What is she doing in an change management class?
Don’t know maybe the movie business doesn’t pay that well anymore
Apparently her marriage consellor sent her here
Hmm… and why would that be
Tom and she need to reconcile their differences
November 9th, 2006
I was with a CIO for a large public utility, where several of the IT systems control real world infrastructure. He made a very interesting point — universally what people in IT are doing to reduce cost is to automate all the manual tasks. While this seems the correct way of doing things, one of the big dangers of this is cascading changes is causing cascading failures.
Pre-automation there were several manual steps which inherently created barriers for the failures to cascade and also in some sense partitioned the infrastructure. Several examples came out
- Active Directory/DNS: since the directory auto-replicates, if you make a mistake it propogates relatively quickly
- Production and Disaster Recovery: auto-sync between these two can bring down both
- Network: this is the classic because routing changes propogate quickly
- Any clustering solution
We had an interesting discussion about what to do in this case. Clearly you want automation, introducing a human in the loop is not an option in many cases. But how do you solve this problem?
One of our colleagues at a large minufacturing facility had solved this problem in an interesting way. He took one node in a cluster or active directory and used to keep it disconnected!!! and the manually connect it once in a while.
That was very interesting because he had figured out a way to technically enforce a change window which opened by him connecting and dis-connecting to the network.
November 9th, 2006
Previous Posts
