OACA Blog June 2020

Refactoring Business Strategy

Author(s): Tom Scott, Cloud Technology Strategist

Shamir Charania, Co-founder and Managing Director at Keep Secure

Mark Williams, Executive Senior Advisor, TachTech

https://www.linkedin.com/feed/hashtag/refactoringbusiness/

Introduction

COVID-19 has caused a lot of uncertainty in the business landscape. This uncertainty has caused a lot of complexity in how business is conducted. Refactoring business strategy is about how to rethink business strategy in a changing environment where barriers to productivity present a moving target. Visit almost any company website today and you will find it marked with special notices about the COVID-19 pandemic. These banners of warnings are often designed to stand out and catch the attention of the masses, taking up valuable real-estate at the top of most webpages. What it signifies is the global impact that this pandemic has had on how businesses operate and where their values actually lie. Companies have had to make difficult choices in this period, and in most cases, shift priorities from the age-old standard of “profit” to that of “compassion” and “caring”.

When we see these warning banners, it is just the tip of the iceberg on a breadth of changes companies have had to make during these times. Some of these changes, such as dealing with employees sheltering at home, are obvious to most. Other changes, such as impact to supply chains and impacts on the supply/demand balance, can be more subtle. Entire industries have been brought to their knees with demand for their services either evaporating overnight or scaling beyond their capacity to deliver. It’s time to rethink and refactor business.

On Pivoting

A popular concept in the start-up business world is the idea of pivoting. Pivoting is the action one takes when their hypothesis of a product/solution does not pan out in the market. A foundation of movements such as “lean start-up”, pivoting is an effective strategy when you are able to throw away most or all of what you have built in pursuit of something else. Pivoting is likely not a strategy that companies can take on as they try to weather the storm of COVID-19.

https://rethink.beta-i.pt/2016/03/30/to-pivot-or-not-to-pivot/

So, what are some other concepts that companies could employ to deal with the uncertainty and complexity introduced by this global pandemic? One answer may lie in the software engineering discipline of “refactoring”. To quote Martin Fowler’s book on the subject,

