Catalogue yourselves as an Information Service Provider

If your service catalogue says you provide application "hosting", your IT department is committing organisational suicide. You need to be an Information Service Provider.

These thoughts are triggered by looking at yet another real-life service catalogue that positions IT as providing a "hosting" service for the applications. This strikes me as organisational suicide. "Hosting" gets benchmarked on cost against the external commodity providers. If all you do is host you might as well get on the job market now. It shows you have low importance to the business strategy and no differentiation from an external provider, no value add through specialised understanding of the business. It is that same old fixation on the "T" part of "IT".

For IT to survive within an organisation it needs to provide a service that is unique, aligned and high value. In the context of the application systems, that service is to be an Information Service Provider. You are the custodian or steward (NOT "owner") of the enterprise's information resources. That custodianship covers far more than hosting them, though it does include it. You provide CIA: confidentiality, integrity and availability. You provide data architecture and design. You provide the systems to execute transactions against that data, empowering the business to use and maintain their information resource. Don't peel these things out as separate geek-level services ("Security Protection Service"). They are integral parts of the Information Service.

Most of all you provide the capacity to grow and redevelop the service behind that information in order to respond to the changing strategic needs of the business. Because you are part of the business and know and understand the business. Because your success depends on the business's success unlike the external service providers (only their sales people say sucky things like that). The service catalogue should make that explicit.

To me there are four types of service:
Information broken up into discrete services for the kinds of information or the subject areas of the information ("Customer Information Service", "Distribution Information Service").
Professional Consulting where you provide knowledge and advice on architecture, selection, design, improvement, usage and so on.
Technical Services for the geeky services that are directly exposed to the users and consumed by the users: personal/desktop computing devices, remote access, user provisioning...
Hosting is sometimes imposed upon us. Finance department has bought a system on their own and refuses to let IT have any role but hosting it. Fine, make it explicit that this is low value and outside the standard model. Show this service as "deprecated": exists but no longer available for new services.

I know this has been discussed extensively in other places and slightly different terms (I welcome references). It is the core message of many works. I'm not trying to invent something new here. I'm trying to get people to STOP DOING IT, undervaluing themselves. Find your differentiated value. Find your alignment with business strategy. Then articulate it in the service catalogue, while you still can.


IT Hosting vs. Information Services Provider

Hi Rob,

I've personally had the opportunity to work on a number of Service Catalogs for myself and for clients, over the years. When breaking down IT Services, "Hosting" has never been a Service that's been offered in any catalog for no other reason than it's too general or coarse. And, maybe this is the nature of the larger IT organizations I've dealt with, I've never seen an IT organization classify itself as providing hosting services. Is this something you're seeing in different areas of the world?

In my experience, when most leaders have gone down the road of finally defining their Services, it's usually for one or both of the following reasons:

1) They want to know what their people are doing (by breaking things down into Services, they get transparency into who's performing what work and if there are redundancies or gaps in their Service Portfolios)
2) They want to clean up how organizations interact with each other and help optimize how Service Requests or Work Requests get fulfilled, in a repeatable and measurable manner.

In the event you're a 3rd party that is providing IT Services to your clients and something like hosting is the Service you provide, then I don't know that I would recommend trying to obfuscate your service's name. The rules and experience of successful marketing state to be clear for your niche, that is until you become the size of an entity like IBM and you can market yourself any way you'd like because you have far too many offerings to cover in a succinct marketing pitch.

I would suggest organizations never classify themselves as providing "Application Hosting" because it's simply too vague. One of the things I've seen be most successful is to be very specific about the Services that are put in a Service Catalog so that consumers of those Services know exactly what Service they're invoking and what they're going to get delivered as a result of that Service Request. For example:

Service Discipline or Category = "Application Server Management"
Related Service Requests:
- Request New Application Server
- Request Deployment of Application to Existing Application Server
- Request Migration of Application From One Application Server to Another
- Request Decommission of Existing Application Server
- Request Decommission of Application from Existing Application Server
- Request Modification to Existing Application Server (Size, Performance, etc.)
- Investigate Issue with Application Server or Hosted Application
- Other (Catch-All)

I believe that specific being specific about Service Requests help decouple organization labels and classifications from the work they perform.

If you don't want to commit organizational suicide, then I suggest providing many, clear, and valuable services that your clients must depend on to be successful. Then organizational name won't matter, at all. Something tells me that if you're worrying about changing your organization's name to deal with perception of what you do, then you may have bigger issues to deal with.

My Best,


The International Foundation for Information Technology (IF4IT)
Open IT Standards & Best Practices

different things

To be clear I'm talking about internal service providers, i.e. IT departments. Hence the concern of being outsourced.

I think a service catalogue should contain no more than "a few dozen" first-level services, else it becomes inaccessible to humans.

I suspect we might be talking about different things, just because of some of the requests in your example. I find it hard to imagine a user asking for "Request Migration of Application From One Application Server to Another". I can't imagine a scenario in which a user knows or cares what server an app is on.

I'm discussing the service catalogue that defines the services an IT department provides to its customers in the enterprise.

User vs. IT Staff Making Service Requests

Hi Rob,

Addressing your statement "To be clear I'm talking about internal service providers, i.e. IT departments. Hence the concern of being outsourced."

My opinion in this area is that is inappropriate to attempt and create job security for yourself in any way other than to provide the best services at the lowest cost, even if you're an internal Service Provider. If an organization is good at what it does and is cost effective, then that organization will have its best chances of not being outsourced.

