ITIL Service Delivery Manager

Maybe I missed it, but ITIL V3 doesn't appear to have one person owning and accountable for the customer experience. I don't mean for one service, for one process, for one customer: all of it.

It has always seemed to me vital to have a Service Delivery Manager who owns the "front office" - all of the customer/user experience: Service Desk, Service Level Management, Customer Relationship, Availability. And non-ITIL functions User Field Support and User Training.

[Putting Availability here may require explanation for some readers. Service Delivery owns Availability strategy and planning. The Service Delivery Manager owns the Availability Plan; IT Operations executes on it; Service Level Management (which the SDelivM owns) measures it.
And BTW in my view Capacity is a subset of Availability - I've never understood why ITIL splits them apart.]

What do you think?
Does ITSM care if there is a central Service Delivery Manager or not?
Is the role there and I missed it?
Is Service Delivery Manager an organisational position (and hence each organisation's decision whether they have one) but not an ITSM role?

[Updated: please please read the comments. they are goldmine. If you are the typical 21st Century Digital Boy or Girl, skip straight to the answer and miss all the value]

If you found this post useful, and you are a Facebook user, please Like this blog :


Efficency of Processes


I think perhaps the point is that if you have designed an effective, efficient Service Management Delivery model with well-crafted and well-defined roles and responsibilities in Service Strategy (with the insight of the CIO and other Senior IT Management AND their backing to ensure the accountability of those responsibilities) then the role of Service Delivery Manager should be wholly redundant and unnecessary.


Missing role

Somebody responsible should manage business relations and ITIL does not decribe that role. This lack is a elephant (Pink?) size hole in the whole framework and alone quite sufficient reason to leave ITIL books alone. (FakeITIL has described several alternative uses for the books on Twitter;-)

How can you manage a service lifecycle without sales/business relationship management? In a very small and simple environment the IT manager can take the role but in most cases you need several people to take care of different customers and it is not the CIO's job. This Service Delivery Manager could handle business relationships in an internal shop. An external service provider need both sales and delivery management.



While I agree that BRM is an important omission in the books, it wasn't the role I am describing.

I've seen the term Service Delivery Manager used for a BRM so perhaps I'm causing the confusion. Note that ITIL talks about multiple BRMs and SS p67 states that they are synonyms for Account Managers.

Somebody should sit above the BRMs and the Service Desk and the field support and service level reporting and all the channels that touch the customers and users, and OWN that experience. If you don't have that very senior role I think it is harder to be customer focused or outside-in.

Craig wrote that one needs

Craig wrote that one needs "an effective, efficient Service Management Delivery model with well-crafted and well-defined roles and responsibilities" and Rob writes "Somebody should sit above the BRMs and the Service Desk and the field support and service level reporting". Yes, both are right but ITIL will not tell you what these roles and processes are and how they interact.

As these roles, functions and processes are necessary, people need to make their own definitions. What is best practise in this area?


PS I will tell mine later but now I have to go.

My best practise

All service can be either service or customer oriented. A service oriented unit provides a portfolio of services to various customers. A customer oriented unit has a number of customers to whom it provides a variety of services. Of course there are technology oriented IT units that provide technology their own company but let's leave them out here.

The role Rob descibes above is a Director of Customer Service (USMBOK uses the term Service Fulfillment Manager). I have created such roles as a consultant and I believe it is a good practice. This role/function is in charge of Service Desk, Service Level Management and Business Relationship Management for IT services. That role fits best a customer oriented unit, such as an internal IT unit that provides specific services to different departments. ISO 20000 gives some guidance on the process/function of BRM. BRM works at one level higher than SLM. SLM reports to BRM and BRM reviews the service and discusses needs for changes is SLA's with the customer. BRM is also in charge of complaints and customer satisfaction.

A serive oriented company offers more or less standardized services to a group of customers. This a typically an external service provider and here sales and customer service are different functions. Service Delivery management would be in charge of a specific service. There might be a need to have BRM's to handle key customers. There is so much variety in the types of business that it quite difficult to give any general advice. I do not think it is a good idea to model an internal IT unit as service oriented. It can be done but in many cases there are too many services and many of the services have only one customer.

I think that is also a mistake to bring organizational models to a book of best practices. Internal and external IT services are quite different and ITIL is never clear on what it is talking about. My guess is that the writers of the Service Operation book studied mainly big US corporations that had huge internal IT Operations units. It has a distinct mainframe aura, some pages smell of dead dinosaurus ;-)


the Perseid meteors or the alignment of the planets

I can't decide whether it is the Perseid meteors or the alignment of the planets that has kicked the commenting on this blog up a notch lately. it must be one or the other because it is nothing I've done and it is consistent across regular contributors like Aale, newcomers I know like Hoop, newcomers I don't like David Zaucha, and anonymous contributors like ... er ... Visitor.

P.S. Clearly as much as the mysterious influence is lifting the intellectual standard around here, it is sucking the last vestiges of sentient consciousness out of the religious right. Apparently now Einstein's relativity joins evolution as anti-biblical and the work of Satan, or of liberals which is worse. Some days I am very afraid for 100 millennia of human intellectual advancement.


Aale - thanks for the tip. Just checked out FakeITIL - very funny.


Bottom of page 7...

There is one picture

BRM is like the elusive proactive problem management which is mentioned in the glossary but does not exist. BRM is in the glossary but if you search the strategy book, you will find that there is a picture on page 221 where there is a box for BRM. That is all. It is clear that it should have been a process/function but the guys who wrote the SS book missed it.


Not quite

SS book on BRM: Pages 67, 137 - 138, 221.

There is also writeup in the Key Element Guide of the SS book.

Inside Out

Well yes there are four passing mentions of the BRM in the SS book. Saying "137-138" might give readers the impression there are two full pages describing the role, which there aren't. there's no description of the role.

And there is no description of the Business relationship function/process/whatever which the BRMs presumably belong to. I agree with Aale - it's hard to think of am more important function to leave out. Classic example of ITIL's "Inside Out" thinking

Quite Limited, Yes

I see your point.

I did think it was more than simply the glossary entries, but I don't have my books with me right now, and can't look it up, so I will have to conceed that for the time being.
Even with the information I thought was available, however, it is still quite a limited treatment.

I do think people often complain about ITIL's lack of coverage for this process or that role - and much of it I have to say that I agree it is validly outside the scope of ITIL. When I hear someone cast criticism about lack of coverage for their pet process in one breath and then complain about how unweildly large ITIL is in the next, I generally just stop listening altogether. It is, after all, a framework built from collected practices and intended to be a fairly high point of view - not a prescriptive, all encompassing philosophy intended to guide IT through the minutiae of all sundry aspects of ITSM.

That said, BRM is one of the processes (along with Knowledge Management - _my_ pet process) in which it is, in my view, a justly applied criticism.

(I had to add the _ in my name, because apparently my membership has gone through, but I haven't received the email yet to set my password)


The "Business Relationship Manager" role manages the business relationship.

Virtual Desktop Infrastructure needs a consumer-focused SDM

In the Cisco-delivered VDI solutions we advocate, encourage and define the role of a Service Delivery Manager for a VDI Solution that is delivery Desktop as a Service.

This role does not own any technology layers but consumes them: take networks, as an example - the network team delivers a defined network service for remote desktops to connect over. The VDI Service Delivery Manager has visibility of data for that service, understands "what is normal?" and can influence the network team much like a paying customer can influence their provider.

In effect, this SDM is an intermediary service champion on behalf of the desktop customers: while the SDM is paid for and lives in the IT world, he or she is absolutely on the side of the users.

This goes to show that although folks think I'm anti-ITIL in fact I spend more of my time gluing ITSM folks to technology solutions which, IMHO, is far better than standing around bitching about the gap between ITSM and Tech and wasting more time, money etc.

Let's raise a glass to putting the Technology back in ITSM and ITIL!



I'll be honest I'm torn on this whole issue.

First of all what a lot of people on the Apps Support side seem to forget, or simply don't know, is that a lot of the early thinking around ITIL was driven by those with an Apps Support and Project Development background, especially by those of us with a very guilty conscience. We knew we were throwing things over the fence with no thought as to how they would be supported in the long term, and wanted to close that gap. On the other hand we "knew" we were more sophisticated in our thinking than the "tape monkeys" in Ops.

Having been exposed to some leading edge solutions in the last few years my current thinking is:

a)Functionality isn't worth a d**n if you can't access the application in the first place
b)But it is application functionality that adds value to the business. Most infrastructure is, or should be, a commodity deliverable that enables the value add.
c)A lot of issues arise because the "customers" involved in project delivery aren't the "customers" for the day to day service
d) Most of us don't have a clue what we are talking about when we say "service" Just look at most SLAs.
e)All roads lead to a very complex point where technical, infrastructure and functional terms get translated into service talk. This point used to be called service management or service delivery, but increasinlgy is being called service integration. I think Steve captures that view nicely.
f) Has anybody noticed we all report to the CIO? Just saying.

