Using a Cloud Center of Excellence (CCOE) to Transform the Entire Enterprise

Large enterprises beginning a transformation journey often find that they already have pockets of transformation that have escaped notice. But why haven’t good practices spread from these isolated corners of the enterprise and transformed the rest of the organization? I think the answer is that transforming the whole of the enterprise requires…well, a large transformation. The enterprise must find a way to make its deep changes scale broadly until they reach critical mass. Pockets of innovation, as a general rule, don’t have the leverage it takes to cause a global change.

In this contributed blog post, Milin Patel, the Principal Architect and Co-Founder of Rearc and formerly the Head of DevOps of Dow Jones, talks about Dow Jones’s move to the cloud and DevOps, and the organizational changes this shift inspired. Fundamental to their transformation strategy was the use of a Cloud Center of Excellence (CCOE) to gain leverage across the enterprise for the change initiative. It is tempting to think of a CCOE as just a team of experts who can be consulted for their knowledge of operating in the cloud. But as Patel points out, a CCOE can be much more than this: it can be the driver of change across the enterprise, the focal point for transformation that is broad as well as deep — the Archimedean lever that moves the world, or at least the enterprise.

Thank you to Milin Patel for providing this how-to guide on how to set up a CCOE that can drive organizational change.

— Mark

Building a Cloud Center of Excellence (CCOE) Team to Transform Your Tech Organization

By Milin Patel

I have been very fortunate to be involved in a few enterprise IT transformations over the past five years. It all started at Dow Jones under the leadership of Stephen Orban, who was CIO at Dow Jones at the time. I was tasked with figuring out a new way to build and run software in the cloud so that Dow Jones could stay relevant and cater to constantly changing customer demand. Stephen is currently the Head of Enterprise Strategy at Amazon Web Services (AWS) and talks in detail about our journey in his upcoming book, Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT. I can only add that the three years I was leading Dow Jones’s DevOps transformation were the most fulfilling and rewarding years of my career. So much so, that I have partnered with other colleagues from this journey, including Mahesh Varma and Chad Wintzer, to found Rearc, a business that helps other companies unleash the potential of DevOps and the cloud.

Our success at Dow Jones and Rearc can largely be attributed to making developers the focal point of the transformation journey, and treating them as paying customers. My goal with this blog is to inspire leaders looking to transform their organization with my experiences building and running a successful Center of Excellence (COE) team at Dow Jones. The COE team at Dow Jones enabled the transformation of our software development and operations practices. While this COE story is mostly geared toward cloud and DevOps adoption, the six-step approach I outline can be applied to solve other problems across your organization as well.

From my perspective, the goal of a Center of Excellence team is to take a large, widespread, deep-rooted organizational problem and solve it in a smaller scope with an open-minded approach and then leverage the small wins to scale it across the organization.

Dow Jones is a more than 125-year-old news and business information company, and has been innovative in its ability to deliver news information in new ways. Its flagship product, The Wall Street Journal, has been a subscription-only website (www.wsj.com) since its launch in 1996. By 2013, WSJ was seeing a big shift in consumer behavior around consumption of news and media content. Their readers were looking to consume news on their phones, tablets, and other connected devices on the go, all the time, and they expected Dow Jones to provide a seamless digital experience across devices and platforms. Print-based businesses had been experiencing a slow decline for years, but all of a sudden, even the digital businesses were being challenged by freemium news sites, digital upstarts, and tech giants. In order to meet their readers’ needs, Dow Jones had to deliver new products, features, and experiences at a very fast pace. They had to experiment, learn, and adjust quickly, but they were just too slow.

At the time, Dow Jones was following a waterfall project management approach, which required planning, budgeting, and capital expenditure in advance before the technology could be tested. Additionally, the data center hardware procurement and installation process took anywhere from one to three months.

The specific business problem we identified and set out to solve within the technology department was to accelerate software delivery and promote experimentation. Dow Jones’s current ways of building and running software were not meeting their growing business and customer needs. We had to solve this problem by fundamentally changing their approach to software development and delivery.

Given this problem and some initial experience working with the cloud, Stephen was confident that cloud-based technologies and DevOps practices were necessary ingredients for success. But how do we take a large organization accustomed to working in a specific way and change everything it knows about infrastructure, operations, and software delivery? At the time, there wasn’t much industry knowledge for us to draw from. We figured we had to move away from infrastructure-driven projects with huge capital costs and slow delivery cycles to a nimble, software engineering-driven, cloud-first approach that would allow us to iterate quickly without the fear of failure and financial risk. All of this led to the formation of our Center of Excellence team at Dow Jones (internally referred to as the DevOps team). I am still very honored to have been given the opportunity to be one of the three founding members of our COE team working alongside Tejash Patel, who is now leading several transformation efforts at Guardian Life Insurance.

The COE’s mission statement was to figure out the right tooling and practices that would empower our development teams to deliver awesome digital experiences for our customers with agility and confidence. It was given the autonomy to make the necessary design and process choices rather than being forced to operate within the boundaries of what the organization already knew or was comfortable with.