Executives look at Organizations and Services as being components of a portfolio they have to manage. There is only so much money to go around and fund everything an enterprise wants to achieve. When it comes down to it, outsourcing is a decision made because an organization is perceived to not provide the same "value" (a combination of deliverables, costs, quality, timeliness, etc.) as some external Service Provider that performs the same Services. Unless I'm misreading it, your original post appears to recommend not using a name that brings attention to your group so that you won't be outsourced. I know this is a tough thing for many professionals to hear but an enterprise has to run itself like a business and, in doing so, such an enterprise has to make judgement calls about what is or isn't valuable. Therefore, my position is that if a group doesn't provide quality services, in a timely manner, for justifiable costs, then maybe it should be outsourced in favor of another group that does, so that funds can be freed to achieve other things in other areas of the enterprise. If an organization is changing its name to not draw attention in an attempt to avoid being considered for outsourcing, I think that organization is inappropriately trying to create job security for itself, at the expense of the enterprise. This doesn't seem appropriate to me. I think the most effective way to avoid being outsourced is to simply be very good at what you do, at competitive prices.

Addressing your statement "I think a service catalogue should contain no more than "a few dozen" first-level services, else it becomes inaccessible to humans."

I want to agree with your statement and I agree that "simplicity" and "intuitiveness" make a Service Catalog usable and effective. However, the best and most effectively used Service Catalogs that I've seen and participated in have had many hundreds of standardized Service Categories and many thousands of standardized Service Requests. The way I've seen implementers handle your reference to "a few dozen first level services" was to create "contexts" or "groups" of Services. Depending on your role or the work you were performing, you would use the contexts associated with those roles or that work that would quickly lead you to the available Service Requests that could be invoked for those areas. However, there are many times that you need to go out of your role based context and do something else. In this case, you need to find a way to get to other Services offered throughout the enterprise, especially if you need a Business Service as opposed to an IT Service. In these cases, you need to be able to find a way to get that work done or who performs that type of work. Done correctly, I've seen the Service Catalog become the knowledge platform for how a business operates. You go to the Service Catalog, look things up by keyword and it points you to your options, throughout the enterprise. If you take all of the Services throughout an enterprise and put them into the Enterprise Service Catalog, it's never small. It's only when you create an intentional hierarchical set of categorizations (i.e. Service Taxonomy) that you start to get a smaller list to work with, at the highest levels of the Taxonomy. I've found that in some cases Service Taxonomies work and in others they don't. I think this has to do with the experience level and skills of those creating them as well as those of the people implementing the Service Catalog, itself. BTW, the best Service Catalogs I've ever seen have always been home-grown. Two of the best, believe it or not, were spreadsheet driven. In one case the spreadsheet was translated to a two-dimensional HTML table as a script and simply published to the enterprise Intranet with embedded links to all Organizations, Services, Service Request Templates, etc. In another, the spreadsheet was published as a hyper-link enabled two-dimensional table in a Microsoft Sharepoint List Structure. In both cases, people used the "Find" feature in their browser to highlight the key areas of interest in the table and, step through the highlighted keywords until they found the desired service, and simply click the links that led them to where they need to go (Request Forms for that Service, the Service Organizations' home pages, Service Contacts, SLAs, reference material, etc.).

Apologies if this sounds like marketing but the IF4IT is actually working on an open Service Management & Catalog Framework (the name of it is still TBD) that takes the above concepts and puts them into practice via a repeatable pattern that standardizes enterprise Service names and their representations, with the intent to decouple the Service names from the enterprise's organizational names (which can be custom to the enterprise). It's intended to be published in the next few months. Given that your blog's community have experience in these areas, maybe, with your help, we can find people to help review it and provide feedback, when it's ready. We all realize that no solution is perfect. However, through productive collaboration, there is always a way to help solutions evolve in a positive direction.

Always a pleasure.

My Best,

The International Foundation for Information Technology (IF4IT)
Open IT Standards & Best Practices

change the goal-posts

An internal IT department is unlikely to ever be cost-competitive with a professional outsourcer. As i said in the original post "For IT to survive within an organisation it needs to provide a service that is unique, aligned and high value." it is a mistake to compete at the commodity level with outsourcers. Change the goal-posts by moving up the IT maturity scale to value-add integrated part of the business and they'll never look at an outsoucer. if you are in an industry or company where IT will never be more than a back-office commodity service, then your days are always numbered.

Cost Alone Doesn't Cut It

Hi Rob,

I guess that if Cost were the single factor, then it would be true. However, while Cost might look like an enticing reason to outsource, smart leadership knows (or burnt leadership learns the hard way) that Cost, alone, doesn't cut it.

I've dealt with at least two enterprises, just this year, that have been reversing their outsourcing investments. While the external Service Provider offered lowest Costs and had all this wonderful marketing material that promised wonderful Services with spectacular response and delivery times, it turned out that the Services weren't at all what they were pitched to be. As a result, both enterprises went in a direction of undoing significant portions of their outsourcing models. In the end, they did keep some Services outsourced but realized they couldn't successfully outsource nearly as much as they would have liked to.

In the case of something like "hosting," if an enterprise outsources such a Service, experience will soon teach that enterprise that the only way to be successful at it is to have "technical people," both leadership and staff, on the inside of your enterprise boundaries to manage and understand what you've put on the outside of your enterprise boundaries.

I believe (from my own experiences) that Cost, alone, doesn't cut it.

My Best,


The International Foundation for Information Technology (IF4IT)
Open IT Standards & Best Practices

Syndicate content