As an ITIL© consultant and trainer, I've used words like: Top-Down...End-to-End... Outside-In... and I'm afraid that adding this jargon to the jumble of ITIL terms may be resulting in clients getting a picture that looks something like M.C. Escher's Relativity.
More often than not, Service Catalogs represent IT's view of the world and are nothing more than Technical Catalogs that mean very little to the business (and even less to the business' customers).
This reality simply must change if the vision for ITSM is to be realized. Nowhere is this more exposed than when we instrument IT services for 'end-to-end' monitoring. Everything's relative.
So I thought I'd put some of these terms in perspective to highlight why this matters when defining IT services.
Outside-In, End-to-End, Top-Down .... just what are we talking about?
The term Outside-In is not new. In fact its roots trace back to Peter Drucker's work in the 1950's:
“It is the customer who determines what a business is. For it is the customer, and he alone, who through being willing to pay for a good or a service, converts economic resources into wealth, things into goods. What the business thinks it produces is not of first importance—especially not to the future of the business and to its success. What the customer thinks he is buying, what he considers ‘value’ is decisive—it determines what a business is, what it produces and whether it will prosper. The customer is the foundation of a business and keeps it in existence. He alone gives employment.”
GE drank this Kool-Aid long ago too:
If IT seeks alignment with the business then the best way to achieve this is to align with the business' External Customers. ITIL©'s Service Design (figure 3.10, page 41) shows 'Integrated business-driven technology management' and states:
“[ ...it is vital that the management architecture is developed from the business and service perspective (i.e. 'top down').]”
So Top-Down suggests we should be focusing design efforts on understanding requirements (duh) and then proceeding to Bottoms-Up implementation (i.e., monitoring instrumentation) efforts. OK, so what about 'End-to-End'? As best I can tell this started as one of the design principals of the Internet; my simple mind translates this into every layer (i.e., the ISO 7-Layer Model) of every component (i.e., Configuration Item) of an IT service ---- and therein lies the rub.
Why Outside-In (read External Customer) Perspective Matters
How we define services is as fundamental to IT service management as a CMDB, Service Catalog or any IT process. Most would agree that limiting service definition to a Technical Catalog of services is not adequate, which is why we have a Business Catalog of services as well.
However, even when we view The Business as our (IT's) customer we can be off the mark when it comes to defining services. The silos that exist in IT also exist in the business, and it is common for organizations to take a functional (inward) view of business processes.
So we wind up with Finance, Sales, Marketing, Manufacturing etc. processes that make good sense to the business (but may not make very good sense to external customers). The processes customers 'see' often cross functional boundaries, and in many cases supplier boundaries as well. This complexity of customer/supplier relationships, coupled with an inward view of business processes, can spell trouble for an organization. In a world of increased outsourcing and cloud computing, this is of paramount importance.
When the term End-to-End is used, we must ask the question from whose perspective? Ask a functional unit like manufacturing or finance and you're likely to get a systems oriented view of their processes;
“[ ...The great shortcoming of the input-process-output paradigm is that it leads to a focus on the internal workings of a system so intense that the external world is sometimes ignored or overlooked. .... Nickols 2003]”
Perhaps more importantly, Outside-In thinking is an organizing principal. It provides a uniformity of purpose that all functional units in the organization can relate to. This is critical to obtaining acceptance and keeping people pulling the rope in the same direction. It also establishes the boundaries essential for defining what 'End-to-End' means.
So, when the Good Books say define VALUE as part of Strategy, be careful to simply view 'the business' as IT's customer; it's the External Customers of the business that really matter.
Outside-In and Service Monitoring Intelligence
While there can be some benefits associated with service monitoring intelligence even when true End-to-End services are not defined from the eyes of external customers, the value of monitoring intelligence increases when we get closer to an external customer perspective of End-to-End services.
Of course simply instrumenting individual silos (network, Web, App, DB, et al) is not close to 'End-to-End'. However, even if we instrument infrastructure 'End-to-End' (meaning we've included all infrastructure components) it offers minimal benefit. The reason is that the applications that ride on top of that infrastructure are closer to the business.
But even when we instrument both infrastructure and applications, we can still miss the mark. The most obvious example of this is when key transactions are not identified or instrumented for monitoring. To quote Nickols again, “[ ...the external world is a vital factor in the performance of all systems. The relationship between an organization and its external world is characterized by transactions -- by the exchange of outputs for inputs."]
Another benefit of taking the time to understand high level business processes from external customer perspectives is that it clarifies what monitoring views are appropriate for the organization. This has everything to do with the cross functional nature of business processes and establishing boundaries essential to understand what End-to-End really means. This is a Top-Down design activity that requires adequate time be spent up front.
Finally (and perhaps most importantly), cycles of monitoring instrumentation are improvement cycles. When we target monitoring instrumentation without the unifying thread of external customers, we can wreak havoc on the organization. For example, services are targeted where parts of the infrastructure are undergoing a server refresh or applications are under extreme pressure for a new release. When this happens, the monitoring instrumentation cycle is at odds with the organization.
So call it what you want.... Top Down, End-to-End or Outside-In.
Perspective matters.