Creating the Cloud Business Office

“However beautiful the strategy, you should occasionally look at the results.” —Winston Churchill

“Tell me and I forget. Teach me and I remember. Involve me and I learn.” —Benjamin Franklin

Many modern enterprises are a maelstrom of emotions, facts, opinions, and in many cases, outright competition both inside and outside of the organization. The bigger the business, the bigger the challenge for leaders to set and execute a common strategy. This is especially true when looking to reap the benefits of moving to Cloud. When you suddenly remove a huge amount of undifferentiated heavy lifting, pay attention to being customer-obsessed, and focus on the data and logic required of technology to deliver this end, some people are going to feel intimidated at best and hostile at worst for what this means to them personally. This FUD (fear, uncertainty, and doubt) can be magnified in the move to Cloud, because it cuts across so many paradigms and existing job roles.

It very often materializes itself in what is called the “frozen middle,” where senior executives, engineers, and developers can clearly see the benefits of Cloud adoption and actively want to move that way, but managers, directors, and junior executives are concerned they about what it means to them. So, the conscious and unconscious desire of this latter group is to try to block or control such a move. Nearly every enterprise Cloud journey will suffer from this frozen middle at some point, and it can be fatal to transformations. At times, it’s frustrating and akin to walking through a room filled with treacle (molasses), while everyone is shouting from the sides for you to go faster.

So what mechanism actually works to remove these stalls?  Time and again I see customers moving at pace when they have a Cloud Business Office (CBO) in place.

What Does a CBO Do?

“The Cloud Business Office ensures the effective governance for the organization to adopt and accelerate Public Cloud use across the business. It does this through the holistic representation of key stakeholders from across the business who form a quorum, who commit to be broadly educated on key Cloud differentiators across security, reliability, availability, cost, and time to market. It will establish and agree bold objectives and principles to the same, and act positively to encourage the enablement of the workforce to adopt Cloud at scale and address and remediate any risks or blockers that arise in its course.” —AWS Enterprise Strategy Team

Pro-tip: Although the above quote may sound formal, we have many customers who ask for a clear definition they can cut and paste into a team’s terms of reference, so we offer it here for that purpose. In fact, feel free to plagiarize as much of this blog as you need for your organization’s CBO terms of reference. If it helps you get going quicker, then all the better!

Ultimately, the CBO exists to ensure (or identify when it doesn’t) alignment of the Cloud goals to the business’s goals and the strategic and tactical execution of them across elements of people, process, and technology in a well-governed and inclusive way.

Getting the Right Leadership Team Together

Cloud Transformation Leader

The Cloud Transformation Leader (chair and leader of the CBO) is a first line of defense leader. This individual has the implicit authority to accept and/or mitigate perceived risks in line with the board’s risk appetite and sets controls appropriate in this regard. The position works best when either the CIO or CTO themselves—or at the very least, a direct report of these two roles—assumes the role. The Cloud Transformation Leader has an expansive role in leading the CBO, and indeed for taking everyone on the journey across people, process, and technology in congruence with the board’s risk appetite. It is a senior executive role.

Pro-tip: In Amazon, Single-Threaded Owners and Single-Threaded Leaders are subtly but importantly different. A Single-Threaded Owner is directly accountable for the results of their team, who will work directly for them. A Single-Threaded Leader will have to manage intent amongst teams that do not work for them. An example of a Single-Threaded Leader could be someone who ensures that a certain compliance goal or executive goal is reached and will engage with Single-Threaded Owners and their teams to achieve this.

Chief Information Security Officer (CISO)

Security is of course Job Zero for us all. Having either the CISO themselves in this position—or an empowered direct report—is crucial. This person has multiple roles within the group: First, to educate themselves in the Amazon Shared Responsibility model, with clear understanding of which parts AWS handles and which parts customers are responsible for. Second, to educate others in the new security paradigm that now exists. Third, to ensure potential blockers are scrutinized appropriately. And, finally, to ensure the security objectives for the organization’s move to Cloud are clear and appropriate.

Legal and Procurement

In the old world of business, supplier contracts were heavy with CAPEX decisions and guesstimates of as-yet unknown required capacity. The contracts would take months or even years to negotiate and were often packed with a multitude of SLAs that were pretty much just so many words on paper when an actual outage occurred.

