Well, “save your life” is a bit of a stretch. But it can make your professional life easier and more prosperous. It may save your company lots of pain, time and money. Interested? Great. So, what is an RTSM?

Traditionally, people have gotten the idea that an ITIL project must start with a CMDB. While there is nothing wrong with CMDBs per se, it translates to years of effort of trying to create the perfect CMDB. And nobody has ever done it.

In fact, most “successful” CMDB projects are just asset management projects. When it is time to “connect the dots” of thousands of collected components and create relationships among them to represent real business services, everybody fails.

Why? So many causes…I think it deserves it own post. Think of miscommunication between IT and business, the lack of a real idea of what a “service” is, immature underlying technology, usage of bottom-up approaches instead of top-down, overall tool complexity, lack of integration from point monitoring tools from multiple vendors (or the same big vendor who bought different companies to create a lovely Babel tower), inside-out thinking and more.

It usually ends with blood, sweat and tears, believe me. Unless someone smart decides that asset management is good enough for the CMDB initiative, and stops the madness, declares victory, and starts doing something useful.

But after all this work, many companies are still unable to answer these questions:

1) Are business services really up and running and producing real business results within the stated goals?

2) How can you tell between the five dollar incident and the five million dollar one?

3) How do you continually improve business services?

A Real Time Service Model (RTSM) answers all these questions easily.

An RTSM starts with services. And if you are smart, these are just a handful of critical, real business services, not internal IT services.

Remember, services have business objectives (the insurance quotation service should make the company at least 1000 new customers per month, for instance). Services have processes. Processes have steps. Steps have stated goals (a credit card authorization should not take more than two seconds, for instance). Users have response time expectations for processes steps (a new credit card should not take more than two weeks to arrive at home, for instance). Process steps rely on one or more applications. Applications have interfaces among them. There are lots of things that may go wrong in these interfaces (the sales data from the branches need to be received by 11 p.m. each day, for instance). And finally, yes, applications have components.

And everything has security controls and auditability built in.

The ideal way to represent all this is through a Real Time Service Model. Why?

Firstly, because infrastructure changes so rapidly (think virtualization and on-demand adaptation) that you need the model to be easy to change, including the use of automation (but get this: automation will not cover 100% of it, not even close. If it does, you are not modeling what you should). You need an agile process to modify the model, and a very usable user interface to the proper technology.

Secondly, because an RTSM calculates availability status for your services— automatically. All relationship rules in the RTSM are computational. In a traditional CMDB you may create all kinds of spaghetti-like relations (even custom ones) that mean nothing. And you could inadvertently add circular references . Instead, a good RTSM will make it very easy for you to create a model that makes sense.

The Service Model is the foundation. If you are comfortable with it, you will maintain it. If not, it will become obsolete quite rapidly and you will have wasted your time.

But thirdly, and maybe more importantly, you are not constrained with the concept of “Configuration Items.” You may leave out CIs that add no value. And you may add anything that is business-relevant to the RTSM—even processes you don’t own. Logical controls. KPIs trend checks. External data. Manual process steps. Security controls. Whatever makes the model stronger, more accurate and more useful.

If the model is right, it’s heaven. Calculation of service status is automatic. Probable root cause of an incident is automatic. Business-oriented prioritization of incidents is automatic. Indication of components that fail often is immediate, so you can continuously improve your service indicators (availability, MTBF, MTTR, MTBSI, etc.) and get budget for infrastructure improvement much more easily.

And please notice, you don’t need to have all the model figured out just from the start. Yes, you can start with infrastructure and an open mind to make it evolve. It’s fine. The point is that the RTSM will let you advance. You will be adding indicators, end-to-end controls and more while you learn about them later.

A successful monitoring project starts with the right approach, and becomes a Visibility project very rapidly. Then you start creating beautiful dashboards with an audience outside of IT to find bottlenecks and opportunity areas for the whole company. And you become the hero. You just need the right tool for the job.

An RTSM can be deployed in weeks, not years. It’s the shortest path to success.

But wait, is it ITIL compatible?

The right answer is “Who cares?” But, yes, of course it is. ITIL V3 extends the CMDB concept into the CMS (Configuration Management System). A way to see this is: CMDB plus RTSM equals CMS.

The bottom line is that you don’t need to start with the CMDB. You can add it later. If ever.