Yeah, I went for another typically enterprise certification everyone despises and it wasn’t for kicks and giggles. Surely, it doesn’t hurt to have another well-recognized acronym in the CV, but that was *not* the point: honestly - I’ve dealt with IT within a few large enterprises and the ubiquitous lack of understanding the difference between IT product and IT service is overwhelming.

"Oh noes, here he comes with the corporate lingo!"

"App is app, first you deploy it, then … it’s running!"

"Ain’t IT infrastructure about hardware? Not my thing."

"If it involves the word «process», I’m out.".

Nah, don’t worry - it’s not that bad at all.

All this starts to make much sense when you enter the world of commercial relationships: supplier <-> consumer. Having an application ready (what’s "ready"?) is just a beginning - once users start using that you’re usually somehow obliged to:

  • confirm that running it makes sense in an economical way -> revenue exceeds the costs

  • make it accessible enough (to a given degree)

  • keep some security & performance standards

  • estimate its capacity to make sure you’ll able to keep it operating within given market conditions

  •  etc.

That’s not all. Once the service goes online, things will start happening:


  1. users will start ask questions and demand clarifications (who will respond those?)

  2. incidents (service disruptions) will appear (and users will expect to get them solved!)

  3. things may be reported several times (by different users) and some problems may cause several different effects because of the same root cause (someone would have to recognize that so this information may be used in future)

  4. application(s) will get its (their) inertia -> the volume of communication and processing will prevent you from manual verification of operations’ correctness -> some proper monitoring will be required

  5. etc.

"Service", "service" - what’s the fuss about services and processes? Can’t we just call those "apps"? Not really, because the end-users and business owners care more for business operations and functions -> and such an operation may be serviced (involve usage of) by several applications:

ITIL (http://www.itil-officialsite.com/) is an attempt to describe all of that and much more. Usually it’s terribly generic as it’s supposed to be extremely industry-, technology- and tool-agnostic. Sometimes it lacks the internal coherency (mainly to the complex nature of the topic, but that’s not a problem as personally I won’t recommend anyone following ITIL directly and precisely (and brainlessly).

I find it very useful as some kind of check-list -> what you have to think about and refer to when putting your freshly developed app into the cash-earning automaton.