https://www.infoq.com/articles/framework-architectural-decisions/ BT QCon New York (June 13-15, 2023): Learn how software leaders at early adopter companies are adopting emerging trends. Register Now Close Toggle Navigation Facilitating the Spread of Knowledge and Innovation in Professional Software Development English edition * English edition * Chinese edition * Japanese edition * French edition Write for InfoQ Search [ ] [Search] Sign Up / Login Email [ ] Password [ ] [Login] Forgot password ? InfoQ Account Email [ ] [Send Recovery Email] Back to login Resend Activation [ ] [Resend] Back to login Login with: Google Microsoft Twitter Facebook Don't have an InfoQ account? Sign Up Logo - Back to homepage 2,138,915 Feb unique visitors News Articles Presentations Podcasts Guides Topics Development * Java * Kotlin * .Net * C# * Swift * Go * Rust * JavaScript Featured in Development * Blazing Fast, Minimal Change - Speed Up Your Code by Refactoring to Rust Lily Mara takes an existing codebase and rewrites part of it in Rust, focusing on writing a Rust reimplementation, cross-language regression testing, performance benchmarking of the new code. Blazing Fast, Minimal Change - Speed Up Your Code by Refactoring to Rust All in development Architecture & Design * Architecture * Enterprise Architecture * Scalability/Performance * Design * Case Studies * Microservices * Service Mesh * Patterns * Security Featured in Architecture & Design * A Simple Framework for Architectural Decisions This article describes a framework for making architectural decisions using three building blocks: The company's own Technology Radar; Technology Standards; and Architecture Decision Records (ADRs). The framework clarifies decision-making, team involvement, and information on already made decisions and aligns with the company's needs and culture. A Simple Framework for Architectural Decisions All in architecture-design AI, ML & Data Engineering * Big Data * Machine Learning * NoSQL * Database * Data Analytics * Streaming Featured in AI, ML & Data Engineering * Orchestrating Hybrid Workflows with Apache Airflow Ricardo Sueiras discusses how to leverage Apache Airflow to orchestrate a workflow using data sources inside and outside the cloud. Orchestrating Hybrid Workflows with Apache Airflow All in ai-ml-data-eng Culture & Methods * Agile * Diversity * Leadership * Lean/Kanban * Personal Growth * Scrum * Sociocracy * Software Craftmanship * Team Collaboration * Testing * UX Featured in Culture & Methods * How Visual Thinking Can Help Teams Get Clarity, Be More Creative, and Have More Inclusive Meetings Visual thinking is a way of making sense of the world through images, putting thoughts into pictures. This article is here to help you understand about visual thinking, and how you could use it to support yourself, your teams to create a more inclusive, creative and collaborative culture at work. How Visual Thinking Can Help Teams Get Clarity, Be More Creative, and Have More Inclusive Meetings All in culture-methods DevOps * Infrastructure * Continuous Delivery * Automation * Containers * Cloud * Observability Featured in DevOps * Improving CI/CD Pipelines Through Observability CI/CD pipelines are a vital addition to any workflow but they can be further improved by the selective addition of observability. This article covers what data to monitor, which metrics to track, and how to best visualize the collected data. Improving CI/CD Pipelines Through Observability All in devops EventsNew Helpful links * About InfoQ * InfoQ Editors * Write for InfoQ * About C4Media * Diversity Choose your language * En * Zhong Wen * Ri Ben * Fr [ewogICJidW] QCon New York Find real-world practical inspiration from the world's most innovative software leaders. Attend in-person or online. [ewogICJidW] QCon San Francisco Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or online. [ewogICJidW] The Software Architects' Newsletter Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free. InfoQ Homepage Articles A Simple Framework for Architectural Decisions Architecture & Design QCon San Francisco (Oct 2-6, 2023): Find real-world practical inspiration from senior software engineers. A Simple Framework for Architectural Decisions Like Print Bookmarks Mar 21, 2023 7 min read by * Grygoriy Gonchar reviewed by * Thomas Betts Write for InfoQ Join a community of experts. Increase your visibility. Grow your career.Learn more Key Takeaways * A framework for making architectural decisions can provide clarity on the process of decision-making and who should be involved. * An internal Technology Radar can help teams understand the technology landscape and make informed decisions about which technologies to use. * Technology Standards can ensure broader consistency of crosscutting concerns and reduce the risk of suboptimal adoption of new technologies. * Finally, Architecture Decision Records (ADRs) can capture particular decisions that follow the Standards and the Radar and provide a historical record of their reasoning * These methodologies combined together satisfy all the needs around architectural decision governance and give a simple framework to use A Simple Framework for Architectural Decisions Software engineers must make architectural decisions to proceed with the development. Can we use Python instead of Java for our new microservice? Can we use another bundler when developing our new frontend library? Should I agree on the repository structure with my manager or other teams? Should I use snake_case or camelCase when I am designing the REST API? The company needs to establish a clear framework for making those decisions, who needs to be involved, and where to find information about already-done decisions. It's essential to make such a framework right, as it will define how much freedom and autonomy different teams have. This should align with the business's needs and the company culture you are trying to build at a given stage. Related Sponsored Content Related Sponsor [QconNYrsb-] Uncover emerging trends and practices from domain experts. Attend in-person or online at QCon New York (June 13-15, 2023). This can impact how different leadership roles are perceived, the role of managers and individual contributors in technical decisions, and the level of empowerment at different career levels. While each company will pick different responsible people and different degrees of team autonomy according to its organizational boundaries, maturity, and needs, the framework may need very similar building blocks. In this article, I'd like to share key building blocks which such a framework for making architectural decisions could have, based on my recent work experience across organizations of different scales. These building blocks include your own Tech Radar, Technology Standards, and Architecture Decision Records (ADRs). Building your own Technology Radar Some may know Thoughtworks, who initially established their Technology Radar. Thoughtworks captures and publishes what they see in the field with their customers across the industry. Similarly, you can build your own radar showing the maturity of different technologies, tools, and methodologies your company uses or plans to use. A Technology Radar is a visual representation of your company's current and desired technology stack. You should make your definition of different stages--assess, trial, adopt, and hold, as well as the process of how a given technology should move through those stages. [2Image-1-1] heycar Technology Radar example At heycar, we use the stages in the following way. At first, new technology is in Assess, meaning it's actively researched and evaluated. The assessment state usually ends with a proof of concept and an extensive list of pros and cons of the technology usage in our environment. We then discuss outcomes with the respective internal community of practice or teams that may interact with it. If the list of arguments and proof of concept implementation is convincing, the next step is a controlled Trial period. During the Trial period, the technology is pioneered in production for a single use-case only. If that step is successful, we declare the technology Adopted and give any team a green light for further usage. If the new technology is superseding the previously used one, it might be needed to signal that. That's precisely how we use the Hold status--for the technologies we no longer aim to use and have a replacement strategy. The Radar helps teams to understand the technology landscape and make informed decisions about which technologies to use. If you keep the Radar updated, everyone in the company is aware of the latest state of technologies in use and their impact on the business. Introducing internal Technology Standards The second building block is introducing Technology Standards. Technology Radar captures techniques, platforms, tools, languages and frameworks, and their level of adoption across an organization. However, this may not cover all the needs. Establishing consistent practices for things that apply across different parts of the system can be helpful. For example, you might want to ensure all logging is done in the same format and with the same information included. Or, if you're using a REST API, you might want to establish some conventions around how it should be designed and used, like what headers to use or how to name things. Additionally, if you're using multiple similar technologies, it can be useful to guide when to use each one. Technology Standards define the rules for selecting and using technologies within your company. They ensure consistency, reduce the risk of adopting new technology in a suboptimal way, and drive consistency across the organization. Who should be in charge of the standards? Technology Standards should be created and maintained by a cross-functional team of experts in relevant fields. They should be reviewed regularly and updated as needed to keep up with changes in the technology landscape. Teams should be encouraged to follow the standards and provide feedback on their effectiveness. The format can be different but would likely have detailed explanations and code examples. It can be more formal and follow, for instance, the RFC Format Framework, or be more casual, depending on your preferences and engineering culture. Zalando's RESTful API and Event Guidelines are a good example of the publically shared internal Technology Standard. In addition to the API standard, you may want to introduce logging and monitoring, deployment, and QA standards. Based on internal standards, you can create quality gates such as checking for the test coverage, integrating code linter checking for naming conventions or formatting, or fitness functions verifying your architecture or repository structure. A combination of automated checks, using standards during new joiners onboarding, code reviews, or pair programming will help ensure that standards are used and bring value. In addition to gates that check adherence to the standards, this is also a chance to discuss the value of platform engineering to create a paved road. Don't simply tell people when they've done something wrong--make it easy to do the right thing by default. Adopting Architecture Decision Records (ADRs) practice The third building block for aligning architecture decisions is creating ADRs or lightweight RFCs. ADRs are a way of documenting architectural decisions and their reasoning. They provide a historical record of important decisions and help teams understand why a particular approach was chosen. An ADR should be created by the team responsible for making the architectural decision. They should include information such as the problem being solved, the alternatives considered, the decision made, and the reasoning behind it. They are immutable documents. When a given decision is revisited, it typically results in a new document being created. ADR practice is becoming increasingly popular, so major cloud providers such as AWS and GCP added it to their respective documentation. While Technology Radar and Standards are supposed to give guidance and expected boundaries to the technical decisions, ADRs capture the reasoning and document the particular one-time decisions--reasons for creating a new service or package, introducing new technology, or any other major architecture change. ADRs are typically stored in a centralized repository or documentation tool and are accessible to all relevant teams. They also help new team members get up to speed on the overall architecture and reasons behind significant decisions. The ADR review process can be used for multiple purposes--reviewing and approving decisions and sharing knowledge. While it's common to involve everyone affected in the ADR review, sharing it with more people increases overall architectural awareness across an organization. In addition, it's useful to present ADRs in the internal tech circles to collect more feedback. Sometimes you may have an engineer who solved similar challenges in the past but is not directly working on them right now. Like for the first two pillars, the process covering the final say in finalizing ADRs and what decisions are considered major enough to require an ADR would be different for every organization. To avoid duplication, you may use ADRs to agree on particular design choices for building a new major system change while agreeing on a broader usage of languages, tools, and practices using the Radar and Standards. Having the internal Technology Radar and Standards in place, agreeing on an ADR should be a lean and straightforward exercise as the most substantial technological choices, and principles are already aligned. Conclusions Together, the Technology Radar, Technology Standards, and ADRs form a framework that provides a clear and consistent approach to making architectural decisions, reducing the risk of new technology adoption and providing a historical record of important decisions. By establishing a framework for architectural decisions, teams can ensure that their technology stack is aligned with their business goals and that their teams have the information and guidance they need to make informed decisions. The degree of freedom your team has, and the process to change the Radar, Standards, or ADRs, will shape your engineering culture. Some organizations aim for radical team autonomy, and some aim for high consistency and alignment, which are more restrictive. For example, a possible approach could involve your senior technical leaders in changes to the Radar and Standards, which guide further technical decisions and leave ADRs to the teams responsible for respective software functionality. You can pick the framework and adjust it to your company's needs. About the Author Grygoriy Gonchar Show moreShow less Rate this Article Adoption ( ) ( ) ( ) ( ) ( ) Style ( ) ( ) ( ) ( ) ( ) [ ] [Submit] [ ] [Submit] [ ] Author Contacted This content is in the Architecture topic Related Topics: * Architecture & Design * Architecture * Architecture Decision Records * Related Editorial * Popular across InfoQ + A Simple Framework for Architectural Decisions + Kwok, a Tool to Spin up Kubernetes Nodes in a Second + Distributed Application Runtime (Dapr) v1.10 Released + Understanding Java through Graphs + AWS Introduces Global Condition Context Keys to Improve EC2 Security + Becoming a Great Engineering Manager and Balancing Synchronous and Asynchronous Work Inspired by this content? Write for InfoQ. Writing for InfoQ has opened many doors and increased career opportunities for me. I was able to deeply engage with experts and thought leaders to learn more about the topics I covered. And I can also disseminate my learnings to the wider tech community and understand how the technologies are used in the real world. [8192d07] Vivian HuDevOps News Editor @InfoQ; Director of Products @Second State Write for InfoQ Inspired by this content? Write for InfoQ. I discovered InfoQ's contributor program earlier this year and have enjoyed it since then! In addition to providing me with a platform to share learning with a global community of software developers, InfoQ's peer-to-peer review system has significantly improved my writing. If you're searching for a place to share your software expertise, start contributing to InfoQ. [4105a79] Oghenevwede Emeni Articles contributor @InfoQ; Software Developer, CEO @Pact Write for InfoQ Inspired by this content? Write for InfoQ. I started writing news for the InfoQ .NET queue as a way of keeping up to date with technology, but I got so much more out of it. I met knowledgeable people, got global visibility, and improved my writing skills. [90c5fc1] Edin Kapic.NET News Editor @InfoQ; Lead Engineer @Vista, former Microsoft MVP Write for InfoQ Inspired by this content? Write for InfoQ. Becoming an editor for InfoQ was one of the best decisions of my career. It has challenged me and helped me grow in so many ways. We& apos;d love to have more people join our team. [ccccd59] Thomas BettsLead Editor, Software Architecture and Design @InfoQ; Senior Principal Engineer Write for InfoQ Could you be our next Editor-in-Chief? InfoQ seeks a full-time Editor-in-Chief to join C4Media's international, always remote team. Join us to cover the most innovative technologies of our time, collaborate with the world's brightest software practitioners, and help more than 1.6 million dev teams adopt new technologies and practices that push the boundaries of what software and teams can deliver! Apply Related Content * How to Have More Effective Conversations with Business Stakeholders About Software Architecture How to Have More Effective Conversations with Business Stakeholders About Software Architecture * A Skeptic's Guide to Software Architecture Decisions A Skeptic's Guide to Software Architecture Decisions * AWS Application Composer to Visualize and Create Serverless Workloads Now Generally Available * LinkedIn Improves Development Productivity by 10x by Implementing a Messaging Client-Side SDK * The Future of Istio: Sidecar-Less and Sidecar with Ambient Mesh The Future of Istio: Sidecar-Less and Sidecar with Ambient Mesh * The Process of Creating Decentralized Apps (dApps) The Process of Creating Decentralized Apps (dApps) * Resilient Real-Time Data Streaming across the Edge and Hybrid Cloud Resilient Real-Time Data Streaming across the Edge and Hybrid Cloud * The InfoQ eMag - The InfoQ Trends Reports 2022 The InfoQ eMag - The InfoQ Trends Reports 2022 * Going from Architect to Architecting: the Evolution of a Key Role Going from Architect to Architecting: the Evolution of a Key Role * What Does Technical Debt Tell You? What Does Technical Debt Tell You? * Enabling Effective Remote Working - Principles and Patterns from Team Topologies Enabling Effective Remote Working - Principles and Patterns from Team Topologies * eBPF and the Service Mesh: Don't Dismiss the Sidecar Yet eBPF and the Service Mesh: Don't Dismiss the Sidecar Yet * Building & Operating High-Fidelity Data Streams Building & Operating High-Fidelity Data Streams * Docker+Wasm Reaches Technical Preview 2, Includes Three New Runtime Engines * Google Distributed Cloud Hosted Is Now Generally Available * Survey on Supply Chain Practices Finds Perceived Usefulness of Practice Correlates with Adoption * AWS Announces Open Source Mountpoint for Amazon S3 * Blazing Fast, Minimal Change - Speed Up Your Code by Refactoring to Rust Blazing Fast, Minimal Change - Speed Up Your Code by Refactoring to Rust * Orchestrating Hybrid Workflows with Apache Airflow Orchestrating Hybrid Workflows with Apache Airflow * AWS and NVIDIA to Collaborate on Next-Gen EC2 P5 Instances for Accelerating Generative AI * Explore the Latest Updates to WinForms Visual Basic Application Framework * Billions of Messages Per Minute Over TCP/IP Billions of Messages Per Minute Over TCP/IP * AWS Announces Kubernetes 1.25 Support for EKS * Green Software Development - What Can You Do Now, and Where is the Industry Heading? * Improving Developer Experience in Non-Technical Organisations with BMK * AWS Releases New Cloud-Optimized Linux Distribution with Amazon Linux 2023 * Improving CI/CD Pipelines Through Observability Improving CI/CD Pipelines Through Observability * HashiCorp Consul Improves Envoy Integration, Adds Debugging Tool * How Visual Thinking Can Help Teams Get Clarity, Be More Creative, and Have More Inclusive Meetings How Visual Thinking Can Help Teams Get Clarity, Be More Creative, and Have More Inclusive Meetings * Java 20 Delivers Features for Projects Amber, Loom and Panama * Google Uses AutoML to Discover More Efficient AI Training Algorithm * TypeScript 5 GA Extends Decorators, Stabilizes New Module Resolution Option, and More * The Sentence Similarity Scenario in ML.NET Model Builder * Using ASP.NET Core 7 Minimal APIs: Request Filters, Parameter Mapping, and More Using ASP.NET Core 7 Minimal APIs: Request Filters, Parameter Mapping, and More * Stack Overflow Sentiment Survey Aims to Identify Experimental and Proven Technologies * Microsoft Adds Support for Pod Sandboxing to Azure Kubernetes Service * Java News Roundup: New JEPs, GraalVM 23 Early-Access, Infinispan, Mojarra, Micrometer Metrics * Distributed Application Runtime (Dapr) v1.10 Released * Kwok, a Tool to Spin up Kubernetes Nodes in a Second * AWS Introduces Global Condition Context Keys to Improve EC2 Security The InfoQ Newsletter A round-up of last week's content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example Enter your e-mail address [ ] [ ] Select your country [Select a country] [ ] I consent to InfoQ.com handling my data as explained in this Privacy Notice. [Subscribe] We protect your privacy. Hello stranger! You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered. Get the most out of the InfoQ experience. Tell us what you think [ ] [ ] Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p [ ] Email me replies to any of my messages in this thread [Post Message] Community comments Watch thread * Concept that we should not forget about! by Mikhail Laptev, + Re: Concept that we should not forget about! by shane lee, * Concept that we should not forget about! by Mikhail Laptev, Your message is awaiting moderation. Thank you for participating in the discussion. The concept of ADR is quite an interesting one and extremely useful! That's great that I run into this article, as well as into links on those mainstreams like GCP or AWS. I've been playing with something similar, or, better to say, tried to push through something similar to ADR in my current and former team, usually as one of *.md documents being uploaded to github (at least in this case you can try to keep an eye on immutability), with all the conversation going in either google docs or github issues. It would be great to see, what would be the recommendations to keep ADR review process more convenient and more neat, consider that collaboration would land beyond just text, but includes diagrams, code snippets, etc. Like Reply Back to top * Re: Concept that we should not forget about! by shane lee, Your message is awaiting moderation. Thank you for participating in the discussion. I store adrs in GitHub. Use the adr tool for creating records. Prs provide that nice review process. And once merged publish on an internal docs site using mkdocs. Similar to what backstage provides for its tech docs. Like Reply Back to top Close Your Reply Quote original message [ ] [ ] Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p [ ] Email me replies to any of my messages in this thread [Post Message] Cancel Close Your Reply [ ] [ ] Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p [ ] Email me replies to any of my messages in this thread [Post Message] Cancel Close OK 2 * Development + Blazing Fast, Minimal Change - Speed Up Your Code by Refactoring to Rust + Stack Overflow Sentiment Survey Aims to Identify Experimental and Proven Technologies + Server-Side Swift Gets Swift Certificates and Swift ASN.1 Packages * Architecture & Design + A Simple Framework for Architectural Decisions + Distributed Application Runtime (Dapr) v1.10 Released + LinkedIn Improves Development Productivity by 10x by Implementing a Messaging Client-Side SDK * Culture & Methods + Green Software Development - What Can You Do Now, and Where is the Industry Heading? + Improving Developer Experience in Non-Technical Organisations with BMK + How Visual Thinking Can Help Teams Get Clarity, Be More Creative, and Have More Inclusive Meetings * AI, ML & Data Engineering + Orchestrating Hybrid Workflows with Apache Airflow + AWS and NVIDIA to Collaborate on Next-Gen EC2 P5 Instances for Accelerating Generative AI + Google Uses AutoML to Discover More Efficient AI Training Algorithm * DevOps + Docker+Wasm Reaches Technical Preview 2, Includes Three New Runtime Engines + Survey on Supply Chain Practices Finds Perceived Usefulness of Practice Correlates with Adoption + AWS Announces Kubernetes 1.25 Support for EKS The InfoQ Newsletter A round-up of last week's content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example * Get a quick overview of content published on a variety of innovator and early adopter technologies * Learn what you don't know that you don't know * Stay up to date with the latest information from the topics you are interested in Enter your e-mail address [ ] [ ] Select your country [Select a country] [ ] I consent to InfoQ.com handling my data as explained in this Privacy Notice. [Subscribe] We protect your privacy. QCon International Software Development Conference June 13-15, 2023. Attend in-person or online with on-demand access. QCon New York International Software Conference returns this June 13-15. Technical leaders who are driving innovation and change in software will share the latest trends and techniques from their real-world projects to help you solve common challenges. Level-up on emerging software trends and get the assurance you're adopting the right patterns and practices. SAVE YOUR SPOT NOW Home Create account Login QCon Conferences Events Write for InfoQ InfoQ Editors About InfoQ About C4Media Media Kit InfoQ Developer Marketing Blog Diversity Events * QCon New York JUNE 13-15, 2023 * QCon San Francisco OCTOBER 2-6, 2023 Follow us on Youtube223K Followers Linkedin21K Followers RSS19K Readers Twitter53.4k Followers Facebook21K Likes AlexaNew Stay in the know The InfoQ PodcastThe InfoQ Podcast Engineering Culture Podcast Engineering Culture Podcast The Software Architects' NewsletterThe Software Architects' Newsletter General Feedback feedback@infoq.com Advertising sales@infoq.com Editorial editors@infoq.com Marketing marketing@infoq.com InfoQ.com and all content copyright (c) 2006-2023 C4Media Inc. Privacy Notice, Terms And Conditions, Cookie Policy BT *