The compelling need for modeling services

Some time ago I was working with a customer who was new to his organization. His sole responsibility was to administer Managed Objects software – and was tasked with modeling his business’ most important services.

It might defy expectations, but this new hire was made responsible for modeling the service dependencies for an organization he knew little about. We worked together for about a week and I like to believe I gave him a lot of good advice and training. Consequently, he wasn’t exactly humored at the quantity of work that lay before him, but he gotten some good ideas on how to begin.

About a year later, I spoke with him again and to paraphrase, this is what he told me:

He was viewing his Managed Objects BSM operations console and saw a critical problem -- one of their Oracle servers had thrown a critical error. He walked over to the network operations center to see what they were doing about it.

In response to telling the ops guys that Oracle was down on one of their critical apps, he received blank stares.

“Huh? No, Oracle isn’t down, it all looks okay.”

And then just as the ops people were saying as much…they saw he was right. There was an error. Their question to my customer was, how did he know that, and more importantly how did he know that before they knew?

The answer is simple: he asked the hard questions about what the service dependencies were and then was able to model them. He didn’t model every service, but he modeled the important ones.

He asked questions of managers, operators and developers. He read standards. He pieced together information to develop a picture of how the systems work, and then going back and asking more questions. In context, and against some fairly tremendous odds, my customer pieced together how the key systems they monitored actually worked.

This story is cliché amongst my co-workers. They all have had instances where customers have related similar experiences and seen it themselves.

- Tom