Strategic Cloud Migration: Embracing a Capability-First Paradigm for Socio-Technological Systems

Introduction

In the rapidly evolving landscape of technology, it’s crucial for businesses to stay abreast of the latest developments and breakthroughs. Given the swift pace of technological advancements, formulating long-term strategies and making future-oriented decisions have become increasingly complex in the business realm. The decision to migrate socio-technological systems to the cloud represents a pivotal moment for any organization. Once this decision is made, it’s vital to strategically approach the migration process. In this blog, drawing from my own experiences, I aim to share insights, actionable advice, and practical suggestions for navigating the intricate process of migrating socio-technological systems to the cloud using a capability-first approach.

The Need for a Capability-First Approach

The defining characteristic of a capability-first approach is its focus on delivering business value. This approach provides a business context to the migration, enabling us to move and adapt complete capabilities in unison, rather than sporadically modernizing potentially low-impact applications. This approach is holistic, agile, and strategic, taking into account the overall abilities and competencies of the organization. It involves examining our business from both micro and macro perspectives, understanding what our organization is capable of, and determining how those capabilities can be enhanced through the migration process.

Understanding the Business Landscape

Every business is uniquely structured to deliver value. To comprehend this structure, we should begin with the business overarching framework (as depicted in the figure below) that guides organization’s activities. Generally, this framework is quite similar across all sustainable businesses. It’s also important to remember that organizations, whether they’re businesses, non-profits, or governmental entities, operate in dynamic complex environments with various internal and external factors influencing their operations.

Businesses exist to fulfill a specific societal purpose and meet a particular societal need, typically reflected in their “Vision” and “Mission” statements. Business capabilities are the essential components that transform business ideas into tangible value.

Defining Business Capabilities

While there are numerous ways to define business capabilities, I find it beneficial to view them as evolving competencies built upon the integration of four key elements: Technology, Organization, Process, and Data (as depicted in the figure below).

Identifying business capabilities in an organization involves a systematic approach and often requires a blend of qualitative and quantitative methods to gain insights into the intricate web of various contributing factors within the organization. It may also involve understanding and addressing key aspects of the organization, such as “Diverse Functions and Departments”, “Technological Infrastructure”, “Strategic Objectives”, “Cultural and Behavioral Factors”, “Regulatory and Compliance Considerations”, and more.

Delving into Business Complexity

Our aim is to examine the organization as a complex dynamic system to capture the hierarchical structures and emergence of capabilities needed for business value creation. I find it particularly useful to consider complexity in organizations through stacked abstraction layers, used to model different organizational and communication levels. An abstraction layer acts like a filter or a simplifying lens that conceals (but does not remove!) the details of the elements and their interactions at other layers, facilitating the separation of concerns to ensure interoperability and platform independence. The abstraction layers (and elements) we model, and the number of these layers, depend directly on our migration objectives. However, we should always strive to have at least one layer above and below the layer where our capability is located.

In essence, abstraction layers provide a structured way to analyze complex systems, understand the relationships between elements, identify emergent properties, frame problems, and communicate these concepts to others. They allow us to manage complexity by focusing on the relevant details at each level of abstraction, without getting overwhelmed by the details of other levels.

It’s important to remember that socio-technological systems themselves are, by definition, complex dynamic systems and are thus sensitive to initial conditions. Neglecting to consider the initial conditions (assumptions, given situations, environmental, social and economic factors, concrete use-cases, etc.) during our migration and blindly applying “best practices” and/or “approved patterns” is often the root cause of migration project failures.

Scoping the Migration Process

One effective method to address the scoping aspect of our migration challenge is to apply the overall organizational framework to our migration project, as if we’re about to build a new business. Creating vision, mission, and strategy statements and then identifying and verifying the required capabilities might seem excessive, but in most cases, this approach significantly helps to clarify the scope of the migration process. By using this approach, we also acknowledge the importance of the temporal dimension, recognizing that future developments and events (both internal and external to the organization) can significantly influence and impact our perspective of this system (“business”).

A simplified model using abstraction layers is shown in the figure below. This model can easily be transformed into a diagram where we can visually represent various relationships between elements (for instance, between the abstraction layers).

Once we have pinpointed the capabilities, it’s crucial to delve further and unpack the components of these capabilities to understand their functions, structure, and interconnections. At this point, our next steps in the migration process depend on the location of our identified capabilities. Capabilities at higher layers are often more closely related to business functions and processes, and we need to consider factors such as business impact, user experience, and reengineering of business processes and operations. Capabilities at lower layers are often more technical in nature, and we should focus on factors such as system dependencies, system integration, data migration, security, compliance, and rearchitecting of the existing system design.

Under all circumstances, it’s important to understand the dependencies between the identified capabilities and the environment(s). This will help us anticipate potential risks and impacts on other parts of the system during the migration. At this stage, I found the Causal Loop Diagram (CLD) indispensable. CLD offers a unique level of dynamic and simulation options that can be particularly useful in understanding complex dynamic systems. However, the application of these diagrams is highly specific and context-dependent, making it challenging to provide a general description without delving into various specific situations. Each use case is unique, and a comprehensive exploration of these scenarios is beyond the scope of this blog. For those interested in learning more about CLD usage in specific contexts, I encourage you to explore additional resources or specialized literature on the subject.

Planning Migration Tactics

