fredag 31 maj 2013

The tail of a server, asset and ci

Once upon a time there was a small server born. Along his interesting life he always took comfort in the "computer God" that he was was told lived in the Internet. From birth he always considered himself as curious, open for new ideas and thoughts, and this is his story.

Early on he lived in a big factory pretty much waiting for something to happen. One day there was a big fork-truck loading him and many other server on their journey towards new exiting adventures. After a couple days of traveling he could feel that the box he was inside had stopped. Somebody was scratching on the outside. The box was slowly opened and a face full of anticipation look down at him. - Oh look at that. What a beauty the person said. He was one of the company technicians and was known for his love for hardware new technology. The server had never felt this kind of care and warmth. He was really enjoying the mounting in the server room and installation of Software that the technician put him through. He was told plenty of times that he was the proud and joy and how fantastic everything was going to be.

During the unpacking he had seen that the technician had been talking notes and writing down numbers from the box on a piece of paper. He thought about it and asked the "Computer God". -What was that about? Why did the technician write down all that stuff? God replied -You are now an Asset. When you where received here you entered a new stage in your Asset lifecycle. You where registered as "received" instead of "ordered". You will soon be registered as "in use". You belong to the type of servers called "small server". You are the first of your kind and there are other ones, not of the same kind, already living here, also called "small server". They will slowly be faced out and replaced by more of your kind. -Wow, this really sounds fascinating thought the server and asked God. -Why am i a asset? God replied. -the company needs to keep track of you so that we know what contracts covers and supports you, what licenses are used on you, the cost of owning you and who the supplier is etc. You have a lifecycle that will manage and follow you as an Asset until you are disposed of. -What, said the server. Is my purpose to be disposed of? God replied -Well, not your purpose, but that will eventually happen to you. Just like it is now happening to the server that you are replacing. The server was very disheartened by this and did not feel good about the new things that he had learned.

The days passed and the server was really doing well and enjoying his job. Every time there was a need of process power he really put his hardware to it and performed his very best. Occasionally the technician came by and told him that he was doing such a good job and everyone was very impressed with his work. The server felt really good about this and continued to work very hard. One day he turned to God and asked. -I really like the job and its very clear to me that i do it good. But i am still wondering why i am doing it. Do not get me wrong, i really like it and the technicians are very kind and i like it here. -Well this is the life of a server. We keep track of you and take care of you. If something in you breaks down we order a new part and replace the broken one, everything is a part of you lifecycle. The server remembers the last time he was broken. It took 3 days before someone replaced the broken part and additional 2 days before he was fully operational again.

One day there was a buzz in the server room. All server where talking because one server had overheard a technician say the there is a new process guy starting at work. -Why is this so exiting? asked the server. The technician had said that the process guys was going to explain the purpose of all equipment including the servers. This sound really exiting thought the server but remembered what the God had told him about getting disposed of. He felt a bit depressed by it but was interrupted in his thought by a burst of processor capacity and did not think about it more. 

The months passed and the process guy had visited the server room a couple of times but there was no news about what was about to happen. After some additional weeks the buzz in the server room started again. -The process guy is done with the first stage, the server heard another server say. Everyone was exited about the news but time went by and nothing happened. One day, suddenly the server noticed that he was getting warm and after a wile a memory card broke down. Well, he though. I will just sit here and wait like the last time he broke down. But this time everything was different. People came running and remote control tools where used and he had never seen this much attention for any server before. He was up and operational in less that two hours. Less than two hours! This had never been seen before in the server room and all the servers where talking and discussing what had happened but without any answers. 

The little server felt proud. He did not really understand why he got all that attention but he did and the other server look at him with admiration. Everyone was happy for him and he felt very good. He asked God. -Do you know what happened and why i got all the attention? -Well, God said. You are now a Configuration Item as well as an asset. -I already knew that i was an Asset but what is a Configuration Item. -Well, you have actually always been an asset and then later a CI but the process guy has done some changes in the CMDB and now everyone can se what you are used for and who is using you. We also know if it is important that you work correctly and how long it can take before you need to be fixed. The server look confused and asked. -What is the difference between an Asset and a CI? God replied. -An asset is tracked from a financial perspective and the information is structured to fulfill those needs. An Assets being grouped into variants that is grouped into products that is grouped into types etc. This structure is used ,among a lot of other things, to maintain license compliance on the software that is running on you. -So what is a CI? -You se, said God, when you are used for something then the Asset status is set to "In use" and a new lifecycle starts and kicks in and that is the lifecycle of the CI. So in short you could say that within the status of "in use" for an Asset there is many more statuses that is irrelevant from an Asset perspective but i crucial in the delivery perspective where the CI exists. To keep them separate we call them Asset and CI. You are both Asset and CI but depending on what information is require we can look at it from different perspectives. 

