How can you safely and quickly experiment with system architecture using continuous delivery?

1 What is continuous delivery?

Continuous delivery is a software development practice that aims to deliver software changes to users frequently and reliably, by automating the build, test, and deployment processes. Continuous delivery allows you to release software updates in small batches, rather than in large and infrequent releases, which reduces the risk of errors and failures, and enables faster feedback and learning. Continuous delivery also supports a culture of experimentation and innovation, where you can try out new features, functionalities, and architectures, and measure their impact on user satisfaction and business outcomes.

2 Why experiment with system architecture?

System architecture is not a static or fixed aspect of your software system. It evolves and adapts to changing requirements, technologies, and environments. Experimenting with system architecture can help you discover new ways to improve your system's performance, scalability, reliability, and maintainability, as well as to address technical debt, security issues, or legacy code. Experimenting with system architecture can also help you explore new opportunities for innovation and differentiation, such as using cloud services, microservices, serverless computing, or event-driven architectures.

3 How to experiment with system architecture using continuous delivery?

Experimenting with system architecture using continuous delivery requires techniques and tools that can isolate, deploy, and evaluate different architectural options without disrupting existing systems or users. Feature toggles allow you to switch on or off different components, such as databases, APIs, or services, and compare their performance. Branch by abstraction is a technique that gradually replaces old code with new code without affecting system functionality. Blue-green deployment deploys two identical versions of the system to two separate environments and measures the impact of the different architectures on user experience and business metrics. And finally, canary release deploys a new version of the system with a different architecture to a subset of users so that you can monitor their behavior and feedback before rolling it out to the rest of your users.

4 What are the benefits of experimenting with system architecture using continuous delivery?

Experimenting with system architecture using continuous delivery can bring you several benefits, such as reducing the risk and cost of architectural changes, increasing the quality and reliability of your system, enhancing user satisfaction and loyalty, and boosting the innovation and competitiveness of your system. This is achieved by testing architecture changes in small and controlled increments, being able to revert them quickly if needed, detecting and fixing issues early and frequently, using automated tests and monitoring tools, delivering software changes that meet or exceed user expectations and needs, soliciting and incorporating feedback from users, exploring new architectural possibilities and opportunities, and creating value for users and stakeholders.

5 What are the challenges of experimenting with system architecture using continuous delivery?

Experimenting with system architecture using continuous delivery can also pose some challenges, such as managing the complexity and diversity of architectural options, balancing the trade-offs and dependencies of architectural choices, communicating and collaborating with your team and stakeholders, and measuring and learning from your architectural experiments. You must ensure your architectural options are consistent, compatible, and coherent with your system's goals and constraints. Additionally, you must evaluate their impact on your system's non-functional requirements, such as performance, scalability, reliability, and maintainability. It is also important to share your architectural vision and rationale with your team and stakeholders to align your decisions with business objectives and user needs. Finally, you need to define and collect relevant metrics and indicators to analyze the results of your experiments.

6 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?