So far, our focus has been on “Why” and “What” type of questions. The main objectives include detailed specifications of our business capabilities, a clear scope for the planned changes to our systems, and an overall plan for the migration. Now, we should delve into the “How” part of our migration process to address the technical and tactical aspects of the migration.

In this process, we should pay special attention to the existing architectural decisions and technical debts in our systems. Architectural decisions address architecturally significant requirements in our systems. Technical debt refers to the eventual consequences of our system-related decisions, mostly technical. During the migration process, these can guide and verify our decisions and expose certain limitations and constraints. We wouldn’t want to apply a “rehosting” strategy (lift-and-shift) to a system with high technical debts because the migration might even amplify them. And we certainly wouldn’t want to overlook any binding contract with our customers about the location of their data.

The deeper we dive into the planning process, the more specific challenges need to be addressed. Preparing ourselves for the migration process reduces the risk of potential negative surprises. In the figure below, I’ve tried to list some of the areas and possible options that we might need to consider during a migration. This reference list may not adhere to the MECE principle, but it can still spark ideas. Not all areas will be relevant to every migration case, and additional areas not listed may emerge. However, the migration strategy, discussed in the next paragraph, is a common and complex aspect of most migrations.

Choosing the Right Migration Model

Selecting a migration model depends on the context and specific aspects of our system(s). This decision is challenging, primarily because it often represents a point of no return in the migration process. When dealing with socio-technological systems, I believe the best way to approach this challenge is in terms of the system’s complexity and complicatedness. The idea is to carefully assess the level of complexity and complicatedness in our system(s) and then use the diagram below as a sense-making mechanism to guide us towards a potential migration model.

To assess the level of complexity and complicatedness in our system, consider the following definitions. The complexity of our socio-technological systems increases with the number of interconnections among its components. The complicatedness of our socio-technological systems increases in direct relation to the number of external processes it interacts with. For instance, a simple Excel spreadsheet stored on a shared drive and used by many in our organization could be classified as a high-complicated but low-complex system. Conversely, an application specifically designed for maintenance purposes based on operational data and used by a single team could be placed in the fourth quadrant of the diagram below.

The entropy in our system will likely increase along with both complicatedness and complexity, forcing us to spend more time on system maintenance. On the other hand, highly complex and highly complicated systems provide both push and pull incentives for system innovations. The migration process is a unique opportunity to lower the entropy in our system(s). As the entropy of the system(s) decreases, some often positive emergent properties may become more apparent. We can use these new properties as the main indicators to monitor and assess our migration process. Ensuring that these properties align with our business values is key to a successful migration.

One final piece of advice: We must be aware of well-defined system boundaries. We should always strive to migrate “closed” systems – or ones with clear interfaces/dependencies. However, if we are dealing with an “open” system, we must have a plan for how to handle the interfaces at the system boundaries. Open systems tend to be classified as both high-complex and high-complicated systems and, as such, they are potentially more difficult to migrate. Therefore, we should regularly revisit and update our assumptions. Every assumption represents a certain risk that may result in a problem. And, of course, all high-risk assumptions need to be clarified and tested before we start building our next decisions on top of them.

Leveraging Artificial Intelligence for Optimal Outcomes

An additional topic that warrants our attention is the “AI” dimension within the identified capabilities. AI is a general-purpose, transformative technology, and finding a way to leverage AI in our business capabilities could be a game-changer for our business. Regardless of whether we’ve already introduced AI into our system or are planning to do so, the following steps might serve as general guidelines.

Firstly, we identify or reassess our needs. Delve deep into the specific areas within the systems where AI can bring business value. It’s also important, depending on our needs, to select an appropriate AI technology. We also need a proper data assessment to evaluate the quality and quantity of data available. In some cases, a small-scale project to test the feasibility of the AI component helps in understanding the potential challenges and benefits.

Secondly, we need to ensure that the necessary hardware and software infrastructure is in place, and we need to test the AI components for accuracy, reliability, and bias. We also need to ensure that the AI components are correctly integrated into the system and then establish appropriate continuous monitoring and maintenance procedures. We must remember to educate the system’s users on how to interact with the AI components.

Finally, we must consider the ethical implications of introducing and maintaining AI components in our system.

Conclusion

Achieving a successful transition of socio-technological systems during migration can be challenging. However, migration presents a significant opportunity to enhance the existing business. We need clear goals and objectives that align with our business values. In this blog, I discuss migration to the cloud. Selecting the cloud as our final destination opens up many new possibilities. Of course, there’s always the option to stay on-premises. Staying on-premises doesn’t necessarily make our migration easier or faster, but it might be a better (or even the only) choice in some cases. Regardless, the suggestions can be easily (and in most cases, directly) applied to any technical project aiming to improve business using technology.

In summary, socio-technical systems are indeed complex dynamic systems due to their intricate nature, their ability to adapt and change over time, and the complex interactions between various components within the system. They require a careful and thoughtful approach to design and implementation to ensure they meet the needs of all stakeholders and contribute positively to the organization or society they are part of.

We can gain a significant advantage by using a Capability-First approach for Socio-Technical system migration. The success of a socio-technical migration depends on careful planning, clear communication, and consideration of both the social and technical aspects of the environment in the form of business capabilities. And finally we must remember to set our expectations exceptionally high - this will fuel our motivation.