DEVOPSdigest

Tommy Cooper, the late great British magician and comedian had a great routine. Walking on stage holding a framed painting and a violin, he'd say, "today I bought a Rembrandt and a Stradivarius, but there's a problem – Stradivarius was a lousy painter and Rembrandt made terrible violins." He would then smash the violin into the painting – hilarious.

In IT we have our own Rembrandts; development artists increasingly tasked with differentiating the business through awesome code. Over on the operations side we have the instrument maestros - those that keep aging infrastructure banging out tunes, or who slavishly provision server instances at the request of developers – a kind of you-hum-it-I'll- play-it type of arrangement.

Over the course of many years both groups have learned many tricks to improve their individual and separate artwork. For Dev, that recently includes agile management for faster iterative style development, while in Ops, best practices such as ITIL have helped pave the way for more service-centric IT delivery.

Message to IT Ops – Get with the Program or Get Out of the Way

Times are changing. With the imperative to deliver applications faster, developers are increasingly stepping outside their traditional skill-zones and leveraging new automated capabilities – allowing them to develop and test in parallel, while releasing software continuously. In essence, and analogous to the Rembrandt and Stradivarius skit, they're not only writing great music, but also building the instruments upon which to play it.

All this is becoming far more realistic because of cloud, open source and interoperable solutions. Now, tools like Jenkins and GIT have facilitated continuous integration, newer storage systems like MongoDB and Cassandra can be installed in minutes, while a plethora of infrastructure-as-code products enable developers to describe or codify how an environment should look and have it built automatically. They also have access to a vast range of monitoring utilities and widgets for performance insights at an element level.

So what's left for our IT Operations master violin makers? Is their work actually needed anymore?

Well yes it is – but only if the discipline can be transformed. This involves less running things and more "crafting" capabilities others will use to build operational excellence into the fabric of everything developed.

Inconvenient truth: Developers Code First and Worry About Operations Later

It's no stretch to state that even with all their new tools, aspects of operational excellence like maintainability, resilience and supportability are not top-of-mind for developers. And even if there are concerns, one team's approach to establishing these could be less rigorous than another's.

For example, with minimal research a development team could install, configure and monitor a non-SQL database for group usage in a matter of minutes, but will probably be oblivious to major operational performance, scalability and optimization concerns. Concerns that only get addressed when the application reaches operations – and then only after lots of pushback and conflict.

This operational blind-spot is an opportunity for IT Operations to take their considerable expertise in reliability and resilience engineering and help other teams incorporate it into what they develop, build and test. This means no more waiting to see how things turn out in production, but working collaboratively to craft improvements all across the software development lifecycle.

Essentially therefore, IT Operations becomes very much more front office – not just keeping the technical lights on, but being the craftsmen everyone calls on to make the business lights shine brighter!

In this dynamic context, Operations will develop mechanisms and utilities other teams will use repeatedly to build quality applications faster. So rather than mundanely spinning up virtual server instances, IT Ops will construct more complete automation developers use to provision environments as code is released.

Rather than watching alarm storms across many production consoles, these new agile operations craftsmen will provide developers access to pre-production monitoring capabilities so that code defects can be resolved before they hurt the business. As such, monitoring will come out from behind the "production curtain", providing teams with rich and realistic performance information for more reliable testing.

Agile Operations – New Craftsmen and Trusted Advisors of Operational Excellence

New agile operations craftsmen will become trusted advisors across the organization. This doesn't mean running a separate, silo'd team of experts, but using them to infuse operational excellence into everything.

Naturally, this will mean providing automated capabilities to ensure resilience in new modern architectures, but it also extends to providing good old fashioned guidance on what'll help make an application more supportable – especially when they fail at 3:00am and every team starts playing blame games

Of course developing agile operations craftsmanship will be harder for some organizations, especially those who haven't been good at establishing effective feedback loops with development. Without the intelligence gained from scalable application performance monitoring and analytics, teams could be procuring unneeded capacity (increasing project cost), or have releases delayed. Do this repeatedly and development will naturally question operational capability.

Worse still, it could be the impetus teams need to overrule operations and push software changes to production by default. That's tough medicine for operations, but potential suicide for business – especially if along with performance, other elements like compliance and security are neglected.

IT Operations remains essential, but the discipline needs to change. Re-engineer your role to become digital maestros and craftsmen, or risk being bypassed by anyone who can build a half decent violin.

Pete Waterhouse is Senior Marketing Strategist at CA Technologies.