-You still did not tell me why i got all the attention earlier on. -Well said God and thought about it for a while and continued. -I might as well show you because it is kind of hard to explain it. God showed him a picture with lots and lots of squares and lines and pointed to one of them at the bottom and said. -This is you. -Me? said the server and looked very confused. -Yes it is you and everything you are in relation with. -But said the server -Just follow me here, interrupted God. -This is a visual representation of everything in the server room and connected to it. We store the information in the CMDB and this square is you. This one over here is the server next to you. Here you have the network you are connected to and this is the softwares that is run on you. -We have always had this information said God. The server asked -Last time I broke down it took 5 days before i was in operational state and this time it took two hours. If we always had this information why was it such a difference. -As i said earlier the process guy had done some changes in the CMDB, which actually is what we are looking at right now but as a visual representation. The changes and additions he made are these squares here at the top. They are services. They shows us who is using the equipment for what and how important it is that it is working at a specific moment. The reason you got all the attention is because you are a very important part. The server look shocked and said -important, me, but, why? -You are a very critical part of a service delivery and when you break down there is a lot of people that can not do their job. We did not know that before but now when the process guy have shown us how to understand whats really important we can focus on the right things and make priorities based on that. 

As the story continues out little server experienced breakdowns and upgrades until he finally was replaced by a new server. The server felt that he had lived a fulfilling life and was looking forward for retirement. The Ci was decommissioned and the Asset was disposed of and the server ended up in a secondhand store. He was purchased by a newly graduated student who was exited to get her own server so she could learn how to write program code. She had a brand new new idea for a program like nothing else seen on the market but that is a completely other story.

onsdag 29 maj 2013

The power of service request

When talking about a service request it is easy to refer to the service request catalog. In the service request catalog there is something and that something is commonly applications that the user can request access to.

So that means that a access request to a application that a consumer wants is a service request?

This is very common and it does not take to much surfing to find examples of request catalogs filled with this kind of requests. How they are fulfilled is just a matter of automation and that is something i will leave for another topic. So the question here is if a request for application access is a service request? I think it is according to definition but i get sad if i think that is how far the evolution of request have taken us. 

I am pursuing completely different content for a request catalog. when my consumer steps in to my service area aka request catalog i want to know the full picture. If she wants access to a specific application thats fine but i want to know WHY she needs it. You see, i know stuff about that application that she does not know and therefor i can deliver parts that will be completely transparent for her to fulfill her wishes in the best way possible without her knowing all the details.

Lets compare two scenarios and you pick the one you would like to interact with as a consumer. The first part is general and applies to both following scenarios.

General situationFor some reason you need access to a application that you do not already have access to. It might be due to that you will stand in for someone during a time period or that your work description has changed a bit. Either way you are in the works of requesting access to application A. Prior to this you received a quick "demo" of your new work assignment and instructions of how to do perform "order processing" but you still feel a bit unsure about it, but hey, who would not. 

Scenario one. After a search in the request catalog for application A you have found a service request for access to application A. You request it according to instructions. After a while you get a notification saying that your request has been carried out and you received some credentials to access the application. When performing the "order processing" there is a verification step that actually requires access to a web portal (via url link) but when trying to access it you are denied. There is no obvious name of the portal and after a new quick search in the request catalog resulted in to many hits on the words "web" and "portal" and a additional search on application A only resulted in the request you earlier requested. so a call to the ServiceDesk solves the situation and you can continue with your work after listening to an agent explaining that you need access to something you have never heard of.

Scenario two. After a search in the request catalog for application A you have found three service requests that contains application A. It is a "order processing", "complaints" and "packaging". You choose the "order processing" and request it according to instructions. After some while you get a notification saying that your request has been carried out and you have received some credentials to access the application. A this point the rest of the scenario is a user performing the work without any more disturbances.

Difference in scenarios. In scenario one the request is isolated and access to that specific application is carried out. The ServiceDesk does not know what the consumer needs the access for so we fulfill the application A access "by the book" according to access instructions. Case statistics are great and the number off processed requests are rocketing. 

In scenario two we took some time when defining and creating the service request by identifying three possible situations where access to application A is relevant. The reason for this is that each situation needs additional fulfillment steps and access granted. This way the request can contain far more bits and bites which is irrelevant from a consumer perspective but crucial from a successful fulfillment perspective. 

