how to treat hosted applications in the ITIL service catalogue
Here's one that a colleague wrestled with recently at a client site: how to treat hosted applications in the service catalogue.
I'm reminded of the issue by a recent comment from Charles Betz:
How do you handle application hosting, development, and support in your Service Catalog? Is each application an instance of a generic "hosting," "development," or "support" service offering? Or are applications themselves service offerings (e.g. "user subscription to payments system")?
I framed applications as both service instances and service offerings in my book, but am continuing my inquiries.
Here's my answer: that depends on the relationship between IT and the customer.
If the customer sees IT as an infrastructure service provider - if they are hands-on involved in how the service is provided (e.g. design, technology selection, standards, architecture) - then the service is "hosting" and each app is an instance.
If the customer sees IT as an application service provider - if they just want transactions to come out of the screen like water out a pipe - then each app is a service. Or more strictly speaking, each service is made up of an app or maybe a small cluster of what IT sees as apps but the customer sees as a single "pipe".
The world is unfortunately not this binary, ISP services vs ASP services, so the model is seldom this crisp in real situations, but I think this forms a useful guiding principle. [There are two kinds of people: those who divide everything into two kinds and those who don't].
What do you think?
Made in New Zealand 
Comments
ITIL Service
ITIL V3 can indeed be complicated and the implementation process can be equally challenging. My employer recently made the decision to implement such things and is going down a heavy automation road. Though both our IT team and it’s leaders are competent and educated we watched them have plenty of issues with itil. It eventually got to a point where the company decided to bring on an outside company, one that specializes in itil service management (www.stratavia.com/itilstandards.php). Once this third party stepped in and worked their magic, everything fell into place.
The Stratavia tooth fairy
Wow Manny! That must have been miraculous to see! I was always a bit skeptical about magic especially in the context of ITIL services, but if you saw it then that's good enough for me.
Those Stratavia guys sure seem to do magic alright. Anyone who can solve ITIL problems by automation coming from a database and data modelling perspective is certainly doing magic.
Quick everyone, stop wrestling with nasty problems like people and culture and process. Go buy some of the Stratavia magic and you can automagically implement a database-driven IT automation solution for ITIL! What a relief! Even those readers who are "competent and educated" (both of you) will benefit.
Now we can all relax and stop worrying.
ha
hahahaha... the way you handle it is sooo funny. But then again, Manny is so convincing in being funny that it is almost mean to take advantage of it.
too funny not to share
First I unpublished it, then I edited the link out, then I left it in: it was just too funny not to share. Luckily we don't get too many of these, but as the blog's page rank creeps up (5 now!) they crop up more often of course.
The paranoid in me wonders whether it is so bad a name-drop that it is in fact SpamWatcher returning to troll me.... nah.
Really !!
Curious use of the word Standard
Brad Vaughan
http://blogs.sun.com/buraddo
would that it were that easy
It's definitely not binary. Large organizations can encompass all of the combinations shown in my hosting zone of contention analysis, with the additional complexity that some application teams are owned by the business while some may be owned by a central IT group (as ASP).
The same hosting service offering may be consumed by both business-owned application teams (your ISP model) as well as central ASP teams. Even in a pure ASP model, in large organizations the hosting capability is significant enough that it's advisable for it to frame service offerings, even if those offerings are never directly consumed by business partners.
See also Service Catalog Confusion.
Charles T. Betz
http://www.erp4it.com
zone of contention and d-marcs
While customers often say 'application', they do not run in isolation and will surely hold IT's feet to the fire when things go wrong so I do not like equating applications to services AT ALL --- regardless of who 'owns' the application team.
I love the 'zone of contention' though (and liked your book as well); seems like the key is really getting agreement on the dmarcs....like 'does that include the local loop'? (and if not, what kind of hell do we have to go through to understand who should own an issue?)
This 'zone of contention' for complex, n-tier application infrastructures can be a nightmare for customers and IT people alike. Drawing a d-marc between 'application' and 'infrastrcuture' is a lot more complex than the local loop example given above.
I'll continue to harp on the need for a real time, collaborative and intelligent service monitor that can measure every layer of every component of a service infrastructure (including applications), learn the norms of all collected metrics, and automatically isolate which layer of which component is the source of an anomaly. Once this is effectively shared by all parties to the service, establishing d-marcs becomes less of an issue.
I've called this a 'CDB' in past posts about the reality of the 'CMDB vision', and find it interesting that we now see analysts and vendors incorporating a 'process' and a 'real time' engine into their 5 year CMS visions..the CDB' capability described above (which does encompass relationships) has been available and in use for over 2-3 years...so much for CMDBs. Focus on what's needed.
The Service Catalog should be meaningful to the customers who use it, and help enable easy provisioning of IT services. If that means calling 'applications' 'services' I don't really care.
But at the end of the day, regardless of d-marcs or what's in the Service Catalog, when it hits the fan you'd better be able to point the finger at the right area or IT takes the hit. If you can actually give the parties involved in your value network a 'heads up' before things crash, you've laid the groundwork for true collaboration and partnership (instead of tribal warfare).
John M. Worthington
MyServiceMonitor, LLC
The real business purpose of the enterprise CMDB
"If you can actually give the parties involved in your value network a 'heads up' before things crash, you've laid the groundwork for true collaboration and partnership (instead of tribal warfare)."
The real business purpose of the enterprise CMDB, to my mind... of course, the CMDB's relationship to service mapping for operational monitoring is a very interesting one and badly under-examined in the industry...
and bear in mind, while I say that an Application - suitably large grained, and when run as a unit - may also be essentially equivalent to an IT Service, not all IT Services are Applications.
Charles T. Betz
http://www.erp4it.com
staying on purpose requires agreement on boundaries
Much of my background is as a Service Level Manager, principally in service provider (for-profit) environments. Hank hits a nerve I think; the catalog gets clearer when money is involved. Customer outcomes and focus on the total business objectives are what should drive behavior (and service definition) but the real world is often full of people and politics that can result in a catalog and service definitions that are pretty twisted. A need for CobiT! :)
We might use CMS now instead of 'CMDB', but I could not agree more with your comment; "CMDB's relationship to service mapping for operational monitoring is a very interesting one and badly under-examined in the industry..."
As for d-marcs, I still think this is where we wind up. Who is responsible for what? What am I paying for? How does it work? are all questions that change as the boundaries shift with changes in how we define "what is a service?". To make it even more complicated, the business often is not at all clear on these boundaries either (see The Difficult Process of Identifying Processes: Why It Isn't as Easy as Everyone Makes It Sound
I think the 'element/component' - 'system' - 'service' (IT or business) seems to work for me as far as the catalog goes, but if everyone in our value network is not working off the same page finger-pointing is inevitable (regardless of d-marcs).
Without the discipline that money provides, the CMDB/CMS will need clear definitions of service that enable effective demarcation points. I'm not sure splitting 'applications' from 'infrastructure' works, which is why I tend to favor the element/component, system, service approach. In any case, establishing these boundaries is where the rubber seems to meet the road.
John M. Worthington
MyServiceMonitor, LLC
its a product management thing
I think the answer lies in the field of traditional product management. The degree with which you break up the service depends on whether the customer can genuinely acquire the components from other sources.
So if you are offering an application service, but you are happyfor it to be hosted anywhere, the you might package it as an integrated offering and as a component which the customer can build into a offering using other components.
My thought would be that if you offer a complete thing that a customer wants to buy then you have a service. If you depend on other things being present (mandatory) then you have a component. You are transfering ownership of the complete thing to the customer.
$0.02
Brad Vaughan
http://blogs.sun.com/buraddo
Service Products based on Purchasing decisions?
The way we ask our clients to think about this is as a multistep process.
First, what are the things you sell, or, more precisely, what is it customers (internal or external) buy?
Second, is the thing (service) you sell consumed by IT customers or IT internals? This is really a question about who's the prime contractor vs. subcontractors.
Third, bundling of the services to make a prime service (a product) is based upon individual, discrete customer buying decision choices. Careful to not overdo the number of nonsense choices.
Fourth, we recommend that clients explicitly break out the "hidden" overhead functions, such as the "consumer reports" work, and make those separate services. We feel this makes comparing internal vs. external services easier. One of our sub-goals is to help our clients appear as least cost providers.
Service pricing is best based upon rates built up from all the subcontractor services with the overhead allocations.
Fulfillment processes should be standardized to the extent possible. We recommend clients use a manufacturing work breakdown structure/bill of materials approach and apply Lean Six Sigma principles - Define, Measure, Analyze, Improve, Control. We believe that the customer's perceived value to the customer comes in the consistency, the dependability of the delivery of the services.
Oh, and we generally recommend that our clients structure their three service catalogs within the UNSPSC outline so that spend management can be facilitated against vendors.
"Is each application an
"Is each application an instance of a generic "hosting," "development," or "support" service offering?
Or are applications themselves service offerings (e.g. "user subscription to payments system")?"
These questions indicate that a better understanding of Services is needed.
An application may be an IT System or a component of an IT system but will not be a Business Service.
The Business service is the part of the application that a user will use or interact with
e.g. MS Access is the "application"
The interaction that the user will have with that application will be described as "the Business Service" as the user is fulfilling a business outcome or objective by using this service.
Anyway, it should not matter whether or not a service is hosted or where it is hosted. If it is a service that is used it should be recorded in the Service Catalogue. The trick is to be able to identify what are the "Business Services" and what are the IT Systems and Components that make up the Service.
Agreed
I'm inclined to agree with you, Mark. An application is not a service. (Except I wouldn't refer to a "business service". If a service is a service is a service, then why not just call it a service?)
If IT's products are not perceived as services by IT management, then they aren't designed and managed as services to customers. Instead, they are managed as administrative routines. Consequently, customers see IT as an administrative unit rather than a service provider.
Value emerges in the customer's consumption of IT's services in the pursuit of an outcome for themselves. Therefore, any definition of services must begin and end with the customer's perceptions.
Depends on the definition of application
Let's start first with a most cogent thinker on the subject, Martin Fowler (an "IT Skeptic" of the software engineering community, if you will):
http://martinfowler.com/bliki/ApplicationBoundary.html
Quote: "applications are social constructions...[e.g.] A group of functionality that business customers see as a single unit...An initiative that those with the money see as a single budget."
(See also http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html for a good thrashing of SOA.)
So, given the fact that applications themselves are consensus political concepts, how then do we distinguish them from IT Services? How do we make this distinction repeatable and achievable by myriads of IT Service implementors?
I discuss the consequences of attempting to distinguish between IT Service and Application here: http://erp4it.typepad.com/erp4it/2007/08/the-evolving-do. Imposing one squishy consensus political concept on top of another is difficult at best. And, buliding off my long debate with Troy DuMoulin, I'd additionally challenge the service advocates with some basic data architecture questions.
First, let's assume that you've defined an "HR Systems Service" that includes Peoplesoft HR, an employee satisfaction portal, and the employee training system. While the service team might draft some flowery language about a "customer facing mission of providing excellent HR system services," carefully avoiding specifying their applications, for practical purposes this "service" is nothing more than a grouping of applications given an abstract name. Questions:
Is your concept of "IT service" directly related to SLAs? Or do we need to actually base our understanding of SLAs through mapping specific measurement objectives to more granular applications with their measurement points?
Are Incidents directly associated with IT Services? Or are they associated with the more granular Applications? How does it help us to know that the "HR Systems Service" has an Incident? The first relevant question will be, which application?
Are Changes directly associated with the Service? Would we find it more useful to report Capacity by the higher level Service rollup, or by the actual application?
What about the fact that many business people, for better or worse, see IT's primary "service" as "running application X for me." See What's an Application Manager to Think. No-one has answered this post in a manner that any application manager I know would find satisfactory.
Part of the problem in this debate is of course definitional. Microsoft Access is not an application to me, it is merely a software product. But that is because I have spent many years now working in the largest corporate IT shops, whose primary mission is the design, construction, building, and support of large scale transactional and BI applications in support of business objectives. And the linguistic reality of that world is that the "IT Service" concept, as people are discussing it here, is nebulous and academic, while people know what production applications are and don't see much value in changing the terms of their discourse.
Is there *anyone* reading this blog that has spent significant time as a production application manager for a large IT organization?
I also am not sure that there are many ITSM consultants who are at all prepared to lead abstract discussions on the service portfolio. I've seen this work done, at a major US retailer, where it was led by enterprise architecture consultants, not ITSMers. These consultants (led by one of the best in the business) decomposed a set of "business service functions" revolving around high level concepts like Create Demand, Fulfill Demand, and Serve the Customer. It was painstaking, abstract, consensus-building work. The end result was a credible taxonomy of 200 final service functions, all of which bore names that might well serve as a service portfolio (HR System Services being a characteristic example).
But this operational model ultimately proved of little value for IT service management. The applications were mapped into the service functions, but it was a many to many relationship which meant that there were no rollups, and right there we started to lose business credibility (people want hierarchical accountability). Ultimately the work added more value in portfolio rationalization and future state planning than anything else. It was clearly no basis for day to day IT management - which I think is what we are talking about here...
I also discussed this with a practitioner at the ITSMF USA in Charlotte. They had drunk the IT Service Kool-Aid, and defined an elaborate ontology in which Applications rolled into Application Groups rolled into IT Services. The trouble was that they wound up in analysis paralysis actually getting people to agree to the hierarchy. (Unsurprising to anyone who has fought a dimensional conformance battle.) He came up to me after my presentation and confided that my assertion that the simple, lowly Application was a fine place to start had been a revelation to him, given his current data architecture struggles in implementing something more ambitious.
See also http://erp4it.typepad.com/erp4it/2007/02/application_and.html - nor have the Application Portfolio Management authors aligned with the "IT Service" terminology.
I know I am swimming upstream, and may yet change my mind. But the problem is nowhere near as clear or simple as is implied, when viewed from a conceptual architecture perspective. I remain convinced that a baseline application portfolio, with clear maintenance process and recognized as a system of record, is an essential step in IT Service Management, upon which all higher-order service management objectives depend. Any problem can be "solved" by adding another layer of indirection. Larger grained abstractions come later. Walk before you run.
Charles T. Betz
http://www.erp4it.com
Begging the Question
Debating Fowler's argument invokes the fallacy of "begging the question". This consists of taking for granted what is in dispute, in passing off as an argument what is really no more than an assertion of the position. In other words, Fowler hasn't really scrutinized his fundamental assumptions.
For example, he gives the following as applications:
1 - A group of functionality that business customers see as a single unit
So a hammer is an application? Or a division of IBM? Or a DVD player?
2 - An initiative that those with the money see as a single budget
So project is an application? Or a merger or acquisition? Or a training event?
Because someone calls something an application (or a service), doesn't mean it is.
Is it safe to assume your organization has already taken the stance of application=service? Let's assume this is correct; that an application is indeed a service. Before taking an opposing position, let me ask: How's that working out?
Observation, not debate
Of course Fowler's brief statements are meant to be read in the context of software solutions delivery and enterprise IT applications architecture, not carpentry tools, organizational structure, or consumer electronics. Nor does he take a position on service versus application; he only states his eminently qualified observation (as would an ethnographer) that the term "Application" is used in all three of those senses, and therefore is a political concept.
Fowler's observations are not a debatable matter, unless you have some reason to believe he is falsifying that observation or is otherwise not credible. Personally, I find his credentials compelling; he is (along with Steve McConnell) one of today's most widely known and respected software engineering practitioner thought leaders.
Whether the term "Application" *should* be so elastic might be debatable, in an ivory tower sense... but the linguistic usage is simply an observed fact, consistent in both his experience and mine.
It would be more correct to say that I remain skeptical there is much value in basing day to day IT management upon a higher order "IT Service" abstraction. At best the concept seems to be a reporting rollup suitable for dashboarding, not a fundamental governance entity. Nor in all the ITSM commentary, blogging, and debate have I seen much attention to basic conceptual architecture:
- What processes create and use the IT Service concept? Are they the same processes as create and use the Application concept? Is it sensible to tie Changes to Services or Applications? Incidents? Capacity? Configurations? Security? Releases? I believe all are best done at the Application level (if production applications are involved). We can roll up to IT Service, but then lose visibility. I do see the "IT Service" concept used for SLA aggregation and operational availability monitoring, but that monitoring can roll up well beyond any sensible "service" level, to the very top of the organization (availability dashboarding).
- If one IT Service may be supported by many Applications, can one Application support multiple IT Services?
- If an Application rolls up under one and only one IT Service, is the IT Service concept then no more than a simple aggregator?
- If an Application may support multiple IT Services, how are costs allocated? Is one IT Service deemed the "primary owner"?
- What process is responsible for maintaining the mappings of Applications to Services?
- If an Application cannot be itself an IT Service (no "is a" relationship allowed), what about IT Services that in fact are supported by one and only one Application? What is the value of having two logical entities stacked upon each other when they are both describing essentially the same thing? Or is there a business rule that any IT Service must be supported by more than one Application?
- If an organization has a portfolio management process, is that process creating and using Applications or Services?
Charles T. Betz
http://www.erp4it.com
Do we need an answer
Does this level of question need to be answered in the abstract or theoretical..
Just deal with it in the practical, case by case basis..
Brad Vaughan
http://blogs.sun.com/buraddo
Coincidence?
Forgot to mention the ironic part: It was Fowler (Thomas) who coined the term "begging the question" back in late 1800's. There was something about the name that sounded familiar.
Whoooosshh (Sound of that going over my head)
No criticism. This is just this is a bit of fun for me, and the depth of the argument got a bit much for me.. I also tend to avoid abstract debates on architecture of services, but that is just my simple mind (getting simpler as I get older)..
I spent three years running the business consulting, app dev/integration and DBA teams for the IT department of an enterprise in australia. I never ran into any of the myriad of employees and contractors that passed through the organization that did not believe we offered a service.
I am very simple person. In simple terms, everything that is not a capital acquisition, is a service. Even if you buy a capital asset through a lease, its a service.
I think I get your point (maybe).. Applications are not services, but mere products (bits and bytes). Applications, plus other things make services.. These things include implementation, system integration, data management, application management, etc.. etc..
The whole "Software as a Service (SaaS) industry is based on this premise. Assuming you do not buy IP of the software in the form of a licence, you just buy the ability to use the software.
So I agree an application is generally a IT construct that tries to support through automation, business processes. For an application to be offered as a service it needs a whole lot of supporting activities.. If a customer genuinely buys an application as a service, then they care not of any detail beyond the business requirements they have for this service. In reality, it rarely happens.. The conflict between major application vendors trying to build a singular view of business process, with a business desire to do things "there own way" means that customers are exposed to the technology selection because it is too difficult to evaluate and select these technologies in a abstract manner (on paper if you will). There is convergence here though for legacy application (Finance, HR etc..), business's are happy to accept the the general definition of a business process that most vendors have created and vendors have built enough flexibility to accomodate various industries and markets.
On the other hand, offering access to MySQL is also a service. It does not support a business process, but in this case the the business is choosing to do some of the IT work themselves. The service they want to access to this technology.. This is a service, certainly a different level, but a service non the same..
The degree to which business is abstracted from the technology depends on they business' interest in technology. IT would love business to keep out of technology decisions, but in reality, IT is still not mature enough in many areas to simple define application systems. We still rely of user testing, acceptability testing, UI preferences, integration with other systems etc..
Changes, incidents need to follow the dependencies all the way up to the highest level of abstraction of the service catalog at some point. The service catalog really defines the interface between IT and Business, so you need to represent things this way. You may however use metrics that reflect on something lower in the stack to explain the quality of service As much as the service I am being offered is a heart bypass, I still want to know how long I was on the table and how long my heart was stopped, because they define some of the qualities of the service and I am educated enough to know how they impact the service. If I truely trusted the doctor and was happy to be ignorant, I might just ask, was it successful and should to keep an eye on anything.
Apologies if I am well off the mark..
Brad Vaughan
http://blogs.sun.com/buraddo
Applications may be Services
My key point is that an Application may directly be a Service, if both the provider and consumer are treating it as such, and that many Application Managers in fact perform all the roles of Service Management, most critically as a single point of contact to the business, and proxy for all subsidiary/underpinning services.
It's a terminology thing, primarily. But critical. And the difference stems from two competing views of the term "Application": one view is that Application is just about the bits and bytes; the other view (per Martin Fowler's second and third examples) is much more expansive, recognizing that in many organizations the "application" concept is already a very elastic layer, and distinguishing it consistently from a "service" layer presents practical difficulties.
ITSM is not a universally accepted conceptual framework for all things IT, not yet, and especially with regards to this distinction, which would require general agreement from other communities of practice (application portfolio management, application lifecycle management, solutions development) who have not yet embraced ITIL. In those worlds, the "application" is the major governed concept with respect to the business and its requirements. There is no general acceptance of an intervening "service" layer, ontologically speaking.
For support for the application-as-service concept, we need look no further than the very name of the Application Services Library; their highest level process (equivalent to ITIL's Service Portfolio Management) is called Applications Cycle Management. Note that the joint OGC/ASL statement says that "The ITIL publications give sufficient guidance for organizations that manage commercial off-the-shelf applications but if an organization maintains the applications and therefore actually modifies the source code, then ASL provides additional and necessary guidance."
Does this eliminate the need for higher order reference models of IT and the business (what some see as the service portfolio level)? No - and this layer is typically the province of enterprise architecture, where (as I noted before) its value lies more in portfolio rationalization and future state planning, and not in day to day operational IT management.
Charles T. Betz
http://www.erp4it.com
One more thing
There are many applications that business take as services and do not care about the technology.
Business's used to print there own checks or pay cash to employees, Many don't even do there own HR processes around leave entitlement, or super annuation/401K, how about employee share schemes..
Does this mean that internal IT cannot do this level of abstraction? Maybe, because if you get to this level then you may as well outsource it. Maybe business then buys the service directly, or IT manages on behalf of business.
Fodder for thought.
Brad Vaughan
http://blogs.sun.com/buraddo
The Politics of IT Service Valuation
Here's an interesting angle on this from Hank Marquis:
Value Creation v Value Capture
It's an interesting analysis but the wheels come off the rails in several places. For brevity, I'll focus on one:
Services are indeed a transfer mechanism for risk, as Hank insightfully points out. ITIL appears to agree, given the v3 definition of service: "...a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and *risks*." Risks haven’t gone away. Someone else with better capabilities takes responsibility for them. That’s why it’s a service. By taking on the risks - and potentially reducing them - services increase the probability of the customer's success.
But while risk is an important cause of services, it is not the source of value creation. That argument is a bit like saying the reason the World Trade Towers no longer exist is because planes flew into them. The planes may be the *cause*, but they are not *reason*. When the two are confused, we are led down the wrong path.
Customers seek IT services for the practical realities of their own day-to-day jobs. If IT can understand that job, design a service and associated experiences to facilitate that job, and deliver it in a way that reinforces its intended use, then when customers find themselves needing to get that job done, they will seek and value that service.
Hence the need for utility and warranty. They articulate the realities of the customer's day-to-day job.
Risk, or the lessening thereof, is why customers choose not to perform the service themselves. By taking on responsibility for a service (i.e., risks and costs), the internal IT provider creates a mechanism for "value capture", not "value creation". That is, the portion of value creation the provider gets to keep.
(Yes, there are exceptions. Insurance and disaster recovery providers for instance. :-D )
Does this open the door for politics? Absolutely. Since services are inherently relational, there aren't easy ways of escaping this conundrum. There are proven methods for dealing with it, however.
(Actually, we've known for thirty years that manufacturing is highly relational also. So there's not much escaping it there either.)