What are the challenges?
• How can I get better visibility of my IT environment?
• How do I reduce the number of major outages that keep happening?
• Do I need to reinvent the wheel just for my organisation?
So, as mentioned in the introduction to this guide, I reckon it’s a fairly safe bet that if you are reading this book then you feel that you have some issues that you need to sort out with regards to your IT infrastructure and the management of that environment, and possibly that you think those problems are linked to a lack of information, structure or control.
Well, if you feel that just walking into the office on a Monday morning means that you will be greeted by chaos and failure day after day, week after week, then there is a good chance that you need some structure in how your configurations are organised and some order in the working practices and processes that you follow every day.
At the outset of the project, it is important to understand what you want to get out: your objectives. These should relate to your view of what is wrong and needs to be achieved. Set those objectives in concrete, put them to one side, and return to them regularly throughout your project life cycle. Do not be pressured into changing your priorities, the order of your objectives or, in fact, your overall goals (unless they threaten to get you fired, in which case discretion is definitely the better part of valour!).
From my experience, the value of process and procedure is never to be underestimated and in the Information Technology Infrastructure Library (ITIL®) there can be found an excellent template for creating the structures and foundations upon which you can base your infrastructure and environment. Within the ITIL® framework there are, without doubt, a number of processes that will be key to your success. In ITILv2®, the three main support processes – Incident Management, Problem Management and Change Management – were introduced, and even though the ITIL® framework has undergone rewrites since that time, these key processes are still the ones that the IT support departments in most organisations live and die by, regardless of whether or not they operate as clearly defined or more integrated combined managed processes.
So here is a quick five-minute, common sense, practical introduction to those key processes and their purpose:
Incident Management is about recovering the service that the customer was using and relying upon to carry out their everyday work. This service will, for whatever reason, no longer be available, or is no longer responding in the way that the customer expects. The process of Incident Management is all about recording the failure and defining the steps to be taken to restore the service back to an operational state, so that the end-user can continue on with their work. It involves capturing how the end-user presented the issue to the support desk, the time it took and the resources that were used to restore the service, as well as what action was finally taken to restore the service.
Overall, Incident Management is a reactive process – reactive, as it is instigated when the end-user has an issue – and remains open until the service has been restored.
Problem Management is about investigating what causes the failures that we record in Incident Management, or, in fact, in any other area within our environment. It involves bringing together resources to investigate the possible root causes of the failures and pulling together enough information to propose potentially permanent resolutions. In this way, future major failures can be averted, or the level of minor failures within the organisation can be reduced.
In summary, Problem Management is a much more proactive and contemplative process, that takes time to consider all the facts and thinks through possible solutions before proposing the best resolution to be implemented via the Change Management process.
Change Management is about implementing changes into your environment in a controlled manner. All stages of the implementation, the testing and, potentially, the recovery, are considered, documented and followed, so as to achieve a predicted outcome. The process has a number of control points – that is, go/no go points. These points are considered by the change manager or appointed change related officials, all with the aim of providing the best, most comprehensive and complete view of any possible changes needing to be made to the infrastructure.
In short, Change Management is the gatekeeper process that ensures that a balanced and controlled view is taken on any infrastructure changes and, if a failure should occur, ensures that the service it has affected can be restored in a controlled manner.
But, whilst the world of IT was generally concerning itself with the Big Three support processes, there was one process that was frequently overlooked, frequently glossed over and frequently considered to be too much work without bringing quick, obvious results. This process was Configuration Management. This was the process that controlled how and when data was stored within the Configuration Management Database (CMDB). No one really wanted to take the time to get the data within the CMDB in order, and yet it was this data that was actually key to the success of the Big Three processes.
Perhaps it was because Configuration Management was just not as glamorous as the other, more customer-facing processes?
Perhaps it was that we struggled to understand a process that, to all intents and purposes, was not a single process, but a group of processes?
Perhaps it was that we were more comfortable being forced to start a process than being relied on to run a regular audit-type workflow?
Perhaps it was because what we actually needed to kick-start Configuration Management was good old fashioned Asset Management, but we were too proud to admit it or roll up our sleeves and make a start.
Perhaps it was because there were very few decent applications on the market to help us, and those that were there were either over-priced or under-featured?
At the end of the day, when all is said and done, and when the curtain falls (and any other clichés you want to use), there is actually no getting away from the fact that Configuration Management underpins and connects the main support processes, as well as the Service Delivery processes and, in truth, Asset Management is actually part of the fundamental core of it. Without Asset Management, starting any CMDB project and trying to deliver an effective IT service is much like trying to put a roof on a new house without first building the walls. It’s just not structural common sense; it’s going to take a lot of shoring up and, ultimately, you are likely to be left standing looking at a pile of useless rubble.
Without Configuration Management underpinned by Asset Management disciplines, you will find that your logged incidents are not connected by common data, such as the location, software, manufacturer and OS platform, and you will be unable to understand volumes and linked trends. You will treat every new incident as a fresh instance, unlinked and unrelated to anything else that has happened, save perhaps the user that logs the incident.
Without linked trends and defined configuration relationships in the CMDB, trying to investigate problems to establish root causes will be like trying to find an ice cube in the middle of the Sahara Desert.
Without having an understanding of configuration, knowing which devices support a particular service, being able to understand the ultimate cause and effect of downtime on the end-user community and being able to identify potential single points of failure – all of which are defined within a CMDB – you will be unable to make an informed decision about major changes in your organisation, and will probably move from one major disastrous change implementation to the next.
• Better visibility comes with creating order from chaos, which takes some organising!
• There’s no need to reinvent the wheel – ITIL® may hold some or all of your solutions.
• A beautiful house is only built by completing key tasks in the correct order.