How the British Medical Journal ditched its old culture for a DevOps environment

James has more than a decade of experience as a tech journalist, writer and editor, and served as Editor in Chief of TechForge Media between 2017 and 2021. James was named as one of the top 20 UK technology influencers by Tyto, and has also been cited by Onalytica, Feedspot and Zsah as an influential cloud computing writer.

Picture credit: British Medical Journal

During a recent VMworld keynote, Pat Gelsinger, the CEO of VMware, gave special praise to General Electric (GE). For a company which was founded when Queen Victoria was still on the British throne, its continued innovations through cloud, analytics, and more has helped it remain the only company still standing from the original 12 listed as part of the Dow Jones Industrial Average.

The British Medical Journal (BMJ), founded in 1840, a full 52 years before GE, is another case in point. The company’s expansion over its storied history now encompasses 60 specialist medical and science journals. Its infrastructure grew with it; but with time at a premium, and new products to launch, there was little to scope to examine and evaluate the architecture. An expiring hosting contract gave the journal time to breathe, however, with the BMJ selecting managed hosting provider Datapipe to help them through this digital change.

Sharon Cooper is chief digital officer at the BMJ. Having previously been CTO since 2012, the parallels between then and now are stark. “Like any company, we had a lot of legacy systems,” Cooper tells CloudTech. “One member of staff threw their laptop on my desk after a business trip referring to it as ‘as much use in a sales meeting as an etch-a-sketch’.” This meant that the whole company was running on Lotus Notes and Windows XP. Employees used third party cloud storage systems and forwarded email to home accounts to help get their job done.

Today, Cooper insists that the cloud storage provided by the company is just as good as anything else. But this is just the icing on the cake, the baubles on the Christmas tree, or whichever metaphor you prefer. Underpinning the journal’s transformation is a concerted move to DevOps and agile processes.

Back in 2012, there would be on average one release a month with “several people standing around whilst a manual process that took the best part of an afternoon played out”, as Cooper explains. Now, it’s up to four times a day. The working relationships between dev, ops, test and business needs is “unrecognisable” from before. “One of our product owners was disappointed he didn’t have a ‘big bang’ release [that] one of the devs built an Android app in an afternoon with a big red button on it – to bring back the sense of ‘ta-da’,” says Cooper.

As the team and collaboration aspects changed, the infrastructure was changing with it. In total, more than a dozen suppliers were long listed, which then became five, and eventually three. The shortlisted firms were given some code and asked to stand it up; and Datapipe came out on top. “Some vendors draw a line – you’re either fully managed or not at all, but Datapipe had the flexibility and the know-how to work BMJ’s way,” said Alex Hooper, BMJ’s head of operations.

This partly refers to the fact that the BMJ’s environment is not the easiest to work with; they operate on a separate managed service outsourced platform. But the results spoke for themselves; alongside the already-mentioned much improved release cycle, content and services are now built and delivered around APIs as opposed to weekly batch file transfers, while more than 200 virtual machines run applications 24×7 in a private cloud infrastructure.

Plans for the future, however, will aim to see workloads being moved to the Amazon Web Services (AWS) public cloud. Cooper explains that some workloads are not suited for public cloud, such as development environment, but moving over without any interruptions, and ensuring maximum cost reduction, is equally important.

“We have some experience in this, having moved between two private clouds recently,” says Cooper. “Generally, we’d move the application servers across first but leave the data stores in the old data centre – we had a VPN set up between the two cloud, and all the data traffic flowed across that. Then we’d replicate the databases between data centres and switch to the replica in the new data centre.

“This worked very well, easily taking the 200 request a second authentication traffic until we finally moved that system across,” Cooper adds. “Getting that hybrid architecture right between private and public cloud will be key.”

For organisations in a similar boat, Cooper advocates several points to consider. Think about the problem you are trying to solve before jumping in, work out where your talent is – “you can outsource the doing part, but don’t outsource all of the understanding” – manage expectations, and build in contingency plans. Above all, however, is the importance of getting employees onside.

“You need your team to buy into the change,” Cooper explains. “Infact, I can’t take much credit at all for our modernising programme in detail. I set out a very clear place I wanted to get to – it was very business-focused, it was really clear just how critical that back office ops team was in ensuring our customers got what they wanted – and why I wanted them to change to improve that customer experience.

“How we got to that future state was really determined by the team,” adds Cooper. “They worked out the detail, they changed significant parts of their jobs, built really strong working relationships across the team to deliver. I’m immensely proud of my team – it has been their dedication, hard work and preparedness to change that has made this work for us.”

View Comments
Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *