https://www.infoq.com/articles/what-software-architecture/ BT Attend QCon San Francisco (Oct 24-28) and find practical inspiration from software leaders. Register 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,359,240 May unique visitors News Articles Presentations Podcasts Guides Topics Development * Java * Kotlin * .Net * C# * Swift * Go * Rust * JavaScript Featured in Development * Reproducible Development with Containers Avdi Grimm describes the future of development, which is already here. Get a tour of a devcontainer, and contrast it with a deployment container. Reproducible Development with Containers All in development Architecture & Design * Architecture * Enterprise Architecture * Scalability/Performance * Design * Case Studies * Microservices * Service Mesh * Patterns * Security Featured in Architecture & Design * Designing Event-Driven Architectures Using the AsyncAPI Specification Fran Mendez discusses event-driven or asynchronous APIs, comparing AsyncAPI with OpenAPI/Swagger, AMQP/MQTT/Kafka with HTTP, and publish/subscribe with request/response. Designing Event-Driven Architectures Using the AsyncAPI Specification All in architecture-design AI, ML & Data Engineering * Big Data * Machine Learning * NoSQL * Database * Data Analytics * Streaming Featured in AI, ML & Data Engineering * What You Should Know before Deploying ML in Production What should you know before deploying machine learning projects to production? There are four aspects of Machine Learning Operations, or MLOps, that everyone should be aware of first. These can help data scientists and engineers overcome limitations in the machine learning lifecycle and actually see them as opportunities. What You Should Know before Deploying ML in Production 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 * Building Effective Developer Tools to Enable an Entire Organization to Move Faster Building effective tooling can help bring down the time to delivery and increase the number of changes delivered safely. This article demonstrates the tools that Monzo has built to enable developers, and how these tools are being used within the engineering function to deploy hundreds of times per day and beyond the engineering function to run a bank at scale. Building Effective Developer Tools to Enable an Entire Organization to Move Faster All in culture-methods DevOps * Infrastructure * Continuous Delivery * Automation * Containers * Cloud * Observability Featured in DevOps * Netflix Drive: Building a Cloud-Native Filesystem for Media Assets In this article, Tejas Chopra discusses Netflix Drive, a generic cloud drive for storing and retrieving media assets - a collection of media files and folders in Netflix. Netflix Drive ties together disparate data (such as: AWS S3, Ceph Storage, Google Cloud Storage, and others) and metadata stores in a cogent form for creating, cataloging and serving these assets to applications and workflows. Netflix Drive: Building a Cloud-Native Filesystem for Media Assets 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 InfoQ Live June InfoQ Live June Learn how cloud architectures achieve cost savings, improve reliability & deliver value. Register Now. InfoQ Live July InfoQ Live July Learn how to migrate an application to serverless and what are the common mistakes to avoid. Register Now. QCon San Francisco QCon San Francisco Understand the emerging software trends you should pay attention to. Attend in-person on Oct 24-28, 2022. InfoQ Homepage Articles Software Architecture: It Might Not Be What You Think It Is Architecture & Design QCon San Francisco (Oct 24-28): Uncover emerging trends and practices from domain experts. Software Architecture: It Might Not Be What You Think It Is Like Print Bookmarks Apr 15, 2022 9 min read by * Pierre Pureur * Kurt Bittner reviewed by * Thomas Betts Write for InfoQ Join a community of experts. Increase your visibility. Grow your career.Learn more Key Takeaways * Software architecture needs to be wrested from committees of people disconnected from developing, and to put it in the hands of the people who can actually make it real and executable, the developers. Only then will we achieve the resilience and sustainability that we need from today's applications * Software architecture is about capturing decisions, not describing structure * Architecting is a skill that agile teams embody, which means that Architect should not be a role * Architecting means continuously exploring new approaches and different alternatives to best meet quality attributes * The key activity of architecting is forming hypotheses about how the system will meet quality attribute goals, and then using empiricism to test whether the system meets them, and then repeating this loop until the system meets its quality goals Software architecture has a contentious reputation in the agile community. In the experiences of many, it is the cause of valueless meetings and irrelevant documentation that is aptly summarized by the expression "the map is not the territory." And yet, applications with poor architecture can quickly become like vehicles abandoned by the roadside, broken and unrepairable. So is there a useful middle ground between these poles of pointlessness? Part of the problem is that architecture is an inapt metaphor for the result of the work of architecting software systems. Inspired by the work of building architects, the word conjures images of beautiful designs that hint at utopian futures. But the work of architecting software systems is far more dynamic than the building architecture metaphor supports. Buildings are static, and the work of building architects is done just once. Software, by its nature, is ever-shifting and dynamic; when it stops changing, it starts to die. To arrive at a better understanding of software architecture, we have to go back to the origins of the word architect: It comes from the ancient Greek word arkitekton, arkhi- (arkhi-, "chief") + tekton (tekton, "builder"). Architecture is created by people building things. That sense has become lost in the work of building architects, many of whom have never poured a foundation, framed a building, or run plumbing or heating pipes. Design and building have become separated. Not so in software, where how something is built influences what is built, and vice versa. Software architecture is about decisions, not structure Related Sponsored Content * Cassandra: The Definitive Guide - 3rd Edition (By O'Reilly) Related Sponsor [DataStaxLo] The Open Stack for Modern Data Apps. Kubernetes Based. Cloud Delivered. Developer Ready. Sign up to try Astra for free. The building analogy has led some software architects to focus too much on structure and behaviors, and not the decisions that produce those structures and behaviors. It's not that structure and behavior are unimportant, but they are the results of a thought process that is important to preserve if the system is to sustainably evolve over time. Knowing why someone did something is just as important as knowing what they did. What they did should be easy to see in the code, if it is well-organized and commented on, but the why is often lost. The reason for this is that architectural decisions in software are rarely clear-cut; nearly every architectural decision is a compromise between competing alternatives, and the merit of alternatives is hard to see until you try a few and see how they work. Knowing what was tried and rejected is often more useful than knowing what worked. As an old saying goes, good judgment comes from experience, most of which comes from bad judgment. This is also one reason why software architects must still be developers; they can't understand or predict the forces at work in a system without developing and testing something. Software Architect is not some sort of honorarium for people who have retired from active development but still have knowledge the organization finds useful; it has to be more. The act of architecting requires sufficient knowledge of a system to frame useful hypotheses about quality attributes, and the expertise to write code and devise tests (or work closely with team members who can) that can evaluate those hypotheses. Architecting is a skill; Architect is not a role In truth, using a title like Software Architect sends the wrong message about the nature of the work. The reality is that lots of software developers do architectural work, they just don't recognize it as such. Anytime they make decisions about how to handle quality attributes, they are affecting the architecture of the system. Being more aware of how implicit decisions affect the ability of the system to achieve quality goals is the first step in improving the architecture of the system. So what kind of skills do people need to develop to improve the quality of their architectural work? There are a few: * An increased focus on quality attributes, which are the key cross-cutting requirements that good architecture should address. It's easy for teams to focus on functional requirements, as they tend to be tangible, even visible things the system does for its users. But it's the quality attributes of a system that shape whether it will remain viable over the long term: things like scalability, performance, security, supportability, and maintainability, to name a few. * An ability to conceptualize and address system-wide concerns. Quality attributes are most often determined by forces that affect the whole system, not just one part. While modularized design and separation of concerns are important to building good systems, they also make it harder for team members to have a holistic view of the system. * An understanding of the complete lifecycle of a system. This requires having experience not just developing a system, but also testing it, deploying it, running it in production, maintaining it over time, and making substantial modernization to it when it needs to do significantly new things. Understanding the lifecycle of a system and how it responds to change is essential to making good decisions that limit technical debt that, over time, can threaten the viability of a system. * An ability to balance concerns and compromise. There is rarely one right answer in architecture work. Architecture often involves making trade-offs between conflicting Quality Attribute Requirements (QARs) and constraints. * An ability to learn from experience and synthesize new approaches. This involves the ability to take the results from trying things in a directed way (running experiments) and to generalize that learning in the form of principles that can guide further experiments. Some of these principles take the form of "standards," which is a somewhat misleading term because standards need to be constantly tested using experiments to determine when they are no longer useful. We've seen many developers justifiably frustrated with organizational "standards" that made sense at one time but which now keep teams stuck in the past. * An ability to demonstrate leadership. The ability to raise concerns, foster discussion of different perspectives, and facilitate consensus helps a team confront and overcome complex architectural problems. Anyone on a team could do this, and anyone who is architecting must do this. Architecting means continuously exploring Architecting modern software applications is a fundamentally explorative activity. Teams building today's applications encounter new challenges every day: unprecedented technical challenges as well as providing customers with new ways of solving new and different problems. This continuous exploration means that the architecture can't be determined up-front, based on past experiences; teams have to find new ways of satisfying quality requirements. As an example of how exploration is essential to discovering the architecture, consider the following: Assume that you are part of a team working on a software system originally designed to handle structured, tabular data stored in a SQL database. This system now needs to be enhanced to handle unstructured data, including images and videos, and the volumes are expected to significantly increase over what the system currently handles. You consider adding a NoSQL database to your technology stack to handle the new data types, but since your team does not have significant experience with this technology, experimentation is essential to select the right database product and configure it to meet the new data volume requirements. As the team works through these technical issues, they form hypotheses about which approaches will best meet their desired QARs, which are assumptions as well and will change over time. They build a part of the solution to test these hypotheses, and they make decisions based on the results. The cumulative result of these decisions about how to meet QARs is the architecture of the system. The team may communicate these decisions in different ways, including using documentation and diagrams, but the docs and diagrams are not the architecture, it's the decisions, and their why, that matter. Important information about these decisions includes things like: * The cost of reversing a decision, should that become necessary. If you have to replace a service, a DBMS, or even a framework, it would help to know how expensive you think this might be. In some cases, it may mean rewriting the application. * Clearly articulating any constraints or assumptions. Understanding the working constraints and assumptions that you've made may help the team who has to renovate your work in the future. For example, knowing that you've assumed that you will have no more than X concurrent users, and this has caused you to make certain decisions about concurrent threads or processes will help your future colleagues understand where they might need to change something if that constraint is exceeded. * How you've met specific quality attribute requirements (QAR). For each QAR, you should describe what you've done to ensure that it will be met, and not just in theory, but what tests you've run to prove it. Link to specific test cases and their associated automated tests, so that when the QARs change you will be able to easily reevaluate the architectural quality of the system. * What options you've considered as your rationale for decisions. Knowing what things you considered and rejected is often even more useful than knowing what you decided; it shows your thought process and provides insights into constraints you may have been under when you made the decision. If these constraints are removed in the future, knowing why you made certain decisions will help future developers make better decisions. [1Decisions] Figure 1: Relationships between QAR, Decision, and Technical Debt * What technical debt you've knowingly incurred. Some decisions will, inevitably and unavoidably, create technical debt; for example, the decision to meet reliability goals by using a SQL database has some side effects on technical debt (see Figure 1). The now long-past "Y2K problem" was a conscious decision that developers made at the time that reduced data storage, memory use, and processing time needs by not storing century data as part of standard date representations. The problem was that they didn't expect the applications to last so long, long after those constraints became irrelevant. Had they communicated their decisions and described the potential impact more precisely, there may not have been such a scramble to respond at the end of the last century. Conclusion Software architecture, as a discipline, needs a makeover. Its image suffers from a lot of old ideas about what problems it needs to solve and how it should go about solving those problems. Viewing software architecture as a continuous activity focused on forming hypotheses about how the system will meet quality attributes, and then using empiricism to prove that the system meets them, is the essence of a continuous approach to software architecting. What also needs to change is to wrest software architecture from committees of people disconnected from developing, and to put it in the hands of the people who can actually make it real and executable, the developers. Only then will we achieve the resilience and sustainability that we need from today's applications. About the Authors Pierre Pureur Show moreShow less Kurt Bittner Show moreShow less 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'd love to have more people join our team. [ccccd59] Thomas BettsLead Editor, Software Architecture and Design @InfoQ; Senior Principal Engineer Write for InfoQ Rate this Article Adoption ( ) ( ) ( ) ( ) ( ) Style ( ) ( ) ( ) ( ) ( ) [ ] [Submit] [ ] [Submit] [ ] Author Contacted This content is in the Architecture topic Related Topics: * Architecture & Design * Architecture * Related Editorial * Popular across InfoQ + AWS Publishes Guide to Architecture Decision Records + AWS Introduces IP-Based Routing on Route 53 + Spring Boot 2.7.0 Released with Support for GraphQL, Podman and Cache2k + Google's New Imagen AI Outperforms DALL-E on Text-to-Image Generation Benchmarks + Spring for GraphQL Version 1.0 Released + Managing Tech Debt with Glenn Engstrand Related Content * AWS Publishes Guide to Architecture Decision Records * Minimum Viable Architecture in Practice: Creating a Home Insurance Chatbot Minimum Viable Architecture in Practice: Creating a Home Insurance Chatbot * A Minimum Viable Product Needs a Minimum Viable Architecture A Minimum Viable Product Needs a Minimum Viable Architecture * Why You Should Care about Software Architecture Why You Should Care about Software Architecture * Software Architecture and Design InfoQ Trends Report--April 2022 Software Architecture and Design InfoQ Trends Report--April 2022 * Microsoft's New Simulation Framework FLUTE Accelerates Federated Learning Algorithm Development * How Do We Utilize Chaos Engineering to Become Better Cloud-Native Engineers? How Do We Utilize Chaos Engineering to Become Better Cloud-Native Engineers? * Mammoths Stumping in the Cloud Era: Meeting EU Regulations by Being Cloud Native and Cloud Agnostic * Reducing Cognitive Load in Agile DevOps Teams Using Team Topologies Reducing Cognitive Load in Agile DevOps Teams Using Team Topologies * Designing Secure Tenant Isolation in Python for Serverless Apps Designing Secure Tenant Isolation in Python for Serverless Apps * Low-Code Tools Optimize Engineering Time for Internal Applications Low-Code Tools Optimize Engineering Time for Internal Applications * Architecting for Resilience Panel Architecting for Resilience Panel * How the Financial Times Approaches Engineering Enablement How the Financial Times Approaches Engineering Enablement * The InfoQ eMag: Paths to Production: Deployment Pipelines as a Competitive Advantage The InfoQ eMag: Paths to Production: Deployment Pipelines as a Competitive Advantage * The InfoQ eMag: The InfoQ Trends Report 2021 The InfoQ eMag: The InfoQ Trends Report 2021 * Designing Event-Driven Architectures Using the AsyncAPI Specification Designing Event-Driven Architectures Using the AsyncAPI Specification * JFrog Artifactory Supports Binary Dependencies for Swift * How to Become a Staff-Plus Engineer * C# Warning Waves Hint at New Keywords in the Future * Reduce Carbon Dioxide Emissions with Serverless and Kubernetes Native Java Reduce Carbon Dioxide Emissions with Serverless and Kubernetes Native Java * Google's New Imagen AI Outperforms DALL-E on Text-to-Image Generation Benchmarks * Microsoft Launches the Public Preview of Dynatrace for Azure as a SaaS Solution in Their Marketplace * Building Effective Developer Tools to Enable an Entire Organization to Move Faster Building Effective Developer Tools to Enable an Entire Organization to Move Faster * Microsoft Introduces a New Learning Resource with Azure Skills Navigator * Spring Boot 2.7.0 Released with Support for GraphQL, Podman and Cache2k * Java News Roundup: JDK 19 in Rampdown, JDK 20 Expert Group, Eclipse Mojarra 4.0 * GitHub Extends Its Supply Chain Security to Rust * CNCF Accepts KubeVirt as an Incubating Project * AWS Introduces IP-Based Routing on Route 53 * Microservices to Async Processing Migration at Scale Microservices to Async Processing Migration at Scale * Java 17: the Path, Features, Tips and Tricks Panel Java 17: the Path, Features, Tips and Tricks Panel * Netflix Drive: Building a Cloud-Native Filesystem for Media Assets Netflix Drive: Building a Cloud-Native Filesystem for Media Assets * Apple Extends macOS Virtualization Capabilities and Introduces Rosetta for Linux Binaries * What You Should Know before Deploying ML in Production What You Should Know before Deploying ML in Production * New Observability Features for AWS Step Functions * How to Accelerate Your Staff+ Career through Open Source Engagement How to Accelerate Your Staff+ Career through Open Source Engagement * Transitioning to Modern Testing: How Testers Can Stop Being the Training Wheels for Teams * A New Microsoft Platform in Town: the Microsoft Intelligent Data Platform * Heighliner: an App Development Platform to Bring Stack-as-Code Experience * Spring for GraphQL Version 1.0 Released 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 * Could be a role too... by Sam Siddiqi, + Re: Could be a role too... by Eirik Mangseth, o Re: Could be a role too... by Sam Siddiqi, # Re: Could be a role too... by Pierre Pureur, @ Re: Could be a role too... by Saheem Siddiqi, @ Re: Could be a role too... by Saheem Siddiqi, * Software Architecture is More Than Just Decisions by Kelvin Meeks, + Re: Software Architecture is More Than Just Decisions by Pierre Pureur, * architect in the role of facilitator or mentor by Glenn Engstrand, + Re: architect in the role of facilitator or mentor by Eirik Mangseth, + Re: architect in the role of facilitator or mentor by Sam Siddiqi, + Re: architect in the role of facilitator or mentor by Pierre Pureur, o Re: architect in the role of facilitator or mentor by Glenn Engstrand, + Re: architect in the role of facilitator or mentor by John Broderick, * Architecture Is Certainly Not What You Think It Is by Dick Dowdell, * Could be a role too... by Sam Siddiqi, Your message is awaiting moderation. Thank you for participating in the discussion. Architecture is certainly a skill, but if there is sufficient effort required in matters related to archcitecture, it may well be a distinct role. With respect to metaphor, Sam Newman in his book on Microservices had described an Architect as akin to a city planner...that one resonated with me. Like Reply Back to top * [N1JAYKN1RA] Software Architecture is More Than Just Decisions by Kelvin Meeks, Your message is awaiting moderation. Thank you for participating in the discussion. My response to this article: intltechventures.blogspot.com/2022/04/2022-04-1... Like Reply Back to top * [9VaMyfrPrb] architect in the role of facilitator or mentor by Glenn Engstrand, Your message is awaiting moderation. Thank you for participating in the discussion. Thanks for your article documenting how software architecture has changed in a modern, agile world. Other articles that capture this important trend include Scaling the Practice of Architecture, Conversationally and Establishing an Architecture Council. I suspect that you are emphasizing how architecture should not be a role as a response to the old days of top-down, ivory tower style architecture. I agree with you in that the old school role of architect is not productive in today's world. May I humbly suggest that there is still a need for a role of architect that serves a different function? The devs doing architecture on a product focused team may not be all that focused on the big picture. Cross team interoperability and refactoring for platform services that span products are big opportunities to reduce wasteful duplicity or rework. There is logistical value in advising an organization wide technology landscape. It is harder to move engineers from one team to another if each team has completely disparate technology stacks. Someone with a larger scope than a single product could be more helpful with these issues but they should not dictate. Instead those kind of portfolio architects should still advise. It's all about soft leverage. Like Reply Back to top * Re: Could be a role too... by Eirik Mangseth, Your message is awaiting moderation. Thank you for participating in the discussion. @Sam Siddiqi He (Newman) also derides "non-coding architects" in his book. Like Reply Back to top * Re: architect in the role of facilitator or mentor by Eirik Mangseth, Your message is awaiting moderation. Thank you for participating in the discussion. Glenn Engstrand, is that why Spotify lets each team decide which tech stack to use focusing on rapid delivery of services instead of standardising the tech stack throughout the company? Perhaps the "common tech stack benefit" is more of a fallacy that anything else? If you have skilled people who understands software engineering concepts and how to apply them across stacks, then surely you don't need an architect (or architects) to mandate a particular stack, do you? Also, do platform services really require an architect role? Not so sure about that either. Like Reply Back to top * Re: Could be a role too... by Sam Siddiqi, Your message is awaiting moderation. Thank you for participating in the discussion. @Eirik Mangseth, Architects should, and IMHO must, keep their coding skills sharp. And I do agree that's where the building Architect analogy falls short...I suppose the "real" architects don't really need any level of competence in the trades their essentially guiding. It does not, I feel, negate what I wrote. If there is sufficient work, that is to say if the system is non-trivial enough and the problem domain rich enough, then perhaps a distinct role if not outright team might be merited. Your millage will vary based on the kind of system you write, the nature and structure of your organization, the impacts and risks that need to be mitigated (financial, loss of life, etc), and so on. All architects should code, but the idea that all architecture could emerge from 'skilled enough' coders is a very shallow take. Like Reply Back to top * Re: architect in the role of facilitator or mentor by Sam Siddiqi, Your message is awaiting moderation. Thank you for participating in the discussion. @Glenn Engstrand, Agreed, these trade-offs might seem obvious for some, but need serious consideration for others. It seems that too many in the field want to copy the F/MAANGs, but when you put into practice what they do with a tight budget, and 20 devs tops...with a large enterprise-y feature set that has thousands of distinct feature points...reality hits quite hard. A simple decision to use a particular language may seem trivial to one organization, but a major investment to others. Individual development teams, driven by a PO, will be well aware of their functional need, but architectural decisions will more or less come from a global context. An Architect, among other things, will need to derive architecturally significant requirements directly from organizational objectives. They almost never come from the POs. In this sense an Architect is an important stakeholder along side a PO, and for platform like features may double as the PO. Making such decisions at a team level is just architecture by committee. Again, I stress, individual organizations will have differing needs. Like Reply Back to top * Re: Software Architecture is More Than Just Decisions by Pierre Pureur, Your message is awaiting moderation. Thank you for participating in the discussion. The main point about focusing on decisions is to treat all architectural and design ideas, including quality attribute requirements as unproven assumptions until they are evaluated empirically. As long as architects only deal with "key abstractions" at a purely conceptual level, they are fooling themselves about what they really know. If you can't test it, it's not real. Structures and other architecture deliverables result from decisions. If portraying structure communicates the decision most effectively, then convey structure, but structure alone may not convey the rationale for that structure. In the "Continuous Architecture In Practice" book, we stated that "decisions are the primary unit of work of architectural activities" (continuousarchitecture.com/2021/06/01/essential...) and I would still choose architectural decisions and their implications if I had to pick one single concern for architectural activities. Like Reply Back to top * Re: Could be a role too... by Pierre Pureur, Your message is awaiting moderation. Thank you for participating in the discussion. I believe that architecture has become a skill, not a role, and is now a continual flow of decisions that are revisited continuously. Architecture activities have become a team responsibility in the Agile, Cloud, and DevOps era. Making this a "role" implies that one (or perhaps several) IT professionals will end up driving most architectural decisions. In my experience, things work much better when the whole team is responsible for the decisions. When things do not go as planned (and unfortunately it happens), there is no finger pointing and everyone ends up pulling together to find a solution. Like Reply Back to top * Re: architect in the role of facilitator or mentor by Pierre Pureur, Your message is awaiting moderation. Thank you for participating in the discussion. I honestly don't believe that putting someone in an "architect role" automatically ensures that facilitation or mentoring will happen. Those are critical skills that need to happen in any well-functioning team. and I would expect senior team members to mentor and facilitate regardless of their "role". One of the best ways I know of in order to mentor people is to involve them in the architectural decision-making process, that more often than not involves writing code to settle architectural debates. In addition, one of the skills critical to architectural work is the ability to conceptualize, and to look beyond the scope of a project in order to make a good decision. Like Reply Back to top * [9VaMyfrPrb] Re: architect in the role of facilitator or mentor by Glenn Engstrand, Your message is awaiting moderation. Thank you for participating in the discussion. Perhaps Greghor Hohpe's take on this would make more sense in his The Architect Elevator -- Visiting the upper floors article. Here is an excerpt. Traditionally, architects were considered to be those folks who make major design decisions on a project, draw architecture diagrams, and direct developers. Those tasks are in fact better handled by the development team and modern tooling than by a single person. Many modern companies therefore eschew software architect as a separate job title, even though they highly value software architecture. The good news is that many new tasks await architects in large organizations. And they are far more interesting and impactful than drawing class diagrams. However, they require architects to engage at the upper floors of their organization. Like Reply Back to top * Re: Could be a role too... by Saheem Siddiqi, Your message is awaiting moderation. Thank you for participating in the discussion. @Pierre Pureur, tl;dr; It's a distinct practice, (not just a set of checklist todos), and any practice with sufficient work merits a corresponding job role. Architecture can't just be the decisions. I say this if the decisions are static or continuously evolving. There's a whole rich practice that produces those decisions, and I think you did a good job in capturing this fact in the article. To elaborate on my personal expierence, there is a context that determines what is architecturally significant, and what is not. Who mines that? What are the possible ways to address the requirements? There is then a subsequent trade-off analysis that any diligent practice should consider. What are the trade-offs? What are the criteria we use to evaluate? Who are the important stakeholders that have inputs, and who is the target audience for this analysis? If the proposal requires funding, who is going to make the business case? That's work. Like it or not, once a decision is going to be made, you're going to have to explain it to key stakeholders. What are the cost implications? How are developers to realize what is proposed? A POC-quality experiment might answer some of the questions, for the developers. Won't help much with executives that need to know why you're proposing an increase in operational costs by 100K a year because of a decision by a particular agile team. So you're going to have to explain the same thing multiple times, in different ways. That's work. Now, a particular design might span multiple teams. Each team will be responsible for the delivery of their part of the solution. How to coordinate? How do such designs get produced? By committee? Now, during the course of development, there will be further trade-offs. Some will be immaterial. Others will negate capabilities promised to stakeholders. What's the process by which we consider these? Who's going to keep track, across teams? That's work. I really am scratching the surface, but I'll stop short there. Now, let's look at the agile teams. They're paired with a PO that is charged with delivering, continuously, value to the clients. If an agile team is to work on something, it must be backlogged. You can't monetize architectural work like you can feature work backed by paying clients, possibly sponsoring the specific work item. How does the agile team negotiate time? How do you justify exploratory tasks, or testing a hypothesis which may, more often than not, have a negative result? Has your organization budgeted for this work? How does the agile teams, which ideally work on specific business value streams, handle the context switching and (most importantly) the cognitive load that may result in performing all of what I just mentioned above, plus much more? Again, I'm scratching the surface. I'm not suggesting that any of the above questions absolutely require an Architect role to address. Ultimately, I'm simply saying that for a myriad of reasons, some organizations look at the concerns above and opt to have a distinct stream of work, and a distinct architecture practice led by the Architect role, because there is a sufficient amount of 'architecture' work that must be done, and it's desirable to track and prioritize it independently than development work. And there are ways to do that without having Architects as ivory tower gurus (e.g. consider Architects as peers to POs), who can definitely contribute (e.g. working POC hand-offs, possibly have architects embedded in agile teams to lead the charge and be prime for enabler tasks) to the agile effort. I fully understand the desire to have autonomous, self-sufficient agile teams. I just don't see Architects as a distinct role as contrary to that goal, unless we force ourselves to adopt a particular caricature of the ivory tower architect...even if we don't fit the profile ourselves. I also don't see diluting the practice of Architecture as a 'everyone does it' kind of activity as having real value, unless you're blessed with a project/ product/organization that just doesn't require that much effort. Cheers! Like Reply Back to top * Re: Could be a role too... by Saheem Siddiqi, Your message is awaiting moderation. Thank you for participating in the discussion. @Pierre Pureaur, in my previous comment the "not just a set of checklist todos" is a silly statement, and I recognize it's not at all what you and Kurt suggest in the article. Cheers! Like Reply Back to top * Re: architect in the role of facilitator or mentor by John Broderick, Your message is awaiting moderation. Thank you for participating in the discussion. I really like this article and it's great to see so much discussion about it in the comments. On "refactoring for platform services that span products are big opportunities to reduce wasteful duplicity or rework", I've seen this firsthand. Product team A built their solution and some time after product team b built their solution. Both teams focused on their product alone, so neither knew that there was a common sub domain between the products. There was no-one responsible for the big picture here, and this resulted in duplicated effort. To make it more difficult, each teams implementation was specific to their own product, so extracting the sub-domain after the fact is a much more costly job. Being able to identify this before it happens would be something that falls under the architect umbrella, and it looks like a responsibility that you could call "describing the structure". The thing is, unless that someone is actively doing this in a role, it's unlikely to happen. Like Reply Back to top * Architecture Is Certainly Not What You Think It Is by Dick Dowdell, Your message is awaiting moderation. Thank you for participating in the discussion. There is an old saying: "A camel is a horse designed by a committee." Being an architect is a role, and architecture is more than recording decisions. Architecture is mostly about defining component models and how pieces are connected to each other. It is also a discipline built upon years of acquired knowledge and technique. It is an exercise in rational compromise and it is an integral part of software development--- never be trusted to non-developers. A foundational Agile principle is that the best architectures, requirements, and designs emerge from self-organizing teams. That means that the knowledge and expertise of the whole team should be utilized. Not that the Web developer should write the Java code or the Java coder should style the Web pages. Effective teams apply the skills of their members to the most appropriate tasks (and listen to the ideas of all their members). Many of the problems of agile development come from oversimplifying the complexities of software systems. Many of the practices recommended by the amateurs, who teach things like Scrum without real development experience, are counter-productive. medium.com/nerd-for-tech/leading-agile-developm... 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 15 * Development + How to Prepare for the Unexpected: an InfluxData Outage Story Told at KubeCon EU 22 + Reproducible Development with Containers + Green Software Development: Terminology and Climate Commitments Explained by Microsoft at Devoxx UK * Architecture & Design + Designing Event-Driven Architectures Using the AsyncAPI Specification + Minimum Viable Architecture in Practice: Creating a Home Insurance Chatbot + Managing Tech Debt with Glenn Engstrand * Culture & Methods + How to Become a Staff-Plus Engineer + Building Effective Developer Tools to Enable an Entire Organization to Move Faster + Mailchimp's Culture of Production-ready, Momentum, Togetherness, and Pragmatism * AI, ML & Data Engineering + Google's New Imagen AI Outperforms DALL-E on Text-to-Image Generation Benchmarks + Microsoft's New Simulation Framework FLUTE Accelerates Federated Learning Algorithm Development + What You Should Know before Deploying ML in Production * DevOps + GitHub Extends Its Supply Chain Security to Rust + CNCF Accepts KubeVirt as an Incubating Project + Netflix Drive: Building a Cloud-Native Filesystem for Media Assets 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 Software Development Conference Real-world technical talks. No product pitches. Practical ideas to inspire you and your team. QCon San Francisco - Oct 24-28, In-person. QCon San Francisco brings together the world's most innovative senior software engineers across multiple domains to share their real-world implementation of emerging trends and practices. Uncover emerging software trends and practices to solve your complex engineering challenges, without the product pitches.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 * InfoQ Live JUNE 21, 2022 * InfoQ Live JULY 19, 2022 * InfoQ Live AUGUST 23, 2022 * QCon San Francisco OCTOBER 24-28, 2022 * QCon Plus NOVEMBER 29 - DECEMBER 9, 2022 * QCon London MARCH 27-31, 2023 * QCon San Francisco OCTOBER 2-6, 2023 Follow us on Youtube212K Followers Linkedin18K Followers RSS19K Readers Twitter50k Followers Facebook20K 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-2022 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with. Privacy Notice, Terms And Conditions, Cookie Policy BT *