这篇文章上次修改于 200 天前，可能其部分内容已经发生变化，如有疑问可询问作者。 ###Chapter 14 Architecture Review Board 第 14 章架构审查委员会 > We shall be unable to turn natural advantage to account unless we make use of local guides.—Sun Tzu > 除非我们利用当地向导，否则我们将无法利用自然优势。——孙子 We started the last chapter by explaining our shifting focus from reactive processes,such as what we do when things go wrong, to proactive processes, such as how wedesign features to have fewer problems. The first proactive process that we intro-duced was the Joint Architecture Design (JAD) process. JAD ensures the design offeatures, and projects are conducted in a cross-functional manner, bringing the bestof all technology knowledge to work on the problem. We concluded with the men-tion of a review process for certain JAD projects. This review process is known as theArchitecture Review Board (ARB). The ARB has many purposes, but the primarygoal is to validate the design of the JAD. 在上一章的开头，我们解释了我们的重点从反应性流程（例如出现问题时我们做什么）转向主动性流程（例如我们如何设计功能以减少问题）。我们引入的第一个主动流程是联合架构设计（JAD）流程。 JAD 确保功能的设计，并且项目以跨职能的方式进行，利用所有最好的技术知识来解决问题。最后我们提到了某些 JAD 项目的审查流程。此审查过程称为架构审查委员会 (ARB)。 ARB 有很多用途，但主要目标是验证 JAD 的设计。 We used a very simple sport analogy of running to provide a high-level idea of thedifference between JAD and ARB. If you will recall in our analogy, JAD was theequivalent to the training and ARB was the actual race. JAD can take place over sev-eral days or weeks, whereas ARB is generally a single meeting that provides a focuseddiscussion on the outcome of the JAD, including not only the design but the tradeoffsas well. ARB is by our definition a review board of select architects and leaders fromeach of the functional or business areas, whose job is to ensure that all companyarchitectural principles have been incorporated and that best practices have beenapplied. ARB is also one of the barrier condition processes that we will discuss withinChapter 18, Barrier Conditions and Rollback. 我们使用跑步这个非常简单的运动类比来提供 JAD 和 ARB 之间差异的高级概念。如果您还记得我们的类比，JAD 相当于训练，ARB 相当于实际的比赛。 JAD 可能会持续几天或几周，而 ARB 通常是一次会议，集中讨论 JAD 的结果，不仅包括设计，还包括权衡。根据我们的定义，ARB 是一个由来自每个职能或业务领域的精选架构师和领导者组成的审查委员会，其工作是确保所有公司架构原则均已纳入其中并应用最佳实践。 ARB 也是我们将在第 18 章“屏障条件和回滚”中讨论的屏障条件过程之一。 ####Ensuring Scale Through Review 通过审查确保规模 We have asked you repeatedly through this book how a certain process or focusmight have an impact on scalability. It shouldn’t come as any surprise that the answeris generally the same: the people and processes within your organization will make orbreak the scalability of your application. Chances are nil that you will luck into anarchitecture that scales as required by your business and supports itself without theproper team in place and with that team following the proper processes. As we dis-cussed in the last chapter, having a cross-functional team design the applicationensures that people with different knowledge work together to find the best solution.Additionally, these people now have a combined goal of making this feature a suc-cess. Without those two critical pieces in place, the missing knowledge and experien-tial chasm prevalent in most organizations ensure that periodically features will failand cause availability and scalability issues for your business. 我们在本书中反复询问您某个流程或焦点如何对可扩展性产生影响。答案通常是相同的，这不足为奇：组织内的人员和流程将决定或破坏应用程序的可扩展性。如果没有适当的团队，并且该团队遵循适当的流程，那么您幸运地获得一个可以根据您的业务需求进行扩展并支持自身的架构的可能性为零。正如我们在上一章中讨论的那样，让跨职能团队设计应用程序可确保具有不同知识的人员共同努力找到最佳解决方案。此外，这些人员现在有一个共同的目标，即使此功能取得成功。如果没有这两个关键部分，大多数组织中普遍存在的知识缺失和体验鸿沟会导致定期功能失败，并导致业务的可用性和可扩展性问题。 The JAD process is an excellent major step in guaranteeing that you have designeda feature that takes into account all the various technology aspects as well as one thathelps to break down the cross team barriers that typically exist. The second step inthis process is to make certain that there is some oversight and governance on theJAD teams as well as provide a check to ensure consistency across the JAD teams. JAD 流程是一个出色的重要步骤，可确保您设计的功能考虑到所有不同的技术方面，并且有助于打破通常存在的跨团队障碍。此流程的第二步是确保对 JAD 团队进行一定的监督和治理，并提供检查以确保 JAD 团队之间的一致性。 This oversight and consistency check comes in the form of the ARB. 这种监督和一致性检查以 ARB 的形式出现。 Architectural principles are similar to coding standards; if they are documentedand taught to all engineers, they should be consistently followed. But if you don’t fol-low up and check on your engineers, some of them, even those with the best inten-tions, may cut some corners with the intention of fixing things later. Unfortunately,with competing demands for engineers’ time, the likelihood is that they won’t fixthose corners that were cut, no matter how well intentioned they are. If standards arenot reviewed by peers or managers, they will slip. Unfortunately, it is a natural phe-nomenon among almost every team. We will discuss this more in Chapter 19, Fast orRight? when we cover whether to do things quickly or correctly. In a perfect world,there would be no other pressures on the engineers except to get the projects donecorrectly, but that is rarely the case. There are almost always additional pressuresthat must be balanced. The other factor with standards is that someone will likelymisinterpret even the clearest of them. Especially as you have new engineers comingon to the team, you need to ensure that they all properly understand the standardsand can implement them. Discussion on hypothetical examples and even testing canbe good predictors, but validating with real-world examples is always the best way toensure the standards are truly understood. 架构原则与编码标准类似；如果它们被记录下来并向所有工程师传授，那么就应该始终如一地遵循它们。但如果你不跟进并检查你的工程师，他们中的一些人，即使是那些有最好意图的人，也可能会偷工减料，以便稍后修复问题。不幸的是，由于对工程师时间的竞争性需求，他们很可能不会修复那些被削减的角落，无论他们的意图有多好。如果标准没有经过同事或管理者的审查，它们就会下滑。不幸的是，这几乎是每个团队的自然现象。我们将在第 19 章“快还是对？”中对此进行更多讨论。当我们讨论是否要快速或正确地做事时。在完美的世界中，除了正确完成项目之外，工程师不会有其他压力，但这种情况很少发生。几乎总是有必须平衡的额外压力。标准的另一个因素是，即使是最清晰的标准，也可能有人会误解。特别是当您的团队中有新工程师加入时，您需要确保他们都正确理解标准并能够实施它们。对假设示例的讨论甚至测试都可以是很好的预测因素，但用现实世界的示例进行验证始终是确保真正理解标准的最佳方法。 Validation of the use and interpretation of architectural principles is the primarypurpose of the ARB. By reviewing certain JAD designs, you will ensure that teamsstay focused on performing the best designs possible, not cutting corners, and thatacross all the teams there is a consistent understanding and implementation of theprinciples. Through a continuous use of the architectural principles, you will guaranteethat your application is designed from the start to scale. This is the direct correlationbetween architecture principles and scalability that we talked about in Chapter 12,Exploring Architectural Principles. JAD is used to set the standard that these princi-ples should consistently be followed and ARB is the check to make sure this is done. 验证架构原理的使用和解释是 ARB 的主要目的。通过审查某些 JAD 设计，您将确保团队始终专注于执行尽可能最佳的设计，而不是走捷径，并且所有团队对原则都有一致的理解和实施。通过持续使用架构原则，您将保证您的应用程序从一开始就被设计成可扩展的。这就是我们在第 12 章“探索架构原则”中讨论的架构原则和可扩展性之间的直接关联。 JAD 用于设定应始终遵循这些原则的标准，而 ARB 则用于检查以确保做到这一点。 ####Board Constituency 董事会选区 There are certain people or roles that you will want on the ARB, but more impor-tantly are the traits that these people need to display. Let’s talk about these traits firstand then we will discuss the roles. Hopefully, these two spheres overlap completelyand all the proper roles are filled with people who display all the proper attributes.To start with, you want people who are respected in the organization. They may berespected because of their position, their tenure, or possibly because of their expertisein a particular area of technology or business. 您可能希望在 ARB 中聘用某些人员或角色，但更重要的是这些人需要展示的特质。我们先谈谈这些特征，然后再讨论角色。希望这两个领域完全重叠，并且所有适当的角色都由具有所有适当属性的人担任。首先，您需要在组织中受到尊重的人。他们可能因为他们的职位、任期或者可能因为他们在特定技术或业务领域的专业知识而受到尊重。 People who hold a particular position can be important to the ARB in order toprovide the gravitas to uphold their decisions. You do not want the JAD team to beasked by ARB to redesign something only to have them petition to the CTO or VP ofengineering to have that decision overthrown. The ARB needs to be comprised of theright people to make the right decision and to be given the final authority of thatdecision. If this requires VPs to be on the ARB, they should be. If the VPs delegate theARB to managers or architects, the VPs need to support them and not second-guessthem. The ARB, in these matters, would be considered the A (Accountable) withinour RASCI process. 担任特定职位的人对于 ARB 来说可能很重要，因为他们可以为他们的决定提供庄严的支持。您不希望 ARB 要求 JAD 团队重新设计某些东西，结果却让他们向首席技术官或工程副总裁请愿，要求推翻该决定。 ARB 需要由合适的人员组成，以做出正确的决定，并获得该决定的最终权力。如果这要求 VP 加入 ARB，他们就应该加入。如果副总裁将 ARB 委托给经理或架构师，副总裁需要支持他们，而不是事后批评他们。在这些问题上，ARB 将被视为我们的 RASCI 流程中的 A（负责人）。 There are always leaders in an organization that are not in the management ranks.These can be senior engineers or architects, anyone who demonstrates leadership insome manner. These are the people that the team looks to in meetings to sway opin-ions and provide guidance. These people are the ones we describe in our chapter onleadership as naturally gifted in understanding people and how to motivate them, orthey have worked very hard to become good at that. Either way, the trait of leader-ship is one that you want to look for when selecting people to place on the ARB. 组织中总有一些不在管理队伍中的领导者。他们可以是高级工程师或建筑师，任何以某种方式表现出领导能力的人。团队希望这些人在会议中影响意见并提供指导。这些人就是我们在领导力一章中描述的那些人，他们天生具有理解他人以及如何激励他们的天赋，或者他们经过非常努力的努力才变得擅长这一点。无论哪种方式，领导力特质都是您在选择 ARB 人员时需要寻找的特质。 Expertise, whether in engineering disciplines, architecture, or business, is a charac-teristic that people should display if they are participants on the ARB. These peopleusually are in roles such as architects, senior engineers, or business analysts but canbe found in lots of other places as well. They are the type of people that get soughtout when there is a tough question to answer or a crisis to be solved. Their expertisecomes in a variety of subjects and could include expertise on the platform itselfbecause of a long tenure working with the product or perhaps with a specific technol-ogy such as caching or even with a specific large customer of the business. 专业知识，无论是工程学科、建筑学还是商业领域，都是 ARB 参与者应该展示的一个特征。这些人通常担任建筑师、高级工程师或业务分析师等角色，但也可以在许多其他地方找到。当有棘手的问题需要回答或危机需要解决时，他们是那种会受到追捧的人。他们的专业知识涉及各种主题，并且可能包括平台本身的专业知识，因为他们长期使用该产品，或者可能使用特定的技术（例如缓存），甚至与特定的业务大客户合作。 To summarize, the traits or characteristics that we want to look for in ARB mem-bers are leaders who are respected and who have domain expertise. Some membersmay have a greater amount of one characteristic than another. For instance, a seniordirector of engineering may be well respected and display great leadership but maynot have true domain expertise. This senior director may still be an excellent candi-date for the review board. Here are some roles within the organization that youshould consider looking at as possible candidates as members of the ARB. 总而言之，我们希望在 ARB 成员中寻找的特质或特征是受人尊敬且拥有领域专业知识的领导者。有些成员的一种特征可能比另一种特征多。例如，一位高级工程总监可能会受到尊敬并表现出出色的领导能力，但可能不具备真正的领域专业知识。这位高级董事可能仍然是审查委员会的优秀候选人。以下是组织内的一些职位，您应该考虑将其视为 ARB 成员的可能候选人。 * Chief architects * Scalability architects * Infrastructure architects * VP or directors of engineering * VP or directors of operations or infrastructure * Senior systems administrators, database administrators, or network engineers * Senior engineers *CTO or CIO * General manager of business unit * Business analysts This list is not inclusive but should provide you with an idea of where to look formembers who display our three key traits of respectability, leadership, and domainexpertise. As with most topics that we have discussed, the real test is whether it worksfor and within your organization. The number of members of the ARB can varydepending on the organization, the number of people available, and the variety ofskill sets required. We recommend the board consist of between four and eight members. * 首席建筑师 * 可扩展性架构师 * 基础设施架构师 * 副总裁或工程总监 * 运营或基础设施副总裁或总监 * 高级系统管理员、数据库管理员或网络工程师 * 高级工程师 *首席技术官或首席信息官 * 事业部总经理 * 业务分析师 此列表并不包含所有内容，但应该让您了解在哪里寻找具有我们的三个关键特征（即受人尊敬、领导力和领域专业知识）的成员。与我们讨论的大多数主题一样，真正的考验是它是否适用于您的组织以及在您的组织内是否有效。 ARB 的成员数量可能会有所不同，具体取决于组织、可用人员数量以及所需技能的多样性。我们建议董事会由四到八名成员组成。 Membership on the ARB should be considered an additional responsibility to anindividual’s current role. It is always considered voluntary, so if necessary a membercan ask to be excused. We ideally would like to see the ARB team remain in place fora significant period of time so that it can establish tenure in terms of assessingprojects and designs. There are many ways that you can modify the permanent ornonpermanent nature of this membership and several factors that you may want toconsider when deciding on who should be a permanent member and who should berotational. ARB 会员资格应被视为个人当前角色的额外责任。它始终被认为是自愿的，因此如有必要，会员可以要求缺席。我们理想地希望看到 ARB 团队在相当长的一段时间内保持不变，以便它能够在评估项目和设计方面建立任期。您可以通过多种方式修改此成员资格的永久或非常任性质，以及在决定谁应该成为常任成员以及谁应该轮换时您可能需要考虑的几个因素。 One factor to start considering is how many suitable members do you have in yourorganization? If there are only four people who display the traits that we mentionpreviously as necessary for serving on this board, you will probably have to insistthat these be permanent positions. Another factor that will determine how perma-nent, semipermanent, or rotational this role should be is how often you have featuresthat need to proceed through ARB. If you have enough engineers and enough JADprojects that you are meeting more than once per week, you may need to rotate peo-ple or even consider having two different ARB teams that can alternate. A third fac-tor, besides the quantity of candidates and quantity of ARB meetings, is specificity ofexpertise. If there are multiple technologies or technology stacks or separate applica-tions, you should consider rotating people in and out of the board depending on thefeature being discussed. 要开始考虑的因素之一是您的组织中有多少合适的成员？如果只有四个人表现出我们之前提到的在该委员会任职所必需的特征，那么您可能必须坚持让这些人成为永久职位。决定该角色的永久、半永久或轮换程度的另一个因素是您有需要通过 ARB 进行的功能的频率。如果您有足够多的工程师和足够多的 JAD 项目，每周要开会不止一次，那么您可能需要轮换人员，甚至考虑拥有两个可以轮换的不同 ARB 团队。除了候选人数量和ARB会议数量之外，第三个因素是专业知识的特殊性。如果存在多种技术或技术堆栈或单独的应用程序，您应该考虑根据正在讨论的功能将人员轮换进或出董事会。 There are various methods of rotation for the ARB positions. One straightforwardmethod is to change the constituency of the board every quarter of the year. Depend-ing on how many people are fit for this service, they could rotate on the board everysix months or once each year or even beyond. Another method for rotation of ARBmembers is to leave some members permanent, such as the architects, and rotate themanagement (VP of engineering, VP of operations, CTO, etc.) and the team members(senior engineer, senior systems administrator, senior network engineer, etc). Any ofthese methods will work fine as long as there is consistency in how each teamapproaches its decisions and is given the authority of approving or rejecting the JADproposals. ARB 位置的轮换方法有多种。一种简单的方法是每年每个季度更换董事会选区。根据适合这项服务的人数，他们可以每六个月或每年一次甚至更长的时间在董事会轮换一次。 ARB成员轮换的另一种方法是让一些成员永久保留，例如架构师，并轮换管理层（工程副总裁、运营副总裁、CTO等）和团队成员（高级工程师、高级系统管理员、高级网络工程师） ， ETC）。只要每个团队的决策方式保持一致，并被赋予批准或拒绝 JAD 提案的权力，任何这些方法都可以很好地发挥作用。 ####Conducting the Meeting 主持会议 The ARB meeting can be as formal or informal as your organizational culture feelsthat it is necessary. Our experience is that these meetings can be very intimidating forline engineers, database administrators, and other JAD members; therefore, a veryinformal setting is our preference. The formality should come from the fact that therewill be a go or no-go decision made on the architecture of the feature; that should beenough to establish the need for a well thought out and well-presented design by theJAD team. ARB 会议可以是正式的也可以是非正式的，具体取决于您的组织文化认为有必要。我们的经验是，这些会议对于一线工程师、数据库管理员和其他 JAD 成员来说可能非常令人生畏；因此，我们更喜欢非常非正式的环境。正式性应该来自于这样一个事实：将对功能的架构做出进行或不进行的决定；这应该足以证明 JAD 团队需要经过深思熟虑和精心呈现的设计。 Regardless of how formal or informal you determine the meeting should be, theyshould all include the following steps: 无论您确定会议应该是正式还是非正式的，它们都应该包括以下步骤 1.Introduction. Some members of the JAD may not know members of the ARB ifthe engineering organization is large. 1.简介。如果工程组织规模较大，JAD 的一些成员可能不认识 ARB 的成员。 2.State Purpose. Someone on the ARB should state the purpose of the meeting sothat everyone understands what the goal of the meeting is. We suggest you pointout that the ARB will be making a judgment on the proposed architecture andnot people on the JAD team. If the design is sent back with major or minor revi-sions requested, the decision should not be taken as a personal attack. Everyonein the organization should have as their agenda to ensure the proper governanceof the IT systems and ensure the scalability of the system. 2.陈述目的。 ARB 中的某个人应该说明会议的目的，以便每个人都了解会议的目标是什么。我们建议您指出，ARB 将对提议的架构做出判断，而不是 JAD 团队的人员。如果设计被发回并要求进行重大或较小的修改，则该决定不应被视为人身攻击。组织中的每个人都应该将确保 IT 系统的正确治理并确保系统的可扩展性作为自己的议程。 3.Architecture Presentation. The JAD team should present to the ARB its pro-posed design. A well-structured presentation should walk the ARB membersthrough the thought process starting with the business requirements; follow thiswith the tradeoffs, alternative designs, and finally the recommended design withstrengths and weaknesses. 3.架构演示。 JAD 团队应向 ARB 提交其提议的设计。结构良好的演示文稿应引导 ARB 成员从业务需求开始思考流程；接下来是权衡、替代设计，最后是推荐的设计及其优点和缺点。 4.Q&A. The ARB should spend some time asking questions about the design toclarify any points that were vague from the presentation. 4.问答。 ARB 应该花一些时间询问有关设计的问题，以澄清演示中模糊的任何要点。 5.Deliberation. The ARB members should dismiss the JAD team and deliberate onthe merits of the proposed design. This can be in many forms, such as cast an ini-tial vote to weigh where each member stands or choose someone to lead the discus-sion point by point through the pros and cons of the design before casting ballots. 5.审议。 ARB 成员应解散 JAD 团队并审议拟议设计的优点。这可以有多种形式，例如进行初步投票以权衡每个成员的立场，或者在投票之前选择某人逐项引导讨论设计的优点和缺点。 6.Vote. The ARB should have an established process for determining when prod-uct features get approved and when they get rejected. We have often seen ARBsthat reject a design if a single member votes Nay. You may want to adopt a 3/4rule if you believe getting a 100% agreement will be unlikely and unproduc-tively arduous. If this is the case, we recommend that you reconsider who makesup the constituency of the board. Members should most highly consider what isbest for the company. Someone who abuses his power and consistently hasslesJAD teams is not looking out for the company and should be replaced on theARB team. 6.投票。 ARB 应该有一个既定的流程来确定产品功能何时获得批准以及何时被拒绝。我们经常看到，如果单个成员投反对票，ARB 就会拒绝某个设计。如果您认为获得 100% 的一致意见不太可能且难度很大，您可能需要采用 3/4 规则。如果是这种情况，我们建议您重新考虑董事会选区的组成人员。成员应该高度重视什么对公司最有利。滥用权力并不断骚扰 JAD 团队的人并不是在为公司着想，应该在 ARB 团队中被替换掉。 7.Conclusion. When a decision is made, the ARB should call back in the JAD andexplain its decision. This decision could be one of four courses: 7.结论。做出决定后，ARB 应回电 JAD 并解释其决定。这个决定可能是以下四种课程之一： * Approval. The first decision could be an approval to move forward as out-lined in the proposal. * 赞同。第一个决定可能是批准按照提案中的概述继续推进。 * Rejection. The second decision could be a rejection of the design and arequest for a completely new design to be constructed. This second choice isan absolute rarity. Almost always there is something from the proposeddesign that can be salvaged. * 拒绝。第二个决定可能是拒绝设计并要求建造全新的设计。这第二个选择绝对是罕见的。几乎总是有一些东西可以从提议的设计中挽救出来。 * Conditional Approval. The third option is an approval to move forward butwith some changes. This would indicate that the team does not need to resub-mit to ARB but can proceed under its own guidance. * 有条件批准。第三种选择是批准继续前进，但进行一些更改。这表明团队不需要重新提交给 ARB，而是可以在自己的指导下继续进行。 * Rejection of Components. The fourth choice is a rejection of the proposeddesign but with specific requests for either more information or redesignedcomponents. This fourth option is the most common form of rejection andthe specific request for more information or a change in the design usuallycomes from specific members of the ARB. This fourth decision does require aresubmission to ARB for final approval prior to beginning development onthe feature. * 拒绝组件。第四种选择是拒绝拟议的设计，但有具体要求，要求提供更多信息或重新设计组件。第四种选择是最常见的拒绝形式，对更多信息或设计更改的具体请求通常来自 ARB 的特定成员。第四个决定确实需要在开始开发该功能之前提交给 ARB 以获得最终批准。 These steps can be modified as necessary to accommodate your team size, exper-tise, and culture. The most important item to remember (and you should remind theteam of) is that it should first and foremost put what is best for the company beforepersonal likes, distastes, or agendas, such as something causing more work for theirteam. And, what is best for the company is to get more products in front of the cus-tomers while ensuring the scalability of the system. 可以根据需要修改这些步骤，以适应您的团队规模、专业知识和文化。要记住的最重要的一点（你应该提醒团队）是，首先应该把对公司最有利的事情放在个人喜好、厌恶或议程（例如会给团队带来更多工作的事情）之前。而且，对公司来说最好的就是让更多的产品呈现在客户面前，同时确保系统的可扩展性。 #####Image Storage Feature 图像存储功能 At our fictional company AllScale, a feature for the human resource management (HRM) appli-cation that allows for the storage of pictures of personnel had been developed. The softwareengineer, Sam Codur, was not knowledgeable about storage hardware and designed the fea-ture without any input from the operations team. When it was time to deploy the feature, the VPof operations, Tom Harde, had some tough questions that could not be answered in terms ofthe system level requirements of the storage such as SLAs, retrieval time, and so on. After lotsof discussion with the VP of engineering, Mike Softe, the issue was escalated to Johnny Fixer,the CTO. He decided to pull the feature from the release and redesign it properly. As part of theafter action review or postmortem of this issue, Johnny decided to introduce the teams to theconcept of Joint Architecture Design. Both the engineering and operations teams embracedthis process as a way to improve the product features being developed as well as strengthenthe working relationships between the teams. 在我们虚构的公司 AllScale 中，开发了一项人力资源管理 (HRM) 应用程序功能，允许存储人员照片。软件工程师 Sam Codur 对存储硬件不了解，并且在没有运营团队任何意见的情况下设计了该功能。当部署该功能时，运营副总裁 Tom Harde 提出了一些棘手的问题，这些问题在存储的系统级要求（例如 SLA、检索时间等）方面无法得到解答。经过与工程副总裁 Mike Softe 进行大量讨论后，该问题被上报给首席技术官 Johnny Fixer。他决定从版本中删除该功能并对其进行适当的重新设计。作为此问题的事后行动审查或事后分析的一部分，Johnny 决定向团队介绍联合架构设计的概念。工程和运营团队都接受此流程，作为改进正在开发的产品功能以及加强团队之间工作关系的一种方式。 Johnny was very pleased with how the teams had really taken to the JAD process. He knewthere was more that he could do and thought now was the time to continue improving histeams’ processes. Johnny asked Tom and Mike to join him for lunch and introduced the idea ofan Architectural Review Board. The idea, he explained, was to allow us, the leadership team,as well as our senior technical folks, a chance to review all of the large or riskier features. Withboth the teams having availability and scalability as goals, which affected their bonuses, bothTom and Mike were anxious to implement a process that would allow them to have a direct say inthe design and architecture of key features. The three of them worked the rest of the afternoonto rough out the process, including who should be permanent members of the board (the threeof them) and who should be revolving (the engineering architects and operations directors). Johnny 对团队真正采用 JAD 流程的方式感到非常满意。他知道自己可以做更多的事情，并认为现在是继续改进团队流程的时候了。约翰尼邀请汤姆和迈克一起吃午餐，并介绍了架构审查委员会的想法。他解释说，这个想法是让我们领导团队以及我们的高级技术人员有机会审查所有大型或风险较高的功能。由于两个团队都以可用性和可扩展性为目标，这会影响他们的奖金，汤姆和迈克都渴望实现一个流程，使他们能够在关键功能的设计和架构中拥有直接的发言权。他们三人花了整个下午的时间来制定流程，包括谁应该是董事会的常任成员（他们三人）以及谁应该是轮值成员（工程架构师和运营总监）。 After introducing the new ARB process to their teams, it was decided that the first featurethat would go through the ARB process was the image storage feature that had been the inspi-ration for the JAD process. Sam Codur, the engineer responsible for the image storage feature,and Mark Admeen, the operations systems administrator, assigned the responsibility of partici-pating in the JAD, worked on their presentation of the feature’s design. They were a bit nervouswhen it came time for the meeting, but Johnny, Tom, Mike, and the other board memberspresent quickly put them at ease by asking questions and taking up the conversation them-selves to discuss the merits of various approaches. Sam and Mark concluded their presenta-tion and were asked to wait outside for a few minutes while the board discussed the matter. 在向团队介绍新的 ARB 流程后，他们决定通过 ARB 流程的第一个功能是图像存储功能，这也是 JAD 流程的灵感来源。负责图像存储功能的工程师 Sam Codur 和操作系统管理员 Mark Admeen 负责参与 JAD，负责介绍该功能的设计。开会时他们有点紧张，但约翰尼、汤姆、迈克和其他出席的董事会成员很快就通过提问和自行对话来讨论各种方法的优点，让他们放松下来。萨姆和马克结束了他们的演示，并被要求在外面等几分钟，以便董事会讨论此事。 After the door closed, Johnny began by asking each member in turn his or her opinion ofthe design. Knowing that this was his or her chance to sign off or reject the proposed design,each person started quite cautiously. By the end of the discussion, all members had agreedthat they were impressed with the level of detail and thought that had been put into the featuredesign and had unanimously voted to approve the feature to move forward to the developmentphase. They brought Sam and Mark back into the room and shared the good news with them,congratulating them on being the first to present to the ARB and on being the first to pass theARB with flying colors. 门关上后，约翰尼开始依次询问每个成员对设计的看法。每个人都知道这是他或她签署或拒绝拟议设计的机会，所以开始时都非常谨慎。讨论结束时，所有成员都一致认为，他们对细节水平印象深刻，并认为已将其纳入功能设计，并一致投票批准该功能进入开发阶段。他们把 Sam 和 Mark 带回房间，跟他们分享了这个好消息，祝贺他们第一个向 ARB 汇报，并第一个出色地通过了 ARB。 ####Entry and Exit Criteria 进入和退出标准 Similar to the JAD process, we recommend that specific criteria must be met before aproduct feature can begin the ARB process. As such, certain criteria must be met inorder for that feature to move out of ARB and for development to begin. These crite-ria should be held up as strict standards to ensure that the ARB process is respectedand decisions emanating from the board are adhered. Failure to do so results in aweak process that wastes everyone’s time and is eventually bypassed in favor ofquicker routes to design and development. 与 JAD 流程类似，我们建议在产品功能开始 ARB 流程之前必须满足特定标准。因此，必须满足某些标准才能将该功能移出 ARB 并开始开发。这些标准应作为严格的标准，以确保 ARB 流程得到尊重，董事会做出的决定得到遵守。如果不这样做，就会导致流程薄弱，浪费每个人的时间，并最终被绕过，转而采用更快的设计和开发路线。 The entry criteria for a feature coming out of JAD into ARB are the following: 从 JAD 进入 ARB 的功能的进入标准如下 * Established Board. The Architecture Review Board must be established basedupon the criteria mentioned earlier in terms of roles and behaviors that themembers should demonstrate. * 成立董事会。架构审查委员会必须根据前面提到的关于成员应表现出的角色和行为的标准来建立。 * JAD Complete. The feature should meet the exit criteria outlined in the lastchapter for JAD. This includes the following: * JAD 完成。该功能应满足 JAD 上一章中概述的退出标准。这包括以下内容 + Consensus. The JAD team should be in agreement and all members shouldsupport the final design. If this is absolutely not possible, a feature may besubmitted to ARB with this fact acknowledged and the two or more proposeddesigns each presented. + 共识。 JAD 团队应该达成一致，并且所有成员都应该支持最终设计。如果这绝对不可能，则可以向 ARB 提交一项功能，并承认这一事实，并分别提出两个或多个提议的设计。 + Tradeoffs Documented. If there were any significant tradeoffs made in the designwith respect to the requirements, cost, or principles, these should be documented.qFinal Design Documented. The final design must be documented and postedfor reference. + 权衡已记录。如果设计中在要求、成本或原则方面做出了任何重大权衡，则应记录这些内容。最终设计记录在案。最终设计必须记录并发布以供参考。 * Feature Selection. The feature having completed JAD should be considered as acandidate for ARB. If this feature meets any of the following, it should proceedthrough ARB: * 特征选择。已完成 JAD 的功能应被视为 ARB 的候选功能。如果此功能满足以下任一条件，则应通过 ARB 进行处理 + Noncompliance with architectural principles. If any of the architectural prin-ciples were violated, this feature should go through ARB. + 不符合架构原则。如果违反任何架构原则，则该功能应通过 ARB。 + Projects that cannot reach consensus on design. If the team fails to reach con-sensus, it can either be reassigned to a new JAD team or it can be sent to ARBfor a final decision on the competing designs. + 无法就设计达成共识的项目。如果团队未能达成共识，可以将其重新分配给新的 JAD 团队，也可以将其发送给 ARB 对竞争设计做出最终决定。 + Significant tradeoffs made. If tradeoffs had to be made in terms of productrequirements, cost, or other nonarchitectural principles, this should flag a fea-ture to proceed to ARB. + 做出了重大权衡。如果必须在产品要求、成本或其他非架构原则方面进行权衡，则应标记一个功能以继续进行 ARB。 + High risk features. We will discuss how to assess risk in much more detail in afuture chapter, but if the feature is considered a high risk feature, it should gothrough ARB. A quick way of determining if this is high risk is to look at howmany core components the feature touches or how different it is from otherfeatures. Either of these will result in an increase amount of risk. + 高风险特征。我们将在下一章中更详细地讨论如何评估风险，但如果该功能被认为是高风险功能，则应该通过 ARB。确定这是否是高风险的一个快速方法是查看该功能涉及多少核心组件，或者它与其他功能有多么不同。其中任何一个都会导致风险增加。 Depending on the decision made by the ARB, there are different exit criteria for afeature. Here are the four decisions and what must be done following the ARB session: 根据 ARB 的决定，某个功能有不同的退出标准。以下是 ARB 会议后的四项决定以及必须采取的行动 * Approval. Congratulations, nothing more, required of the team from ARB. * 赞同。恭喜，仅此而已，ARB 团队需要的。 Now the tough part begins by having to actually develop and implement theproject as it has been designed. 现在最困难的部分是必须按照设计实际开发和实施项目。 * Rejection. If the design is completely rejected, the ARB provides a number ofreasons for its decision. In this case, the same JAD team may be asked to rede-sign the feature or a new team may be formed to do this second design. Theteam should remain in place to provide the design if the current team has theright expertise and if it is still motivated to succeed. * 拒绝。如果设计被完全拒绝，ARB 会提供多种决定理由。在这种情况下，可能会要求同一个 JAD 团队重新设计该功能，或者可能会组建一个新团队来进行第二次设计。如果当前团队拥有适当的专业知识并且仍然有成功的动力，则该团队应该留在原地提供设计。 * Conditional Approval. If the ARB has conditionally approved the design, theteam should incorporate the conditions into its design and begin to produce thefeature. The team may return to the ARB in person or via email if there are anyquestions or feel it needs further guidance. * 有条件批准。如果 ARB 有条件批准该设计，团队应将这些条件纳入其设计并开始生产该功能。如果有任何问题或认为需要进一步指导，团队可以亲自或通过电子邮件返回 ARB。 * Rejection of Components. If the ARB rejects the design of certain components,the same JAD team should come up with alternative designs for these compo-nents. Because ARB is most often treated as a discussion, the JAD team shouldhave a good idea of why each component was rejected and what would beneeded to satisfy the board. In this case, the JAD team does need to reschedulewith the ARB to receive final signoff on its design. * 拒绝组件。如果 ARB 拒绝某些组件的设计，同一 JAD 团队应该为这些组件提出替代设计。由于 ARB 通常被视为讨论，因此 JAD 团队应该清楚了解每个组件被拒绝的原因以及需要满足董事会的要求。在这种情况下，JAD 团队确实需要与 ARB 重新安排时间，以获得其设计的最终批准。 #####Checklist—Keys for ARB Success 清单 — ARB 成功的关键 The following is a checklist of key attributes or actions that you should follow to ensure yourARB is a success: 以下是您应遵循的关键属性或操作清单，以确保您的 ARB 取得成功 * Proper board composition * Successfully complete JAD with the feature * Ensure the right features get sent to ARB * Do not allow political pressures to bypass features from ARB * Ensure everyone understands the purpose of ARB—improved scalability through rigor-ous design * JAD team should be well prepared for its presentation and Q&A session * Establish ahead of time the ARB criteria for passing (100% of members is recommended) * No petitions allowed on the board’s decisionsBy following this checklist, you should be able to ensure the success and proper outcome ofthe ARB process. * 正确的董事会构成 * 使用该功能成功完成 JAD * 确保将正确的功能发送至 ARB * 不允许政治压力绕过 ARB 的功能 * 确保每个人都理解 ARB 的目的——通过严谨的设计提高可扩展性 * JAD团队应为演讲和问答环节做好充分准备 * 提前制定ARB通过标准（建议100%会员通过） * 不允许对董事会的决定提出请愿通过遵循此清单，您应该能够确保 ARB 流程的成功和正确结果。 ####Conclusion 结论 In this chapter, we covered the Architecture Review Board in detail. We started bydiscussing why it is important to review the outputs of processes such as designs fromJAD or code from development. Without review, it is too common for people withthe best of intentions to allow the standards to slip, inadvertently misunderstand thestandards, or misapply them. Review solves both of these problems and does not cre-ate an overly burdensome process step. 在本章中，我们详细介绍了架构审查委员会。我们首先讨论了为什么审查流程的输出（例如 JAD 的设计或开发的代码）很重要。如果不进行审查，善意的人很容易忽视标准、无意中误解标准或误用标准。审核解决了这两个问题，并且不会产生过于繁琐的流程步骤。 We then talked about the ARB constituency. We detailed the three behaviors ortraits that we felt were essential for members of the ARB regardless of their positions.These behaviors are respect, leadership, and expertise. We offered some suggestionson specific roles that individuals may hold within your organization who wouldlikely meet these criteria. Lastly in this section, we discussed whether the ARB mem-bership should be a rotational role or a permanent one. Either way, the ARB positionshould be in addition to one’s primary job in the organization. 然后我们讨论了 ARB 选区。我们详细介绍了我们认为对于 ARB 成员至关重要的三种行为或特质，无论其职位如何。这些行为是尊重、领导力和专业知识。我们针对您的组织中可能满足这些标准的个人可能担任的特定角色提供了一些建议。最后，在本节中，我们讨论了 ARB 成员身份应该是轮换角色还是永久成员。无论哪种方式，ARB 职位都应该是组织中主要工作的补充。 Next, there was an outline of how the ARB meeting should be conducted. Theamount of formality in the ARB is dependent on the culture of the organization, butwe recommended for as much informality as possible in order for it not to be toointimidating and to foster a discussion about the design. 接下来，概述了 ARB 会议应如何进行。 ARB 中的正式程度取决于组织的文化，但我们建议尽可能多地非正式，以免过于令人生畏并促进有关设计的讨论。 We concluded this chapter with the entry and exit criteria for ARB. The entry cri-teria are focused on ensuring that the right feature is being sent through ARB, thatthe right ARB team is formed, and that the feature is as prepared as possible to pro-ceed through ARB. Selecting the right feature is not always easy; therefore, we rec-ommended four tests for whether a feature should proceed through ARB. These werenoncompliance with architectural principles, significant tradeoffs having to be madeto the business requirements, inability of the JAD team to reach consensus, and highrisk features. 我们以 ARB 的进入和退出标准来结束本章。准入标准的重点是确保通过 ARB 发送正确的功能、组建正确的 ARB 团队以及为通过 ARB 继续进行该功能做好尽可能的准备。选择正确的功能并不总是那么容易；因此，我们建议对某个功能是否应通过 ARB 进行四项测试。这些问题包括不遵守架构原则、必须根据业务需求做出重大权衡、JAD 团队无法达成共识以及高风险功能。 Through the proper establishment of ARB, adherence to the criteria, and follow-ing the proper process steps, your organization can be ensured of better designs thatare purposefully made for improving your scalability. 通过正确建立 ARB、遵守标准并遵循正确的流程步骤，可以确保您的组织获得更好的设计，这些设计是专门为提高可扩展性而设计的。 #####Key Points 关键点 * A final review of the application’s architecture ensures buy-in and acknowledge-ment as well as prevents finger pointing. * 对应用程序架构的最终审查可确保获得认可和认可，并防止相互指责。 * The proper constituency of the ARB is critical for it to uphold the purpose of afinal architecture signoff as well as for the decisions to be respected. * ARB 的适当支持者对于维护最终架构签核的目的以及尊重决策至关重要。 * Members of the ARB should be seen as leaders, well respected, and have exper-tise in some area of the application or architecture. * ARB 的成员应被视为领导者，受到尊重，并且在应用程序或架构的某些领域拥有专业知识。 * ARB membership can be on a rotational basis but the position is always seen asincremental to current duties. * ARB 成员可以轮流担任，但该职位始终被视为对当前职责的补充。 * The ARB should be as informal as possible as long as it is taken seriously andthe decisions are understood to be final. * 只要 ARB 得到认真对待并且做出的决定被认为是最终决定，ARB 就应该尽可能非正式。 * All ARBs should start with a discussion of the purpose of the ARB—to ensuredesigns that support the business needs including scalability. * 所有 ARB 都应首先讨论 ARB 的目的，以确保设计支持业务需求（包括可扩展性）。 * Entry into an ARB should only be granted to features that are sufficiently prepared. * Decisions by the ARB should be considered final. Some organizations mayinclude an appeals process if it is deemed necessary. * 只有准备充分的功能才能进入 ARB。 * ARB 的决定应被视为最终决定。如果认为有必要，一些组织可能会包括上诉程序。
没有评论