The world of contracts in hyper-scale Public Cloud are appropriately different, with no committed spend and pay-as-you-go consumption, along with a profoundly high security bar and the natural requirement to protect every customer from every other customer. As a result, it’s important that legal and procurement are involved from the start and have a chance to understand these differences.

Risk and Audit Representation

Ensuring the Risk and Internal Audit teams (if appropriate for your organization) are present with the CBO is very important. As you look to adopt the profound benefits across people, process, and technology that Public Cloud bring, these functions will help ensure that frontline leaders are raising, accepting, or mitigating risks across these areas.

From the Enterprise Strategy team’s experience, having these groups involved will make life tremendously easier. In fact, many of the professionals from these functions have wanted to deepen their understanding of AWS , and in many instances have decided to follow a path to AWS certification themselves to become powerful advocates and hold a high bar of understanding.

Head of Infrastructure and Operations

The operations function of most businesses will nearly always implicitly command 51 percent of the vote for any decision that comes to the CBO. And, when you look at it from their perspective, this makes some sense. The team that gets woken up at 3:00 am when things fail—and has to maintain critical operations 24x7x365, as well as patching, availability, and DR and all the infrastructure in between—will always have a powerful voice in the CBO quorum. Of course, an element of “Wait a minute, I build infrastructure—what do I do when we move to Cloud?” can also be a very large elephant in the room.

The Infrastructure Engineers who previously built, ran, and continually upgraded data center-based infrastructure have a crucial role in Cloud migration and growing the business. Their ability to understand infrastructure as code, whether it be by experience with the Linux/Network/Storage/Windows/Database command line subsystems of legacy data centers, is of profound advantage. This is particularly the case when it comes to using those same Command Line Interfaces skills to configure scripted API-Calls as AWS Cloud-formation scripts to build not just servers or networks of servers, but entire regions of servers, data services, and everything in between as Continuous Integration/Continuous Development pipeline code.

The boost in motivation (which comes from autonomy, mastery, and purpose) as they become skilled AWS experts able to perform scripted miracles across any of the AWS Building Blocks in seconds will make them maestros of our digital world as their place amongst Agile teams is assured. Helping the engineers through this profound change curve is the job of leaders.

Head of Delivery and/or Line of Business Representation

By far the most rapid transformations are when business leaders demand to leverage the new tools that AWS Cloud brings to transform the ability of their lines of business to deliver different and better results for customers.

I’ve seen for myself that it’s potent stuff indeed when business leaders can clearly articulate a vision of value, leverage the new building blocks of the digital age, and then rapidly engage with IT to deliver this change. In more times than I can count, the catalyst is being able to use their data to make better automated customer decisions, whether they’re in the areas of credit risk, decisioning, fraud reduction, cross-sales opportunities, and much more—the list is endless. And when you have the ability to test different hypotheses with profoundly powerful and cost-effective pay-as-you-go infrastructure, this is the world that opens up to leaders.

Having their representation, critically for the first workloads, is literally like jumpstarting your journey to AWS Cloud. It provides a problem catalyst, funding, and goal. Everything else follows.

Human Resources

As you move to re-skilling your current and future employees at all levels for Public Cloud, the place of Human Resources to act as trusted advisors to ensure you are engaging effectively and appropriately with your workforce is absolutely required. This is especially the case as you look to continually adapt and transform your workforce and job roles.

CCoE Leader

The individual that the CBO chooses to lead this team is important and I have seen this role make or break early wins in your journey. Speaking from personal experience, choosing individuals that over-indexed on empathetic People Skills and a firm collaborative Bias for Action. Emotional intelligence is just as, if not far more important, than technical smarts for this role. I am often asked about this in EBCs so I will refer to this quote from the great book ‘The EQ Edge’ by Steven J. Stein, Ph.D. and Howard E. Book, M.D.

Emotional Quotient is the set of skills that enable us to make our way in a complex world — the personal, social and survival aspects of overall intelligence, the elusive common sense and sensitivity that are essential to effective daily functioning. It has to do with the ability to read the political and social environment, and landscape them; to intuitively grasp what others want and need, what strengths and weaknesses are; to remain unruffled by stress; and to be engaging. The kind of person others want to be around and will follow.

This role is best enacted with an individual who has a level of seniority that is both explicit and implicit.

