Continuous Architecture with Kurt Bittner and Pierre Pureur

Introduction to QCon London 2024 and Authors

• The QCon London 2024 conference will take place in London from April 8th to 10th, featuring senior practitioners discussing emerging trends and best practices in software development, including AI, software architectures, generative AI, platform engineering, and modern software security 1s.
• Kurt Bittner and Pierre Pureur have co-written several articles for InfoQ, including a seven-part series on continuous architecture and exploring the concept of a minimum viable architecture 42s.
• Kurt Bittner works for Scrum.org, focusing on Enterprise agile issues, and has a background in software development and architecture, believing that software architecture is crucial for organizations to achieve agility 1m4s.
• Pierre Pureur is a retired software architect who was previously the Chief Architect for a large insurance company, and has co-written books on continuous architecture and minimum viable architecture 1m56s.

The Authors and Their Work on Continuous Architecture

• Kurt and Pierre aim to make the concept of continuous architecture more practical and implementable, and have been exploring the idea of minimum viable architecture 2m42s.

Misconceptions about Software Architecture and the Role of Architects

• The discussion starts with the first article in the continuous architecture series, titled "Software Architecture: It Might Not Be What You Think It Is," which sparked conversation around the role and responsibilities of software architects 3m7s.
• The article's headline led to comments and discussion, indicating that there are common misconceptions about what software architecture is and what software architects are supposed to do 3m9s.
• The role of a software architect is being questioned, with some people believing that architecture is part of software engineering, and job titles are changing from software architect to software engineer at companies like Google 3m40s.
• There is a debate about whether architecture should be developed upfront or as the project progresses, with some people recognizing that it's impossible to do it upfront and instead developing it as they go 4m20s.
• Experience with agile approaches has led to a skeptical view that everything said about a system is an assertion that may or may not be true, and that empiricism is needed to test ideas 4m42s.
• Software architecture is not just a set of diagrams or documents, but a set of decisions made by the team about critical aspects of the system, such as memory consumption, sessions, and security 5m36s.
• It's essential to recognize that software architecture exists, whether or not there is a software architect role, and to be explicit about the decisions and assumptions made, and then test those assumptions 5m57s.

The Nature of Software Architecture: Decisions and Trade-offs

• Software architecture is a series of compromises or trade-offs, and there is no absolute right or wrong way, which can make people uncomfortable, but a good practitioner should be able to make these trade-offs and limit the downsides 6m28s.

Documenting Architectural Decisions with ADRs

• Architecture is about capturing decisions, not just describing structure, and traditional diagrams with boxes and arrows often fall short in conveying the full scope of architectural decisions 7m18s.
• Architecture Decision Records (ADRs) are used to write down decisions, including who made the decision, why, and when, as well as the solutions considered and discarded 7m31s.
• Recording decisions is crucial, and it doesn't matter where they are kept, but it's essential to maintain a record of the decision-making process 8m3s.
• Keeping ADRs close to the code, such as in GitHub, is considered good practice, as it increases the chances of the records being maintained 8m28s.

The Cost of Reversing Architectural Decisions

• An architectural decision is one that becomes exponentially costly to reverse, often involving significant data structures, concurrency, and assumptions about timing 8m51s.
• Architectural decisions can be costly to change, and in some cases, it may be more expensive to modify existing code than to rewrite it from scratch 9m47s.
• The importance of ADRs lies in preserving the thought process behind architectural decisions for future developers, allowing them to understand the reasoning behind the choices made 10m14s.
• ADRs serve as markers or breadcrumbs, enabling future developers to agree with or reassess the decisions made, and make new choices if necessary 10m33s.
• Architectural decisions are extremely expensive to reverse, making it crucial to understand why certain decisions were made, which can be challenging without leaving a record of the decision-making process 11m1s.

The Importance of Documenting Architectural Decisions

• The importance of documenting decisions is likened to watching the Olympics, where only the gold medal winners are shown, and the process of getting there is not visible; having a record of decisions provides the necessary context for future reference 11m16s.

