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).