Many IT organizations are run through a culture of fear.  The fear is of course costs.   Stalin might as well be running them for how effective they are. 

This article is of course targeted at business leadership.   It's very tempting to appoint Stalin as  your CIO.  Stalin gets things done.  Stalin always says yes, he's the consummate politician.   However, for many businesses, IT is a core part of how customers interact with the business and can even be a differentiator. Do you really want Stalin there?  Do you really want to sic Stalin on your customers?

The analogy is rather far fetched, but the outcome, maybe not so.  Culture is the most important aspect of any IT organization.  Much more important than process.   Much more important than tools.   Once you create a culture of fear, its rather hard to remove it.

As an example.   A company I worked with closely had a cost problem.  Instead of focusing on improving service at the same time as removing waste, the CEO appointed Stalin.  Stalin reduced costs.   Stalin doesn't really care much about the end result.  He cares only for power.   Leaders who had new ideas of how to improve service were marginalized and purged.  The culture change to one of thinking of the customer to one of protecting one's backside.  Senior IT leaders in this company now only cared not to come to Stalin's notice - the customer was spoken of, but at the end of the day paled into insignificance compared to Stalins' wrath, and the irrelevant metrics that Stalin measured his staff by.

In this company, Stalin is now gone.   He's been gone for over year.  But he's still running IT.  How is this possible?  Stalin created culture of fear.   His senior leaders manage through a culture of fear and protecting their own area.   The new leader might as well go home because the culture has become so embedded that without a wholesale staff change of all leadership, the organization will never move from cost focused to service focus, no matter how much lip service they pay it.

The point of this article is to beware of appointing Stalin to run IT.  You may think he can add value, even for a short time.  Stalin is very tempting.  But Stalin never pays off in the long run.  Just look at the Soviet Union.

Culture trumps process and tools every day of the week.  The difference between a rabble and a well run department is often Culture.  Well run organizations understand this and build an appropriate culture over a long period of time.

BMC, through their Remedy solution have long been the 800 pound gorilla in the service desk market.  Their acquisition of the remedy technology from Peregrine is arguably one of the most successful acquisitions in IT service management.  It certainly transformed BMC and provided the platform for their successful BSM strategy.

However, in the last few years the success was starting to loose its luster from more innovative competitors who could offer service desk solutions at a fraction of the cost and with more flexibility thanks to a SaaS delivery model.    I know of a number of companies who were able to move from Remedy to such solution for a fraction of a Remedy upgrade.  We also saw traditionally exclusive BMC partners sign up with additional solutions to fill this gap.

Todays announcement at least shows the market that BMC is serious about filling this hole and moving into this space.  The choice of the SFDC platform also seems like a good choice, not only allowing BMC to get their solution to market quickly, but also to exploit existing SFDC customers who want to move to an enterprise service desk but also integrate it with their sales automation solution.  

It will be interesting to see if BMC have left this too late or not.   Certainly if they had made this announcement two years ago they could have capitalized on the huge momentum behind Remedy.  However, vendors such as Service Now, Netsuite and the like have started to gain market share - will BMC be able to stop the erosion and win back some of those customers?   Probably its really down to how willing BMC are to cannibalize the existing Remedy install base and let them move to the new solution in a cost effective manner, and provide seamless migration from existing Remedy solutions and the new SaaS based offering.  

This announcement certainly makes the Service Desk market more interesting again.

With the recent acquisition of Tideway by BMC software, the last of the independent application dependency mapping tools is off the market.   nLayers was bought by EMC, Collation by IBM etc etc.   But do these technologies really provide value, or were they more of a 1.0 technology that everyone (especially the analyst community) expected these vendors to have?

The concept of dependency mapping is extremely compelling.   Wouldn't it be great if you could have an accurate map of how technology supports a business service, updated in real time?   Wouldn't that be an amazing resource to do change management, business impact management, fix production problems and so on.   Wouldn't it also be great if these vendors could make their CMDB work by magic - to really have that silver bullet that they have been marketing?

