Who need Architect？谁需要架构？（Martin Fowler）

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.

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

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

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.

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

标签：because,Who,important,architect,architecture,Martin,Architect,change,software
来源： https://www.cnblogs.com/guanghuiqq/p/16355306.html