tisdag 28 maj 2013

"We will" vs "we have"

How often are we in the situation where we talk about the future and things to come for an audience we need committed in our cause? To reach there, there is a lot of "I will" and "we will" have to do. Arguments are hypothetical and examples are fictional. The rhetoric is perfect and the audience is "sold". Looking back, How many of these brilliant ideas really comes to life and sees the light of day? 

My own experience have given me some elements that increases the probability of commitment substantially.

Alternative today. If we hade it today how would it look like. Not in a year or five years, today. Make the homework and base any calculations or predictions on facts and not hypothetical assumptions. Yes it can be a lot of work but if you can not show that today's reality is the lesser of two comparable cases its hard to get engaged. Why would it be better in the future if it would not be better today, prove it based on facts and show what you "have" instead of what "will".

Actionable engagement. Make the calculation or prediction actionable. If the wanted situation is something we would prefer, what would we do then? Make it easy to feel engaged by leading the audience to the point where they know what they would do if they already had what you are pursuing. They should almost want to start doing it right there based on your calculations. 

Keep it short and repeat the punshline. If you can not explain it shortly it is not ready. Einstein said: If you can't explain it simply, you don't understand it well enough so nobody else will get it either (a bit modified). This is always very relevant so do not underestimate simplicity. Things do not catch on at once so repeat the punshline a couple of times. 

Do not say it with the presentation material. If you use PowerPoint, Keynote or equivalent media make sure you do not repete/say the content on the media. If you are lecturing you should be fine with only ONE word for each slide, yes one word. Chose a word that reflect the essence of the part of the topic you are going to talk about. It can even be a word like "fantastic" if that's what you want the audience to think. A relevant picture on each slide does the job as well. Keep it as minimalistic as possible. You should absolutely not need to look at the presentation to keep the "flow". 

torsdag 23 maj 2013

service vs process

I have read numerous examples and descriptions of this topic but i miss an important point in them. Thats why I will make my own contribution in the matter so I will start from the beginning.

A service is the bundling or packeting of something that is consumed by someone and there is a provider which take responsibility in delivering it according to some kind of agreement. The service might consists of multiple parts/options where some can be mandatory and others can be optional. Sometimes the service is static and can only be purchased in its current shape but nevertheless, the consumer needs and wants it.

A process is the way (a sequence of activities) where a defined outcome is achieved. Its supposed to be efficient and repeatable so that the outcome is achieved every time the process is triggered and completed. The framework ITIL consists of processes, and the description of them, and is a common way of describing the way (workflows) an IT department is trying to work.

The service is consumed once or frequently over time. The process is triggered and driven according to the flow.

This far i think it is quite strait forward but how about the missing point? Well when defining a service there are things that are crucial. If part of your goal as a provider is to contribute and align with your customer. The first thing to understand is what the heck is the consumer trying to do and achieve. The other thing is to understand the process of how the consumer is doing it ........ but ........ here is that process again? This time the definition of the process is still valid but now it is not the IT departments processes that we are talking about. Now it is the consumers process we are talking about and this is the point i miss. As an IT service provider we need to define internal processes for how we do our work but that does not have anything to do with the services we provide. To define a service we need to have a clear understanding of the consumers process and its only then we can align and contribute.

To define a service where the consumer actually perceives it as valuable it needs to be fitted into how the consumer achieves its outcome. We as a provider need to understand the consumers process and choose a part of it or the complete consumer process and define how IT is used to achieve the outcome. When this is done we can package a service to enable the consumer process, or part of it. For better understanding and communication, the service should be named as or similar to the part of the process its enabling. If the service is designed to support or enable a complete process, the consumer process outcome is good start for the naming of it.

If IT can define a service where its utterly clear for both the consumer and the provider what the service enable or supports, eg. exactly what part of the consumers process it is supporting, and the consequence when the service is not available, eg. how important the outcome is at the specific moment for the consumer, you have a good foundation to start with defining services.

With this information IT can design a service where the following is true.
- When available, both parties have the same understanding of what it is used for and what it is enabling.
- When unavailable, both parties have the same understanding of how critical the situation is at that specific moment in time.

in one case it might not be critical until next day/week/hour and in the other it might be critical at once. This is only achieved by understanding the consumer process and the value of the outcome for the consumer. The process within IT is the way we manage and deliver our IT services. The service is the way IT enable the business process IT supports.

