6 Processes You Need to Mature Your Managed Services

Are you struggling to rapidly mature your services?

You’re probably not alone.

As Director of Solution Engineering at INAP, I see how tough it can be for my customers. All of them know their particular business sector, and the vast majority are highly technology-literate, but that doesn’t necessarily make managing technology-based services any easier.

IT Infrastructure Library (ITIL) is a logical process framework to start from and build upon, but even more fundamental is to construct a set of Minimum Written Processes.

In the interest of full disclosure, I did not come up with these myself; this checklist is something that I learned from others during my career—and directly corresponds to concerns and challenges that I hear from INAP customers. What I’ve found through my experience is that if an organization has these minimum processes, it is well on its way to maturing its managed services.

There are six Minimum Written Processes required to have a managed service:

• Installation
• Monitoring
• Troubleshooting
• Recovery
• Changes
• Decommission

Let me explain each in a bit more detail.

Installation

Having a written process for how to install a new customer provides a path for consistency and standardization between customers. This also allows you to implement a new customer without affecting any others.

Consistency can be a double-edged sword though. If your installation process is workable, then you can have anyone in your team successfully implement a new customer. On the other hand, if there is some mistake in your process, you’ve replicated it with every new customer. That being said, even with a mistake in the installation procedure, you have done so consistently and can go back and rectify accordingly. This is far preferable to a random error that requires an audit of all customers. A defined installation process loosely addresses release management within the ITIL management framework.

Monitoring

An effective monitoring plan will let you know when your service has stalled and will include billing and reporting as well. Monitoring data is used for capacity management, which fits within the ITIL framework, as does financial management, which partially comes down to how billing should be done. This can be a flat fee or usage-based. If usage-based, then a feed of data is needed to determine each customer’s usage, which might be gleaned from monitoring systems. For example, many AWS services have charges based on usage, such as with Route 53, Elastic Load Balancing or S3.

Troubleshooting

If you are monitoring the uptime of a service, then you need to prepare your team for what happens when any given alarm is tripped. For example, if a server happens to halt, I want to know about it, and I want my team to follow a troubleshooting process to determine the failure and be prepared to announce the impact to affected customers. Again, in the ITIL framework, this has tentacles into incident management and problem management processes.

Recovery

If I am troubleshooting something, there is a strong chance that there is a component failure and I need to replace something. Put another way, an upgrade can be thought of as a planned recovery effort, so this process has a dual purpose. For example, say I have a failed firewall and a spare on the shelf. The same process used to install a replacement firewall might be identical to installing a higher-capacity model.

Changes

Once you build the environment, part of managing it is adapting to minor changes. Changes for users need to accommodate personnel changes like new hires, departures and name changes. There are also minor configuration changes to be concerned with, such as firewall rule or backup policy changes and the like. What you want to avoid is having to flush and recreate a user or a component configuration; it’s far easier to adopt processes that allow for easy changes. Linking back to ITIL, this addresses a big portion of change management.

Decommission

Customers will eventually stop using one of your services. Many firms lack a process to disconnect and decommission a former customer.

I once worked at a startup firm that was acquired by a much larger one, and in a bout of reverse acquisition, we ended up inheriting the larger line of business—the one we had previously competed against. In the interest of standardization and efficiency, we decided to consolidate the larger firm’s monitoring configurations into our own monitoring tools.

Unfortunately, the larger firm never had a decommissioning process and would just suppress alarms, which put them to sleep but didn’t eliminate them. During the ingestion process, the monitoring configurations were imported, and the suppressed alarms become active. All those monitors tried to poll for old customer equipment, some of which had been gone for years.

We found ourselves going from a manageable number of alerts to several hundred thousand alerts each month. A proper decommissioning process—rather than a workaround—could have saved us a lot of trouble.

It’s not uncommon to have resources reserved for long-departed customers, and it takes audits to determine their departed status. Instead of going through audit cycles, it makes more sense to have a process to notify operations to decommission a recently departed customer.

One Process Doesn’t Fit All

Checklists are great things. I like to go backcountry hiking in the Rocky Mountains, which entails loading up a backpack for a multiday adventure in the wilderness. I usually plan out all the things that I need before I even leave home and have built a standard checklist of things to pack. Some things on my backpack checklist are very specific, such as a water filter, a stove, my sleeping bag. Those items never change.

Then there are items on my list that allow for some flexibility, depending on the trip: for example, 2,000 calories of food per day. My checklist doesn’t have exactly what food to take, just that I need that much. Similarly, this framework doesn’t say exactly what the process will look like for you, just that you need a process for it.

If you are building anything as a service, you will eventually get to these minimum processes. Instead of falling into processes by happenstance or trial and error, it is far better to determine a checklist of minimum processes before releasing a service. Having these defined when you release your service will put you in a far better and more mature position to support the entire customer life cycle.