James Finister

changing world

"it is application functionality that adds value to the business" In one sense, no. In-house bespoke application functionality is a time and money drag on the business, and often gilds the lily.

Company after company is realising that an 80% fit to idealised requirements is good enough and the organisation can bend to the rest. trying to go the last 20% just pisses money.

In the past that realisation was already starting to emerge in organisations who still retained an in-house development capability,
but it has really been kicked on first by COTS (especially financials and ERP - the world has learned the hard lesson DON'T CUSTOMISE) and more recently by SaaS.

Applications can be 80% just good enough so long as they work reliably. Service management is emergent and application development is in decline. It's reality.

And while I'm at it, the tape monkeys are in decline too (Hey! I started out loading tapes in a goldfish bowl). It is a more recent trend but the Cloud will make infrastrucutre and operations decline in signifigance too.

What will be left to hold it together? service, governance and assurance. You read it here first

Boys with Toys

Sure Skep, but it won't happen.

Reality is if we took away Ego and Agenda this thread and most blogs would be widdled down to 3 words: "Let's do it" (yeah I realize technically that's 4)

Its about better business outcomes. It killed me today sitting in a meeting hearing from the VP of Client Services that he was going to be spending 4 days on billing because our systems are not integrated. 3 COTS applications, and 2 SaaS but not a single one has an API to handle financial metrics and no one considered this when they bought these toys. (yes, I beleive in blaming the predecessor publicly)

So could he be reviewing SLA's, targets, warranties, surveys to improve service, governance and assurnace? He could... but he won't. Neither will I this week.

CIO or not, ideas and visions are easy to have, but difficult to carry forward.

enterprise architecture

Nothing is easy. IT enterprise architecture will be as important as ever (and is currently as neglected as ever, as your case demonstrates). I think I will add EA as another aspect of assurance.

I didn't say the new toys are any better at delivering than the old toys. And i certainly didn't advise rushing to buy the fad. But it will happen in time, for the simple reason that COTS and SaaS and the Cloud are cheaper... even when done properly.

Late to the party

Wished I had been free to join earlier. I just had this same conversation with a customer as they were trying to wrap their heads around a service. They initially viewed a Service as something different from an Application (they can't mix right?!). So they had Application Development, Project Management, taking out the garbage, as Services and ignored the Applications.

We then spent an hour reshaping their view that an Application can be defined as the perceived Service, but that when you define the Service portion it includes all the underlying infrastructure, people, processes, etc... necessary to manage that application as a service. When it is named and defined as an Application, we're now just talking about the stovepipe of the app itself and the related activities, ownership, quality, and development, etc... that needs to be individually considered in that specific focus.

I like Ian's even more expanded view and context (earlier in the comments) that a Service has to focus not just on all the related components, but also Marketing Management and the like. It's gotta be both inside out and outside in... Good stuff.



The application is no more the service than the server is. it is the information IN the application(s) that is the service, or more precisely the stewardship of that information: housing it, protecting it, making it available to the right people, providing facilities to maintain it (i.e the application)...

I think there are about four categories of IT service:

Information (one for each "kind" of information, NOT one for each type of consumer of it: eg financial data not finance department. Financial data may be delivered by or kept in multiple applications, and some of it may not be in finance-specific applications at all (e.g. spreadsheet, EDW), and the applications may be replaced by others over time, it's all one service)

Professional services, i.e. expertise

Technical services (making geeky stuff available to the users, NOT the geeky stuff IT does in-house)

Hosting (for those cases where the customer treats us as a low-level infrastructure provider. Ever here it is not one app per service, it is one type of app, where "type" means variations in how they are hosted)

Is information in an application a service?

Hi Skep,

You state "The application is no more the service than the server is. it is the information IN the application(s) that is the service, or more precisely the stewardship of that information: housing it, protecting it, making it available to the right people, providing facilities to maintain it (i.e the application)..."

To me this sounds rather weird or at least confusing. Information and data are mixed up or used in a different way than we in the Netherlands do, I guess.

There is no information in an application, just data. Only thanks to building in the correct functionality, an application is able to transform the data into the information a customer wants or needs. Developing, maintaining and enhancing an application that can provide the proper information from the data can be seen as a service (from the application management (AM) department - AM as defined by ASL).
Making sure that the right data are stored in the databases is no service. That is the responsibility of the users (the business organization) themselves.
Taking care of housing, protecting, and making data available to the right people and providing facilities to maintain the application can be seen as services. Services of the infrastructure management department and not of the application management department of course.

Services are Outputs - Second that

Skep's analogy of a service being what comes out of the pipe is spot on. I actually like it and will use it (with permission of course ;) )

On the ServiceSphere podcast the other day, I heard the analogy of Google apps or Quickbooks Online as a service. While they are called "apps" and app appears in the name, whoever uses them does not know anything about the actual application, where they hosted, protected, etc - it's just a service that is free (google apps) or paid for (Quickbooks online).

While ITIL has changed the definition of what a service is through its iterations, I have always preferred this pre-ITIL v2 definition of what a service is;

A Service is a Value Exchange Process across an Organization or a Public Interface.
- “Public Interface” = a boundary of authority; different reporting structure
- “Exchange” = formal and measurable, payment in exchange for value

A Process is any set of steps that are performed with the intent of satisfying a purpose or achieving a goal.

I have always argued (and people have argued back) that a service is ultimately the output of an "overall" business process. One could argue "Hosted MS Exchange" is a service and is just software (no process). I would argue there is a process in place to plan it, sell it, promote it, provide it and support it ~ processes.

John M. Clark

My point exactly

"While they are called "apps" and app appears in the name"

My point exactly. In the dialect of major parts of the IT community, "applications" are "services." Perhaps not all apps are services, and certainly not all services are apps.

But to attempt to say that "apps are never services" is like trying to convince 1950s hipsters that "bad" never means "good." It's a linguistic thing, is all I have been trying to point out.

Software/protocols/stacks/heaps/source vs. object code/binaries/components/interfaces/ports/sockets/etc, those I can agree are all technical terms underlying the higher level abstractions.

I asked a friend, a very well established developer in town, what he thought of "app versus service." His mind went nowhere near ITSM. It went instead to the current ferocious debate in the software engineering community, whether applications would be replaced by services in the SOA (service oriented architecture) sense.

I don't think there will be widespread adoption of the term "IT service" in the sense discussed here until SOA's spin on things is also accommodated. And in general, where ITSM says that "IT services are composed of applications," SOA says that "applications decompose into services."

Now, square that circle...

Two must reads from the esteemed Martin Fowler, a man as skeptical as our host:

Charles T. Betz


As Martin points out, there are plenty of other terms destroyed by IT's terminological debasement. I'd add "management" and "governance" to the list. We work with it.

There is no circle to square just because "service" is used in utterly different contexts to mean utterly different things. Should I be concerned that tennis uses it for something different as well? Should an old-time jailer be concerned because jail cells are made of wood and wood is made of cells? Because my factory is full of plant do I need a botanist?

English already has far more words than any other language - I guess we're not allowed to invent too many more. We have to make do with duplicate meanings.

Software developers can call their "services" fish for all I care - they have no more relation to the services we are discussing here than disk drives or ethernet cables do.

Nor do applications.

assertion <> truth

You can assert that "services are not apps" all you want. But, to return to the original question, it does not change the fact that I know many app managers who perform all the duties of an ITSM service manager, without using the term "service."

I have met other app managers whose orientation *was* more technical, and I have served in organizations where production services included Level 2 app management. I think that some of the viewpoint here is from folks whose experience may be limited to that older model.

But in other organizational models I have direct experience with, the app manager is the general contractor to the business partner and when they are in that role, they own service delivery. They negotiate the service levels, manage both a "new features" pipeline as well as "lights on" availability, subcontract their infrastructure needs, and so on. I think this is actually a more successful model, more consistent with Lean and related philosophy.

You can say that this "shouldn't be," that it's "not consistent with ITIL," or other forms of value judgment. But I swear to you the organizational model and linguistic usage is as I have reported.

I posted this six years and several organizations ago. At least in my neck of the woods, it has stood the test of time:

Charles T. Betz


I'm enjoying this, and it's very hard to disagree with any of the points made; a lot of it does come down to how we use the terms.

Both 'application' and 'service' are used too frequently and too loosely to be meaningful. Both are composite concepts anyway, and only useful if they are defined at the right level for the intended audience. Once upon a time, we talked to our customers about applications, but the trend has been to start speaking in terms of services, which is natural considering the increased focus on IT cost and the continuing commoditization of traditional IT stuff. Our business customers used to have to (pay IT to) buy or build applications that delivered desired results, now they have increasing opportunities to have somebody else perform services for them that deliver those same results, which forces internal IT to adopt a similar dialect.... even when what lies under the covers in either case are still... applications.

I tend to think that in the past these two concepts were not so different because IT departments were smaller, applications were larger and automated relatively static business processes, and external alternatives were few and far between. Everything is more dynamic now, and to keep pace development groups strive for SOA style systems with loosely coupled components. The resulting "applications" (that's what most folks here call them, anyway) are way too fine grained to be considered services in the ITSM sense or from a business customer perspective. My practical experience is that aside from a small handful of UI type systems, the things we treat as applications today within IT are too far removed from the end customer. Developers also have a quirky habit of renaming applications every time they add significant functionality or adopt a new technology within the system, and from a naming standpoint often fail to distinguish between projects and applications.

Services need to be about hiding the gory details, not just drawing better boundaries and more well defined API's around them. Just as a solution architect helps figure out how to glue all of the little technology pieces together to accomplish a higher level goal, someone acting in a product manager type of role is necessary to package this stuff up, describe it, and price it for customers to be able to make decisions.

No doubt, applications really do form the core of a service by providing the basic utility a customer is looking for. But, at an enterprise level, almost any single named application usually needs to be combined with other stuff (both other applications [additional utility] and some non-application [warranty] stuff like 24x7 support and Disaster Recovery) before it can be properly positioned and priced as a service.

Anyhow, I really like the pre-V2 definition for service that John Clark mentioned above ("A Service is a Value Exchange Process across an Organization or a Public Interface") earlier. It all depends on where that public interface is drawn. I think for most of us in internal IT, and certainly for a service catalog, the primary boundary is between IT and other organizational units within the same enterprise. Once we have that one well established, we can work on the less formal boundaries that exist within the IT unit itself. And, at that point maybe we can start to square the circle Charles mentioned above...


If the business wishes to have separate service providers for information/application services and technical/infrastructure services than good on them.

I agree that in that case - which i have never encountered - then the Application Manager is indeed a service role by another name.

We shall have to wait and see which terminology is emergent as the generally accepted one.

or perhaps that question is already answered...

Different service providers

In the Netherlands most of the big companies have other service providers for information/application services than for the technical/infrastructure services.

that way lies madness

MM, if you are refering to external service providers, I don't think that's the point. Who is responsible within the company for overall provision of information technology? And is that provision managed as a service? (Almost always these days, surely)

So the person who owns provision of information technology services to the organisation is providing what? services or applications?

If the organisation is maintaining distinct relationships with application providers and technology providers (internal or external) without overall holistic service management tying them together, then that way lies madness I say.

External service providers

I think that this is a true issue (I hope you understand what I mean, I am not native English of course).

In my environment we always almost automatically think of service providers as being external, even when they are an internal department of the business organization they should act like the external ones.
Therefore ISO 38500 and ITIL, in our opinion, mess things up. They don't make the same differentiation between supply and demand as we do. Tasks of the service provider and the business (service demand) are mixed up. That makes the world a lot more confusing.

Within the company you can hardly make anyone responsible for the provision of all IT services. You can make someone (usually more than one) responsible for the demand of the IT services. That is, on the business side.
Of course you can have a (small or larger) internal IT department that only buys services from external providers and is reponsible for the direction (? in Dutch regie) of all those IT providers. I would say that this department provides services to the business. Applications are a part of those services. As are the network, the PC's, the mainframes, the OS, the people on the service desk, the operators, the application maintainers, etc.

This internal department will only be responsible for certain aspects of the overall service provision. Not for all the aspects that are mentioned in ISO 38500 or ITIL.

I see the madness you fear everywhere :)

By the way : I wonder how I can make certain words bold.


The world you describe is an alien one. In my world, some service desks are outsourced (and big call-cetres are moving to India or the 'Pines). Some datacentres and operations are outsourced, on the "one great big lump to EDS" model or as bits like the facility or servers or storage; some application maintenance and/or development is outsourced. But very seldom all of IT. I can think of very very few companies with the "vestigal" IT department you describe. Though there are more who aspire to it, I would say the majority don't. I'd go so far as to say there's a counter-movement to bring it back in-house. Maybe we're just backward in New Zealand...

Information about formatting comments is here (it is under "Input Format" when you enter a comment).

Briefly, all users can use the HTML tags: ul ol li blockquote i b u strike

totally agree

Skep & I may disagree as to terminology, but I think we are agreed on semantics. For it to be a "service," or an "application service," all underlying delivery must be hidden from the end consumer.

Charles T. Betz

I don't think they want it.

After a long, hot (July was the warmest month in Finland during the 100+ years they have been measuring) vacation I see that there has been a lot of activity here. Actually a lot more than on the LinkedIn side (or then I might have changed my settings back in June).

I have seen the situation which Charles describes very well. I do not think this is a case of customers wanting separate providers for apps and infra, it is the IT people who force it. In ITIL V3 application management is hidden as a function within SO which is silly as application management is often close to business relationship management. App people talk with business and try to translate the needs to the infra.

Application and infra people have never been close. Why? I think it it is just human nature. When we still had communists in this country, they were split in two and were each other's most hated enemies. Factory management had to work with both trying to keep peace. The situation was not good for the communists and it is not good for IT. Breaking this separation could be one of the reasons behind Apples success.


again, exactly the point

"App people talk with business and try to translate the needs to the infra."

They facilitate the application of computing technology to the business need (again, the etymology of "application.") In doing so, they position themselves front and center as the primary deliverers of IT service, by whatever name.

Why are sections of the ITSM community so reluctant to see this?

Charles T. Betz


(a) That's not how it always works. the people who broker with the business may sometimes be application people - if you say so - but they are frequently from IT management, projects, customer relations, or service management
(b) unless you have a VERY wide definition of applications, then not every service is based on an application. You seem to be redefining Application to mean "IT" so don't go accusing ITIL of land-grabs :)
(c) application-led requirements and design have a poor track record for designing in operational readiness and ongoing sustenance. the focus is on function at the cost of non-functional.
(d) what you describe might be the primary DESIGNERS of service, but they sure as hell don't stand front and centre in the ongoing DELIVERY of service - see (c)

so many confusions

"the people who broker with the business may sometimes be application people - if you say so - but they are frequently from IT management, projects, customer relations, or service management"

This statement is incoherent, when considered in the orgs I have seen.

IT orgs in my experience are typically roughly half and half infrastructure vs. apps. So, "application people" are from "IT management." Not an either/or. There are hierarchies on both sides, rolling up to EVPs for systems on the app side (or, in some cases, LOB CIOs reporting to the enterprise CIO).

Application delivery organizations often maintain a stable of in house project managers. So, "projects" often come from "applications." (Other projects, almost all non-business-facing, may be run by the infrastructure team.)

"Customer relations" people are usually aligned with application delivery organizations, because the "customer" in this context is a business partner with some functional requirements.

The lack of attention to NFRs (non functional requirements) on the part of application projects is a known issue and I won't argue it. But it *never* in my experience has resulted in infrastructure service folks taking a lead in interacting with business partners. At best, you get a seasoned project manager who knows to engage architecture & infrastructure early and takes their requirements seriously. Bad project managers try to run and hide from architects & infrastructure folks.

We're almost getting into comparative org structure here.

Charles T. Betz


You seem to be assuming anything not-Applications is infrastructure i use the word too for the Operations/Delivery side of the shop, who do look after infrastructure as one part of their job and even get called that at times. I have done in this thread I think, but Operations or Production or Delivery are better terms.

in fact service management is not part of either
though it does tend to rise out of the Operations side

And of course the model is more complex: projects, customer relations etc are just as likely to not be part of EITHER Applications OR Operations, just like Service. I've seen PMOs indep of both, or even outside IT, as i'm sure you have

services cross an organisational boundary

I love that old service definition. This drawing is from my recent Numara Service Catalogue webinar:

as was this one too...

[of course Numara tarted them up a bit for the webinar - these are my originals]

Service Catalogue defines the outputs across an organisational boundary. Specify the boundary before you specify the services. if they don't cross the boundary they aren't a service of this organisational unit so don't catalogue them (in this catalogue). How the hell has the industry so thoroughly lost sight of that such that 75% don't get it any more? The consultant-babble of the new definition may have something to do with it, as does the hopeless ambiguity of Service Design on this subject. ITIL should lay down simple first principles along with all the waffle. i think it is Charles Betz who wants to reduce Service Management to fundamental axioms?? A fine ideal.

The stuff that "comes out of the pipe"

A service is an output of the service provider and a delivery of value paid for by the customer.

the application is not the value, the information is. The stuff that "comes out of the pipe" is information (or expertise, or cool technical stuff, depending on the type of service). yes the application provides meaning to the data and tools to manipulate the information. that is why it IS one of the components of the information service. So too is data management, network, security, servers ....

Yes, developing and maintaining application software is a service in some organisations - it is a professional service, an expertise. So too is acquiring and implementing packages. or managing SaaS service providers.


So Jim,

What you are saying is ITSM is like an Oger, it has layers. (like and Onion, which is also like Parfait. - but I digress) and manages the swamp.

We need to deal with each layer in it's own right whether its:
End- Users - Business Services - Business Logic - Applications - Operating Systems - Servers - Networks - Data Center

We have to remember that there are consumers of the service provided (customer-paying or not) , sponsers of the service (fund and request/reject), service managers (govern and control), and service providers (strategize, design, build, deploy, maintain).

Without considering all these players, and watching each layer for the quality of service provided (fault, availability, performance, capacity, security, change) we will have business failure.

I'll agree with that. I also agree that the Customer is not the Service Sponser. Customer (or client) by definition (and not ITIL's definition) can be terminated, as can the supplier. Therefore IT departments who subscribe to this terminology of the business as the "Customer" and wonder why the other business units feel they are disconnected get what they ask for. Act like a tourist and you'll be treated like a tourist.

Btw, I don't report the CIO. :)


I sure don't report to you either!



I could go on at length about onions, especially if problem management is involved. But here I think something more complex is involved. We need to de-construct processes, capabilities, functions and relationships and then remap them onto an organisational structure. Until about a year ago I thought we could do, and did do, that OK. Now I'm not so sure. For instance can you manage, in the broadest sense, a commodity service like email in the same way you can manage an accounts payable service? I suspect not, on many levels.

Should I have said we all report to a CxO level? That would give me another chance to plug ISO 38500 as well.

James Finister


Should I add this whole topic sounds like it should be the subject of a ITSM Weekly Podcast special?

James Finister

Service or Application? -Same difference! - Let’s talk.... Value

A lively debate has been going on about whether using the term applications instead of services is an acceptable service management practice. Many may say we have reached the “How many angels can dance on the head of a pin?” stage here. But if service management is about managing services, would it not make sense to have some common understanding what these services are? More at

Reality is that neither Service nor Application are very well defined concepts. Most people agree they are related and often refer to the same thing. Development will call what they build an application while operations calls the same thing a service when they run it. But what is this “thing”?

The first question we face is granularity: Is Office the application or is Excel? And is the shared spell checker part of the application or not. And if we use the translation function, is that part of the application? ( while in reality it is a service running at either Microsoft’s or Google’s website?). And is the online training part of the application or is that only part of the service? Same for support, automatic patches and updates?

But more important than the answers to the above, is the fact that in reality nobody cares! Unless we are still trying to write down (defend) what we do, it makes no difference to anyone.

Is there an alternative that will make people care? I think there is. See

Applications and services and ASL

Charles is right when he says that ASL was (amongst other things) created because ITIL ignored the importance of applications and application management.

I think many discussions, and this one as well, are hampered because people have their own idea by the meaning of the terms. For instance: when ITIL speaks about application management this does not include all the activities for maintaining, enhancing and renovating applications. In ASL - which is created exclusively for application management - maintenance, enhancement and renovation of applications forms the major part of application management (well over 50% of all the operational, tactical, managerial and strategic activities necessary to make applications do what they should do).

In ASL we define applications on the one hand and services on the other. Applications include the software, the design, the (set-up of the) databases, the documentation. The term application does not include the infrastructure that is necessary to make it do its work.
The (application) services included in ASL are similar to the services that are recognized by ITIL. But only focussed on the role of the applications within the service. For instance: the response times are far too high - then ASL says (e.g.) investigate the SQL-queries or the indices on the database. The role the quality of an application has on the service seems to be underestimated by people that have worked in an infrastructure field only.

Why is a focus on applications that important and why is a focus on services only not sufficient? Because the most important thing for a customer is: functionality. Does this application provide me with the proper information. Only the next step is: do I get the information timely etc. If the quality of the product is poor and your services are of the highest standard the customer will be dissatisfied.

In ITIL an application is considered as (just) one of the ingredients of a service. That is far too little.

In an environment where mostly customizes applications are used by the customer it is very wise to let the application manager lead the service management team. If the customer uses COTS only, then it is most obvious that the service manager comes from the infrastructure department. Bill Gates does not have the time to manage all the Microsoft related services, of course. :)

Does ASL define "application" anywhere?

I just spent some time going through ASL and don't see that it defines "application." Am I missing something?

Charles T. Betz

Application according to ASL

You are right that the basic books of ASL do not contain a glossary of terms. This is the definition (to be found e.g. in the Dutch Standard NEN 3434):

automated part of an information system, consisting of application software, application-related data, the (physical) storage structures in which these data are embedded and the corresponding documentation

Application without service is a chocolate teapot

Putting aside for one moment that I like both chocolate and tea (What am I? My wife?) but this last post reminded me of that bit in the ITIL books about the drill. You know the 'people don't buy a drill; they buy a hole' thing. A simple point but one worth revisiting for some I think.
This also reminded me of a situation at work recently. Our department had SharePoint 'sold' to us. It's now the corporate standard which we are supposed to use for document publishing and sharing. We are supposed to use it for it's version history, controls and history tools. Well I learnt that a hidden feature in SharePoint designed to stop the system slowing down automatically deletes workflow history on documents (including who approved what document and when) after 60 days.
The application management view on this was: We've told you why it does this, it's a feature and no you can't have your lost data back.
The service management view is: This service we sold you doesn't deliver the utility that we promised and we will get the data back (incident) and look at options for fixing it (problem).

I don't take kindly to the application management view at all.

key role definition

Is there a SDM role defined anywhere ?? I've not seen it in ITIL ....ISO uses the Service Level manager and the Business Relationship Manager as the key point of focus for the business. I don't believe the SDM role is within COBIT either ... Nor SFIA.......

customer focused

I don't think it is defined in any of those places. USMBOK also separates support from customer relationship and from SLM.

It seems to me odd that we talk about being customer focused and we don't have someone accountable for the whole customer experience. Without it, buck passing and finger pointing is too easy with accountability spread across silos.

Common frameworks are INSIDE-OUT


Its common for commonly used 'public frameworks' to gloss over how service management methods actually connect with the customer and their experience of using products and services. This is likely because they are generally written from an inside-out perspective by folks who have no practical training and experience in Marketing Management - where customer centricity lives.

The USMBOK has an entire job role and knowledge domain 'Service Customer Management' that includes specific skillsets (knowledge areas) that address the customer interface and gathers key elements of the 'customer experience'. The 2010 version of the USMBOK included the following terms: moments of truth, touchpoints, interactions, service encounter, and overlayed these over the existing service request pathway and value and expectation equations, to provide a comprehensive set of concepts and methods for customer experience management. It also respects the two discrete skills of service (product) marketing and service planning that cooperate to ensure the experience is counted and designed.

Articles I have subsequently posted at my blog ( speak further to the gaps in traditional frameworks, this article is specific to that concern "Service Management's Moment of Truth"

I agree - it is odd that the frameworks most commonly used and referenced as part of an (IT) Service Management explanation - miss completely the fundamental need to drive every decision with the customer experience in mind....

Application managers...

So, if "front end" means user experience, and "back end" means infrastructure, I would think that your director/EVP of application management would be the de facto SLM.

Usual ITIL blind spot here if folks are thinking that app teams just cut code. There are other models. When the app team writes and supports the running code, they are the front end of your service management team.

Charles T. Betz

blind spot

Usual development blind spot here. App developers/maintainers should stay in the back room where they belong - we'll chuck in meat and pull out code just as we always did :) Applications are not the sum total of service delivered, just a subset. Email? Secure remote access? Desktop device build and install? New user provisioning? Cabling a new office? etc etc how about SaaS applications? Apps installed and managed by a 3rd party provider?

In fact, apps aren't even a subset of services - they are some of the component CIs one layer below services.

I've never met an app manager who cared much about service levels, request fulfillment, or security.

"Application," in the canon

"Email? Secure remote access? Desktop device build and install? New user provisioning? Cabling a new office? "

I have never argued that all IT services are application services. And these examples you name are not the SLAs that command executive attention. (Those are a bit fine grained; email, remote & desktop would all roll into new user provisioning in cases I am familiar with.)

But here is the rub: "apps aren't even a subset of services - they are some of the component CIs one layer below services."

Who says? When was this written into law? Show me the data model... the normative semantic standard expressed with even the tinest bit of rigor.

ITIL says (consistent with your view): "From the third perspective, IT is a category of services utilized by business. They are typically IT applications and infrastructure that are packaged and offered as services by internal IT organizations or external service providers."

But what is an "application"? I've been looking for a while and I think I may have succeeded in my quest for the authoritative first use of the term. The first article published in Communications of the ACM, Volume I, Issue 1, was "General Principles of Coding, with Application to the Eniac" by John von Neumann. Another in the same issue (by James McPherson) was entitled "Census Applications of High-Speed Computing Machines."

Thus, computing hardware is applied to business problems. Or coding practice is applied to hardware. In either case, an application *is* the combination of hardware and software. Not software alone. The statement "applications and infrastructure" is redundant; "application" implies infrastructure. That is the fundamental misunderstanding that has plagued us in these discussions.

And if "application" already semantically bundles computing instructions and their hardware, why track two concepts? Were "applications" of computing hardware ever *not* services themselves? Leaner and simpler to just track one concept, and allows more constructive engagement between app teams & SLM.

Would Turing or von Neumann have embraced a "service" concept additional to the language they used at the time? If it is truly a necessary construct, why did they not think of it? I am not arguing against progress, but I think the semantic foundations of the term "IT service" need some skeptical review. Where is the peer reviewed paper in a top tier journal (nothing less will suffice) arguing for the establishment of this as a term of art in the world of computing?

I continue to be reminded of the well known quote, "Any problem in computer science can be solved by adding another layer of indirection." Is that fundamentally why the concept of "IT Service" as subsuming "Application" arose? One should always look skeptically at any such additional complexity.

On another front - if one subscribes to Lean philosophy, the functional "keep them in their silo" mentality you're advocating (tongue in cheek I hope) is going by the wayside, and it is *not* unreasonable to expect app teams to play a much stronger ongoing service role (as in fact they do in all the large shops I am acquainted with).

If we need to synthesize a higher level service out of multiple apps, in that case the challenge back to the app team is "why are you being so granular in your tracking."

As far as I can tell, there remain significant unresolved issues in the relationship of individual application services to the concept of service catalog. Despite half a decade of talk, mostly what I see in case studies of service catalogs and portfolios is the commodity trivialities. Or generic abstractions like "hosting service" that only are invoked on the initial build of an application.

The definitive debate between Troy DuMoulin & me is here:

See also

You yourself have characterized ITIL (esp v3) as a bit of a "land grab." In my view, it is failing in its attempt to rationalize the most valuable parts of enterprise IT (the application portfolio) into its universe of discourse, and this can be seen in the ongoing lack of interest in ITIL by application teams, who will continue to command the heights of the most critical relationships with business partners. Proprietary business rules, specialized semantic structures, finely tuned algorithms, polished and compelling user interfaces -- those are the crown jewels of IT value. Not Change and Incident Management.

Charles T. Betz

Not as per ITIL!


It is an interesting view: The statement "applications and infrastructure" is redundant; "application" implies infrastructure.

How ever, I dont think ITIL takes it that way -

Just to illustrate that, look at the functions defined by ITIL V3 : Technical management and Application Management.

As per ITIL (Service Operation) , : " Technical Management refers to the groups, departments, or teams that provide technical expertise and overall management of the IT Infrastructure."
and they go on to: " Application Management is responsible for managing applications throughout their lifecycle."

and if you are not convinced on that, ITIL also says: " Application Management is to applications what Technical Management is to the IT Infrastructure."

Vinod Agrasala

Hmm. ITIL versus the computer science canon.

You're quoting ITIL. I am quoting the first issue of Communications of the Association for Computing Machinery, the premier global professional organization in computing.

Which came first? Has more influence on our field?

Charles T. Betz

Wide usage

Frankly speaking, don't see a real value on 'which came first'. Would go for which is more accepted or adopted in the Industry.

Pardon my ignorance, but I don't think that the journal entry that you quoted has a greater, or wider influence in the IT Service industry today, than ITIL.

I myself dont believe that some of the concepts in ITIL are not really a industry-wide used 'good practices' (including term 'incident' - before ITIL started introducing that-, CMDB/CMS, SKMS etc.)

But, in this context, the way ITIL treats the terms 'Application' and 'Infrastructure' seems to be the way it is widely used in the industry today. (Check how much a typical 'application manager' knows about infrastructure part!)

And the term 'Service' also has been widely adopted to represent the wholistic view (including Application, Infrastructure and probably information) that you have mentioned about - Don't see a real reason to change that interpretation.

Hence quoted ITIL.

Vinod Agrasala

Adoption may not be as widespread as you think

There are implications to what you say. The implication that has concerned me for years is the idea that applications are less than services. I know too many application managers who *are* fully conversant with infrastructure, service levels, and operations to accept this. I don't believe the ITIL terminology is accepted by application managers, and I have broad connections with large scale app managers in quite a few Fortune 500 companies.

And I *do* believe that application managers would *need* to accept this terminology for it to ultimately succeed. Otherwise, ITIL is a phenomenon limited to the less important parts of IT management.

When you say "check how much an application manager knows about infrastructure" it's like a masonry subcontractor grumbling that the general contractor doesn't "really know" about concrete. The app manager is like the general contractor; the infrastructure is only needed because there is an application, and the app manager is the one in charge of driving its specification and acquisition. Some domain expertise may be required to correctly size the system, but at the end of the day it's the development team that determines what is being built, what is computationally possible, and exactly what the value proposition is for it. Service levels are an attribute of the application. But the application itself *is* the service.

See Application Services Library which was created precisely because ITIL does not address Application Management well. Skeptic has blogged about the ongoing "living together in separate rooms" dance between ITIL & ASL.

Charles T. Betz

General contractor

I never said or implied that Application or infrastructure which is superior or inferior etc.
The point was both should be treated subcomponents of the "General contract" which is "Service"! And that approach works just fine, and dont see a real need to go back to some 'original' definitions.
May be unfortunate, but the word 'Application' in the Industry has mostly been restricted to the 'Software'. And rather than changing that to a more 'original' definition, ITIL might have introduced a more holistic approach for the term 'Service'.
So in that sense, 'Application' is not equal to 'Service'.

As per my view, the general contractor is a 'Service Manager' (IT Manager, CIO etc if you will) and not 'Application manager'.
Hence, it is not really concerning if ITIL is accepted by 'Application managers' - but I do believe this approach of ITIL is being accepted widely by IT Managers, Service managers, CIOs etc. - Might be my limited exposure.

I *don't* think ITIL is limitiing itself to less important part of IT Management - it is really putting technological aspects like 'Application' and 'Infrastructure' to the right places where they belong and putting the focus to where it should be - The 'Service' : the outcomes business expects from IT.

You are right - ITIL doesn't address completely address Application management; same might be true for Information (or IT Service Secuirity management) - But, that doesn't mean ITIL is only talking about Infrastructure (Though the name unfortunately is still 'Infrastructure Library') . As Rob said, the frameworks that are designed focused on those area should complement ITIL and not really compete and try to gain supremecy.

As I said, I am ignorant of the 'original' definitions and 'pioneers' - but am not really convinced that there is an issue with the current approach of ITIL.



I'm pretty sure I own a copy of ASL but since my life is in boxes right now I can't put a hand to it, so I have ti rely on what's on the Web

The Application Services Library (ASL) describes a standard for processes within Application Management (the discipline of producing and maintaining information systems and applications)
If you read that entry you will see that applications are built but services are delivered. [You'll also see that the page makes some outrageously incorrect and openly competitive statements about ITIL, which annoys me - the two need to work together. However the prominence of services in delivery is clear.]

Please find me one single service catalogue where the only services listed can be completely described as applications, and it doesn't matter whether the catalogue describes what is produced by the overall organisation or of only the IT supplier. Applications are so clearly one supporting component of a service, and only supporting a subset of all total services, that I am quite puzzled at your insistence on this.

P.S. In the rapidly changing world of IT I doubt that Johnnie von Neumann would have known a service if it stood up in his cornflakes, so quoting dead people as an authorative source of IT definitions may be open to challenge


"Please find me one single service catalogue where the only services listed can be completely described as applications"

That's not what I am saying. End user computing is also a service, not easily equated to an application in the current discourse. What I am saying is that semantically, Application is a subtype of Service. Not just a sub-component. This has real consequences for real CMDB data models and operational processes, and so I am not walking away, despite your puzzlement. Surely you of all people might be sympathetic to my goal of a simpler CMDB conceptual data model. "Service" as a first class entity, with a required composition of "Applications," complicates things greatly from a practical data management perspective.

"Applications are so clearly one supporting component of a service, and only supporting a subset of all total services, that I am quite puzzled at your insistence on this."

If it is "so clearly" true then there must be sources, please. Other than ITIL. The trouble with ITIL is that it is becoming a big echo chamber, and when something of a different resonant frequency enters, the reaction is well, reactionary. Even from someone purporting to be a skeptic.

I challenge you to read:

Handler & Maizlish

& others from the enterprise software engineering community and non-ITIL IT management world, and tell me where they support your point of view. Heck, just Google "IT Portfolio Management," "Application Portfolio Management," and "Service Portfolio Management" and tell me where the real industry braintrust lies. Maizlish, Handler, Kaplan, Benson, and the rest did *not* call it "Service Portfolio Management." While we're trading shaky Wikipedia definitions have a look @ Application Portfolio Management,, which extensively discusses the definition of "Application" without coming anywhere near using the term "Service" in the ITIL sense ("service" is used in the more granular, Web services sense).

"In the rapidly changing world of IT I doubt that Johnnie von Neumann would have known a service if it stood up in his cornflakes, so quoting dead people as an authorative source of IT definitions may be open to challenge"

Fine. Put your money where your mouth is. Saying something is "open to challenge" is not the same as challenging it. Sixty years is just the blink of an eye. My view is that there is nothing new under the sun and we are still using Turing/Von Neumann architectures. Disprove that and then we'll talk.

I'm open to quoting live people as sources of IT definitions, if they have based their work on the pioneers in the field. Basing their work also means contradicting it. Where is the definitive "Application considered harmful" statement?

If I go back to 1948 and interview an Organization and Methods vice president as to the characteristics of the new "high performance computing" solution they have just put in would they clearly indicate some primitive lack of knowledge of a "service" concept? And if what they had just put in was *not* a service, what was it? A good? Storable? Tangible? I don't think so. "Applications" of "computing" have always been a "service" even when "computing" was performed by hundreds of female "computers," before we automated them away with Turing/Von Neumann architectures.

Let me propose a different point of view, one that will surely discomfit some readers here. I have quoted Turing on my own blog thus:

"Roughly speaking those who work in connection with the [Automated Computing Engine] will be divided into its masters and its servants. Its masters will plan out instruction tables for it, thinking up deeper and deeper ways of using it. Its servants will feed it with cards as it calls for them. They will put right any parts that go wrong. They will assemble data that it requires."

The bottom line is that not everyone can be a "master," i.e. a developer, where productivity differentials are consistently shown to be as high as 30:1.

Where do you think the real IT value is? In the 30 ITSM staff or the 1 high value developer?

And what do the premier developers, and their managers, call their world? What semantic frameworks do they use to understand it? If you go and talk to them, are they developing "applications" or "services"?

Charles T. Betz

the application is one bit

I leave it to others more learned than me to debate some of your points. It is many years since I read Yourdon and Demarco, and I've only been trained by Zachman, never read his books. So i can't argue from first principles, only from what I see:

COTS and SaaS and Open Source are rapidly rendering the in-house developer obsolete, though granted we will still require architects and high-level BAs and designers
Programmers no longer stride like gods - they are a commodity profession
Development staff no longer have the keys to the production machine - they have to justify and test what they do and it isn't their choice any more whether it flies or not and THEY DON'T LIKE IT. Poor stifled creative genii that they are. Agile development is a last ditch scam to try to wheedle back some control over what matters - production.

Conversely the greasy overall-clad engine-room chaps now wear white coats and work up on the bridge.

There is a shift of power in IT with all the predictable ruckus. The business and IT management have finally twigged that it is not what you build it is what you deliver, which might mean a crappy old system that everybody is comfortable with and which runs dependably day in day out.

What we deliver is information, expertise and technology. Technology is stuff like putting PCs on desktops, providing WAN and VPN access from home, having firewalls and threat prevention. Expertise is projects, architecture, application procurement, business analysis...

And information is whatever the business consumes, categorised however they categorise it. Most businesses have the predictable finance, customer and HR information, as well as industry-specific stuff. if it is a railroad, they have information about track, rolling-stock, schedules, and waybills.

the rolling-stock information service consists of an application to manipulate the rolling-stock data, a network to get access to the application, a SAN to store the data, servers and a database to run it on, processes for backups and reorgs and audits, more processes for change and security and strategising, plans for availability and DR and upgrades etc etc

In the old days the business might have seen IT as just hosting the rolling-stock app, but that only reflected their lack of appreciation for all the infrastructure and activity wrapped around it to actually deliver information to the users ... as a service.

Of which the application is one bit. When we need a change to it, once we've approved it, we'll be sure to call the Applications Manager. Unless we've dumped it for a SaaS solution.

Zachman Framework

Zachman and his framework is another emperor with no clothes. The reality is the entire framework approach to EA is largely obsolete.

In fact, the sorts of changes Zachman is willing to make to the Framework highlight the lack of progress. He recently hired a team of linguists who recommended the removal of all adjectives from the Framework. Instead of “logical system model” there is now a “system logic” row, and instead of “physical system model” the row below now has the label “technology physics.”

Now we can get the EA cult together for a lovely argument over which is better, “physical technology model” or “technology physics”. Meanwhile, our enterprise continues to struggle with cost overruns, regulatory compliance challenges, and marketplace pressures. Arguing about terminology and ontology is just so much more productive.

OBASHI & Archimate

If you don't like Zachman there are Archimate and OBASHI - the latter actually a TSO/OGC product - neither of which recognize the concept of "IT Service" and both of which embrace the concept of "Application Service."

Some support for your sweeping statement "the entire framework approach to EA is largely obsolete" would be appreciated. My experience runs counter.

The problems and challenges of effective architecture are well known. This is a good recent article: My reading is that it implies that frameworks will continue to be useful, to manage complexity.

Charles T. Betz

Availability and Capacity

And BTW in my view Capacity is a subset of Availability - I've never understood why ITIL splits them apart.

Just wanted to add 5cts on this idea... Capacity is a subset of Availability, wich is itself a subset of security... I'm thinking a lot about this and the impact that has in Incident Management (since by definition may be all incidents are security incidents) and the impact on ISO/IEC 20000 (that requires a special path for security incidents)

Antonio Valle
G2, Gobierno y Gestión de TI

security availability

I know security is summed up as CIA - Confidentiality, Integrity and Availability - but I always saw that as a land grab :) I've always interpreted security's "availability" as a different use of the word, to mean that the data is accessible to those who are authorised and not to those who aren't. I don't consider it to cover the availablity of the entire service. I think they're quite different, but I'm listening...

Quite different, but...

Just to discuss and generate new knowledge with a little help from my friends...

The ultimate objective of the IT service is to provide information for the business process to work, so an availability incident in a service will impact in the availability of the information for the business process...

Directly from the concepts database

Availability (ISO 27000): property of being accessible and usable upon demand by an authorized entity!display.action?entry=195079&language=1

When an user can not access his information or can not use it, they call ServiceDesk and log an incident.. isn't it?

Do we have a problem (well... not an underlaying cause of one or more incidents... I mean a trouble) with the definitions?

Antonio Valle
G2, Gobierno y Gestión de TI

real world

No problems, just a turf war :) Security as a function is NOT responsible for Availability as a property. That just isn't how it works in the real world.

"Property of being accessible and usable upon demand by an authorized entity" is perfectly true.

Security is responsible for the "aurthorised" bit and for not screwing up the "accessible" bit.

Service Delivery is responsible for the planning overall Availability.

IT Operations is responsible for executing and monitoring.

Service Demand is responsible for building for it

etc etc

:-) Good dribbling

Ok, better a turf war than a mud one! LOL

I say "good dribbling" because I was talking about processes and you changed to functions...

Let's face it in the other direction. Both ISO 20K and 27k ask you to have a specific process to manage security incidents. So, at ServiceDesk you must identify when an incident is a security incident.

If I follow your concept about the "authorised" bit, then only those incidents that deal with authorization would be categorized as a security incident, but that's not how real world works.

I think that it's more related with the "being accessible" part of the definition. (the authorization correspond to the confidentiality part of the ACID, from my point of view).

The problem is very easy: how do I instruct the ServiceDesk that an incident is a "security incident" ? (because it has to follow an specific procedure, that can be different from the "normal incident" flow).

I have a customer that defined this classification in the following way: "any incident that has no documentation in the KBase or that in the KBase has been identified as a security incident", just because he wants the security guys to know about each "unknown" incident just in case it is a symptom of a greater security incident...

Antonio Valle
G2, Gobierno y Gestión de TI


Given that in my limited experience the security team is often the LEAST responsive team to user incidents and requests - i.e. a bottleneck - the last thing i'd want to do is pipe most incidents through them :)

I don't understand how a security-related incident requires a different flow? except in the narrow set of incidents that are a detected intrusion or violation.


This is the very reason we created IT Marketing Management, call it a plug, but seriously all our work over the past year in the development of this process has been to address the lack of this position in organizations.

not so sure about the name

I like the concept of IT Marketing Management but I'm not so sure about the name. "marketing" carries a lot of negative baggage. "delivery" promises less waffle and more outcomes, and suggests more accountability.

Also I saw ITMM as a function in the Customer Relations space, more than directly owning all the customer facing functions?

It's just an ITIL position

I'm an ITIL certified, I spent a lot of time working and studying on it, and I can't answer your valuable questions, it was studying to feel important in the meetings.
It's not clear whether SDelivM is an IT or some business position, it's just an ITIL position.

BTW, my conclusion is ITIL is a priesthood to give the unskilled people a consideration in the creative world of IT!

There's the Service Manager

There's the Service Manager role (CSI 6.1.2) which seems to fulfil some of the criteria - albeit at a very senior level. I didn't see much reference to it in the other volumes though.

I wonder if Service Delivery Manager was avoided because of the potential for V2/V3 confusion?

focused on the customers

I looked at Service Manager [readers should note that the CSI Service Manager bears no relation to the Service Manager in the ITIL v3 Glossary nor the Service Manager mentioned in Service Design Appendix G. They have a LOT of work to do in the Update sorting out all the roles. See my list of V3 roles]

Service Manager is some sort of uber-god of ITSM. I'm not sure how it differs from CIO :)

The Service Manager owns both front-office customer-facing activity and all back-office management. I'd settle for half that :) Somebody needs to be focused on the customers through total ownership of their interactions with services: managing the whole customer experience e.g. re-jigging Availability to help Support, directing Training to reduce incidents... As far as i can see in ITIL, nobody is.

Uber god - if only I could

Uber god - if only I could get that as a job title!

The experience/qualifications list for the Service Manager is truly daunting - working out your ideal candidate is a fun little exercise on a training course.

My service mgt professional bucket list

Phew - a while ago I blogged on what I expected myself to be able to do as a service management professional - my personal bucket list... the article is here:

Scroll down a bit and let me know if its reasonable and whether there is training out there that is helping knock these items over...

Syndicate content