However, the reality is vastly different.   In real live environments - with really complex, customized applications that span many tiers, have many levels of technology, are highly virtualized and span over multiple data centers, these tools struggle to provide an useful map of how this mass of infrastructure actually supports an application.    Sure, they are great at finding all the servers, but a simple nmap scan can do that.   They can even find some basic components, like databases and web servers, but again, nothing rocket science about that either.   Really understanding the application is beyond their reach.

A couple of examples.

I was associated with a BSM project for a large manufacturing company.   This company had invested millions in a CMDB project and was trying to populate this CMDB for impact management and change management.   Given the size of company, the chaotic environment, that spanned over multiple service providers, a manual approach to the CMDB was necessary.   The discovery tool did find a bunch of 'stuff' - a very bottom up approach where a dazzling number of hosts were found.   This would have been great if asset inventory was their goal.   They also found some base components.     But the applications were custom, so they were not discovered.   Instead, the tool generally identified that certain servers talked to each other.    Even making the assumption that the servers that were constantly communicating with each other must be part of an 'application', it was still very difficult to work out what the application actually was (especially in a highly leveraged environment), and how these components contributed to the application.    The result was worse than nothing at all, because the data was very incomplete, and most of what was seen was shared services that were hooked into all applications.   This company started again on the CMDB, and we moved forward with BSM without it and completed our project.

In another project, an online company was trying to identify their core applications and what made them up.   Their applications were all custom developed.   This company used a leading discovery tool, but found that creating, maintaining and updating the definitions that were used to discovery these applications was so much work it was easier (and much cheaper) to hire a few interns during summer holidays to manually go round entering data into their system.  

Finally, today, I met with a large organization that derived a huge part of the their revenue from a set of key applications.   Understanding the dependencies was seen as an important risk mitigation strategy.   Another leading discovery tool was selected (a different one from example 1, or example 2).   Months later, the project was abandoned after a series of half completed infrastructure maps were created.

I could continue with these examples, but it seems clear from real world examples, that unless you have very simple standard applications like MS exchange, at best these tools take a huge amount of work to get going?   Is it worth it?   Obviously some think that they are.

Personally, I would rather wait until the second generation of these tools becomes available that can deliver real value - and focuses on identifying the business applications, not blindly discovering basic infrastructure.  

Does a claim of having invented something really provide you with that much credibility in the market, especially when its patently obvious that the invention was done elsewhere?

Having looked at other industries, its rather common for the 'inventor' to be replaced by newer companies who add efficiencies to the idea and do it rather a lot better.   One could argue that the first airline to pioneer travel to the masses was Pan American, yet they closed their doors in the early 90's, out maneuvered and surpassed by more innovative competitors.   Or take the car, 'invented' by Mercedes Benz, but today are a niche player in todays car industry (albeit a well regarded one) - but few buy a Mercedes Benz because they made the first car.  What is probably more interesting is how Ford revolutionized the car industry with the production line.  

looking back to IT Service Management, there have been many claims over the years to have 'invented' BSM.   BMC software is the most guilty here, which is rather humorous since they were a comparatively late player to that market.    Managed Objects (before the Novell acquisition) were another, yet again, IDC had written about the concept long before MO started doing so.   Is reducing your credibility with these claims worth the added value?  I guess BMC and MO thought that it was.   I wonder how many actually bought because of this.  

What might have been more interesting would have been if BMC made the claim that they had revolutionized the BSM market space.   In reality they probably did.   They took an established market segment (although small at the time) and twisted it to put the Configuration Management Database at the center, and closely align it with the service desk; conveniently the two strengths of BMC.    This focus on CMDB has been to the detriment of the BSM concept, but certainly vital for BMC's sales success over the last few years.   Certainly now the 'what is BSM' discussion is confusing and fraught with religious style debates about the merits of the CMDB, discovery and so on.  

But I wonder if they would have won more Kudos if they had come out and correctly said that they took the CMDB to BSM and how BSM was incomplete without?  (even if in reality making the CMDB the centerpiece of BSM is akin to using a sledgehammer to hang a picture)

Of course none of this really matters and at the end of the day its more of a philosophical debate, but interesting nevertheless.