Implementing a CMDB is Like Blogging Alone: Why Products & Process won’t be enough to reconnect with the business
Starting your ITIL journey with a very complex, usually expensive, lengthy and often invasive technology-based initiative may only serve to increase the divide between IT silos and, more importantly, IT and the business. In a similar vein, too much focus on process may simply lead to more policy and procedure manuals that sit on a shelf.The problem with Change, Configuration and CMDB implementations is they do not really enable a real-time connection between IT staff, and between IT and the business, which tends to perpetuate vicious cycles of tribal warfare.
“When people lack connection to others, they are unable to test the veracity of their own views, whether in the give or take of casual conversation or in more formal deliberation. Without such an opportunity, people are more likely to be swayed by their worse impulses….”
- Robert Putnam (2000) Bowling Alone: The collapse and revival of American community, New York: Simon and Schuster: 288-290
In the book Bowling Alone, by Robert Putnam, “Putnam warns that our stock of social capital - the very fabric of our connections with each other, has plummeted, impoverishing our lives and communities … we sign fewer petitions, belong to fewer organizations that meet, know our neighbors less, meet with friends less frequently, and even socialize with our families less often. We're even bowling alone.”
The focus on Process (BPM, ITIL, CobiT, et al) and Products (read CMDB, SOA, et al) by IT leads me to believe we’re talking more than ever – but sometimes communicating even less than ever before.
I like the concept of blogging so much I’ve found myself actually Blogging Alone! (Personally, I’d rather bowl alone than blog alone, so please visit my blog!) The hype around the CMDB can have a similar effect on your ITIL implementation.
It’s the People
It’s the social networks that really make things happen in most companies, not those dusty old policies and procedures. It is the network of people-to-people commitments that are often what make things go (or not go).
So, when looking to embark on a ‘quality journey’, remember at the end of the day it’s the people --- and that intricate social network of commitments – that are often the ‘current state process’ and that people may fiercly protect this tribal knowledge.
Process, Products and Paradigm Shifts
In a recent webinar more people were familiar with the CMDB than with ITIL (see EMA’s webinar: CMDB Adoption in the Real World - Just How Real Is It?), which was interesting considering that the CMDB is very much an ITIL term. Just shows you what market opportunity will do to reality.
Getting your IT staff to achieve the paradigm shift to a services orientation is going to require people skills more than anything else, and your selection of tools --- particularly early in the journey --- can significanlty impact how people react to the implementation of IT service management.
Services, Stakeholders and Real-Time Analytics
Stakeholders & Services targeting is a fundamental best practice that is often ignored or skipped as customers try and “accelerate” implementation. This often means the implementation of ITIL considers the business from afar, rather than part of a cross-functional team.
While this may provide an easier path to get the ball rolling, at some point the business had better become part of the team. Process and commitment based stakeholder analysis leveraging both business and IT tracks can ensure that all stakeholders are included and services are understood from the customer’s perspective.
Starting with the end in mind assumes IT truly understands the business process, when sometimes that process is not that well understood even by the business! It also drives participatory decision techniques, which are successful more than 80% of the time.
In addition, Product-led ITIL implementations are likely to focus on the technology, particularly when the supplier is also driving process improvement activities. (The ITIL literature has spoken at great length on this subject.)
When considering process improvements and investments in automation, consider the following:
-Investments should target areas for highest return
-Should enhance ITSM process communication
-Should be consistent with business and IT objectives
-Should be driven by stakeholder input
Realizing the Paradigm Shift
I understand and agree that an ITIL journey needs to include eventual design and implementation of things like Change and Configuration Management, the CMDB, and other critical process and technology related efforts.
However, making these investments should be driven by participatory decision techniques and should enable every tribe to see the same information at the same time (a fundamental CMDB concept). The evolution to an ITIL-based CMDB is going to take time and significant effort, in most cases at least a year.
But achieving a paradigm shift involves people. Process and Product-centric implementation efforts can lead to edict-based decisions (Change freezes, etc.) which are the least successful of all decision techniques.
The case for service-oriented monitoring, particularly where real-time analytics can be incorporated into the solution, can provide every stakeholder with an end-to-end view of the IT business service infrastructure that is tailored to their perspective; without the time, cost and risk of implementing a CMDB. (See the White Paper, Choosing a monitoring system for your IT infrastructure?)
It also focuses on where most companies are spending the most money; isolation and diagnosis of complex, n-tier infrastrcuture problems.
These kinds of solutions can provide an intelligent, virtual operations bridge which is absolutely consistent with best practice. More importantly, it provides IT and business management with a solution that can help with the the hardest part of change --- people.
The ROI on People
Quickly providing a real-time source of truth, via a ‘top-to-bottom’ and ‘end-to-end’ IT business service infrastructure monitor with root-cause analytics, can help people get focused on the real problem and learn to trust each other. (When driven by the business, it can also provide political cover for IT tribes since it becomes a business-driven mandate.)
The argument of those concerned with social capital is that when harnessed it generates economic returns. More particularly, the benefits claimed include:
Better knowledge sharing, due to established trust relationships, common frames of reference, and shared goals.
Lower transaction costs, due to a high level of trust and a cooperative spirit (both within the organization and between the organization and its customers and partners).
Low turnover rates, reducing severance costs and hiring and training expenses, avoiding discontinuities associated with frequent personnel changes, and maintaining valuable organizational knowledge.
Greater coherence of action due to organizational stability and shared understanding. (Cohen and Prusak 2001: 10) (from Social Captial in Organizations)
Providing the ability to monitor monitor what is happening at every layer of every component of an end-to-end business service, and automatically identifing which layer of which component is the source of a problem establishes a basis of real-time truth. This is the key to establishing a real and lasting paradigm shift.
Your road to ITIL best practice does not have to be a savage journey. Consider an implementation approach based on stakeholders, services and intelligent service monitoring. By applying all the best practices -- Process, Products and People – you can achieve both ROI and a quality culture along the way.
2 Comments:
I happen to think that the original thought process behind the implementation of a CMDB was done without specific domain knowledge of how difficult this may be.
For example, the ITIL doco state that every Config element and its relationships be inserted into the CMDB. And that Management applications use this data to reference the CMDB.
I think this may be a bit backwards as the true data is out in the Enterprise and not in some monolithic database. And rightfully so. Things change in your enterprise. Dynamically. After all, this stuff is supposed to heal itself. Like routing protocols. Or a netBEUI file mapping will attempt to reaccomplish connection.
Some of Vendors are using the term Federated to say that only a portion of data goes into the Vendor's CMDB and other data such as user data, groups, applications, etc. may be stored elsewhere in a propritetary database! (BMC - How open is that!)
When you throw in the modelling funtionality of the TMN specs, you quickly see that the CMDB will become a HUGE behemoth!
For a database of this magnitude, you have data providers and data consumers. Have the designers of the CMDB specifications (CIM) REALLY thought about the overall data model of this?
I have my doubts. You see, there are some data elements that are very static in nature. There are others that are not static at all. Such as connections between a Web Server and a backend database. You can discern a basic path between the two but the number of connections used vs. possible is a very dynamic metric.
What about a Call Center situation. You have 10 people on the floor and one checks out of his call application to go to the restroom. Do you track your resources ad infinitum?
Step back and take a very basic look at a Network. There are nodes, routers, switches, and even appliances like printers and overhead projectors. Then consider applications. Like MS Office. Like NetMeeting. What about stuff like Lawson or AG Edwards financials?
In a network where SNMP is deployed... If you look at the MIB definitions themselves, they portray a Schema for management information. Each Agent subscribes to provide data only to specific trees or Tables in the Schema. And each agent provides these data elements, row by row. Only the Client Server protocol used to access the database is SNMP. Not SQLNet or SQLLite, or evne ODBC. If you think about it, you already have a portion of your CMDB loaded... And in place for forever it seems. (I started doing SNMP when it was a Draft!)
When you start looking for each and every relationship, explicit and implicit, CMDB looks like a Very tall mountain. And if you only implement it half way, do you get half the promised ROI?
And what about that measly little SOA Web Service you had Joe the Java Coder do for you in between classes at the local community college. While that code is EASY to implement, it now depends on so many different things that finding a problem when something breaks, is now a major headache. Is it the network? What about the Web Server? Or the UDDI server? Something wrong with the WSDL? What about Tomcat? If you're not looking at this sort of thing end to end, holistically, you're gonna miss not only the boat but all of these other technologies are going to bowl right over you like a Tsunami!
You may be preaching to the choir as I suspect we're in agreement in most areas.
See http://www.myservicemonitor.com/TheRoadToNirvana.html
I do not believe that the ITIL folks wanted to architect the CMDB, but rather identify a 'desired state' based on what they saw being practiced in the field in varying degrees.
A BIG issue for many folks is identifying CI granularity, attributes and relationships for this reason; and ITIL implementations can get stuck in the mud because of it. I think establishing an organization-wide CMDB is part of the journey, not a single step.
Technically, I think this is a debate worth having and wish I were able to comment more...thanks for the post though...beats blogging alone!
Post a Comment
<< Home