The Head of Architecture

Historically speaking (the last few decades), the role of Enterprise Architecture has been vaunted, and at the same time derided, in equal parts. Its role in waterfall execution of projects was a key early stage and ongoing governance function that would often make or break a business case and project in equal measure.

I would respectfully argue that Technology Architecture has never been more important (see AWS Well Architected Framework).  But the way in which this role is performed has changed beyond measure, with the powerful move to Agile and teams that now build and support in this API-based pay-as-you-go Cloud model. The Enterprise Architects of today can no longer sit in their ivory towers and act as the authoritarian old guard. The role has changed. The expectation is now that Architects can code just as well as any developer. It is no secret that Architects really don’t exist in such roles with the technology companies of today. Instead, they are now expected to operate as Senior Principal Developers/Engineers who have significant experience across a multitude of technology disciplines and can effectively technically lead and mentor engineers and developers in their Product/Agile teams to ensure they consider all of the inter-relational components that modern architectures need. In their teams, they groom all the architecture assets for their fit for purpose and adapt them in line with the Product Managers to effectively manage technical debt. That said, their role in the CBO is crucial to ensure a controlled move to Cloud and you will see that their role in the change that is coming is very important.

Responsibilities of the CBO

The CBO has a long list of responsibilities. Here are the ones we have consistently found to be most important:

• Set a bold goal
• Set the Objectives and Key Results
• Catalog and eventually answer all the questions
• Agree on your principles
• Remove roadblocks
• Agree on the first production workload
• Establish the Cloud Centre of Excellence Team
• Sign off Cloud contract
• Provide budget
• Agree, execute, and monitor migration of applications and data
• Communicate, communicate, communicate
• Ensure establishment of training and reskilling mechanisms available to all
• Create Agile Release Teams (if you are using SAFe or parts of it for Agile)
• Create training and certification targets
• Agree on your security, availability, cost, and compliance objectives
• Sign off on recommended tooling and subsequent change
• Conduit to business. Coach business on epics, roadmaps, and prioritization. Cloud backlog grooming ….

Diving Deeper on the Responsibilities of the CBO

Now that we know what the key responsibilities of the CBO are, let’s take a closer look at each.

Set a bold goal—There is simply no substitute for the most senior executive to state the goal clearly and unambiguously. The goal here needs to directly correlate with the business executive committee goals, whether those are to grow revenues, increase profitability, improve customer Net Promoter Score, and so forth.

Set the Objectives and Key Results—Arguably, all of the responsibilities that follow come from defining the Objectives: Where do I want to go? and the Key Results: How do I get there? Regardless, the additional responsibilities below are some of the very best examples of things the group should strongly consider adopting and implementing.

Catalog and eventually answer all the questions—Everyone will have questions—you can count on it. Most senior executives are consciously curious, and this curiosity materializes in the form of questions. Do not simply give these questions lip service; capture every single one. Watch out for folks who both ask and then answer the question themselves, such as “Will that work, because I don’t think so!” While the first part of the statement is a question, the latter part is surely a negative statement. However, each question is important to the person who asked it, and if left unanswered will act like a sea-anchor with a negative drag force on your transformation. The word “eventually” answer is really important here. If the CBO tries to get the answer to every question before it does anything, it will never achieve anything. Don’t let this stop you from getting started! For example, it’s natural for an organization to not let customer data exist in the Cloud until the CISO and their teams quite rightly thoroughly understand the AWS Shared Security Model. But that doesn’t preclude a team starting to work toward a first workload. Think just-in-time answers and eventually answer everything rather than needing to answer everything before getting going. The careful curating and prioritizing of questions should be the job of the Technical Program Director assigned to run the CBO.

Pro-tip: An Executive Briefing Session held locally (in country), or ideally in Seattle at AWS, can answer whole swaths of questions and can be both highly educational and enable rapid building of executive relationships.

Agree on your principles – I cover this in detail in this blog. It’s fine for your principles to evolve with time as you discover and learn more. The CBO should be the group that discuses (often very passionately) which principles are going to apply to the way you want your organization to run. The Single-Threaded Leaders should have the final say. Publish and declare them to all and model the way forward.

Remove roadblocks—The CBO team should meet weekly at the very least. Both authors would have leadership standups every day. Rapid removal of roadblocks builds and maintains momentum and neutralizes large team ambiguity around commitment to the change.

