The IT Skeptic - Comments for "Service Assurance and the pursuit of the elusive service view"

what's the word?

skeptic — Sun, 16 Oct 2011 20:08:25 +0000

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?

Service Assurance - a victim of the Moses Strategy?

ianclayton — Sun, 16 Oct 2011 19:20:03 +0000

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.

Service Assurance

guerino1 — Fri, 14 Oct 2011 10:57:22 +0000

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?

CaryKing — Thu, 13 Oct 2011 22:56:49 +0000

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

skeptic — Thu, 13 Oct 2011 20:58:21 +0000

At the same time as this post, Ivor Macfarlane* said on his IBM blog

there does seem an increasing belief that we can know everything, which I doubt is justified by any kind of objective assessment of our own lives. It is almost as if we believe that we can find out anything we want – or that we can ask an expert who will simply tell us what we need to know. In fact there are – even now –many things we do not know, and will never know. That is true in most aspects of life – from what our children get up to through to configuration management – the trick perhaps is to accept that and make the best use of what we can know. That includes realising that what we do think we know may not be 100% accurate – but that is it still useful all the same...
[G]etting on and using the data you do have might be a good mantra? All too often we seem to seek data for its own sake rather than because we see a need for it...
Maybe you can spot some places where you are spending time, money and worry tying to get ever more precise data that you don’t really expect to use.

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

Daran — Thu, 13 Oct 2011 20:54:58 +0000

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.