Children, candy and the coming data center automation revolution

I recently watched a thought provoking presentation by Glenn O'Donnell from Forrester research. Glenn talks about the need to create a new beast that evolves out of the CMDB of old days. His point of view struck me as very prescient and to explain my point I'm going to use a story that involves children and candy.

 

I have two boys. Both love candy (all children do don't they?). My younger one wakes up in the morning and asks me: "Daddy, can I have some candy"? Naturally, I start explaining the advantages of a balanced diet and that results in him strongly protesting (a nice way of describing my four year old throwing shoes at me) but eventually I get my point across. The problem is that if I'm not there, it is clear that he will find his way to as much candy as possible. My seven year old however, is much more mature. He understands the rules of a balanced diet and I know that even if he goes to a party, he has an understanding of those rules so that he doesn't over-consume.

 

My analogy is your data center automation teams as my children and your change team as myself. When ITIL is implemented, the change process is considered as the pipeline through which any request for a data center change should go. When you are doing a few thousands of changes a month, perhaps this can be resolved with a large change team. When you do 50,000 changes a month, you need a way to cut that list at the knees somehow by using automated impact and risk analysis tools to identify low risk changes that do not require intervention (BTW, asking the person creating the RFC to determine the risk level in this case is like letting the fox guard the hen-house but that's another story).

 

When automation was first introduced it was a technology that removed limitations around the quantity of work that could be done at a limited time and significantly reduced the human error factor when doing repetitive work. In his book "Necessary but not sufficient" Eli Goldratt explains how when removing a limitation through technology one must consider the underlying rules of the organization, otherwise, the newly introduced technology won't achieve its potential value for the customer. This is exactly what happened in this case. The underlying rules are the change process and now when potentially we could have 500,000 change in a highly virtualized environment, change teams simply cannot process such volumes.

 

Organizations today must choose between:

1) Demanding that all automation activities go through the change team, thereby, stifling the automation team's productivity and its value.

2) Turning a blind eye to whatever these automation teams are doing on the side. As automation in production becomes more prevalent, customers that stick to this approach will find themselves at the same levels (and worse) of change related service disruptions that existed before their change process was introduced.

 

When Glenn talks about a CMS++ that has automated change and configuration management, I believe he is looking for something that will allow the change team to put rules in place and then for the automation teams to abide by these rules with minimal human intervention of the change team.

 

I see this as a coming revolution in the way IT is managed. I use the word revolution because relying on humans as your gatekeepers of last resort simply cannot hold water anymore with the coming volumes and volatility that virtual data centers will experience. The potential agility levels and the economic factors offered by virtualization will eventually overcome any conservative reservations. The one thing that will not be tolerated by customers is if that agility introduces chaos and service disruptions.

 

This is where I think the CMS++ Glenn talks about will revolutionize the way data centers are managed. Of course, technology will have to stay abreast of this and have all the relevant data available in near real time for analysis. However, I believe it is even more about the perception of how the process should work. Instead of creating a pipeline, that turns out to be a bottleneck, we will distribute the work and empower the workers. The words "empower" and "worker" at the same sentence smells like revolution to me.

 

I wish I could have a way of doing the same thing with my children. Oh wait, I guess that's called education.

 

Until next time.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
I'm a 20 year veteran in the software industry with experience ranging from control systems, communications systems, RAD systems and for the...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation