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.

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.