https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Martin Fowler is the chief scientist for ThoughtWorks, and Internet systems delivery and consulting company. Contact him at fowler@acm.org.
What makes a component significant? It is significant because the expert developers say so.
正文：
Wandering down our corridor a while ago, I saw my colleague Dave Rice in a particularly grumpy mood. My brief question caused a violent statement, “We shouldn’t interview anyone who has ‘architect’ on his resume.” At first blush, this was an odd turn of phrase, because we usually introduce Dave as one of our leading architects. The reason for his title schizophrenia is the fact that, even by our industry’s standards, “architect” and “architecture” are terribly overloaded words. For many, the term “software architect” fits perfectly with the smug controlling image at the end of Matrix Reloaded. Yet even in firms that have the greatest contempt for that image, there’s a vital role for the technical leadership that an architect such as Dave plays.
不久前，我在我们的走廊上闲逛，看到我的同事戴夫·赖斯情绪特别暴躁。我的简短问题引发了激烈的言论：“我们不应该采访任何简历上有‘架构师’的人。”乍一看，这是一个奇怪的说法，因为我们通常将Dave介绍为我们的主要架构师之一。他之所以被称为精神分裂症，是因为即使按照我们行业的标准，“架构师”和“架构”都是承载过度的词。对于许多人来说，“软件架构师”一词与重新加载的矩阵末尾自鸣得意的控制图像完全吻合。然而，即使是那些最鄙视这种形象的公司，像Dave这样的建筑师在技术领导方面也扮演着至关重要的角色。
What is architecture? When I was fretting over the title for Patterns of Enterprise Application Architecture (Addison-Wesley, 2002), everyone who reviewed it agreed that “architecture” belonged in the title. Yet we all felt uncomfortable defining the word. Because it was my book, I felt compelled to take a stab at defining it. My first move was to avoid fuzziness by just letting my cynicism hang right out. In a sense, I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important. (Yes, you can imagine a similar phenomenon for architect.) However, as so often occurs, inside the blighted cynicism is a pinch of truth. Understanding came to me after reading a posting from Ralph Johnson on the Extreme Programming mailing list. It’s so good I’ll quote it all. A previous posting said
什么是架构？当我为企业应用级架构模式的标题而烦恼时（Addison-Wesley，2002），每一个审查它的人都认为“架构”就存在于标题中。然而，我们都对定义“架构”这个词感到不安。因为那是我的书，我觉得被迫尝试定义它。我的第一步是通过只是让我的愤世嫉俗继续下去。在一个从某种意义上说，我把架构定义为我们使用的一个词当我们想谈论设计但想要鼓起勇气让它听起来很重要。（是的，可以想象ar也会出现类似的现象chitect.）然而，正如经常发生的那样饱受摧残的愤世嫉俗是对真理的一种歪曲。读了一篇帖子后，我明白了来自RalphJohnson的极限编程邮件列表。这太好了，我将全部引用。之前的帖子说
The RUP, working off the IEEE definition, defines architecture as “the highest level concept of a system in its environment. The architecture of a software system (at a given point in time) is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.”
RUP根据IEEE的定义，将架构定义为“系统在其环境中的最高级别概念。软件系统的架构（在给定的时间点）是通过接口进行交互的重要组件的组织或结构，这些组件由依次较小的组件和接口组成。”
Johnson responded: I was a reviewer on the IEEE standard that used that, and I argued uselessly that this was clearly a completely bogus definition. There is no highest level concept of a system. Customers have a different concept than developers. Customers do not care at all about the structure of significant components. So, perhaps an architecture is the highest level concept that developers have of a system in its environment. Let’s forget the developers who just understand their little piece. Architecture is the highest level concept of the expert developers. What makes a component significant? It is significant because the expert developers say so.
Johnson回应道：我是IEEE标准的评审员，使用了该标准，我徒劳地辩称，这显然是一个完全虚假的定义。系统没有最高级别的概念。客户的概念与开发人员不同。客户根本不关心重要组件的结构。因此，架构可能是开发人员对其环境中的系统的最高级别概念。让我们忘记那些只了解他们的小片段的开发人员。体系结构是专家开发人员的最高级别概念。是什么让组件变得重要？这很重要，因为专家开发人员这么说。
So, a better definition would be “In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers.”
所以更好的定义是“在大多数成功的软件项目中，从事该项目的专家开发人员对系统设计有着共同的理解。这种共同的理解称为‘架构’。这种理解包括系统如何划分为组件以及组件如何通过接口进行交互。这些组件通常由较小的组件组成，但架构只是包括所有开发人员都能理解的组件和接口。”
This would be a better definition because it makes clear that architecture is a social construct (well, software is too, but architecture is even more so) because it doesn’t just depend on the software, but on what part of the software is considered important by group consensus. There is another style of definition of architecture which is something like “architecture is the set of design decisions that must be made early in a project.” I complain about that one, too, saying that architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other.
这是一个更好的定义，因为它清楚地表明了架构是一种社会结构（软件也是如此，但架构更是如此），因为它不仅取决于软件，而且取决于团队一致认为软件的哪些部分是重要的。还有另一种风格的架构定义，类似于“架构是一组必须在项目早期做出的设计决策”我也对这一点表示不满，说架构是您希望在项目早期就能够正确做出的决定，但您不一定比其他任何人都更有可能正确做出这些决定。
Anyway, by this second definition, programming language would be part of the architecture for most projects. By the first, it wouldn’t be.Whether something is part of the architecture is entirely based on whether the developers think it is important. People who build “enterprise applications” tend to think that persistence is crucial. When they start to draw their architecture, they start with three layers. They will mention “and we use Oracle for our database and have our own persistence layer to map objects onto it.” But a medical imaging application might include Oracle without it being considered part of the architecture. That is because most of the complication is in analyzing the images, not in storing them. Fetching and storing images is done by one little part of the application and most of the developers ignore it. So, this makes it hard to tell people how to describe their architecture. “Tell us what is important.” Architecture is about the important stuff. Whatever that is.
无论如何，根据第二种定义，编程语言将是大多数项目架构的一部分。首先，它不会是。某个东西是否是架构的一部分完全取决于开发人员是否认为它很重要。构建“企业应用程序”的人往往认为持久性至关重要。当他们开始绘制架构时，他们从三层开始。他们会提到“我们使用Oracle作为数据库，并有自己的持久层将对象映射到数据库上。”但医疗成像应用程序可能包括Oracle，而不将其视为体系结构的一部分。这是因为最复杂的是分析图像，而不是存储图像。获取和存储图像是由应用程序的一小部分完成的，大多数开发人员都会忽略它。因此，很难告诉人们如何描述他们的架构。“告诉我们什么是重要的。” 架构是关于重要的东西。不管那是什么。
The architect’s role
So if architecture is the important stuff, then the architect is the person (or people) who worries about the important stuff. And here we get to the essence of the difference between the Matrix Reloaded species of architect and the style that Dave Rice exemplifies.
因此，如果架构是重要的东西，那么架构师就是担心重要东西的人。在这里，我们了解了矩阵重新加载的架构师种类与戴夫·赖斯所展示的风格之间的本质区别。
Architectus Reloadus is the person who makes all the important decisions. The architect does this because a single mind is needed to ensure a system’s conceptual integrity, and perhaps because the architect doesn’t think that the team members are sufficiently skilled to make those decisions. Often, such decisions must be made early on so that everyone else has a plan to follow. Architectus Oryzus is a different kind of animal (if you can’t guess, try www.nd.edu/~archives/latgramm.htm). This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem.
架构师Reloadus是做出所有重要决策的人。架构师之所以这样做，是因为需要一颗心来确保系统的概念完整性，也可能是因为架构师认为团队成员没有足够的技能来做出这些决策。通常，这些决定必须尽早做出，以便其他人都有计划遵循。Oryzus是另一种动物（如果你猜不到，可以试试www.nd.edu/~ archives/latgramm.htm）。这种架构师必须非常了解项目中正在发生的事情，寻找重要问题并在它们成为严重问题之前加以解决。【类比扁鹊的三兄弟：典故出自《鶡冠子·卷下·世贤第十六》，原文为：魏文王问扁鹊：“子昆弟三人其孰最善为医？”扁鹊曰：“长兄最善，中兄次之，扁鹊最为下。”魏文王曰：“可得闻邪？”扁鹊曰: “长兄于病视神，未有形而除之，故名不出于家。中兄治病，其在毫毛，故名不出于闾。若扁鹊者，镵血脉，投毒药，副肌肤，闲而名出闻于诸侯。”】
When I see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in nontechnical terms—such as development costs. In many ways, the most important activity of Architectus Oryzus is to mentor the development team, to raise their level so that they can take on more complex issues.
当我看到这样一个架构师时，工作中最引人注目的部分就是紧密的协作。早上，架构师与开发人员一起编程，试图获取一些常见的锁定代码。下午，架构师参加一个需求会议，帮助向需求人员解释他们的一些想法在非技术方面的技术后果，例如开发成本。在许多方面，Architectus Oryzus最重要的活动是指导开发团队，提高他们的水平，以便他们能够处理更复杂的问题。
Improving the development team’s ability gives an architect much greater leverage than being the sole decision maker and thus running the risk of being an architectural bottleneck. This leads to the satisfying rule of thumb that an architect’s value is inversely proportional to the number of decisions he or she makes. At a recent ThoughtWorks retreat, some colleagues and I were talking about the issue of architects. I found it interesting that we quickly agreed on the nature of the job, following Architectus Oryzus, but we could not easily find a name. Architectus Reloadus is too common for us to be comfortable with “architect,” and it’s based on a flawed metaphor (see http://martinfowler.com/ bliki/BuildingArchitect.html). Mike Two came up with the best name I’ve heard so far: guide, as in mountaineering. A guide is a more experienced and skillful team member who teaches other team members to better fend for themselves yet is always there for the really tricky stuff.
提高开发团队的能力给架构师提供了比作为唯一决策者更大的杠杆作用，从而承担成为架构瓶颈的风险。这导致了一条令人满意的经验法则，即架构师的价值与他或她做出的决策数量成反比。在最近的一次ThoughtWorks务虚会上，我和一些同事讨论了架构师的问题。我发现有趣的是，我们很快就同意了这份工作的性质，追随了架构师Oryzus，但我们很难找到一个名字。Architectus Reloadus太常见了，我们无法适应“架构师”，它基于一个有缺陷的隐喻（参见http://martinfowler.com/bliki/BuildingArchitect.html）。Mike Two想出了迄今为止我听过的最好的名字：导游，就像登山一样。导游是一个经验更丰富、技术更娴熟的团队成员，他会教其他团队成员更好地照顾自己，但也总是在那里处理真正棘手的事情。
Getting rid of software architecture
I love writing a startling heading, and the best, like this one, have an important meaning that’s not immediately obvious. Remember Johnson’s secondary definition: “Architecture is the decisions that you wish you could get right early in a project.” Why do people feel the need to get some things right early in the project? The answer, of course, is because they perceive those things as hard to change. So you might end up defining architecture as “things that people perceive as hard to change.” It’s commonly believed that if you are building an enterprise application, you must get the database schema right early on because it’s hard to change the database schema—particularly once you have gone live. On one of our projects, the database administrator, Pramod Sadalage, devised a system that let us change the database schema (and migrate the data) easily (see http:// martinfowler.com/articles/evodb.html).【我喜欢写一个惊人的标题，最好的，像这一个，有一个重要的意义，这不是立即显而易见的。记住Johnson的第二个定义：“架构是您希望能够在项目早期正确做出的决策。”为什么人们觉得需要在项目的早期做好一些事情？当然，答案是因为他们认为这些事情很难改变。因此，您可能最终将架构定义为“人们认为难以改变的东西”通常认为，如果要构建企业应用程序，就必须尽早获得数据库模式，因为很难更改数据库模式，尤其是在上线后。在我们的一个项目中，数据库管理员Pramod Sadalage设计了一个系统，让我们可以轻松地更改数据库模式（并迁移数据）（请参见http://martinfowler.com/articles/evodb.html）。】
By doing this, he made it so that the database schema was no longer architectural. I see this as an entirely good thing because it let us better handle change. At a fascinating talk at the XP 2002 conference (http://martinfowler.com/articles/xp2002.html), Enrico Zaninotto, an economist, analyzed the underlying thinking behind agile ideas in manufacturing and software development. One aspect I found particularly interesting was his comment that irreversibility was one of the prime drivers of complexity. He saw agile methods, in manufacturing and software development, as a shift that seeks to contain complexity by reducing irreversibility— as opposed to tackling other complexity drivers. I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs.【通过这样做，他使数据库模式不再是体系结构。我认为这是一件完全好的事情，因为它让我们更好地应对变化。在XP 2002年会议上的精彩演讲中(http://martinfowler.com/articles/xp2002。经济学家恩里科·扎尼诺托（EnricoZaninotto）分析了制造业和软件开发中敏捷思想背后的基本思想。我发现其中一个特别有趣的方面是他的评论，即不可逆性是复杂性的主要驱动因素之一。他认为，制造业和软件开发中的敏捷方法是一种转变，旨在通过减少不可逆性来控制复杂性，而不是解决其他复杂性驱动因素。我认为架构师最重要的任务之一是通过找到消除软件设计中不可逆性的方法来删除架构。】
Here’s Johnson again, this time in response to an email message I sent him: One of the differences between building architecture and software architecture is that a lot of decisions about a building are hard to change. It is hard to go back and change your basement, though it is possible. There is no theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change. Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. That, and duplication. My reservation of Aspect-Oriented Programming is that we already have fairly good techniques for separating aspects of programs, and we don’t use them. I don’t think the real problem will be solved by making better techniques for separating aspects. We don’t know what should be the aspects that need separating, and we don’t know when it is worth separating them and when it is not. Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. “We have met the enemy, and he is us.”【这又是Johnson，这一次是对我发给他的一封电子邮件的回复：建筑体系结构和软件体系结构之间的区别之一是，关于建筑的许多决策很难改变。很难回去换地下室，尽管这是可能的。没有理论上的理由认为软件的任何东西都很难改变。如果您选择软件的任何一个方面，那么您可以使其易于更改，但我们不知道如何使所有内容都易于更改。使某些东西易于更改会使整个系统更加复杂，而使所有东西易于更改会使整个系统变得非常复杂。复杂性使软件难以更改。还有复制。我对面向切面编程的保留意见是，我们已经有了相当好的技术来分离程序的各个方面，但我们没有使用它们。我认为，通过制定更好的分离方面的技术，真正的问题不会得到解决。我们不知道哪些方面需要分离，也不知道什么时候值得分离，什么时候不值得分离。软件不受物理的限制，就像建筑物一样。它受到想象力、设计和组织的限制。简而言之，它受到人的属性的限制，而不是世界的属性。“我们遇到了敌人，他就是我们。”】
