What home plumbing taught me about self-service, Service Manager, and Orchestrator

Author by Nathan Lasnoski

Self-service.  Is your IT process as simple as turning on a faucet? 2013-05-16 22_27_31-home plumbing faucet I'll start off with a basic example of "home plumbing".  If I was in my kitchen and wanted to get a drink of water, all I need to do is walk up to the faucet and turn it on.  It then fills my cup and I turn it off.  It is totally intuitive, so much so that even my three year old can do it.  I (or she) requires no knowledge of home plumbing or complex skills.  However, the "magic" of the faucet is complex under the scenes.  In my house I have a well, which brings water into the house, then delivers it to a holding tank, then goes through the water conditioner, into the water heater, then to the faucet.  I've taken a stab at home plumbing from time to time and even though I might be able to make something work, it is neither well executed nor normalized with the professional plumbing community.  The key point here is that in order for the complex process to be useful to me, it needs to be easy and require next to no training.   If I were to take this example as an analogy for System Center, the faucet is Service Manager and the end user experiences (such a SCCM software center), the plumbing is SCCM, SCOM, and Orchestrator.     I was listening to a talk that Jeffery Snover gave the other day and he mentioned an interesting equation.  Scale + Complexity > Skill.  The general idea is that in order to scale something it can't require more than commodity knowledge.  In other words, you can't hire enough smart people and have them act in unison to scale a process well.  This concept is well realized in the service management space and I'll describe some of the circumstances in this post.   Let's take an example of application deployment.  If I were to desire application packaging and deployment to be standardized and rapid in my organization I could (1) train a whole bunch of people to perform a process from a well written procedure,  (2) I could build a self-service request and automation to deploy the application programmatically, or (3) do nothing and don't install software (not really an option).  In a smaller organization you might be able to get away with manual installations with a procedure, but I think the person performing those installations would get a little sick of it.  In the case of a large organization, manual installation cannot be scaled and normalized at the same time.  In the case of using an automation I drastically change the context of using and deploying applications.   In my example, here is how an IT person or an end user deploys an application: Picking an Application 1 You'll note that behind the scenes I have a lot of complex things I want to do.  I have the installation check the software relationship, add the user to the collection, refresh the client machine, and process an approval.  This complexity allows the SCCM administrator to be happy as the environment he built is clean and well organized.  It also makes the IT end user happy as the deployment experience is really simple.  So simple that I could literally hire a person today and have them trained in less than 5 minutes.  A side effect of using self-service is that the user doesn't require special permissions in the application.  They only require access to the portal. Automation In your organization I'm certain there are opportunities for this same kind of approach.  Think about any process where getting the right information, the first time, and automating a process would provide clear payback to the business.  Articulate what he payback is as an ROI and determine if it is worth tackling.  In most cases clear business value is very easy to come by.   Cheers!   Nathan Lasnoski


Nathan Lasnoski

Chief Technology Officer