Analogy: Whats the point of knowing that there is a flat tire on a car if we do not understand that the rest of the car is useless for the driver without it? It would be better if the parking break was broken and we understood what that meant and could tell the driver to continue to use the car but not to park in tilting conditions until fixed.

måndag 20 maj 2013

Service request vs Service offering

I realize that its not always clear what we mean when talking about service in the context of a service catalog. Usually we talk about a service and the service catalog in the same sentence but we need to be specific about what it means.

A service in this context consists of two things. The service offering and the service request. The service Offering describes what is included in the service. What parts of the service is optional vs mandatory and the cost associated with the consumption of the service or any parts of it. All available services should be found in the IT Service Catalog. This service is often what is used for follow-up with the customer.
The service request is how you trigger a Move, add, change or delete (MACD) request and there are usually multiple different requests depending on what you want to do and they all are connected to the same service. The service request can be requested by the customer on behalf of a consumer or the consumer can initiate it to be approved by the customer if applicable. the consumer is the one that will use the service or parts of it. The service requests should be found in the IT Service Request Catalog.

A customer understands the warranty (when available) and usability (what functionality) of a service that could be available for a consumer by reading the service offering in the Service Catalog. the consumer initiates a service request which states what and how the service is to be consumed, and if required, the customer approves or denies this service request in the Request Catalog.  

In the service catalog you should find the service offering and the service requests you should find in the Request Catalog. Optimal is if there is a relation inbetween them to clearly show what requests are related to what services. The service offering is the description of the service and the service requests are the way you can interact with the service by MACD consumers, capability, functionality etc. 

fredag 17 maj 2013

How to get things done

Here is a simple process that helps you prioritize, plan, delegate and improve!

torsdag 16 maj 2013

What is a KPI in everyday life

The use of the term KPI is very frequent and i think sometimes misused. The term stands for Key Performance Indicator and should be a measurement, which when followed, should lead to an expected success. So lets apply this in everyday life.

The example is a very common one and is applicable in any situation when you have a specific destination to get to at a specific time. It could be at work, school, appointment etc. where you are expected to be at the final destination at a specific time certainly have a couple of KPI's.

I will use my wakeup and morning routine as the example. When i wakeup in the morning the first thing i do is to brew my coffee and while waiting for the coffee to be ready i sit in the couch to wake up thoroughly. When the coffee is ready i sometimes drink two or even three cups before i feel satisfied. After the coffee its shower time. Depending on if i need to shave, the time in the bathroom can vary up to 5 minutes. Now it is time for the wardrobe and the whole clothing dilemma, then pack the work stuff in the portfolio and make sure the phone, keys etc. are packed. After that a i quick stroll from home to the train (yes i travel with train to work). After the train a short trip with underground subway to finally end up at work.

So how about those KPI's?

If i stack the stuff in my morning story it would look like this.
- Brew coffee (5 minutes)
- Drink coffee (15-20 minutes)
- Bathroom (10-15 minutes)
- Get dressed (5-10 minutes)
- Pack stuff (5 minutes)
- Stroll (5 minutes)
- Train (30 minutes)
- Subway (10 minutes)
And then I am finally at work.

So how do i apply KPI's in this scenario? Well there are som hard facts here. One very obvious is the train. The frequency of the train is once every hour and if i would fail to catch the train at the planed time i would not succeed with my goal, to be at work at a certain time. The subway on the other hand have a frequency of every 5 minutes so i just take the first one that comes. The train is a very obvious KPI so all my other measurements i do, watch the time during the earlier activities should be based on the probability to catch the train, which in this case is key for success. Each of the earlier activities has a varying time estimate so this means that i have to adapt each activity based on my measurements i do (checking the time) and considering how much time the next activity might require of me. If needed I could walk faster, dress quicker or even skip the shaving if required to catch the train in time but i cant change the time of the train.

So the KPI here is my ability to catch the train at a certain time. To achieve this, i do allot of measurements that all indicate my status compared to my goal. These measurements are not KPI's and they will always change over time depending on the activities that i want to carryout in the morning. So do not mixup measurements and KPI and don't mixup the goal with the KPI. Always try to identify a few or even ONE KPI if possible to indicate you ability to succeed. If you get to many you are probably identifying measurements and not KPI's.

fredag 10 maj 2013

Process development or decommission

People seem to think that process implementation is about a design phase and a implementation phase. Once it is in place you are done? I think nothing could be more wrong (well actually allot could be more wrong but just bare with me on this). To actually get a beneficiary evolving process you need to care for it. Being actively caring is the key for the process evolution so lets call that management :)

