CCOE (Cloud center of Excellence) A Cloud Center of Excellence is a team tasked with helping your organization get the most out of its cloud infrastructure. The CCoE team defines and manages policies, analyzes cost, performance, usage and security across all environments, and then makes recommendations on capacity planning, modeling and forecasting. The CCoe ensures that everyone within an organization supports a cloud culture.
In a rapidly evolving world of IT, having a well-informed view of the latest and greatest cloud-based opportunities is vital to the success of the cloud. A cross-functional team responsible for developing and managing cloud strategy, governance, methods, approaches, best practices, and knowledge is critical to harnessing the full potential of the cloud.
cloud. To enable accelerated and sustained adoption of the cloud across the Enterprise world; maximizing the ability to achieve benefits while reducing risks.
A cloud center of excellence represents the best way to ensure cloud governance, while maintaining business agility; either in a functional, advisory or prescriptive capacity.
Our CCoE will be responsible for:
• Develop a framework for cloud operations
• Govern IT and all cloud infrastructure
• Implementing cloud best practices throughout the business.
Although organizations can manage their architecture without a CCoE, it is far better to have a dedicated team to do so rather than relying on team members who may not have enough experience with the cloud.
I think of it as a dedicated new department in our business. Managing a cloud infrastructure without CCoE is similar to asking engineers to handle balance sheets - it's inefficient and risky.
Aside from management, the CCoE will work to implement best practices and improve efficiency whenever possible. It also takes into account the goals and culture of the organization to ensure that the cloud infrastructure always meets the expectations of MyappSoftware.
Identifying trends and opportunities in the cloud is another reason to embrace CCoE. Keeping up with rapidly advancing technology is one of the key challenges for MyappSoftware today. With a CCoE we will stay one step ahead of the competition by adopting innovative practices faster than our peers in the industry.
Large companies that begin a transformation journey often find that they already have transformation hotbeds that have gone unnoticed. But why haven't good practices spread from these isolated corners of the company and transformed the rest of the organization? I think the answer is that transforming the entire company requires… well, a great transformation. The company must find a way to make its deep changes scale widely until they reach critical mass. Innovation hotbeds, as a general rule, do not have the necessary influence to bring about global change.
In this contributed blog post, Milin Patel, Rearc's principal architect and co-founder and formerly Dow Jones DevOps Director, talks about Dow Jones' shift to the cloud and DevOps, and the organizational changes that this change inspired. Central to his transformation strategy was the use of a Cloud Center of Excellence (CCOE) to gain influence across the enterprise for the change initiative. It's tempting to think of a CCOE as simply a team of experts who can be consulted for their knowledge of how to operate in the cloud. But as Patel points out, a CCOE can be much more than this: it can be the engine of change throughout the company, the focal point for transformation that is wide and deep: the Archimedean lever that moves the world, or at least the business.
I have been very fortunate to participate in some 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 discovering a new way to build and run software in the cloud so that Dow Jones could remain relevant and meet ever-changing customer demand. Stephen is currently the head of business 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 that I was leading the Dow Jones DevOps transformation were the most satisfying 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 company helping other companies unlock the potential of DevOps and the cloud.
Our success at Dow Jones and Rearc can be largely 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 seeking to transform their organization with my experiences building and leading a successful Center of Excellence (COE) team at Dow Jones. The Dow Jones COE team enabled the transformation of our software development and operations practices. While this COE story is primarily geared towards DevOps and cloud adoption, the six-step approach I outline can be applied to solve other problems in your organization as well.
From my perspective, the goal of a Center of Excellence team is to take a large, pervasive, and deeply ingrained organizational problem and solve it in a smaller scope with an open-minded approach, and then leverage small accomplishments to scale it across the organization. .
Dow Jones is a news and business information company that is over 125 years old, 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. In 2013, WSJ was seeing a big change in consumer behavior around the consumption of content from news and media. Its 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 deliver a seamless digital experience across all devices and platforms. Print-based businesses had been in slow decline for years, but suddenly even digital businesses were being challenged by freemium news sites, digital upstarts, and tech giants. To meet the needs of its readers, Dow Jones had to deliver new products, features, and experiences at a very rapid pace. They had to experiment, learn, and adapt quickly, but they were too slow.
At the time, Dow Jones was following a waterfall project management approach, which required upfront planning, budgeting, and capital expenditures before the technology could be tested. Additionally, the data center hardware acquisition and installation process took one to three months.
The specific business problem that we identified and set out to solve within the technology department was to accelerate software delivery and promote experimentation. Dow Jones' current ways of building and running software were not meeting its 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 early 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 used to working in a specific way and change everything it knows about infrastructure, operations, and software delivery? At the time, we didn't have a lot of industry knowledge to tap into. We thought we had to move away from infrastructure-driven projects with huge capital costs and slow delivery cycles to an agile, software engineering-driven, cloud-centric approach that would allow us to quickly iterate without fear of failure and financial risks. All of this led to the formation of our Dow Jones Center of Excellence team (internally known as the DevOps team).
The COE's mission statement was to discover the right tools and practices that would empower our development teams to deliver amazing digital experiences for our customers with agility and confidence. It was given the autonomy to make the necessary design and process decisions rather than being forced to operate within the limits of what the organization already knew or was comfortable with.
Adopting the public cloud was the most important part of our overall solution to deliver agility in software development, forcing us to experiment, quickly fail, and move on to the next experiment until we found the correct answer. The cloud eliminated the undifferentiated heavy lifting so we could focus on our internal customers.
The target end state was clear, but the focus on how to get there was built over time. I hope that sharing my six-step approach provides a path for you to consider within your organization.
The COE team should start small. Having done it at Dow Jones, I have realized how important it is that the right people are on the founding team. Some important traits to look for in founding team members include:
● Driven by experimentation: able to learn from failures and quickly iterate
● Bold: not afraid to challenge the status quo
● Results-oriented: You can take an idea from its ideation phase to a successful implementation.
● Customer-centric: appreciate the impact of developer productivity and operational excellence.
● Able to influence: You can scale your skills through others
Our COE was comprised of engineers with strong technical skills and diverse backgrounds. Their top-tier engineering talent generally has a fair amount of trust built within the organization, making it easy for them to have a positive influence on the rest of the organization. Personally, I think internal hires work best for the founding members of your COE team, but having a mix of internal talent and new hires or strategic partners can boost your COE efforts as well. In our case, we needed engineers who understood network, system and software development. While our founding team was comprised of internal hires, we subsequently added external hires and recent college graduates.
With the broader vision of an organizational transformation, it is necessary to reduce the initial focus to successfully deliver a single, relatively small but important project. In our case, one of our first projects was to migrate from a data center in Hong Kong.
In six weeks, we migrate the data center of WSJ Asia to the AWS Tokyo Region using a lift and shift approach (moving an on-premises application directly to the cloud with minimal changes). It was a perfect start for the COE team - we had to figure out the networks (VPC, load balancing, WAN acceleration, data replication between our US and Tokyo data centers), Machine Imaging (AMI) 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 decisions necessary for the migration to be successful.
The success of our first production cloud deployment allowed us to show our work to the rest of the organization and overcome that initial concern of running a production application in the cloud. There was less fear and uncertainty about operating in the cloud. It opened a dialogue about what is possible rather than what is unknown.
It is important that technology leadership conveys a clear message to the rest of the organization about the challenges the organization is facing and what the action plan is to address those challenges. In our case, Stephen and his leadership team did not miss an opportunity to talk about the work of the COE. While grassroots adoption for a new technology is absolutely necessary, I strongly believe that a clear vision and message delivered by leadership is also needed. For us, internal blogs and town hall-style meetings strengthened the message across the organization.
Once we had some experience running the first set of applications in the cloud, it became clear that we needed a somewhat repeatable process to incorporate more applications. In speaking with various application teams, some patterns began to emerge. We were able to build reference architectures and blueprints that were a bit stubborn but mostly not objectionable to application teams.
Our COE team did an incredible job not only building the reference architectures, but also building the tools necessary to automate the provisioning and operations of applications that leverage these reference architectures. It was a carrot for application teams to get their applications up and running quickly as we managed to standardize patterns across the organization and reduce operational overhead.
Building on the success of our initial victories and leadership support, the rest of the organization began to participate and be part of the transition. The COE team capitalized on this. We began engaging with the rest of the organization by holding DevOps Days, lunch workshops, training sessions (through a DevOps University program), and showing case studies of successful cloud projects. Our internal customers (development teams) presented their work at DevOps days and workshops, which was a much more powerful message than external presentations. The participation of architects and developer promoters from AWS and Chef generated a lot of excitement and showed how serious we were in our transformation efforts.
Once you have some initial projects successfully delivered using the newest approaches and practices, the rest of the organization should be eager to leverage the COE's services, tools, and expertise for their specific needs and issues.
You must carefully plan for this critical last step of scaling the COE function throughout the rest of the organization. In our case, we were a little late to find that the COE had become a bottleneck for the rest of the organization to adopt cloud and DevOps practices. Eventually, we build federated teams and DevOps capabilities within each application team to scale the COE role.
Our approach to building and growing a COE team to help drive large-scale transformation across the enterprise enabled us to discover what is possible and implement new experiences for our customers at a pace never before seen in the enterprise. In 2013, a change to WSJ.com required a developer to submit their changes to QA by 10 a.m. for construction nights on Tuesdays and Thursdays. Ten to fifteen engineers boarded a conference bridge that lasted for hours and was often unsuccessful. In 2016, we had more than 100 deployments throughout the day to multiple services in production and non-production environments. No one missed construction nights anymore, but perhaps more importantly, the number of production incidents dropped significantly, the speed of delivery improved significantly, and the confidence level was much higher across all engineering teams.