Making the Case for a ‘Technologist as a Service’ Model

For decades, third-party IT service arrangements have generally been structured one of two ways. There are the “break-fix” scenarios where an outside team is on call, either physically or virtually, to patch up whatever goes on the fritz. Then there are the much more involved “consultative” relationships where an outside team gives high-level strategic advice and may (or may not) stay on to carry out a big-ticket project.

Each arrangement is valuable in its own way. Most organizations don’t have the skills or the resources to handle every IT challenge, so bringing in break-fix specialists and consulting teams gives them a certain amount of short- and long-term coverage.

But what about IT problems that don’t fit neatly into one of these two buckets? Who deals with those? What if an issue involves more than a quick fix but less than a full-on engagement with a team of highly paid consultants? What if a problem is hard to diagnose, given the complex mix of IT dependencies that’s developed over time with vendors, partners, and internal technologies? What if one issue seems to be creating others? What if the problem comes and goes, phasing in and out with different degrees of urgency?

What’s needed is a new, more flexible model structured more like the cloud itself, where skilled resources can be dialed in and out at will. The model could ensure that a skilled technologist – or a team of them – is on call not only to fix things but also to help stave off other issue in the future. If you can contract for SaaS (software as a service), PaaS (platform as a service) and even DRaaS (disaster recovery as a service), is there room for a new interpretation of the four-letter term “TaaS” to describe the hiring of a technologist as a service?

A new direction

Of course, every technology service arrangement, by definition, involves technology professionals delivering resources “as a service.” They’re sent in by an outside party, and they leave when the job is done. They help with technology, and they perform a service. Within these arrangements, service providers will often try to customize their services to cover specific client needs. So, one could argue that “technology as a service” is already happening.

But the idea of having a technologist as a service, available to play a more flexible and strategic role, stretches the typical service model in a new direction.

Prototypical break-fix and consulting arrangements are both, by and large, transactional in nature. For a certain fee, a third party will get malfunctioning servers, storage devices, routers, or software configurations running again when they break down. Or it will guide an organization step by step through a project, such as a multistage cloud transformation involving a large number of departments. Either way, the service is narrowly defined and based on the completion of a series of transactions.

A TaaS model could be structured more flexibly – striving to be relational rather than transactional. In other words, the IT customer wouldn’t settle for a service-level agreement (SLA) mandating certain levels of uptime. It would bring the technologist into the fold, onto the IT team, and then leverage the relationship between the team members to accomplish short- and long-term goals.

Skill and empowerment

The success of this kind of model depends on two important factors: the skill of the technologist and the level of empowerment the customer is willing to award.

First, skill. In break-fix arrangements, the technology professionals doing the work tend to be skilled in their own fields – able to trouble-shoot specific technologies and solve specific problems as outlined in the SLA. Their mandates are narrow and specialized.

For a TaaS arrangement to work, the technologist (or team of technologists) has to have a broader skill set. The person must understand the technology that’s involved on a deeper level – not just how it works and how to repair it when it fails. He (or she) needs to know how the technology interacts with other platforms and how the workloads that leverage the technology deliver business outcomes for the customer.

Second, empowerment. To tap the value a TaaS can provide, an organization must be willing to make the technologist a partner in the delivery of business outcomes and give the TaaS the responsibility to identify problems and pursue solutions. In the best cases, technologists are engaged tightly enough that they identify areas most in need of improvement. This could involve proactively preventing the next outage from happening or improving the overall performance of a platform. Technologists as a Service could accomplish this if they approach the technology implementation as an opportunity to drive customer outcomes, not just fix a technology.

TaaS engagements

What kinds of engagements fit between the break-fix and consultative arrangements, where a TaaS would be a valuable solution? Basically, there are two.

There are situations where the customer wants to achieve an outcome as part of the overall engagement. The customer will want the technologist to understand the problem, define the outcome, and bring a team to the resolution.

Then there are situations where a customer needs advice and guidance about the technology it’s using and its future plans. For example, the customer may want to implement a new method of automation or a new feature that creates interoperability between two vendor components. The customer will need an expert that can understand the technical part of the request, suggest best practices to optimize the technical implementation, and lead the outcome that the customer is trying to drive.

Many IT problems are simple, repeatable events – like patch installations or upgrades. These events have traditionally been handled by the IT staff without incident. But they can be time-consuming and disruptive. Having a person on hand that’s engaged with the whole IT environment – not just a single-vendor platform – can anticipate points of stress on the environment and help IT directors manage them in a holistic manner.

Others are more complex. Say, for instance, that IT wants to migrate an engineering workload within a week. Having a resource on hand to ensure the networks, storage, and compute instances are all capable of taking on higher levels of performance could save the organization from having to redo the project if it goes awry.

The bottom line

As IT environments grow more complicated, IT leaders need help keeping them in tune. Traditional service options can’t do it alone. IT leaders should look to add new, more flexible resources that can save them time and deliver the outcomes business requires.

To learn more about HPE’s Assigned Technology Specialists, visit hpe.com/services/completecare

____________________________________

About Nishanth K. George

IT Leadership