Adaptability: the second of three critical foundations for technology strategy and architecture in a fast-changing world

This is part 2 in a series. You can find part 1 (Innovation) here.

Adaptability is about building in the ability to change your systems and strategies as the changes occur quickly. Can you quickly adapt it if your cloud provider releases a new service that can cut your operations costs in half? Or, have you poured virtual concrete around your architectures and strategies such that they are complex, slow, and costly to change? Having strategies and architectures designed to embrace change will position you to take advantage of the opportunities change presents rather than being left behind by it.

Adaptability in Strategy

Strategies tend to be longer-term and define approaches to achieve your product objectives. Technology strategies focus on how technology can be applied to fulfill your product objectives. In a world where technology, market, and product change happen quickly, the ability to adjust your strategies rapidly is essential. These changes can have a broad impact on the organization, and these decisions cannot be taken lightly.

So, how do you make your technology strategy adaptable? Here are some things to consider:

Understand where the change momentum is

You may not be able to predict the exact changes that could cause you to shift your strategies, but you can identify and track where the momentum lies. Trust me, you will still get surprised occasionally but this will minimize the surprises. If possible, seek to have alternative plans for quickly dealing with change in these higher-risk areas.

Prepare the organization for potential change

Communication your change momentum/risk analysis. Let everyone know that these things are being watched and that they are critical to being able to adapt as the change happens. Morale can drop significantly if they feel that they are working on something important and it gets "dropped" for some new priority. If they understand the basis for the change and know that it may happen, they will be more energized to make the shift quickly.

Architecture, design, and development resources should understand "where things are going" to build adaptability in their strategies

Do you see that data ingestion is moving from batch to real-time? Make sure the team knows this and create clear priorities that need to be easily adjusted for in the future. They don't need to engineer for it fully today, but you want to make sure they do not paint themselves into a corner.

Ensure your strategic planning follows a continuous improvement model

You may have an annual planning cycle to plan your year, but you will need to evaluate the marketplace and adjust your strategies regularly. You don't want to find yourself thrashing and changing, but you don't want to get caught off guard either.

Adaptability in Architecture

Most of the points regarding adaptability in technology strategy also apply to architecture. Solution architecture is a mechanism that bridges broader product strategies to implementation and execution. The majority of the work done in architecture is strategy work. Architects have technical objectives they need to achieve and spend a lot of time evaluating and selecting the best approaches (strategies) for achieving those objectives.

So, how can you ensure adaptability in architecture? Here are a few thoughts to consider:

Facades, adapters, and interfaces

As more companies move towards more distributed architectures--whether they are cloud-based or not--the opportunity exists to create loose coupling between many systems components. The more you can leverage these abstractions in code, infrastructure, and module design, the lower the cost of potential change. Swapping out a database can be a significant effort in most software systems. Recently I've had the experience of swapping from one database platform to another (RDBMS to NoSQL for those of you who care) in a few days because we architected knowing that there was a high change rate in data storage platforms and that we would need to change soon due to these changes.

Focus first on capabilities, the way those capabilities are represented, then on the technology used to implement

This will make you more agnostic to the specific platform you leverage for implementation. For example, if you need to move data asynchronously from one system to another, you could pick a message queue technology and then build all your code to use it. Another approach is to define that you need something generic. Call it a "workstream" responsible for moving data from one system to another async and providing a certain amount of buffering of that data. Next, you can decide you want to be able to use queuing semantics when working with that workstream (e.g., get message, send message, delete message). Note we still have not mentioned any specific technology. Now we can pick what technology to use. We can use a queue platform (RabbitMQ, Amazon SQS, IBM MQ-Series, etc.), but we could also wrap our queueing semantics around a streaming platform like Kafka or Amazon Kinesis. If the developers follow this same type of abstraction, swapping the specific technology in the future is highly isolated and lowers the cost to change.

Leverage responsibility-driven architecture

This concept originates from responsibility-driven design and applies it to solution architecture components. Each module in your architecture should have clear responsibilities. Every time you want to add something to one of your architectural components, you should ask yourself if that new item falls within the area of responsibility. If not, you need to look at a few things: 1) should the responsibility be expanded (spoiler alert - most likely not), or 2) should there be another component that owns that responsibility? Having clear agreed-upon responsibilities helps keep the boundaries clean and eases change in the future.

Having architectures with clear responsibilities and interaction abstractions provides immediate value and long-term adaptability. It allows you to start development work on portions of the architecture without fully defining the entire thing. This allows architecture to become a parallel workstream with design and development in an Agile team. It also enables you to take reasonable development steps. You can stub or create a simple implementation to get some near-term value. However, it's isolated, and you can change it more easily without impacting other systems.

Adaptability can take many forms, as seen above. Most importantly, adaptability needs to be part of your work, not just a side element. It gets forgotten in light of the pressure. They just get something working. You can get something working in an adaptable and evolvable way. You can also do it in a way that requires a complete re-write to change. I'll let you consider which would be better.