Oooh Shiny

This is the first part of a set of blog posts where I’ll be introducing a pet project of mine. Combining IT operations and service management with Web 2.0/Enterprise 2.0 concepts.

In the ITIL books and on some vendor slides the Service Knowledge Management System (SKMS) sounds like the dream of every IT manager. A system giving a complete and up to date overview and background information of an IT service.

The mistake the ITIL authors and most vendors make in my opinion is treating knowledge management as a process. This is a very traditional approach, very reminiscent of some tools of the previous generation of knowledge management systems.
The problem of this approach is: knowledge management as a process driven discipline barely works in heavily regulated industries (healthcare, defense, aerospace come to mind), because in these industries it is a set requirement, and people don’t get paid if it’s not done!
Lufthansa is not going to accept the delivery of their shiny new Airbus 380 without the proper and mindblowingly detailed documentation of every mundane detail of the plane.
Now compare this to the level of effort the typical IT organization puts into documenting their IT services. In most cases this is a loose combination of a set of word documents, visio diagrams and excel sheets. Some organizations will claim to have their systems documented in a CMDB, maybe even in one of the CMDB products from the HPs or IBMs of this world.
My point is nobody will get fired if the documentation of a service is not up to date and everybody will get their paycheck even though crucial details of the IT services mode of operation are stored in their heads only.
In an environment like this it is a unrealistic assumption that you can force the documentation of this type of information into a formal process. People are always just going to do the bare minimum, because they don’t want to do more and they don’t have to do more. Appealing to common sense (“if you document this, it will make your life easier”) is a moot undertaking here.
The only realistic way of approaching this is to make sharing of information
- easy to do
- convenient (and not only from a long term perspective)
- maybe even *gasp* rewarding and fun

Now, incidentally enough haven’t we just seen this happen on the internet over the last years? Ten or even 5 years ago sharing any type of content on the internet was the domain of a select few. Corporate websites, few personal homepages and dispersed discussion forums. Communication happened in e-mail.

Today we see a multitude of easily accessible ways for sharing content on the public internet: blogs, twitter, Facebook, LinkedIn, etc. Of course there is a certain amount of hype associated with this movement, but the shift from just consuming information to a two way communication environment has undeniably happened.

Now, if I take a look the state of IT operations and especially the tool support that most of the established (but sadly also the up and coming) players in this market offer, it seems to me that they are still stuck in the internet of yore.

In most cases I am looking at a set of different tools for the different disciplines (incident management, operations, monitoring, etc). Some vendors offer portal solutions that tied their product suite together, such as the Tivoli Enterprise Portal. The very consistent thing in all of these offerings (at least the ones that I have seen) is that they are basically just usable for consuming information.

I admit I am a products person. So please forgive me if I explain these concepts with a product example.
I started experimenting with enriching traditional IT operations tools with social media elements in the spring of 2008. My beef with the CMDB product I was working with at that time was that I was
- pretty difficult to use for the regular user
- not easy to share anecdotal or “soft” data in the product

I’ve said it before, I’ll say it again: IT is a people discipline. A lot of it is based on personal experience, anecdotal information, “tribal” data. This is especially true in IT operations.

The result of this work was a prototype called CMDWiki. A frontend to a CMDB based on the semantic mediawiki software. The main benefits I saw here, were that it combined the process based elements of creating and maintaining a CMDB (as it did not allow people to change CI data that was managed by any of the ITIL processes) with the ease of use of a wiki for finding information and sharing of “soft” information related to a CI.

This year I set out to build a more refined version of this concept.

For a lack of a better term, I am calling this a collaborative SKMS for now. I am well aware that this is a big name. Suggestions for something more humble are welcome.

