From managed IT services to modern managed services

In today's era of public clouds, anything-as-a-services, pre-made frameworks, and tools, Managed IT services have made it possible to develop and run digital services with fewer resources. However, the complexity of managing dozens or hundreds of services, vendors, service providers, applications, and teams is not an easy task.

Offloading part of that complexity and workload to your partners is a sound strategy. That enables your business to operate at peak efficiency without investing in additional internal IT staff. A good partner will also help you improve IT efficiency, reduce your in-house overheads, decrease downtime as well as create tangible business and customer value.

The usual case of externalizing some of the responsibilities starts by defining a clear bounded box. These are the systems, these are the responsibilities and minimum services levels and these are the sanctions if you don't meet the levels.

That is very human. Dividing complex and large systems into smaller, clearly bounded, and interfaced pieces, is a way to manage complexity. However, although these clearly defined and bound boxes help deal with complexity, they might hurt the overall ability to create value.

Value chains go over multiple services, services span multiple systems and most of the services are dependent on the other services. The more you have these clearly defined boxes with individual teams, the harder it is to get something done from idea to production and ensure effective end-to-end value creation. Unless you deliberately measure and incentive that across all of your vendors and services.

Local optimization is a problem that hides well. Individual service might have 99.9999% uptime but you still have a hard time serving your paying end users. Local optimization leads to wasted resources, causing bottlenecks, slowness, and unhappy business, developers, and end-users.

Local optimization and local autonomy are not absolute evils, quite opposite. Usually, agility, ownership, and ability to invent are better in smaller units. However, not seeing the bigger picture, the value chains, and measuring what matters, can lead to losing all the huge benefits you could get by building a system that is loosely coupled and tightly aligned, pulling all into the same direction.

For example, let’s assume the organization has some internal service that works as a master data storage. It is easy to understand the importance of said service, thus strict SLAs are made to ensure that the vendor keeps the system in good shape.

The organization has lots of development teams creating business features. They try to contact the team maintaining the internal service because they need help or changes to the service API. Usually, there is no way to contact the external vendor’s team directly, only through tickets. Because changes and service requests have looser SLAs than incidents, they get deprioritized.

That causes development teams to have to wait. Eventually, the maintenance team answers the ticket, but rarely do things get solved immediately. Correspondence ping-pong starts and it takes a damn too long time to get anything done.

That might eventually lead to shadow IT. Business decides to work around the slowness and stiffness of internal service and build parts of the same functionality by themselves. That is a waste of resources, but usually, the only way to ensure business agility. I’ve seen dozens and dozens of “we have master data in SAP, but because we can't get support from the vendor maintaining the service, we have to build our own duplicated data storage”.

I believe that it is time for “modern managed services”. Help the IT organization and business, but do it in a more holistic, more modern way, to avoid the common pitfalls that the traditional managed IT services bring to the organizations.

Steer away from the local optimization and start describing and measuring the important value chains and the end-to-end value. Measure what your paying customers see. Measure how well your development teams can get help from other teams. Measure the speed from idea to production. Go from a system and ticket-centric approach to an outcome and service-centric approach. Enforce and measure how well external vendors serve the other teams, not just what is the uptime of the system.

IT departments are loved by the rest of the organization when they can efficiently enable and support business to create value. IT is there to help and enable, not block or be a bottleneck.

However, this tango takes two. The common responsibilities of an IT department cannot be forgotten, but some of them can be made as business decisions. What is the SLA of our online store? That should be a decision made by the business, not the IT department.

The business should know how much it costs them if the service is down, so it should be their decision to set the desired SLA to a sweet spot. Any higher would be a waste as increased SLA always costs more, any lower would be too little compared to the criticality and business value of the service.

Site Reliability Engineering tackles some of these issues. It brings down the unnecessary silo between business and IT, and builds a culture where you start measuring relevant things. Not just uptime or how many tickets and how fast did get solved. But instead, do the end users find the products they want to buy, or how well the external team managing some internal system has been able to serve dependent development teams?

Measuring what matters makes the traditional IT metrics business decisions. It enables outcome and service-based thinking, where value is measured end-to-end. Not just how well some individual system or vendor works.

We believe modern managed IT services partners should be passionate about both managing services but also help organizations to transform from an expensive but stiff ticket and system-based approach to the outcome and service-based approach with lesser total costs.