Public cloud adoption was the most important part of our overall solution to deliver software development agility, which required us to experiment, fail fast, and move on to the next experiment until we found the right answer. The cloud abstracted away the undifferentiated heavy lifting so that we could focus on our internal customers.

The target end state was clear, but the approach on how to get there was built over time. I am hoping that sharing my six-step approach will provide a path for you to consider within your organization.

Step 1: Forming the Team

The COE team should start small. After having done it at Dow Jones, I have realized how important it is to have the right people be part of the founding team. A few important traits to look for in members of the founding team include:

● Experimentation-driven: able to learn from failures and iterate quickly

● Bold: not afraid to challenge the status quo

● Result-oriented: can take an idea from its ideation phase to successful implementation

● Customer focused: appreciates the impact of developer productivity and operational excellence

● Able to influence: can scale his/her skills through others

Our COE was composed of engineers with strong technical skills and diverse backgrounds. Your top-notch tier-1 engineering talent usually has a good amount of trust built within the organization, which makes it easy for them to have a positive influence across the rest of the organization. I personally think internal hires work best for founder members of your COE team, but having a mix of internal talent and new hires or strategic partners can also jump-start your COE efforts. In our case, we needed engineers that understood networks, systems, and software development. While our founding team comprised of internal hires, we subsequently added external hires and recent college graduates.

Step 2: Deliver Some Quick Wins

With the larger vision of an organizational transformation it is necessary to narrow the initial focus to deliver a single, relatively small but important project successfully. In our case, one of our early projects was to migrate out of a data center in Hong Kong.

Within six weeks, we migrated the WSJ Asia data center to AWS’s Tokyo region using a lift-and-shift (directly moving an on-premises application to cloud with minimal changes) approach. It was a perfect start for the COE team — we had to figure out the networking (VPCs, load balancing, WAN acceleration, data replication between our US data centers and Tokyo), machine images (AMIs) in AWS, application performance, traffic distribution, change management, etc. We were able to do this only because we had the autonomy to make all the necessary decisions to make the migration successful.

The success of our first production cloud deployment allowed us to showcase our work to the rest of the organization and get over that initial concern of running a production app in the cloud. There was less fear and uncertainty about operating in the cloud. It opened up a dialogue around what’s possible rather than what’s unknown.

Step 3: Acquire Leadership Support

It is important that the technology leadership delivers a clear message to the rest of the organization about the challenges the organization is facing and what the plan of action is to address those challenges. In our case, Stephen and his leadership team did not miss any opportunity to talk about the COE’s work. While you absolutely need to have a grassroots adoption for a new technology, I strongly believe that a clear vision and message delivered from leadership is equally needed. For us, internal blogs and town hall-style meetings strengthened the message across the entire organization.

Step 4: Build Reusable Patterns and Reference Architectures

Once we gained some experience running the first set of applications in the cloud, it was clear that we needed a somewhat repeatable process to onboard more applications. In talking with multiple application teams, a few patterns started emerging. We were able to build reference architectures and blueprints that were slightly opinionated but mostly non-objectionable to the app teams.

Our COE team did an awesome job with not only building the reference architectures but also building the necessary tooling to automate the provisioning and operations of applications leveraging these reference architectures. It was a carrot for the application teams to get their apps up and running quickly while we got to standardize patterns across the organization and reduce the operational overhead.

Step 5: Engage and Evangelize

Riding on the success of our initial wins and leadership support, the rest of the organization began to engage and be part of the transition. The COE team capitalized on this. We started engaging with the rest of the organization by doing DevOps Days, lunch workshops, training sessions (via a DevOps University program), and showcased case studies of successful cloud projects. Our internal customers (development teams) presented their work at the DevOps Days and workshops, which was a much more powerful message than just external presentations. Bringing architects and developer evangelists from AWS and Chef brought in a good deal of excitement and showcased how serious we were in our transformation efforts.

Step 6: Scale and Reorganize

Once you have a few initial projects delivered successfully using the newer approaches and practices, the rest of the organization should become eager to leverage the services, tools, and expertise of the COE for their specific needs and problems.

You have to carefully plan for this critical last step of scaling the COE function across the rest of the organization. In our case, we were a little late to find out that the COE had become a bottleneck for the rest of the organization to adopt cloud and DevOps practices. Eventually, we built federated teams and DevOps capabilities within each application team to scale out the COE’s function.

Conclusion

Our approach to building and growing a COE team to help jump-start a large-scale, company-wide transformation allowed us to discover what’s possible and to implement new experiences for our customers at a pace never before seen at the company. In 2013, a change to WSJ.com required a developer to submit their changes to QA by 10 a.m. for Tuesday and Thursday build nights. Ten to fifteen engineers got on a conference bridge that lasted for hours and often didn’t succeed. In 2016, we had 100+ deployments throughout the day across multiple services in production and non-production environments. No one missed the build nights anymore, but perhaps most importantly, the number of production incidents decreased significantly, speed of delivery improved significantly, and the confidence level was much higher across all the engineering teams. We were able to launch several new web and mobile products for our customers, improve the user experience and performance of our products, grow our digital subscription base, and enter new markets with confidence.

AWS Cloud Enterprise Strategy Blog