To manage your process you can develop it along with time and adjust it for better compliance or efficiency but if you do not nail the effectiveness whats the point? Some call it effectiveness and some call it outcome but let us agree on that every process has a purpose and for sure the purpose has to add value for someone and that someone is probably not you!

So what happens if you do not actively manage your processes. well one thing we do know and that is that everything change. So basically if you do not have active development you will have active decommission ("not to do" something is actually to do something as well). Your process will loose it's focus (effectiveness), not due to that it is changing, but due to the fact that the outcome will not match the changing business needs over time. 

Service vs System

In my mind a system is never a service and a service is never a system. They might even have the same name but they are definitely not the same thing for me. Let me explain myself. Below in the picture you se system X. System X has 2 applications, a web server, one database and four servers. Together all this could be called a system.
Is this the same as saying that this could be described as a service? well lets expand the example with yet another system that has basically the same complexity but delivers different application functionality. Then we get the following.

The above picture shows us two systems with applications, databases and web servers installed on servers. not a to uncommon situation.
So let us try to apply a service to the picture. To identify a service we need to understand "what" the user is doing. lets say that the user is registering an order, so the first part of the service we are creating is the "order registration" service function. We use the service function to define the service and the service will have many service functions. Our first service function is defined and now we can identify what parts from the systems that need to be available so the user is able to register and order.

to register an order we need the following parts of the infrastructure.
- application 1 (from system X)
- web server 1 (from system X)
- db 1 (from system X)
- db 2 (from system Y)
It would look like this if our function is included in the picture and indicated in yellow.
As you can figure out there is a connection between system X and system Y which obviously is required for registration of an order. this is not shown any way between the systems. it is only shown in correlation with the service function. This means that "what" the user "does" and how this is realized in an IT solution is key for how we would define a service and its service functions.

In real life, the solutions are far more complex and the interaction between systems are very common without that the user realizes it. This strengthens the fact that a system and service is not, nor will ever be, the same thing.

What is relevant information in CMDB?

It seems like many of CMDB designs and implementation fails to define the purpose for the content. This often leads to that everything that is accessible and available is stored in the CMDB. Every CI will be populated with attributes usually collected from various discovery products etc. What is the purpose of this? Well in the short term this can be useful. If the information was stored and accessible in different sources the short term gain could be that it is now accessible from one source. But is this really the purpose of the CMDB?

Well I think no, and here is why in my mind.

Imagine a CMDB with CI's and only one attribute per CI, the name. that means that any CI you create in the CMDB only gets a name and nothing more. Could this be used in a valuable way? yes very so, but it requires you to do more than just create CI's from discovery. You need to create services and service functions and you will probably not find them with a discovery tool.

lets make an easy service example and choose the ticket handling service that a ServiceDesk is using. The IT department is the supplier of the ticket handling service and the ServiceDesk is IT's service customer and consumer. Then i guess we have a service called ticket handling but what does it deliver? To define the content of a service i use service functions. One service function that the service desk is using is registration for sure. So lets line up some of the more obvious service functions that the Service Desk might consume.
- Manual registration of tickets based of phone call
- Automatic registration based on e-mail
- e-mail (communication outside the ticket handling application)
- incident Dashboard
- Self service (enduser knowledge, request and ticket registration)
there are more but lets keep to these five obvious service function just to prove the point of using few attributes in the CMDB.

So now we have the following.

We have one service with five service functions which actually tells the provider what the service desk is doing. This means that if we now connect the application CI's that provide this functionality directly to these service functions we get a pretty good view over how the provider is delivering the functionality to the service desk. Just to illustrate it i have entered som applications and server to the structure and we get the following.

This solution is very simplified but I have added three applications and three servers. the ticket application is critical for all functions and therefor have relationships to all functions but there are the e-mail application and the www application that actually does not affect all functions that the Service Desk is consuming. This means that if IT understand the availability demands from the service desk for the service functions IT can use this information when performing changes and handling incidents, problems etc. All this intelligence is still achieved with very few attributes on the CI's. It is the combination of CI's in a context that creates the magic. not the number of attributes you can squeeze into a CI. At this point the service and service function is quite static and the information is manageable even if performed manually by the service responsible.

If we add monitoring to the concept we can calculate the priority very easy when a incident occurs. we do not have application to application relationships and almost no attributes but we have the most important information available. How does this affect our customer! There are of course a lot of information that could be valuable that could be added but this basically covers the basics for a slim CMDB still with a customer centric structure.