Commodity vs. differentiated IT services

September 26, 2013February 8, 2021 by John Borwick In Enterprise Architecture, IT components, IT governance, IT management, IT service management, IT services, ITIL 5 Comments

Central IT departments are asked to provide a wide variety of IT services: the network, desk-side computing, email, research computing, and ERP systems, for example.

Some of these services are commodity services. Some are “differentiated:” they are unique and set you apart. And the decision of offering commodity vs. differentiated services is a business decision, informed by the market–where, inexorably, more and more IT services are becoming commoditized.

If your IT department primarily views itself as building services, you’re in for a rough ride: I feel it is highly likely that the services you are building today will be commoditized within a decade.

However, if your IT department views itself as an integrator or manager of IT services, you will probably do very well. Negotiating underpinning contracts to ensure service level agreements is definitely an IT-specific skill, for example, as is building and implementing an architecture within which your IT services can interoperate.

Services start out differentiated, and become commodities

In the 1980s, email was a differentiated IT service–it set computer science departments apart. For that matter, in the late 1970s so was TCP/IP: look at the organizations that own class A IPv4 address blocks (Stanford and MIT had two of the roughly 70 total class A IPv4 blocks).

However, over time email and TCP/IP have become ubiquitous commodity services: there are many providers offering essentially the same services. Your organization is set apart more by not having these services.

This trend will continue: as new IT services prove their worth, service providers (i.e. vendors) start offering and hosting these services. In the early 2000s, Learning Management Systems such as Blackboard were still differentiating–now you have choices, certainly, but it’s likely that your institution’s LMS looks a lot like your peers’ LMSes.

Offering differentiated services ought to be a business decision

IT building a service unique to your organization is usually very expensive. Think ERP customization, for example: your IT department may write a customization to allow GPA to be calculated six different ways–logic unique to your school. Writing and maintaining that customization, however, may cost $100,000 annually.

Deciding to offer differentiated services should be an IT governance decision.

In the 1990s your institution may have written its own Learning Management System. Writing an LMS is a big commitment, and takes dedicated IT staff and specialized knowledge both of IT and the academic need. If IT governance weren’t aware or supportive of the LMS service, it might become more difficult to justify IT’s budget.

On the other hand, you may have a differentiated email service–even today. Perhaps you have 100 GB email quotas, or dynamic e-mail addresses, or other unusual email features that set your organization’s email service apart. It’s certainly fine to invest this time in a service that otherwise might be a commodity–the non-IT people just need to feel it’s worth the cost.

Thinking as an IT integrator/manager

As time marches on, the services you invested in building five or ten years ago start to become commoditized. If you are thinking as a builder of IT service, this can be very threatening: outside providers are challenging your reason to exist. Why have an IT department when your email can be hosted on Google, for example?

However, if you’re thinking as an integrator or manager of IT service, services becoming commoditized is a great situation: you can show the institution that it was ahead of the curve; you can evaluate vendors and determine whether to move away from your custom systems; you can negotiate contracts and service level agreements to ensure the institution’s needs are met; and you cut the cost of IT service while showing the institution that IT can use the savings to build new differentiating service.

This also repositions the institution assigning IT responsibility for managing IT third-party vendors. How many departments in your organization negotiate directly with IT vendors? How much could you help them, with expert knowledge of IT, your architecture, and negotiation, if they worked through central IT for that service?

These skills are still IT-specific and cannot realistically be managed by a non-IT procurement office. Although IT service becomes commoditized there are still many variables to weigh in considering third-party offerings: the hours, capacity, IT service continuity, ability to migrate data to and from the third-party vendor, the ability to integrate IT service management systems, and so on.

With this way of thinking, IT’s focus should change towards improving IT management processes (e.g. project management and service management) and building an enterprise architecture that supports identity management, interfaces, and generally minimizing the total cost of ownership for services.

Really, if you know your job is safe, there are few more satisfying experiences in IT than getting to shut off a legacy system.