Why IT consultancy had to change

null

I don’t know if you’ve noticed, but IT consultancy has been undergoing something of a revolution over the last few years.  

You know the traditional model: the senior consultancy partner shows up in a slick, freshly pressed Armani suit, with an entourage of freshly indoctrinated graduate program survivors in tow. The offer is beguiling: leave this to us, they’ll say, we’ll take care of your data centre migration, your operating system upgrade, your content management solution. Don’t worry yourself about the details, just sign here on the dotted line.

Before you know it, the junior suits are churning out chunky technical design documents for review and sign-off by mid-level execs who, broadly speaking, lack the critical technical skills to adequately evaluate them - this lack of skill being, of course, the main reason the problem is being outsourced in the first place.  Gantt-chart driven delivery commences, and after a few missed deadlines, the system goes live, and even mostly works. Back-slapping and celebratory lagers all round.

The project’s done… now what?

So far so good, but now the system is in the hands of the users, and generating business value. The friendly faces dotted around the office to help phase in the new system have disappeared, replaced by equally friendly, but ultimately less capable help desk operatives from another shore.

The only constant in business is change, but it turns out that making changes to this system now that it’s live is a very time-consuming and error-prone process, involving paperwork change controls, and manual work performed by individuals who have no bigger picture understanding of the system.

You look around for the original set of domain experts to help with that understanding, but the graduates that weren’t burnt out by the original project have metastasised into other parts of the business, ready to take over another part of your infrastructure.

Gradually the brighter members of your development team drain away, demotivated by fortnightly change advisory board meetings, missed SLAs and the sort of ennui that can only come from never feeling like you’re achieving anything worthwhile.  But still, annually, you send six- and seven-figure sums of cash to your IT outsourcing captor, wishing you could move more quickly.

Does any of that sound familiar? It has been going on in medium to large businesses all over the world, leaving them slow, dumb, lumbering beasts.

A better approach

This isn’t the case everywhere, however.  Smarter businesses have realised that, regardless of what market they’re in, they are now technology companies, and that to compete and stay relevant in the modern world, they need to move more quickly than their outsourcing arrangements permit. With the broad popularity of modern automation tools and public cloud infrastructure providers, larger organisations have been waking up to the fact that they can iterate on their services more quickly by taking back control of how and where they’re delivered.

To achieve this type of delivery, companies need to come up to date with modern DevOps practices.  A term first coined by Patrick Debois in 2009, the term refers to a culture of practice in which developers and systems administrators work collaboratively to deliver working software quickly and safely into production.  This movement came about as a reaction against antagonistic environments in which development teams, incentivised to deliver features quickly, would throw their code over the figurative wall into operations teams, who in turn were incentivised to maintain stability. This sort of incentive mismatch causes conflict between teams, and is exacerbated still further in the type of IT outsourcing model I described earlier, where there are clear contractual penalties for instability or breach of SLA.

How do businesses pick up these skills if they’ve lost technology talent during the outsourcing period?  It can be challenging (though not necessarily impossible) to hire full time DevOps engineers at the level of skill necessary to drive the sort of transformation that is now required - and no doubt there will be existing staff who need to be retrained.

I’m not suggesting that engaging external organisations is inherently bad - you can bring in companies with DevOps expertise.  The key here is to choose a partner who will work in tandem with your own team, sharing skills and knowledge with those who are willing to learn. The key point is that it is important not to become dependent on yet another external supplier, and a consultancy with the correct cultural alignment will work to share their skills with your team, leaving them self-sufficient before moving on.

I get asked a lot whether large enterprises can really take advantage of DevOps principles and structures, or is it better-suited to smaller startups? In my view, DevOps principles can be adopted by businesses of any size with the right implementation. This culture of practise in which developers and systems administrators work collaboratively to deliver working software quickly and safely into production isn’t unique to startups, even though these are often seen to have an agility advantage over more traditional organisations.

Very few of the barriers of moving from legacy IT to DevOps in larger companies are to do with the technology. As touched on previously, with traditional IT outsourcing, businesses divest themselves of responsibility for understanding technology, positioning the problem as one of contracts and SLAs. To succeed at DevOps is to recognise that certain technology activities are fundamental to the business mission, and that to deliver on these it is important to have the technology skill in-house.

Willingness to change and gaining buy in from key people within the business are the most important factors, but it’s also important to understand that a lot of the technology challenges here are not unique - there’s no need to reinvent the wheel; experience and expertise are both available in the consultancy market, where it’s possible to engage without reverting to old outsourcing behaviours.

Only by building an internal DevOps capability will you be able to take back enough control of your IT infrastructure and move quickly enough to succeed.

Jon Topper, Co-founder, The Scale Factory
Image source: Shutterstock/Pressmaster