buchachon - Fotolia

Interview: British Medical Journal’s CDO talks datacentres, DevOps and desktops

BMJ’s chief digital officer explains how the 170-year-old healthcare publication has negotiated several major digital transformation projects since she joined in 2012

As far as Sharon Cooper, the British Medical Journal’s (BMJ) chief digital officer, is concerned, her job is to ensure the healthcare publisher is free to pursue its business goals without technology standing in its way.

In the four years since she joined the organisation, Cooper has followed this mission statement to the letter by pushing through several major digital transformation projects focused on reducing its reliance on legacy technologies, while increasing its business agility by adopting DevOps.

The BMJ is wholly owned by the doctors’ trade union, the British Medical Association (BMA), and started out as a single journal, written solely with the research needs of UK doctors in mind.

“We have grown over the last 10 years from publishing one journal to having 60-plus products and we are now a global business,” says Cooper.

When she joined the BMJ, firstly as CTO, in September 2012, its IT infrastructure was “curling at the edges” and struggling to cope with the demands placed on it by its expanding business interests.

“We had infrastructure that had been in place a long time that we knew was going to be replaced and we had things we were not making nearly enough use of or looking after, creating a lot of frustration across the whole company,” she says.

“Not just from end-users, but from the staff in the technology team because the infrastructure didn’t really do what they needed to be efficient at their jobs.”

Surveying the digital landscape

After taking stock of all she had inherited, Cooper pressed ahead with a desktop transformation project, within six months of joining, that saw BMJ upgrade from Windows XP to Windows 7 and ditch IBM Lotus Notes in favour of Google’s cloud-based productivity suite.

“We had a global staff base with one person in Brazil, another in Saudi Arabia, two people on the west coast of the US, and so on,” she says. “But while we had this global reach and coverage, we had absolutely no scale.

“Google gave me the ability to manage and provide a really good collaborative working space for all our users, regardless of where they were in the world, without any need for infrastructure.”

The organisation also began to investigate ways to update its back-office systems, paving the way for the retirement and replacement of its on-premise CRM system with Salesforce’s software-as-a-service (SaaS) offering.

Setting the agile agenda

Then, in 2013, Cooper’s attention turned to increasing the output and efficiency of BMJ’s technical teams by encouraging them to adopt agile working practices.

“We brought in agile coaches for a year who worked with the team, so there was a huge amount of learning on the job for our developers,” she says. “The operations team started thinking about what they would need to do to support that.

“At the beginning, some people thought it was just a phase, but I was very clear – I don’t care how you do it or what methodology you use, but we have to do this because the way we work is unaffordable.”

To emphasise this, Cooper says it used to take the technology team up to 10 months to get a product shipped and out of the door, and the company was averaging about one code release a month.

“We were not delivering enough for the number of people we employ here, and working in a more agile way allows us to deliver what the business needs us to do,” she says.

“Working in a more agile way allows us to deliver what the business needs us to do”

Sharon Cooper, BMJ

The BMJ now averages about four code releases a day, causing minimal disruption to the organisation’s day-to-day operations, thanks in no small part to its decision to automate as much of the deployment process as possible.

“Our biggest challenge now is that the technology team is so high functioning and can get through things so quickly, the company is having to learn how to deal with having a team that is always saying to them, ‘what do you want us to do next?’ instead of, ‘come back later because we’re busy’,” she says.

But getting to this point has not been without its challenges, particularly when it came to getting everyone in its technical teams to appreciate that agile working practices were the way to go.

“We didn’t lose a lot of people through the process, but those who were absolutely not prepared to change are no longer with us, and we brought in people with those skills and experiences,” says Cooper.

“So, as the team with no agile experience was learning all about it, we were bringing in people with those skills, so they could see how other people did it and learn from them.”

Fostering trust

Another challenge that companies often encounter during the early days of DevOps is fostering a culture of trust between the – traditionally – disparate developer and operations teams.

“One of the things we’ve got rid of is the animosity that used to exist between the two groups,” says Cooper. “We dealt with that by encouraging them to work together, while allowing them to do it on their own terms and through coaching specific individuals whose behaviour was not quite where we would like it.

“It has taken two-and-a-half years, and ops may still not trust devs to do everything, but they trust them to do a good job and they will go in and check what they are doing.”

DevOps and the datacentre

The move to embrace DevOps also required an overhaul of BMJ’s datacentre infrastructure, which was home to a private cloud environment that the organisation used to host its public-facing websites.

But, as the organisation’s continuous delivery ambitions gathered pace, Cooper says it soon became clear that its incumbent datacentre provider might struggle to provide the long-term support required.

“The change in company culture and how the team works had to be coupled with a change in the way our infrastructure was built from the ground up,” she says.

“We did a lot of that at our old datacentre, but it became clear – when the contract for that site came up for renewal – that they couldn’t support us in where we wanted to go, so we re-tendered.”

BMJ’s old provider took a multi-tenanted-type approach to hosting its IT, which meant that if the hardware running it malfunctioned, several of its services could be knocked offline.

With subscribers paying to access these services, eradicating downtime was a top priority for BMJ, prompting it to seek out the services of managed hosting provider Datapipe, says Cooper.

Working with Datapipe

The organisation moved out of its incumbent provider’s datacentre in June, with its technical team working side by side with Datapipe’s architects to oversee the migration.

“We utilised the Datapipe team to build out the underlying infrastructure, working our team so it was configured the way we needed it to be,” she says. “But from that point on, the internal team rebuilt and moved everything with Datapipe architects.

“There was significant rework to some of our applications to make them work our planned, fully virtualised environment, including the rebuild of one critical application database from Oracle to Postgres.”

The first wave of kit to move over was the infrastructure that underpins BMJ’s public-facing websites and the access and authentication systems that allow its subscribers to access their resources from all over the world.

“The team doing it looked at me in absolute horror when I said their key performance indicator [KPI] was that the customer couldn’t notice we had moved and we did it. We moved all the stuff over and nobody noticed,” says Cooper.

The rest of the year will be spent rebuilding and moving BMJ’s development infrastructure from a server room in the basement of the BMA’s offices to Datapipe, says Cooper.

Read more about DevOps and datacentres

The organisation is confident the move will help it build on the improvements it has already made in terms of the time it takes to spin up new developer environments for its DevOps teams to use.

“In 2012, it would take us two to three weeks to build a new environment for developers to start working,” she says. “Now, as we move into Datapipe, it’s taking us two hours and we reckon we could get it down to a couple of minutes if we use more automation.”

Next on Cooper’s agenda is ramping up BMJ’s use of public cloud, beyond dabbling with Amazon Web Services (AWS) for development and testing and data archiving purposes.

“We run that through the Datapipe dashboard and our plan is to move some of our capacity out to the public cloud over the next couple of years, but it’s working out what we want to move out there,” she says.

“What we’re really interested in with public cloud is the capacity to burst out if we suddenly get huge peaks in usage, and what we wanted in Datapipe was a datacentre provider that could give us that without us needing to manage two or three separate relationships, and that’s what we’ve got.”

This was last published in September 2016

CW+

Features

Enjoy the benefits of CW+ membership, learn more and join.

Read more on Datacentre capacity planning

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Sounds like they really went for the investment, put in the time and resources that it takes to update legacy systems and old methodologies. I'm sure it wasn't easy. 
Cancel
It also sounds like they moved to outsourcing and the cloud every opportunity they had.  What happened to all the staff they had in-house that used to manage all this stuff? 
Cancel

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataManagement

Close