Many modern soothsayers predicted that ITIL will cease to exist when DevOps pace picks up. Well, DevOps has picked up rapidly in the last couple of years, and there is no talk of ITIL giving way to something else in the dawn of DevOps. In fact, I consult with clients to keep ITIL speeding along with ITIL. So what ITIL needs is not a replacement but an adapter for DevOps.
Reinventing ITIL in the Age of DevOps is my latest publication that pushes the boundaries of ITIL to cater to DevOps projects. It is a book that gets real, and on the ground to provide practical process modifications, team structural changes and all the bells and whistles that have to be finetuned for ITIL in a DevOps project.
The book is quite comprehensive that it looks at each of the twenty-six processes and the five functions for adaptation into a DevOps project. Plus, the major processes such as incident and change management processes among others are dealt in detail with the workflows, team structure recommendations and alterations to the ways of working to create synergy between ITIL and DevOps.
The book is scheduled to be released late this year or early next year. It is in the production stages, and a near exact date will be known in a month’s time.
I started writing this book earlier this year, and to date, this has been the fastest I have penned a book. My earlier books took me close to a year, and this one in comparison took me about 5-6 months. And Reinventing ITIL in the Age of DevOps is touted to be the biggest book that I have written.
Configuration items and assets carry different priorities in terms of their worth for the organization. Let’s consider the example of a server as a configuration item and a laptop as an asset. If the server was to go down, the business impact caused as a result is bearing. It could bring down services that will possibly affect a number of users. Likewise the business impact of a laptop going down will impact the user of the laptop.
Comparing the two scenarios, it can be concluded that the manner in which configuration items and assets are governed and controlled must be dependent on their business impact/value.
I will highlight a couple of areas that differentiate configuration items from assets.
The advisory body within the process will provide the approval based on the change justifications, and the precautions that you have undertaken. The approval also comes with the rider that it needs to be performed at a particular date and time.
Unless the approval is provided, there is no compliant way to make changes to configuration items. When I say changes, I refer to various types of changes that you might bring in – such as configuration changes, additions and deletions of Cis.
This strict control is in place because any unsupervised changes could lead to service outage, which in turn could result in the business impact – financial, legal and perception.
For assets, there is no such scrutiny because there is hardly any impact if things were to go south. If a change is done in the form of an application installation, and if the installation was to fail, the impact is hardly felt – except for the user using the laptop.
Normally changes to laptops are done on the back of service request or incident tickets. In most organizations, users themselves have the admin or super-user access, allowing them to do whatever they want to, without the backing of approvals or ticket logs.
Finger on the Pulse
Configuration items are actively monitored using tools such as Splunk and Appdynamics. The monitoring activity ensures that the CI works as expected across the clock. Any anomalies get reported to appropriate teams to take action.
Most types of configuration items are monitored for availability, capacity and security. Just as in the case with changes, any issues pertaining to availability, capacity and security can potentially bring down the services. So, it is imperative that the critical elements of the service (read CI) is kept under constant supervision.
It is needless to say that assets are not monitored as the worst possible scenario with it breaking down is the loss of work related activities for the associated user.
I hope in this two-article series I have answered the questions that you might have around configuration items and assets. The Service Asset and Configuration Management process is wide, deep and varied. With my extensive experience around CMDB and asset management implementation, I hope to churn out more articles around the process, and the nuances that surround it.
I often find myself talking to customers, peers, and suppliers who use the terms assets and configuration items interchangeably. They say that ignorance is bliss, but when it comes to management terminologies, it is better to understand the differences between terminologies than to look over it.
In this article, I am going to differentiate the two terms – assets and configuration items. Knowing the difference between the two will help you a long way if you are any way connected to the world of IT services.
What are Assets?
Assets are referred to as service assets in the ITIL V3 2011 publications. An asset contributes in delivering a service. It can be either a tangible or intangible. Examples include servers, laptops, and software. Assets are stored in an asset database (ADB).
What are Configuration Items?
A configuration item is an asset in principle. It can be tangible or intangible. It requires being managed actively throughout its lifecycle, as configuration items have a direct bearing on the delivery of an IT service. Configuration items are stored in a configuration management database (CMDB).
It is important to note that all configuration items are assets. And all assets are not configuration items.
What Exactly is the Difference between Assets and Configuration Items?
The definitions that I read out earlier are similar. The differences are subtle.
The lifecycle of an asset begins when it is procured or ordered and ends when it is disposed of. Let’s take the example of a server. It contributes towards delivering a service. Its lifecycle starts when it is procured and ends when it is disposed of. The server is an asset.
A configuration item’s lifecycle begins when it is put into the production, and the lifecycle ends with the decommissioning of it. Picking up the same server as an example. When it is put into production – agnostic of the environment it is placed in, it becomes a configuration item. It ceases to be a configuration item when it is decommissioned. The server in this example is a configuration item.
Comparing the two lifecycles of a server, we can deduce that within the superset of an asset, the configuration item exists. This proves that – all configuration items are assets.
When is an Asset not a Configuration Item
Not all assets are configuration items. There are certain assets that contribute to services – say in an indirect manner, and even if this asset was to be absent, then the service continues to exist.
Take the example of a desktop. This desktop is used by IT staff to do their respective activities. If this desktop was to go down, it has no bearing on the continuation of a service. It’s not like a server which directly impacts a service. A server going down might bring down the service.
The desktop therefore, does not require to be managed like a configuration item – with eagle eyes. Yet, it still remains an asset. So, we can say that all assets are not configuration items.
In the Concluding Part
In the follow-up post, I will explain what exactly I mean by managing a configuration item. To gain complete control and to remove ambiguity in the Service Asset and Configuration management, it is paramount to understand the subtle difference between an asset and a configuration item.
Scrum is yet another buzz word that is doing the rounds in the IT industry. It is a type of Agile project management framework, which provides the ammunition for projects to swerve in any direction it wants – which was previously missing with the waterfall project management methodology.
Scrum was originally devised for software development projects, but now it has been adapted for hardware projects (in IT of course) as well.
Compared to the PMI affiliated waterfall project management, the agile project management methodology of Scrum is far too simple. Sometimes, it feels so simple that we start feeling that it is missing on the inside. But, that is the beauty of it. In its simplicity is where you find the flexibility that allow projects to take any shape at any time.
Scrum is not the only Agile project management methodology that is out there. There are others such as Extreme Programming, Kanban, Feature Driven Development and Crystal. However Scrum has found favor amongst project management professionals because of its simplicity.
Scrum got its name from the Rugby formation called Scrum which was compared to high efficiency and high performance by cross-functional teams in a study published in HBR back in 1986. The name seemed apt to the founders of Scrum – Ken Schwaber and Jeff Sutherland, as the Scrum agile project management framework too dwelled on attaining high performance and higher flexibility from teams that were diverse.
Buzz words garner a lot of publicity in a short duration of time. SIAM is one of the chief words that is making a lot of noise around. In this article, I will explain SIAM with a different spin to it.
SIAM and ITIL
ITIL is well known today than what it was ten years back. Back then, it was a buzz word. ITIL is a full-fledged complete framework that provides the good practices towards the service lifecycle.
When ITIL was framed, the practice of customers dealing with multiple service providers was not fashionably in vogue. A single service provider, either internal or external used to take care of everything, so there was never a dire need to manage service provider.
As the competition between the service providers became intense, the customer started to smell cheese and a real benefit to be usurped with keeping multiple service providers on tenterhooks.
While the customer benefited from multiple service providers, the competition to outdo on another, and the value add they brought to the table, a new problem emerged. A management layer to keep tabs on the service providers, especially when they had to work together to achieve certain service related goals.
SIAM was born.
SIAM – Old Wine in New Bottle
Around ten years back, we started to see a situation where maybe a couple of service providers used to provide all the services that were needed for a customer. And one of the service providers, the one who had more business, had an additional role to act as a service role.
The service integrator’s role was simple. Act as a bond between the service providers to deliver services, and act like a customer when you need to.
This role of an integrator which started as a practice and as an experiment in some organizations started to get a definite shape, form and meaning.
The SIAM we hear of today is the service integrator of the yesteryears – old wine in a new bottle.
SIAM – Perspectives
I see SIAM through a lens that refracts the ITIL vision from a varying angle. It is an alter-ego of ITIL. I call it perspectives. SIAM is a perspective of ITIL.
When you design SIAM, you are implementing ITIL from the perspective of integration, collaboration, convergence, communication and synergy.
When multiple service providers are in play, there are new problems. The objective of SIAM is to pre-empt the problems and find a favorable solution.
Reiterating, there is new under the ITIL’s sun that is in SIAM, but the perspective it presents is valuable today, and the methodology is worth investing, for it is the new seed that is bound to grow rich dividends.
Before we get into the activity of logging an incident, I want to stress the need for an incident management policy document which sets the groundwork and framework for incident management process to operate.
Policy Around Logging an Incident
The policy around incident logging goes something like this – every single incident must be logged.
Let’s say that a user calls to get an answer to a query – such as where is the My Documents folder. This is not an incident in the basic sense because nothing is broken. Yet, an incident must be logged to keep track of all the inputs and triggers.
This example does not restrict it to users, but also extends to other sources such as event management tools as well. Even if the tool identifies defined anomaly, it must log an incident before anything else can be done to diagnose and troubleshoot.
The incident form must have provision to capture the source of the incident.
This is an important factor to identify the ownership of the incident in terms of clarifications and confirmations, and it is also analyzed to find relevant information that can potentially act as an input for Continual Service Improvement.
Even if I don’t state that timestamps must be captured, most modern tools do it by default.
Timestamping is an important record that can define a lot of things in service management such as SLA measurements, incident management effectiveness and the service uptimes.
Recommended Fields for an Incident
The sky is the limit. You can have anything you want in an incident form. However, you need to define the data source for each of the fields, and also ensure that you capture something that is absolutely needed. Don’t just have a field because you thought about it. Analyze the need, and determine where it can be used
The ITIL Service Operations publication recommends the following fields for an incident:
■■ Unique reference number
■■ Incident categorization (often broken down into between two and four sub-categories)
■■ Incident urgency
■■ Incident impact
■■ Incident prioritization
■■ Date/time recorded
■■ Name/ID of the person and/or group recording the incident
■■ Method of notification (telephone, automatic, email, in person etc.)
■■ Name/department/phone/location of user
■■ Call-back method (telephone, mail etc.)
■■ Description of symptoms
■■ Incident status (active, waiting, closed etc.)
■■ Related CI
■■ Support group/person to which the incident is allocated
■■ Related problem/known error
■■ Activities undertaken to resolve the incident and when these took place
■■ Resolution date and time
■■ Closure category
■■ Closure date and time
The next policy to be defined is around incident updates.
All incidents must be updated on a regular basis. Based on the priority of an incident, the policy defines the maximum permitted time between consecutive. Even if there is no progress, resolver groups must keep the ticket updated.
This comes in handy in tracking incidents by incident managers. If a team is not working on an incident, then there must be a good reason to it, right? Maybe the user is not around or maybe the team is waiting for a certain time when the incident normally recurs.
In these cases, the ticket must probably be placed On Hold. If the ticket is not updated, then the management tracking incidents will have no basis to keep a tab on the open incidents.
In the second set in the incident management lifecycle series, we look at the very basic distinction that distinguishes incident from a service request.
Often, most organizations confuse (some on purpose) incidents with service requests, and both are handled with the same rigor. This keeps things simple, but in hindsight, it does more bad than good.
Let’s discuss why it is better to keep them separate, and how to go about it.
The Story So Far
This is the second article in the series. In the first one, I introduced the incident management lifecycle workflow and discussed the incident management triggers in detail. Once an incident is detected based on the trigger, an activity needs to be undertaken if the detected incident is indeed an incident and not a service request.
This distinction does not arise for triggers based on event management, but rather for user and staff raised incidents, more so with the ones triggered by the users.
To understand the importance of this check, let us first revisit the differences between an incident and a service request.
Incident vs Service Request
An incident is a disruption to a service that is enjoyed by the user. For example, if the user enjoys the internet service, and if it goes down for whatever reason, this can be termed as an incident.
A service request is an add-on service or enhancement to a service, as requested by the user. For example, if the user does not presently have access to the internet service, he/she needs to place a service request for getting internet access. The user cannot raise an incident for getting internet access.
Service requests are not triggered from disruption to any services or downtimes. But rather it is triggered by the requirement of the user to enjoy a new service.
Why should Incidents and Service Requests be Handled Differently?
An incident is a disruption to a service, so it potentially affects the work activities of the user. So, when the user raises an incident, it necessitates the need to fix it on priority.
A service request is an add-on that the user requests for. So, when the user raises a service request, the priority may not be as high as the incident if all priorities were to be weighed in on a single scale.
Say, for example, a single team handles incidents and service requests. Two incidents and two service requests show up at their doorstep. Which one should they handle first? I bet you guessed it right. The incidents, as they potentially could impact the productivity of the user. Once the incidents are resolved, the team can get to the service requests. It is not going burn the house down!
What Happens when Incidents and Service Requests are Handled in the Same Way?
Some organizations don’t distinguish between the two, and they handle both in the same manner – in the same bucket – in fact, all are just called as incidents. What are the consequences?
The biggest drawback is that the IT staff won’t be focused towards what is more important. They could get distracted by items that rank lower on priority rather than where the need is more.
Consider this example. If a house is burning, would the fire tenders rush to douse the fire, or do they head over to install a new pumping station in the city. You know the answer! So, it is highly recommended that incidents and service requests are well defined, and handled in a manner that focuses on priority items first.
Classic Argument against Incidents vs Service Requests Separation
Some smart alecks have often asked me this question – suppose a user needs to get a new service to carry out his work – which is a service request. Without the new service, he cannot work – which means that he is unproductive. Shouldn’t this quality service requests be handled as incidents?
The answer is NO. Owing to a case where zero planning was involved is not a valid argument to balance the incident and service request scales. The user in question should have planned better. The user should be aware of the SLAs and should have put in his/her request well before the deadline. Putting it in the eleventh hour, and expecting incident-like treatment is a futile exercise.