Quality Attribute Requirements (QARs) in Architectural Decisions

• Quality attribute requirements (QARs) are essential in guiding architectural decisions, including performance, scalability, security, and resilience, which are often referred to as the "ilities" 12m13s.
• QARs are critical even when building a minimum viable product (MVP) or a small system, as they drive the architecture and ensure that the system can be scaled up or down as needed 12m24s.
• The challenge with QARs is that they are difficult to pin down, and there is a paradox in that they are needed to make architectural decisions, but they are not always well-defined 12m54s.
• Scalability is a prime example of a QAR that is difficult to guess, and simply relying on cloud providers to solve the problem is not a viable solution 13m10s.
• The problem with scalability is that it is difficult to scale up or down, and an architecture that is designed to scale up may not be suitable for a product that is not successful, leading to unnecessary consequences 13m30s.
• Understanding the impact of architectural decisions on technical debt is also an important consideration, although it may not be discussed in detail 14m12s.
• The initial quality attribute requirements (QARs) are a starting point, but they may not always be right, and they can be refined or changed as the system is developed and more information becomes available 14m19s.
• The QARs provided by stakeholders may be based on their current understanding and may not reflect the actual needs of the system, so it's essential to question and validate them 14m25s.
• As the system is developed, it's crucial to build tests to learn about performance, scalability, security, and other qualities, and to use this information to refine the QARs 15m14s.
• The QARs may need to be adjusted or scaled back as the system is developed, and trade-offs may be necessary between different qualities, such as performance and security 16m0s.

Testing QARs and the Scientific Method in Architecture

• A scientific method to testing QARs involves forming a hypothesis, writing it down, testing it, and checking the results, and this approach can be applied to architecture requirements testing 16m30s.
• Testing QARs is essential to ensure that the system meets the required qualities, and this approach can be extended to virtually everything in the art of architecture 16m55s.
• The art of architecture involves trying to figure out what's the minimal amount of work needed to achieve the desired qualities, and testing QARs is a crucial part of this process 17m40s.
• Performance benchmarking and testing can help identify areas for improvement and optimize system performance, and this approach can be applied to other qualities as well 17m6s.

Minimum Viable Architecture (MVA) and its Relation to MVP

• Building a subset of the real system is necessary to test architectural hypotheses and identify potential issues early on 17m44s.
• Testing and building as little as possible of the system's architecture as soon as possible is crucial to avoid committing to a certain delivery date and then discovering drastic problems 18m17s.
• The concept of a Minimum Viable Product (MVP) is often thrown around casually, but it refers to a product that is released to test the customer base and gather feedback, even if it's not clean or pretty 18m39s.
• The traditional definition of MVP is limited to startups, but it can be expanded to established companies releasing new products, where releasing smaller parts of the product to test the impact on the customer base can be beneficial 19m20s.
• The MVP concept can be applied to architecture, where each MVP has an associated Minimum Viable Architecture (MVA), and each smaller part of the product becomes an MVP 20m8s.
• In Scrum, every Sprint produces a potentially valuable product increment, which is essentially an MVP, and it's a natural extension to think about how much architecture is needed to support that MVP 20m25s.
• The amount of architecture needed to support an MVP is linked to the MVP itself, and if the MVP is successful, it's a contract with the customer committing to deliver certain functionality 20m51s.
• The Minimum Viable Architecture (MVA) should support the system or product for its entire life, and having enough architecture in place allows for making statements about future support without needing everything to be in place immediately 21m12s.
• The MVA doesn't need to be super scalable right now, but it should have a path to become super scalable if needed in the future, and this notion is linked to the Minimum Viable Product (MVP) 21m42s.
• The MVP and MVA are linked together, with the MVP making commitments every release that the system will be supportable, and they should march along together, with one possibly getting a little farther ahead at times 21m50s.
• The MVP is not a throwaway prototype, but rather an initial commitment to support the delivered functionality, and teams should ensure the MVA matches the expectations behind the MVP for incremental releases that don't disappoint people 22m14s.

