News/Trends, Tech/Engineering

Harvard Business Publishing Goes All-In for the Cloud

Alan Zeichick

Of the seven takeaways from a massive cloud migration project, says Harvard Business Publishing’s Ken Griffin, the final lesson is that the best way to manage risk is to commit oneself. No half measures, no long-term hybrid strategy. Griffen explained, “Having two data centers, one on premises and one in the cloud, no longer makes sense, and so we’re all-in on the cloud. Our local data center is technical debt, and our goal is to expedite its demise.”

Many of us read case studies in Harvard Business Review, but today’s lessons come from Harvard Business Publishing (HBP), a wholly-owned subsidiary of the university. HBP has three business units: the Harvard Business Review magazine and website, the Harvard Business School Executive MBA program, and the school’s executive education department.

Ken Griffin is Director of IT Services and Operations at the Harvard Business Publishing, and presented a case study at Interop 2015, held the last week in April in Las Vegas. Entitled, “Cloud Adoption Gets Serious, 2 ½ Years In,” the talk presented Griffin’s experience as a set of seven lessons learned.

HBP’s drive to the cloud started with a simple project in 2011: Migrating the Harvard Business Review magazine from print-only to digital. “We converted thousands of articles, developed mobile apps, and launched in November,” said Griffin. “We thought it would produce cost savings, but it didn’t happen.” When you publish digitally, you have to maintain, store, backup, and continue to improve on old content. “Plus, we still had to do a print edition,” he added.

Despite the lack of cost savings, HBP kept driving forward with new digital technologies because it was good for the business — and good for the organization. “It wasn’t for survival; it was to be relevant and provide a better service,” Griffin said.

As part of the drive to digital publishing, HBP decided to refresh its aging hardware — servers, routers, and other infrastructure — over a 12-month period. That’s when everything hit the fan. “We ended up being behind plan. By September 2012, when Harvard Business Review articles were ready for use by other business units, we literally nuked ourselves,” Griffin recalled with a grimace. “Customers were unaware, but we were in trouble. “

HBP solved its problems in the short-term by implementing an interim solution within its data center. “The escalated hardware refresh resulted in a private cloud using VMware, NetApp, Cisco, and Oracle Database Appliance,” Griffin said. The next step: long term planning. “We asked, what infrastructure do we need to offer a better service in three years? We drew the line in the sand with 2015. In 2012, the cloud wasn’t mature enough, and our data wasn’t ready either.”

By 2015, HBP expected, the cloud would be ready, and that’s where it would live; the organization chose Amazon Web Services as its platform. “AWS is the right answer for us, with more capacity than the nearest 12 competitors combined, global reach, rapid pace of innovation, and pay as you go,” said Griffin. Oh, “…And they’ve had 48 price cuts.”

First Lesson Learned: Without a plan, there is no victory.

HBP set out to understand and categorize its applications, and to come up with a migration plan. Griffin said, “We had 93 applications that had to move — and that meant at least 93 sets of meetings with stakeholders!”

His team came up with a matrix, and placed each application in a quadrant. In one direction, the application was either critical/strategic for HBP’s business, or it was not. The determining factor wasn’t the opinion of the application owner, but where the software fell into HBP’s existing corporate disaster recovery plan. If HBP could exist without the application, then it wasn’t critical/strategic.

In the other direction on the matrix chart, applications were categorized as easy or difficult to move. “Easy to move” included applications that were already in use as Software-as-a-Service or as Infrastructure-as-a-Service. “Hard to move” were those that were custom-written software or third-party applications such as Oracle Financials.

Griffin’s team set out to focus on the easy-to-move applications, especially those which were critical. “If it was easy to move, get it moved. It was important to show progress by moving the low-hanging fruit,” he said, adding, “If you could buy it as a service, just go do that.”

Second Lesson Learned: We needed an identity layer.

Many of the 93 applications officially identified for migration had their own user management system, such as for logins and admin privileges. Not only that, but Griffin’s team discovered lots of “shadow IT,” that is, applications that were not sanctioned or supported by the IT team, but which were important to HBP’s operations. One goal was to unify and establish one single identity layer to improve security and reduce risk.

Griffin explained that HBP chose two primary solutions: Ping Identity for customer end users (such as Harvard Business Review subscribers and MBA students) and Okta for employees. Those are in addition to the Microsoft Active Directory, which he described as the system of record for user authorizations. HBP implemented two-factor authorization for the Okta system, using smartphones, in order to secure SaaS usage.

Third Lesson Learned: Personnel requirements in the cloud really are different from traditional operations.

In the past, HBP’s IT department needed experts in storage and networking infrastructure. With the move to the cloud… not so much, said Griffin. He needed experts in AWS, and in different programming languages.

Fourth Lesson Learned: People, not technology, was our big hurdle.

Griffin cited the challenges for HBP’s staff, from admins to developers to business-unit stakeholders: “We were asking them to maintain current infrastructure, while also learning new skills, building out new infrastructure, migrating applications to the new environment, and decommissioning old environment — on the same salary.”

Fifth Lesson Learned: Excitement only lasts so long.

Griffin admitted that not all the staff could handle the transition and the new workload. This added to the challenge.

The initial excitement about the cloud migration lasted about three months. After that, the migration project became a grind, especially for the workers who were still maintaining the existing infrastructure and applications. “Doing this on top of your regular day job is too hard… for everyone,” he said.

Sixth Lesson Learned: Architecture is key, and AWS support can help.

Griffin talked about the importance of getting the cloud architecture right, especially when you are integrating your own applications with SaaS applications from Amazon and from other vendors like (which HBP also used). ”Help is available from Amazon; use it!” he insisted.

He cited one example of where an open collaboration was necessary. “We were planning on moving the Web, application server, and database server tiers to Amazon, and we did that with a proof of concept,” Griffin said. But the HBP team ran into scalability and performance issues. “[Amazon] said, why not deliver webpages from S3 directly to end users, with no Web server tier.” (S3 is Amazon’s Simple Storage Service, part of AWS.)

No Web servers in a cloud migration

What? No Web servers in a cloud migration?

Seventh Lesson Learned: For us, going all-in is acceptable risk.

Griffin is driven to shut down as many local servers as possible, as soon as possible. As he said at the beginning of his presentation, “Having two data centers, one on premises and one in the cloud, no longer makes sense, and so we’re all-in on the cloud. Our local data center is technical debt, and our goal is to expedite its demise.”

What if Amazon goes down? Griffin admits that HBP is totally committed to the Amazon platform, but he is not worried. He believes that the scale of Amazon Web Services will ensure that the service remains available and affordable. His main cloud worry is preserving his software and data against intentional or accidental deletion or corruption.

The answer: Backups. “We take our core repository and we back it up to another account in AWS,” Griffin said. That separate account is inaccessible to his software engineers. “At least we have another copy, if someone destroys our environment. In the future, I’m going to dump [the repository] to another cloud provider every so often, just to make auditors happy.”

Two and a half years after beginning its move to the cloud, the Harvard Business Review is fully migrated, and the rest of HBP’s infrastructure is heading in the right direction. Griffin believes that another six months or so will bring him much closer to his data center’s demise. That’s a story I hope to read someday in Harvard Business Review.

Learn more about the challenges CIOs are facing today as they go to cloud and they’re addressing them: