Service Assurance and the pursuit of the elusive service view
I learned a new (for me) buzzword recently when a journalist asked me about "Service Assurance". Sounds like a new spin on an old idea: the single view of a service. This is yet another techno-geek wet dream.
According to my source, Service Assurance
combines reporting tools across the IT spectrum so that service levels and application performance can be mapped across networks, servers, databases etc. It's meant to be a means to combine packet sniffing, app performance, etc. Vendors keep promising there is the emergence of a position called service assurance manager who will look at reporting from across the IT spectrum in one console
Sounds very like the CA definition.
As is typical, the term gets used in different ways depending on the vendor or analyst or other source (when all you have is a hammer, everything looks like service assurance). According to techTarget SA is "an all-encompassing paradigm" [barf] that "can involve quality assurance (QA), quality control (QC) and service level management (SLM)". Wikipedia takes a telco perspective, but still has that one-view-of-service uber-console meaning. So does this lovely bit of IBM vendor-speak
...a common, consolidated solution overlay where Business Service Management (BSM), Business Process Management (BPM), Business Activity Monitoring (BAM), Business Transaction Management (BTM) [APM] and Business Quality of Experience (BQE) [SQM/SLM/EUE/RUM] all come together to a provide the right information in the right context with the right scenarios [actions, decision support, etc] available to the right personas within this new, consolidated Business Assurance Center
That sounds supercalafragilistic (SCFL) Doug!
Nowadays all the vendors promise a service-level view of status in their monitoring tools, and a service entity-type in their CMDB. "Service Assurance" sounds like a reporting spin on the same crap. It runs well in a simple demo. It is too expensive to set up or manage for the majority of organisations. In general I think it is a tech geek fantasy of a magic tool solution to a very difficult problem.
We need a "cross system view" because we want to see all of a service. Any other holistic view is a solution looking for a problem - we don't need it. It's just ETF: Excessive Technical Fastidiousness - the geek need for completeness and perfection.
We want a service view for three timeframes
- Immediate for service impact analysis of an incident
- Short term for service impact analysis of a change (or request)
- Long term (say monthly) for service level reporting
All are hard. A service view is possible. No problem is insoluble with enough effort and money: the question is whether it is really worth solving in terms of the business benefits. I maintain that for 95% of organisations, a less-than-perfect solution involving "human computing" - i.e. brains - is economically optimal (In the similar case of CMDB, I call the remainder the Five Percent Club).
All three of the scenarios above are asking a question about a service. Instead of building a massive system to have all the answers on hand at all times for any possible question, let people work out the one answer they need on demand when a question is asked, using the limited monitoring and analytical tools available to them combined with knowledge, experience and intuition. That's what they do now. But instead of leaving them to muddle through with ad-hoc methods, formalise the "answering" processes and optimise them (rehearse, refine, reinforce). That's what ITSM is supposed to be about, not fancy new tools (mostly).
To automate a service-view solution for any of those three timeframes takes an enormous investment in design, technology, integration, data cleansing, and manual data entry, not just to set it up but also to keep it working. For most organisations the cost of the problem is less than the cost of the cure. And even when the cost of the problem exceeds the cure, for many sites there are more pressing and/or higher return projects to make use of the limited funds available.
Not surprisingly, the vendors don't mention that when peddling their magic bullets. And techno-geeks are blind to it when drooling over all that automation. People are insecure: they want their world controlled, predicatable, subdued by the might of machines.
Made in New Zealand 
Comments
Service Assurance
Hi,
When a tool vendor gives you a definition, there's almost always a tool spin on the definition, such as what you were give...
"Service Assurance... combines reporting tools across the IT spectrum so that service levels and application performance can be mapped across networks, servers, databases etc. It's meant to be a means to combine packet sniffing, app performance, etc. Vendors keep promising there is the emergence of a position called service assurance manager who will look at reporting from across the IT spectrum in one console."
A more generic or vendor agnostic definition that we use at IF4IT is:
Service Assurance: "The Actions, Tasks or Activities performed, using the Solutions that are in place and available, to instill a level of confidence or certainty that Service Level Agreements, Targets, Objectives, Requirements and Contracts are all being met according to the expectations of the Service Owner and other key Service Stakeholders, such as but not limited to Customers, Clients, Consumers, End Users and Sponsors."
Given this definition as a baseline, permutations can then exist for specific Service Types, such as but not limited to:
I always warn against the definitions provided by vendors since, more than often, their definitions have often been cooked up by marketing staff and bent to their sales agendas. Its these "bent" vendor definitions that only serve to confuse IT professionals and, ultimately, the industry even further.
Anyhow, I hope this adds value.
My Best,
Frank
--
Frank Guerino, Chairman
The International Foundation for Information Technology (IF4IT)
Perhaps this is just a theoretical goal?
When I was still working for vendors, as Worldwide PS Practice Manager for one and, then, later as a Product Manager at another, we worked on maturity models and scenarios that would use all the products together. We did this because, in big sales, the customers wanted to see how they might all work together.
I never saw a customer that had all of the products implemented. Let alone all the policy, processes and people to support them. I tend to think of these things as marketing theory. But, they are valuable, it seems to me, as a far-off vision of where some IT organizations may want to end up in a distant future.
I tend to think that companies would be better advised to take Teddy Roosevelt's advice, “Do what you can, with what you have, where you are.”
It seems to me that, right now, some IT organizations - especially those that aren't service provider businesses - are building a Maginot Line of tools. That are, in some cases, likely to be bypassed by their move to the cloud or outsourcing. They seem to be making the same mistake the French did with the Maginot Line, building their technology based upon their historical view of things and not the likely future reality.
Perhaps IT organizations would, in many cases, be better advised to spend their time focused on organizing around service-oriented delivery and, to some extent, assume that they will be, in the near future, wanting modular, loosely-coupled, clearly defined services. Whether they actually choose to move to cloud or outsourcing is still a question to be answered.
It seems to me at this time, however, that moving to an outside-in service-oriented organization with an investment-based budget is more likely to yield immediate benefits beyond their purchasing and implementing yet another technical tool. Their underlying assumptions about payoff periods and savings may be based upon flawed assumptions of future operations.
Ivor Macfarlane on ETF
At the same time as this post, Ivor Macfarlane* said on his IBM blog
When one of the co-authors of the ITIL CMDB reference is alerting us to the perils of Excessive Technical Fastidiousness, I'm a happy man.
* Ivor Macfarlane: You newbies look him up. Start with the authoring credits for ITIL V3 Service Transition (the original 2007 edition) and work back in time to a number of ITIL books
I think in this fight you
I think in this fight you will find the techies on your side. Usually techies prefer the native management tool for their platform and are very skeptical of any holistic tools that supposedly cover multiple technologies.
I suspect these tools are more popular with management layers that already suffer from technology overload when you show them a simple dashboard. Unfortunately implementing multiple native tools is a guarantee for sticker shock, and that gives sales weasels the opening to sell their 'integrated' software.
Service Assurance - a victim of the Moses Strategy?
WTF? Here we go again - getting our collective industry knickers in a twist over the definition, or rather redefinition by ITSMers of a term. The only connection I get to an end-to-end view of the service is as part of a testing need to make sure a 'service' works as required.
Its really quality assurance of a service type product isn't it? Why can't we in ITSM use terms that have been in common use for 50 years - especially since a service is no more than a type of product? Or perhaps this is how those who lead our industry prefer to continue this "Moses Strategy" of leading the professional clan in the wilderness for another 40 years... with the occasional trip up and down an ITIL Edition mountain for a refresh of the tablets of stone?
Whenever I read these types of threads I replace the word 'service' with 'product' - just to keep me honest and remind me where many of the answers lay. A worthwhile BS-detector method.
Needless to say, one of the agent-provocateurs here is clearly ITIL. In Edition 2011, Service Transition 4.5.4.3, ITIL discusses 'Service Quality and Assurance'. By the way, there is no glossary definition of this term. ITIL positions the term within 'Service Validation and Testing', where it meanders and fails to actually offer a crisp definition, while reminding us the assurance responsibility reaches as far north as verifying requirements in strategy and design (grabs those books but finds no distinct hand hold or reference).
So we now have a new examinable term that lacks a proper definition in ITIL and bleeds into the ITSM lexicon. Is that the purpose of loose lipping these terms in ITIL?
Others have chimed in as part of this thread quoting definitions that are easily found with an internet search, and providing us with clues to its roots and true meaning. Quality Planning and Control.... Wikipedia sort of covers it under quality assurance here. "Does it do what you expected and planned it do?". Product Management references abound with consistent and very usable definitions - any of which we could likely have adopted into ITIL/ITSM. But we didn't - and we end up with this type of thread.
what's the word?
I agree we could and should have readily adopted quality assurance terminology instead of ITIL inventing its own.
The vendors have started using the term Service Assurance to refer to production quality control (is the service working?) as well as implementation quality assurance (will the service work?) . I'm sure the quality world has distinct terms for both, but I'm laid up with flu andcant be bothered looking.
I pinched the word Assurance for my own use a few years ago as a collective term for governance-monitoring. Not is it working? but is it safe? Compliance, security, audit... What's the word for assuring the quality of management control not of operations execution?