Balancing Short-Term and Long-Term Needs in Architecture

• The idea is to avoid the waterfall approach, where architecture is done upfront, and instead keep it closer to the product development, balancing short-term and long-term needs 23m3s.
• It's essential to realize that most decisions may be wrong or become wrong at some point, and teams should ask themselves what happens if they are wrong and what needs to be done to reverse them 23m41s.
• The "look far, look near" technique is useful in making decisions, where teams need to look far ahead to see where they ultimately need to go and look near to ensure short-term decisions are correct 24m3s.
• Making decisions in product development involves considering both short-term and long-term goals, as solely focusing on either can lead to undesirable outcomes, such as creating an unsustainable product 24m30s.
• Decision-making in product development often involves trade-offs, and there are no absolute right or wrong answers, but rather a need to test and evaluate the outcomes of those decisions 25m7s.
• The concept of a "minimum viable architecture" is important, as it allows for smaller changes and adjustments to be made as the product evolves, with the understanding that the architecture may need to catch up with the product's development 25m28s.

Essential Skills for Developers in Architectural Validation

• Developers should become familiar with load testing tools or learn to write their own load testing drivers to simulate potential loads and identify areas for improvement 25m42s.
• Cross-functional skills, such as testing, are essential for developers, as they cannot rely solely on other teams to perform these tasks, and being able to test their own software is crucial for architectural validation 26m4s.
• Every engineer should have some responsibility for architectural decisions and be able to validate those decisions through testing, rather than relying on a separate architect or testing team 26m24s.
• When using external frameworks or software, decisions made by the creators of those tools can have unintended consequences and should be carefully considered, as they can impact the product's development and security 26m50s.

The Role of AI in Architectural Decision-Making

• Relying on AI to help with architecture and decision-making can be concerning, as it may lead to unforeseen consequences and a lack of understanding of the underlying decisions 27m39s.
• Chatbots can provide incorrect answers, and while some answers can be easily verified, relying solely on chatbots for architecture decisions can be problematic 27m47s.
• Chatbots can be useful as a tool to aid in decision-making, similar to a "rubber duck" for programmers, but they should not replace the architect's responsibility 28m24s.

Continuous Architecture: A Mindset and Practice

• Continuous architecture is about continuously examining, testing, and proving out the decisions made about a system, and it is not just about automation, but also a mental frame of mind 28m45s.
• Continuous architecture involves utilizing technologies like continuous integration and continuous delivery to assess the quality of decisions, but also requires continually questioning and gathering feedback 29m10s.
• It is essential to adopt a mindset of continually reassessing whether the architecture is still suitable and making trade-offs, as architecture is never truly "done" 30m9s.
• Minimum viable architecture should be paired with the minimum viable product, and in every release, decisions should be re-evaluated to ensure they are still valid 30m17s.
• Continuous architecture means continuously testing assertions and beliefs about the system's sustainability 30m31s.
• Architecture is never truly complete, and decisions will evolve over time, requiring a continuous flow of decision-making throughout the product's lifetime 30m41s.
• Expecting architecture to change over time changes one's mental model, and it is essential to be prepared for this evolution 31m3s.
• Assuming all decisions can be made upfront and being right is not a viable approach, and instead, a mindset of continuous evaluation and adaptation is necessary 31m9s.
• Analyzing a situation for too long can lead to incorrect assumptions, and it's better to approach it with the idea of checking and validating decisions regularly 31m12s.
• This approach enables making smaller decisions and affects the entire process, requiring the whole team to be involved, not just one architect 31m27s.
• The team needs to work together to make decisions and validate them, rather than relying on a single person 31m28s.

Conclusion and Call to Action

• Listeners interested in the discussed topics can find articles written by Curt and Pierre on info.com, where they can also leave comments and join the discussion 31m44s.
• The info.com platform allows readers to comment on articles and podcasts, and listeners are encouraged to join the discussion and tune in for future episodes of the podcast 31m51s.