So what is the use case for the Collaborative SKMS?
As in many other cases when it comes to managing IT operations, the cobblers children have no shoes. While it provides sophisticated services to other departments like sales and HR that allow for highly integrated, automated processes, IT itself is in most cases managed via email and Word documents. Of course, most organizations have implemented one or more ITIL processes (or similar processes from competing frameworks). However, as stated before information technology is about more than processes. When it comes to collaborating around aspects of an IT infrastructure, most organizations are stuck in the 20th century and use email, fileshares, etc. Progressive organizations might have implemented wikis or Notes databases for collaboration.
Still, all the negative aspects of this, information buried in emails, difficulties in finding information in a multitude of wikis, Sharepoint sites and fileshares, no communication across departs, geographies and hierarchies prevail in most IT organizations.

The collaborative SKMS is an example of bringing Enterprise 2.0 functionalities and concepts to the IT organization and merging them with existing solutions already in place in many organizations, such as helpdesk, operations monitoring, change management, even CMDBs.
For this prototype I have selected the HP BTO portfolio. This is not meant to be a specific endorsement, its just the portfolio I am most familiar with.

So let’s take a look at the involved elements
HP ServiceManager: Helpdesk, Incident Management, Problem Management, Change Management
HP Release Control: Change Management/Change Impact
HP Business Availability Center: Monitoring, Service Level Reporting
HP Universal CMDB: CMDB

Again, feel free to replace these with other vendors products, they are only examples in this case.

The system has multiple goals:
- Bring together information from multiple solutions used in IT
- Organize the IT environment into a structure that is consistent and relevant for collaboration
- Allow for communication and collaboration in a consolidated environment

Especially the last point is important to mention. Of course communication and collaboration are happening in IT operations today. The problem in my opinion is how they are happening. In every environment I have visited this happens via email in 80% of all cases. The rest usually sits in Office documents on fileservers.

As an entry point into the system the user will be presented with two choices:

A centrally defined homepage


Social SKMS Homepage

or their personal homepage, which they can configure to show the information that is relevant to them. In this case we see the default one.

Personalized Dashboard

So how is the system structured?
There are two distinct structural elements in the system: Spaces and Social Groups.

Spaces represent a centrally defined hierarchy. In the case of the Collaborative SKMS a space would represent things like services (and underlying services if there are dependencies), departments, etc. Spaces are used for information that is relatively static in it’s hierarchy.

Social Groups are used for all information that is not bound to a hierarchy. I.e. whereas there might be spaces representing SAP system P01 and SAP system P33 (IT services in this case), there will be a social group called “SAP Basis” where the people running these systems will come together to communicate and collaborate around all things SAP, no matter where they reside in the organizational hierarchy or in which geographic location they work.

Especially the social groups are addressing an issue most larger IT organizations have today: They are not only functional silos (the DBAs, the networking guys, the Windows admins), there are also geographic silos. I’ve seen way too many customers where the networking team in Frankfurt did not even know which tools the team in Munich was using.
Social groups allow these teams to come together around their common area of interest.

Let’s take a look at an example of a space representing an IT service. In this case the service is an online banking application that is run by the IT department.



Entry point into a service sapce

The entry point into this service space includes a real time display of the current status of the service (in this case coming from Business Availability Center). Also displayed are the statuses of projects related to this service, and an activity stream of recent additions and changes to the service space. In addition the available actions and the most active people in relation to this service (remember this is about people) are shown.
Note the different tabs for the content types available for this service. This includes configuration items, changes and incidents in this case (federated in from the appropriate source systems), but also more generic elements such as discussions (happening directly in the system or in email), documentation and blog posts. We’ll look at these in some more detail. The all content tab consolidates all activities into a single activity stream, which is available via a users dashboard, RSS feeds, email notification, even via their iPhones.

Let’s take a step back: A view like this consolidates all activity around a service in a consolidated, archived and searchable view. In addition to this, the content is also actionable, as we will see in a minute.
While this might sound trivial, something like this is actually incredibly difficult to do in most enterprise systems management suites. In most product suites I am familiar with, this would really be impossible, without a major development undertaking.

This is the end of the first part of the introduction to Collaborative ITSM. The second and third installments will follow shortly. I’m very interested in feedback, so feel free to share your thoughts.