“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.” (https://refactoring.com/)

Typically, successful business strategy depends on the ability of leadership to identify the right direction at the right time while aligning with changes. These processes are tested and vetted through trial and error (and sometimes pivoting) in incremental ways. Making changes in business is hard and costly, and so, businesses typically rely on in-depth analysis to uncover potential obstacles. They rely on planning up front to analyze the foreseen barriers and determine appropriate solutions. Under the current conditions in the world today, the time it takes for this type of business analysis is not realistic. Companies must react to changes as they occur and make decisions in real time, with potentially severe disruptions to the business.

So, what can we learn about the engineering practice of refactoring, and how can we apply those concepts to business? What are some other software engineering principles and practices that may make sense to apply to business? How can we lower the cost of business change while increasing the assurance that the change will be successful?

On Mapping

We think that it breaks down into the following high-level strategies:

• Make effective use of mapping to understand the current landscape and plan for where refactoring would be most effective or most needed.
• Design business processes and structures to support the idea of evolutionary architecture. Understanding that change is constant, and that we should design for change and build processes/structures that are easy to change incrementally.
• Make use of automation to support business processes and reduce the cost of change.

https://fi.co/insight/what-pivoting-is-when-to-pivot-and-how-to-pivot-effectively

Maps are designed to be both visual and context specific, in that they help with the navigation of a given terrain or landscape. With COVID-19, it is important to understand your value chains, the current positions of those, and have some understanding of how the underlying components might evolve in response to the current pandemic.

One such mapping technique is called Wardley maps. In a Wardley map, see figure 1 below, the value that your business provides is mapped on to a landscape that helps to show you the current evolution of underlying components that support your business objectives.

Figure 1 Wardley (Value Chain) Mapping

By mapping which components drive customer value, businesses can prioritize where decision trees can be implemented to manage disruptions caused by unforeseen barriers. Additionally, assessing the “maturity” of those components while determining their relative value can greatly enhance visibility to the business priorities of those components during a crisis.

Another mapping technique that could be useful are maturity models. Maturity models are typically used to understand the level at which a particular component is being used and give actionable steps to move up or down in maturity as required. One of the tools that can help measure this is the OACA Cloud Maturity Model (CMM).

Introducing the OACA Cloud Maturity Model

The Open Alliance for Cloud Adoption (OACA) has released version 4.02 of the Cloud Maturity Model (CMM), see https://www.oaca-project.org/cmm40/. The OACA Cloud Maturity Model has been developed to provide IT implementation teams with a detailed assessment tool for identifying if the current and future state of IT in their enterprise aligns with the requirements of their business goals. There are 31 domains in version 4.02 of the Maturity Model. These domains are divided into two primary capability areas: (1) non-technical and (2) technical. Each capability area encompasses a set of appropriate domains such as finance, governance, and portfolio management so that a consultant or auditor can simply select and review the capability areas and domains that best apply to a specific use case. This can be an important tool in refactoring your business.

On Evolutionary Architecture

In the book “Building Evolutionary Architectures” (https://www.thoughtworks.com/books/building-evolutionary-architectures) the authors thoroughly describe the process of architecture as it relates to software/systems development. In the typical process, requirements for the target system are defined by a list of “ilities”. When one considers evolutionary architecture, a focus is placed on the evolvability of the system. As a definition: An evolutionary architecture supports guided, incremental change across multiple dimensions.

So, the question becomes, how can we structure/change business to make change easier?

One enabler of business refactoring is to adopt optimized services from cloud providers, such as Cloud native computing^[1], leveraging capabilities to manage and even operate much of the business processes that where traditionally done in-house, i.e. on-prem. The idea here is the speed of the cloud allows business to make changes quickly, test out new ways of working, and roll those changes out in controlled ways.

To take advantage of Cloud native computing, companies should consult provider guidance on setting up core infrastructure/components to allow for fast and effective cloud adoption. Business solutions can then be designed under the guidance of cloud-native frameworks such as:

• Azure Architecture Center: https://docs.microsoft.com/en-us/azure/architecture
• AWS Well-Architected Guide: https://aws.amazon.com/architecture/well-architected
• Google Architecture Framework: https://cloud.google.com/architecture/framework

Use of these frameworks, and others, allow companies to ensure they can move as fast as possible while considering foundational architectural principles such as operational excellence, security, reliability, and performance. The idea here is to create business units/processes/etc. that are easy to change. When using cloud services, and adopting a guardrail type approach to its governance, companies can balance the need for change and the speed at which it is done with the core values of the business.

The next step is understanding how to facilitate “managed disruptions”. In order to manage disruptions, a business must first undergo the process of defining “process requirements” and “optimization controls”. This will require defining each business process by three factors: People (who is doing what), Process (how is it being done), and Technology (what is making it happen). By defining each process by each of these factors, the business can capture the inner working of how it operates. Additionally, each of these requirements (or controls or control areas) will have a “desired output” which will be the result of some action or tactical effort to make gains on the maturity/benefit of the requirement/control.

On Automation

Automation is often thought of as replacing human interactions. This is not always the case, and in most circumstances, it is simply a means of gaining efficiency by optimizing process. Automation is the use of instructions to create a repeated process that are used in software tools, frameworks, and appliances that conduct tasks with minimal intervention or overhead.

In IT, automation is used to:

• Automate processes to accelerate the delivery of IT infrastructure and applications.
• Enforce controls while achieving increased performance and reliability.
• Help the application/solution react to outside factors such as external interactions and failures of core components. This is also known as self-healing.
• Enhance monitoring and the collection of “relevant” metrics that can be fed into processes in which automation is used to make changes based on predefined parameters.
• Facilitate capabilities which enable the graceful degradation of services based on external factors, i.e. barriers.

So how does this translate to a business strategy? We think that it ties into the concept of “managed barriers”.

On Barriers

Barriers are traditionally considered obstacles to adoption. They would be encountered, identified, and mitigated. In today’s current (COVID-19) environment, barriers cannot be mitigated; disruption cannot be avoided. We must learn to live with barriers and incorporate disruption into the operational process. Redefining what a barrier is does not change the fact that it is still a barrier. Rather, consider the obstacle as a fork in the road in which decisions are   made based on changing business requirements and unforeseeable thresholds.

Introducing Agile Decision Making

Due to these extraordinary times, decision making must become “agile” and business strategy

should be “refactored” to leverage the optimized capabilities that tools such as automation and service-based utilities bring to the table.

When planning for barrier adoption into the operational roadmap, the experienced analyst must consider which barriers must be identified for management and ensure they are built into the optimized decision-making process. For each of the barriers uncovered, a solution or project must include an optimized decision-making plan, taking into consideration the nature of the barrier, the data accessibility (location), process dependencies/function, and barrier use case.

Operational barriers to be considered for each domain during the analysis can be uncovered by asking these example questions:

• Are there applications that have dependencies on “outside” processes, that if inaccessible would it inhibit the functional use of the application?
• Is there a data dependency from an outside source?
• Are there process-driven jobs from outside of the application environment?
• Is there a mandate to identify outside processes and external data stores that applications are dependent on?
• Are there software licensing constraints when applications/services are unable to function due to the inability to access dependent processes and or data stores?
• Is automation a part of the business plan? It’s important to think about building in automation to handle business disruptions (i.e., supply-chain pricing fluctuations) so that changes can automatically be reflected on the sales site.

Each of the barrier categories are IT related but have a distinct business impact. They will require particular projects to be included in the implementation plan to ensure the barriers are successfully captured.

• UI Barrier – Can no longer access the applications User Interface (UI)
• Data Barrier – Can no longer access data. buckets, stores, DB, etc.
• Network Barrier – Can no longer access application/service via “The Network”
• IAM Barrier – Identify and Access Management not accessible
• API Barrier – Cannot connect to API’s
• Code Barrier – Cannot access code libraries/repositories
• OSS Barrier – Cannot access open source resources
• Pipeline Barrier – Cannot access CI/CD pipelines
• Security Barrier – Security services can no longer access applications

On Artificial Intelligence (AI)

One potential way to address this issue, at scale, is to make use of Artificial Intelligence (AI). AI means many things to many people. For the purposes of this discussion we will use AI to capture optimized decision-making processes based on some criteria. The idea that code can make decisions is nothing new, in fact it has been a part of the benefits of computing since the beginning. For example, AI could be used to make advanced decisions, based on input, automatically adjusting price based on input cost associated with target margins. Analyzing data in real-time to understand the trends and predict what future pricing could be is the sweet spot of AI.

On Building Barrier Roadmaps

The last step is to build a comprehensive barrier roadmap. The roadmap should contain barrier analysis projects and decision transformation processes. The roadmap identifies barriers needed to define disruptive decision making used in the coordination and implementation of the managed barrier business strategy.

An example roadmap based on the result of barrier analysis

Building roadmaps with barriers is nothing new, but what is different is how they are being included as managed components of the roadmap. By linking barriers with managed disruptions, the business can map disruptions as a functional part of the expected outcome ultimately creating an agile response to barriers before they become disruptions. Although this sounds a bit paradoxical, it is really just leveraging agile decision making to manage barriers that can cause disruptions as they occur, such as unexpected disruptions to the supply chain which impact supply while continuing to manage market demand by rerouting to alternate suppliers, in near real time, based on market conditions.

In Conclusion

Barriers have always been there, and we have always found ways to manage them. What has changed is how we manage barriers, not as obstacles but rather as decision points that have a predetermined outcome that we control. Refactoring business means that companies today find a way to implement the least amount of change for the biggest benefit. What that translates to is a re-examining of “everything”. We can no longer assume we will have the resources to manage unforeseen barriers that pop up unexpectedly or be able to cope with disruptions that impact our business in profound and unforeseen ways. We need to rethink and refactor how we deal with barriers, as well as, build and rebuild, processes that account for the “unforeseen” disruptions that either have occurred, are occurring or will occur. This is no small task, and to truly accomplish this we will need to rethink everything we thought we knew about barriers and how to manage them.

Refactoring the business means revisiting business goals, reinventing business strategies and determining new business scenarios. This will require optimized decision making as a result of managed barrier mappings and ultimately, agile roadmaps, that enable change in the predefined decision making processes. The business needs to define the barrier use cases which support each business scenario: the good, the bad, and the ugly.

Please check out the OACA Cloud Maturity Model Usage Manual and Assessment tools which can be downloaded here.

[1] https://en.wikipedia.org/wiki/Cloud_native_computing

Tom Scott

Tom Scott is currently a Senior Staff Security Specialist at The Walt Disney Company. He is a future-focused technologist with over 30 years of technology innovation and experience. From being awarded a US patent for his work in mobile device news delivery, and a pending patent for securing workloads that extend across two or more cloud service providers, to building innovative workflow solutions for broadcast television to architecting cloud solutions. He is also a member of the OACA Business Transformation Workgroup as well as the Cloud Security Alliance DevSecOps Workgroup and has authored and co-authored numerous white-papers and documents ranging from the published Cloud Maturity Model through Integration and Business Strategy for Cloud Adoption. As a pragmatic technologist Tom consistently implements technology that drive business.

Mark Williams

Shamir Charania