What Would Downton Abbey Look like with a DevOps Makeover

I’m no great lover of English costume dramas, but I occasionally watch Downton Abbey on the TV. Even though Australia has been my home for 20+ years, it’s probably the Brit in me that gets a chuckle from watching how historical events and social change impact post-Edwardian social hierarchy – ok, the aristocracy and their long suffering servants.

So thinking about DevOps with its focus on communication and collaboration, what changes would I make at Downton Abbey and how are these analogous with the way we should be running our own IT ‘stately homes’ and period pieces. There are more similarities than you’d think.

One of the main characters in the show is Carsen the butler. Carsen is in charge of the pantry, wine cellar, dining room, plus a swag of underlings. He’s worked at Downton for years and is a father figure to all the other servants. I like Carsen, but there’s a problem - he leans towards nostalgia and resists change (like the installation of telephones and electricity in the house). Now while it’s admirable that Carsen has exacting standards, his gruff immoveable leadership in the face of progress is why I’d still give him his marching orders.

Do you have any Carsen’s working in IT? Like the aforementioned old-retainer they’re not hard to spot. They’ll be equally resistant to change; weaving a mantra of “if it isn’t broken, don’t fix it” into the cultural fabric of your organization. Worse still they might even be rewarded and compensated according to their own “exacting standards” – like deliberately holding back necessary change in the form of software releases. In other organizations that have great teams, DevOps benefits are nullified because our “Carsen’s” persist with manual methods and unnecessary procedures-the bottleneck in our continuous delivery goals.

My Downton DevOps Tip: Never underestimate the time, cost and effort involved in building a strong DevOps culture. Think big yes, but be prepared to enact immediate initiatives to drive the necessary behavioral changes across IT teams and staff.

Ever watched meal time at the Abbey? It’s a meticulous procession of over-the-top food bling, all served up from unblemished silverware at precise times (dinner at 7 M’lord). Furthermore, all the food is produced on the estate, meaning lots of manual prep work before anything warm and edible finds its way from below stairs to the grandeur of the dining room.

In many ways the chaos behind meal times at the Abbey resembles our own traditional software production line, doesn’t it? In our IT version of the show, Dev teams work on different but interdependent software elements, meaning teams have to wait for other components to be completed. Teams have become adept at continuous integration, but manually creating and configuring testing environments takes time and creates more bottlenecks. Worse still, constraints and lack of reliable data cause teams to delay testing until the end of the cycle, when any defects require more rework and become more costly to correct.

My Downton DevOps Tip: Always remember that more tools doesn’t necessarily mean better automation. Look for modern techniques that remove constraints so that teams can work in parallel, integrated with automated testing for quality acceleration. Consider to release automation so teams so can easily create a comprehensive plan from all the activities performed by isolated tools.

The real Downton Abbey (Highclere Castle in Carnarvon) sits on approximately 1,000 acres of land (that’s larger than central park in New York). I haven’t been able to determine the exact number of rooms, but it’s probably in the low hundreds, with 50 plus bedrooms. That’s a mammoth maintenance chore and a heck of a lot of real-estate to keep in good order for the relatively small fictional family that hunkers down within the Abbey’s walls.

Again, there are parallels we can draw, especially managing our own heritage – monolithic applications. For years we’ve invested in complex, tightly coupled systems to support our business processes and serve our customers. With these, our dominant position has been working tirelessly to prevent failure and minimize risk – but that’s changing. Now, mobility and social media means we must become more responsive to customer behaviors through the experimentation and continuous delivery. 

As such, we’ll still support the monoliths, but also architect, develop and monitor independent services. Even “inviting” business partners to share the spoils via secure API’s. In this new world, design for failure becomes emblazoned on our organizational “coat of arms” – acceptance that in an application economy, the goal isn’t to prevent failures - but rather contain and recover from them quickly.

My Downton DevOps Tip: Whateveryour application architecture strategy the likelihood is that SOA styleMicroservices will need to coexist with monolithic applications. Seek outprocesses and tools that support both methods. Also, resist the urge to formdedicated DevOps teams associated with one style of design. This can result inisolated ‘aristocracies’ that’ll isolate your DevOps initiatives.

Watching the trials and tribulations of the English upper-class and their servants played out against a backdrop of social and political upheaval makes for compelling viewing.  Butthat’s pure fiction compared to the real business challenges facing IT everyday. Now is the time to embrace DevOps as the defining set of principles your business needs if it’s to survive and thrive in the application economy.