Agree on the first production workload—Pick something important. It’s got to matter to your business peers, it has to demonstrate value, and it must define a new way. A simple microservice for your production website can work really well but is still important to your business. (If you need more time to learn about the AWS Shared Responsibility model and aren’t quite ready to place customer data in AWS yet, pick a small service that doesn’t include the processing of Personal Identifiable Information.)

Create the Cloud Center of Excellence Team—This is a critically important step.

Pro-tip: The CCoE is a means to end, not an end in itself. Watch out for it becoming a bottleneck or approval body. Your goal is to have the CCoE eventually disband as Cloud becomes the way to deliver Information Technology. And perhaps, at a minimum, have a modest Cloud Ops team that maintains Gold AMI images, best practice exemplars, and runs books and Cloud usage guardrails for costs, reliability, security, compliance and time-to-market goals.

Sign off Cloud contract—A broad senior executive understanding of how the AWS Cloud contract is different from traditional CAPEX-heavy and guesstimate-based contracts is needed. Understanding this up front saves a massive amount of time. Security will always be Job Zero for AWS. That understanding, as well as the broad appreciation of the need to protect every customer from every other customer, is required to best comprehend the Enterprise Agreement. We can walk you through each part and work backward from your regulators’ needs when required. Engaging closely with your AWS Account Team for a broad education, and speaking directly to the CBO, can really help.

Pro-tip: Inviting the AWS Account Team early in the migration to provide a broad education to the CBO—and, in particular, contract/legal leaders—can save an enormous amount of time.

Provide budget—Appropriately allocating budget, while obvious, is a core part of the CBO’s existence. This will increasingly become more important as you work through your migration and will want to priories some application moves ahead of others to avoid onsite CAPEX for upgrades as you can avoid them. This continual grooming of assets is a key role of the leadership team.

Agree, execute, and monitor migration of applications and data—Ensuring congruence, priority and awareness of What, When, and How for migration is a key role of the CBO. Joe Chung and myself did a deep dive on this at reinvent 2018.

Communicate, communicate, communicate—Yes, it is worth saying three times. Either you communicate, or the vacuum will be filled with fear, uncertainty, and doubt. Establishing internal websites (start simple) that provide quick updates, templates, gold images, and progress of certification passes is super important. Establish the right push communications mechanism with a template. Nothing should be hidden, and feedback should be encouraged. While feedback should always be listened to, the CBO should stay aligned to the principles and push through if the feedback is not conducive to the transformation you are trying to achieve.

Ensure establishment of training and re-skilling mechanisms available to all—Ensuring the right mechanism is in place for everyone in the organization to go from Cloud Beginner to Cloud Expert is a crucial role of the CBO.

Create Agile Release Teams (if you are using SAFe or parts of it for Agile)—If you haven’t yet moved to Agile, now is the perfect time to do so.

Agree on the re-skilling target—check out this blog for a deep dive. Reskilling Your Teams for Cloud. The CBO should also focus strongly on reskilling their executive teammates across the organization. Training is not just for Engineers and Developers.

Agree on your security, availability, cost, and compliance objectives—This is a continual cycle in conjunction with the CCoE to establish and agree on the Target Objectives across security, reliability, compliance, and time to market. Publishing these on both an internal website with links to exemplar code and pushing them out via email communications is crucial, as it when they are amended!

Pro-tip: Having this group meet biweekly or even daily (just for a five-minute dial-in call) to establish a cadence and momentum to remove blockers can rapidly move things forward. This will get your first production workloads live in the cloud and move you through the reskilling and into migration phases of the transformation—acting as an immensely powerful catalyst.

Pro-tip: Avoid proof of concepts for your first workload—the AWS Cloud has millions of customers with millions of workloads. It works. Pick something that matters to your internal and external customers.

The CBO should continue until the “right time.” Experience shows that when you have a material number of Cloud workloads, and you have strong cadence of your migrations and the number of times the CBO needs to remove blockers, this is a good time to reassess the final step: your target organization structure and Job Families for a new world.

“All of your assumed constraints are debatable.”

Jonathan Allen
@jonatallen
jnatall@amazon.com
EMEA Enterprise Strategist and Evangelist