Dependancy Inversion in Service Delivery

My college over in Application Development published a blog post on the corporate blog on the Dependency Inversion Principle, and the benefit of applying this to API contracts. I do a lot of work in System Center Service Manager, which is unsurprising to anyone who has seen this blog, and this post got me thinking about the social contract between service desks and the user base.

The case

Most users have the implicit (if not explicit) expectation that if they call up with whatever, the service desk will do something about it. Questions along the lines of “How do i fix my Access database?“, “Can you connect my iPlague device to the network?“, “Can you make sure my Tax Software gets upgraded to my new machine?” and “How do I install My kid’s math software?” are not uncommon things for a service desk to deal with.

Surprisingly, no one seems to think this through to it’s eventual conclusion. Whatever your users ask for is a HUGE possibility space. To extend Josh’s analogy, it’s like trying to write invoice translation software that has to make sense of anything and everything from the French flat-fee software support agreements to binary-only bitcoin transaction fees from the hivemind machine collective.

Moreover, because we’re handling whatever the user needs, there can be no standards. Each request has become it’s own little scary puzzle-box in the the giant-bin-o-needs that is the incoming request queue. It takes a LOT of effort to understand, correct, route, and deliver each of those want-puzzles. In the context of a service desk, effort is extra analysts, or extra stress on your existing analysts.

So how do we get there from here?

Let’s start with the well-defined services you already offer. In this example, we’re going to start with a user requesting new hardware, like a new computer.
You already know how to execute this:

  1. Someone needs to approve, usually a line manager or purchasing manager.
  2. Someone needs to purchase, could be a AP or purchasing analyst.
  3. Someone needs to prep and stage it, probably a imaging person.
  4. Someone needs to deploy, take a guess that it might be a desktop tech.

You already know what information you need to execute it:

  1. Who needs it. the obvious answer is the person who’s requesting it.
  2. Why they need it, because someone needs to approve, right?
  3. What kind of hardware; Desktop, laptop, etc.

Once this is written down (the writing is important, don’t skip this part), then ITIL calls this a Service Offering. Offerings are a small part of your Service Book. The Service Book is the abstraction you need to start doing the dependency inversion.

In the old model, the user calls up and says “gimme thing”. That incident is sent to desktop, because they deliver those, right? Desktop forwards it back to imaging; they don’t have one on hand and need a newly imaged replacement. Imaging sends it back to purchasing, because it’s not coming out of their stock unreplaced. Purchasing bumps it back to the budget approver, who finally makes a choice on if the company should buy it (note: not the same as “if the user needs it“). We’re already an hour in, and we haven’t even done the first step yet.

So if we do an inversion on this request, now we offer a service for “new machine”. This service requires the user to select a machine, justify themselves, and submit. The request gets express’d over to their manager, who can approve  (or reject based on user’s need, btw), and once they do it get’s forwarded to purchasing, who can buy a replacement for stock. hop skip and  a jump over to imaging, where they pull one off the OSD rack and drop it off at desktops, where the desktop team can walk it out to the user. Start to finish process is the same hour as before, but in this example, we’re DONE, where as before we were just about ready to start.


The more of your requests we can handle with these well-defined service offerings, the easier time your service desk is going to have with whatever remains. To go back to our analogies, we are telling our vendors to fit into a processes that is easy for us (Service Offering), and in return they will be paid much faster (half the time, in our example); otherwise, you can still submit whatever, and someone will review it eventually (call the service desk and submit a Generic Incident).

The deal you are offering is going to be pretty appealing to your users; they do a little leg work up front to make sure they fill out the right questions, and their ticket gets express shipped to the right person, has all the right info and processes so that it’s ready to roll.

You may not be able to pull off a dependency inversion on everything your service desk does, but most service desks have a long tail distribution. if you flip even 20% of your most common requests into a well defined service offering, that’s a pretty big deal in terms of delivery time and analyst effort.

And it’s a whole lot better than flipping your table.

In Other News

Why do we define IT departments by the users whims? Largely because most organizations don’t have a strong vision of their services. They view themselves as the “whatever the user needs department”. Consulting companies (like mine) are forced to develop a strong vision of their services, because they need to convince people to pay for those services. The sales process develops communicable abstractions and service offerings. It’s also no coincidence that IT departments struggle with budget and spending justification.

Josh tells me this process is better described as Dependency Injection, the process of pushing requirements from the provider to the consumer. 


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s