This page is powered by Blogger.


 
  corner   



HOME

ARCHIVES

SEARCH

Contacting Us
Recommendations
Mike Tarrani
Linda Zarate
Kate Hartshorn

Who We Are
TEAM Zarate-Tarrani

Our main weblog
Notes from the Field

Our other pages
Mike's home page
Linda's home page
Kate's home page

Forums
Simpatico [we]blogs
Dan Gilmore
Robert X. Cringely
Jakob Nielsen
Julian Bond
Deborah Branscum
Lisa Rein
CamWorld
Ed Yourdon

 

Thursday, March 21, 2002

 

Tarrani-Zarate Model - Part 1. I'm finally caught up and have the time to pick up where I left off nearly two weeks ago. First things first: I greatly appreciate the way Linda Zarate and Kate Hartshorn stepped in and kept this and Notes from the Field going while I was engaged elsewhere. Not only did they cover for me, but they both shared an incredible amount of information about a wide array of topics. With such wonderful colleagues and friends I am doubly blessed. Thank you both!

Genesis. Linda and I developed this model nearly two years ago. The impetus behind it was our dissatisfaction with a model, called the Inteliant Operations Maturity Model (iOMM), that was developed by a company where she and I were working. Although we participated in the development of the model, we clearly saw that it model had many gaps, not the least of which was the fact that it just didn't make sense when you drilled down into it. The reason why the problems existed had little to do with the team that developed it. Indeed, the people with whom we worked were the best and brightest IT operations management professionals in the business. The problem came about because we attempted to cast the model in a neat geometric shape. The first iteration was a pyramid, which did capture the essence of what it takes to effectively decompose the complexities of IT operations management into domains.

The second iteration of the model as it unfolded was depicted in a cube to add another dimension to capture elements that were impossible to depict in a pyramid. This was a major leap forward, but the root cause of the problem was we were looking at a geometric form with which to visualize IT operations management instead of looking at the important aspect: answering the simple question, "What is operations management supposed to accomplish?"

We decided to answer the question and let the shape of the model, regardless of how unseemly it turned out, be determined by that answer.

What is the Tarrani-Zarate Model? In a nutshell, the model is a way of capturing the purpose of IT operations management, looking at the necessary drivers, required processes and casting them into an end-to-end flow that delivers service and support to the business. That, after all, is why IT exists.

What we came up with was a model (see illustration) that had business imperatives as a driving force, and the following major layers:

  • Foundation, consisting of business requirements, service level objectives, processes and organization
  • Key processes, which encompass change and configuration, problem, recovery, workload, security and service level management
  • Technology - the layers of infrastructure and systems that are necessary to provide tools to the business
  • Service Delivery (the end goal of IT operations
  • Applications Delivery - which is how new systems and services are brought into the enterprise
One problem with this model is that we have not shown the full scope of security. While there are IT security processes, they should be under the aegis of an enterprise-wide security program. This is something we'll correct in the model as we develop it.

Business Imperatives. This is the driving force behind the model, which determines how all other layers (both vertical and horizontal) will be managed. Business imperatives can be broken down into five basic forces, all designed to create customers at the most basic level, and business viability at the macro level. The forces are:

  1. Strategic and tactical objectives - the reactive and proactive responses to competition, market shifts, regulatory factors, etc.
  2. Mission and values, which define the business entity and are a function of leadership.
  3. Competition, which determines strategy and tactics to a large degree, and the barrier to creating customers in an open and free market.
  4. Shareholder value, which is an imperative for all publicly held companies. This imperative has legal ramifications that are closely connected to regulatory and legal imperatives.
  5. Legal and regulatory compliance requirements are constraints and govern how all other imperatives affect the business.
One way to see the cause and effect of business imperatives on meeting the model's objective of providing service and support to the business is to closely examine the flow, factors and considerations depicted in the recovery management process. This particular process is at the key processes level in our model, and as shown in the illustration it touches all other aspects of the model (with the exception of applications delivery). Each of the key processes in the model can be traced to business imperatives, so this example is apt.

Closing Notes. Tomorrow I'll discuss the foundation level of the model, which has been partially addressed by Linda's recent entries here and in Notes from the Field. At some point in the coming entries I will also begin introducing books from Mike Sisco's IT Manager Development Series. Until then you may find useful information that addresses business imperatives on our Business and Strategic Planning Resources page.