The IT Skeptic - Comments for "ITIL Service Delivery Manager"

OBASHI & Archimate

Charles T. Betz — Sat, 18 Sep 2010 13:50:46 +0000

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: http://rvsoapbox.blogspot.com/2010/09/future-of-enterprise-architecture..... My reading is that it implies that frameworks will continue to be useful, to manage complexity.

Charles T. Betz
http://www.erp4it.com

Zachman Framework

Visitor — Tue, 14 Sep 2010 04:41:29 +0000

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.

Alien

skeptic — Sat, 14 Aug 2010 19:43:00 +0000

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

External service providers

Machteld Meijer — Sat, 14 Aug 2010 15:09:15 +0000

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.

Application according to ASL

Machteld Meijer — Fri, 13 Aug 2010 21:01:32 +0000

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):

application
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

Does ASL define "application" anywhere?

Charles T. Betz — Fri, 13 Aug 2010 12:46:24 +0000

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

Charles T. Betz
http://www.erp4it.com

the Perseid meteors or the alignment of the planets

skeptic — Thu, 12 Aug 2010 19:14:25 +0000

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.

My best practise

aroos — Thu, 12 Aug 2010 09:54:05 +0000

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 ;-)

Aale

terminology

David Zaucha — Wed, 11 Aug 2010 13:43:39 +0000

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...

Craig wrote that one needs

aroos — Wed, 11 Aug 2010 05:22:57 +0000

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?

Aale

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

confusion

skeptic — Mon, 09 Aug 2010 20:55:58 +0000

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.

Inside Out

skeptic — Mon, 09 Aug 2010 20:48:48 +0000

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

Not quite

Visitor — Mon, 09 Aug 2010 14:12:36 +0000

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

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

FakeITIL

Matthew — Mon, 09 Aug 2010 13:20:23 +0000

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

Quite Limited, Yes

Craig_Wilkey — Mon, 09 Aug 2010 13:14:52 +0000

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)

There is one picture

aroos — Mon, 09 Aug 2010 12:36:38 +0000

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.

Aale

BRM

CraigWilkey — Mon, 09 Aug 2010 11:43:21 +0000

http://www.best-management-practice.com/gempdf/ITIL_Glossary_V3_1_24.pdf

Bottom of page 7...

BRM

CraigWilkey — Mon, 09 Aug 2010 11:40:42 +0000

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

Missing role

aroos — Mon, 09 Aug 2010 11:20:56 +0000

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.

Aale

Efficency of Processes

CraigWilkey — Mon, 09 Aug 2010 10:52:40 +0000

Skeptic,

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.

Craig