这篇文章上次修改于 191 天前，可能其部分内容已经发生变化，如有疑问可询问作者。 ###Chapter 13Joint Architecture Design 第13章联合架构设计 > Thus it is that in war the victorious strategist only seeks battle after the victory has been won,whereas he who is destined to defeat first fights and afterwards looks for victory.—Sun Tzu > 故兵之胜者，必胜而后求战；必败者，先战而后求胜。——《孙子》 So far in Part II, Building Processes for Scale, we have focused on many reactionaryprocesses such as managing issues, crisis management, and determining headroom. Inthis chapter and the next, we are going to introduce two processes that are proactive,not reactive. We are going to shift from reaction (what to do when something goeswrong) to discuss how to build the application in a scalable manner in the first place.These two processes are cross functional and are interwoven within the productdevelopment life cycle. They are the Joint Architecture Design (JAD) and the Archi-tecture Review Board (ARB). In this chapter, we are going to focus on JAD, whichcomes earlier in the product development life cycle than does ARB and sets the stagefor designing a system that scales. 到目前为止，在第二部分“构建规模流程”中，我们重点关注了许多反动流程，例如管理问题、危机管理和确定空间。在本章和下一章中，我们将介绍两个主动而非被动的流程。我们将首先从反应（出现问题时该怎么办）转向讨论如何以可扩展的方式构建应用程序。这两个过程是跨职能的，并且在产品开发生命周期中交织在一起。它们是联合架构设计（JAD）和架构审查委员会（ARB）。在本章中，我们将重点关注 JAD，它在产品开发生命周期中比 ARB 更早出现，并为设计可扩展的系统奠定了基础。 Using a very simple sport analogy of running, JAD would be equivalent to thetraining or preparation for the race. ARB, continuing the analogy, would be theactual race. JAD is a collaborative design process wherein all engineering assets nec-essary to develop some new major functionality work together to define a design con-sistent with the architectural principles of the organization. ARB Board is a reviewboard of select architects from each of the functional or business areas, whose job isto ensure that prior to final sign-off of a design, all company architectural principleshave been incorporated, and that best practices have been applied. 使用跑步这个非常简单的运动类比，JAD 相当于训练或比赛准备。继续这个类比，ARB 将是真正的种族。 JAD 是一个协作设计过程，其中开发一些新的主要功能所需的所有工程资产一起工作，以定义与组织的架构原则一致的设计。 ARB 委员会是来自每个功能或业务领域的精选架构师的审查委员会，其工作是确保在设计最终签署之前，所有公司架构原则均已纳入其中，并且已应用最佳实践。 ####Fixing Organizational Dysfunction 修复组织功能障碍 In the introduction, we mentioned that the JAD process was cross functional. In dys-functional organizations, the implementation of JAD is challenging but absolutelynecessary to help cure the dysfunction. If you are part of one of those organizationswhere engineers do not trust operations staff and vice versa, unfortunately you areamong the majority. It is sad but common to have distrust and even animositybetween teams. Before we can figure out how we can overcome this dysfunction andstart building scalable applications through the use of cross-functional teams, weneed to understand why this problem exists. 在简介中，我们提到 JAD 流程是跨职能的。在功能失调的组织中，实施 JAD 具有挑战性，但对于帮助治愈功能失调绝对是必要的。如果您属于工程师不信任操作人员的组织之一，反之亦然，那么不幸的是您属于大多数人之一。团队之间存在不信任甚至敌意是令人悲伤但常见的事情。在我们弄清楚如何克服这种功能障碍并开始通过跨职能团队构建可扩展的应用程序之前，我们需要了解为什么会出现这个问题。 In most software development shops, it is not too difficult to find an engineer whofeels that the architects and the operations staff, database administrators, systemsadministrators, and network engineers are either not knowledgeable about coding ordon’t fully understand the software development process. The reverse distrust is alsoprevalent where operations staff or architects feel that software engineers only knowhow to code and do not understand higher level design or total systems concepts.Even worse, each believes that the other’s job is in direct opposition to accomplishinghis own goals. Operations staff can often be heard mumbling that “they could keepthe servers up if the developers would stop putting code on them” and developersmumble back that “they could develop and debug much faster if they didn’t haveoperations making them follow silly policies.” This set of perceptions and misgivingsis destructive to the scalability of the application and organization. They also showhow the “experiential chasm,” which we discussed in Chapter 6, Making the Busi-ness Case, can exist among technology teams as easily as it can between the businessand technology teams. 在大多数软件开发商店中，不难找到一个工程师，他认为架构师和操作人员、数据库管理员、系统管理员和网络工程师要么不了解编码，要么不完全理解软件开发过程。当操作人员或架构师认为软件工程师只知道如何编码而不了解更高层次的设计或总体系统概念时，反向不信任也很普遍。更糟糕的是，每个人都认为对方的工作与实现自己的目标直接相反。经常可以听到运营人员咕哝道，“如果开发人员停止在服务器上添加代码，他们就可以让服务器保持运行”，而开发人员则咕哝道，“如果他们没有操作让他们遵循愚蠢的政策，他们可以更快地开发和调试。”这组看法和疑虑对应用程序和组织的可扩展性具有破坏性。它们还展示了我们在第 6 章“制定业务案例”中讨论的“经验鸿沟”如何存在于技术团队之间，就像存在于业务团队和技术团队之间一样。 As a brief refresher on the experiential chasm, we proposed that the differences ineducation and experience between the two groups of people cause a type of destruc-tive interference in communication. The formal education of a software developerand a systems administrator at an undergraduate level may be very similar—samecomputer science degree—or they may vary significantly—computer science versuscomputer engineering. The on-the-job education is where the really large differencesbegin to emerge. Systems administrators or database administrators typically getmentored by more senior administrators for several years until they become profi-cient with a specific technology, ever increasing their specialization in that field. Soft-ware engineers typically follow a similar path but are focused on a particularprogramming language. What server the application runs on or what database theapplication calls is for the most part abstracted away for the software engineers sothey can concentrate on feature development. 作为对经验鸿沟的简要回顾，我们提出，两组人之间教育和经验的差异导致了沟通中的一种破坏性干扰。软件开发人员和系统管理员在本科阶段的正规教育可能非常相似（相同的计算机科学学位），或者它们可能有很大差异（计算机科学与计算机工程）。在职教育是真正巨大差异开始出现的地方。系统管理员或数据库管理员通常会接受更高级管理员的指导数年，直到他们精通特定技术，从而不断提高他们在该领域的专业知识。软件工程师通常遵循类似的路径，但专注于特定的编程语言。应用程序在什么服务器上运行或应用程序调用什么数据库在很大程度上被软件工程师抽象出来，以便他们可以专注于功能开发。 With the experiential chasm as the starting point between the two groups, whenwe add differing and sometimes opposing goals, these groups start becoming so farapart they see no common ground. Most organizations do not share goals acrossteams. This is problematic if the intent is to get these teams working together insteadof fighting each other. The operations team usually is saddled with the goal of uptimeor availability for the site. Any downtime gets taken out of their bonuses. The devel-opment team is usually given the goal of feature delivery. A missed delivery dateresults in lower bonuses for them. At the CTO level, the CTO thinks that all of hisgoals are being handled by one of his teams and therefore everything is covered. Thereality is that separating goals like this actually causes strife among his teams. 以经验鸿沟作为两个群体之间的起点，当我们添加不同的、有时甚至是相反的目标时，这些群体开始变得如此遥远，以至于看不到共同点。大多数组织不会在团队之间共享目标。如果目的是让这些团队一起工作而不是互相争斗，那么这是有问题的。运营团队通常肩负着网站正常运行时间或可用性的目标。任何停机时间都会从他们的奖金中扣除。开发团队通常会被赋予功能交付的目标。错过交货日期会导致他们的奖金减少。在 CTO 层面，CTO 认为他的所有目标都由他的一个团队来处理，因此一切都被涵盖了。事实上，像这样分开的目标实际上会导致他的团队之间发生冲突。 The development goal of feature delivery pushes them to want to get code out fast,and if it breaks, they figure they can fix it on-the-fly. This is by far the fastest way toachieve initial delivery of code, which is usually all that is measured. In the long run,this approach actually takes more time because fixing problems takes a lot of time tofind, fix, and redeploy. As we mentioned earlier, this post-delivery time is usuallynever measured and therefore is missed as being part of the delivery goal. 功能交付的开发目标促使他们想要快速发布代码，如果代码出现问题，他们认为可以即时修复它。这是迄今为止实现代码初始交付的最快方法，这通常是衡量的全部内容。从长远来看，这种方法实际上需要更多时间，因为解决问题需要花费大量时间来查找、修复和重新部署。正如我们之前提到的，交付后时间通常不会被测量，因此作为交付目标的一部分而被错过。 The operations team wants to keep the site up and increase the availability as perits goal. It is therefore motivated to keep changes out of production because changesare the primary cause of issues. It decides that the fewer code pushes or changes madeto the production environment the more likely the team is able to meet its goal.Whether consciously or not, the team is suddenly not so motivated to get codepushed out and in fact will start to find any reason for delays. 运营团队希望保持站点正常运行并按照目标提高可用性。因此，我们有动机将变更排除在生产之外，因为变更是问题的主要原因。它决定了代码推送或对生产环境进行的更改越少，团队就越有可能实现其目标。无论是否有意，团队突然没有动力推送代码，事实上会开始寻找任何原因延误。 As you can hopefully see by now, you have two or more groups that have incredi-bly valuable knowledge about how systems and architectures work in general andspecific knowledge about how your system operates, but they are naturally weary ofeach other and are likely being incented to not work together. How can you fix this?The JAD process is a great place to start. As we’ll discuss in the next section of thischapter, JAD is a collaborative process that pulls cross-functional team memberstogether with a common goal. The JAD team either succeeds or fails together and thisreflects on its organizations and its leadership team. 正如您现在所希望看到的，您有两个或更多的小组，他们拥有关于系统和架构如何工作的一般性知识以及关于系统如何运行的特定知识，但他们自然会厌倦彼此，并且很可能会被激励不一起工作。如何解决这个问题？JAD 流程是一个很好的起点。正如我们将在本章下一节中讨论的，JAD 是一个协作过程，它将跨职能团队成员聚集在一起以实现共同目标。 JAD 团队要么一起成功，要么一起失败，这反映在其组织和领导团队上。 The basic process of JAD is to assign a major feature to not only a software engi-neer but also to an architect, at least one operations engineer (database administrator,systems administrator, or network engineer), and optionally a product manager,project manager, and quality assurance engineer as needed for this specific feature.The responsibility of this team is to come up with a design that follows the estab-lished architecture principles of the organization that will allow the system to con-tinue to scale, that allows the feature to meet the product requirements, and that willbe able to pass the ARB. This team is comprised of the people who will ultimatelypresent the design to the ARB, which we will discuss in the next chapter is made upof peers and managers who get to decide if this design satisfies the exit criteria. Fortu-nately, this collusion does not just stop at the design; because these individuals haveput their credentials on the line with this feature, they are now motivated to watch itthrough the entire life cycle to ensure it is a success. Engineers are now being heldresponsible for the design and how it performs in production. The database adminis-trators are being held accountable for designing this feature to not only scale but toalso meet the business requirements. Now we have the developers, architects, andoperations staff working together, jointly, with a shared goal. JAD的基本流程是将一个主要功能不仅分配给软件工程师，还分配给架构师、至少一名运维工程师（数据库管理员、系统管理员或网络工程师），以及可选的产品经理、项目经理以及此特定功能所需的质量保证工程师。该团队的职责是提出遵循组织既定架构原则的设计，该设计将允许系统继续扩展，允许功能满足产品要求，并且能够通过ARB。该团队由最终向 ARB 提交设计的人员组成，我们将在下一章中讨论该团队由同行和经理组成，他们可以决定该设计是否满足退出标准。幸运的是，这种共谋不仅仅停留在设计上；还体现在设计上。因为这些人已经将自己的资历与此功能放在一起，所以他们现在有动力在整个生命周期中对其进行观察，以确保其成功。工程师现在负责设计及其在生产中的表现。数据库管理员有责任设计此功能，不仅要扩展规模，还要满足业务需求。现在，我们的开发人员、架构师和运营人员为了一个共同的目标而共同努力。 ####Designing for Scale Cross Functionally ####跨功能规模设计 We discussed briefly the structure and mechanism of JAD. Now, we can get into moredetail. JAD is a collaborative design process wherein all engineering assets necessaryto develop some new major functionality or architectural modification work togetherto define a design consistent with the architectural principles and best practices of thecompany to implement the business unit requirements. This group of engineeringassets is comprised of the software engineer responsible for ultimately coding the fea-ture, an architect, at least one but possibly multiple operations staff, and, as neededbased on the feature, the product manager, a project manager, and a quality assur-ance engineer. As mentioned earlier, each brings unique knowledge, perspectives,experiences, and goals that augment each other as well as counter-balance each other.Although the operations engineer now has the goal of designing a feature that meetsthe business requirements, she also still has the goal from her organization of main-taining availability. This helps ensure that she is vigilant as ever about what goes intoproduction. 我们简要讨论了JAD的结构和机制。现在，我们可以了解更多细节。 JAD 是一个协作设计过程，其中开发一些新的主要功能或架构修改所需的所有工程资产一起工作，定义符合架构原则和公司最佳实践的设计，以实现业务部门的需求。这组工程资产由负责最终对功能进行编码的软件工程师、架构师、至少一名（但可能是多名）操作人员以及根据功能需要的产品经理、项目经理和质量人员组成。保证工程师。如前所述，每个人都带来了独特的知识、观点、经验和目标，这些知识、观点、经验和目标相互补充、相互平衡。尽管运营工程师现在的目标是设计满足业务需求的功能，但她仍然有她的组织的目标是保持可用性。这有助于确保她对投入生产的内容一如既往地保持警惕。 Involving each of the technology groups, tradeoffs between hardware, software,middleware, and build versus buy approaches can help shave time to market, cost ofdevelopment and cost of operations, and increase overall quality. The software engi-neer has typically been abstracted from the hardware by the services of the opera-tions team. So trying to have the software engineer design a feature for imagestorage—see the “Image Storage Feature” sidebar for the complete example—with-out knowledge of the storage device that can and should be used is asking to fail inmeeting the requirements, fail in the cost-effectiveness, or fail in the scalability of thesystem. Shared goal of scalability ensures the culture is pervasive; when there areissues or crises, all hands are on deck because of shared ownership. 让每个技术团队都参与进来，在硬件、软件、中间件以及构建与购买方法之间进行权衡，有助于缩短上市时间、开发成本和运营成本，并提高整体质量。软件工程师通常通过运营团队的服务从硬件中抽象出来。因此，尝试让软件工程师设计图像存储功能（请参阅“图像存储功能”侧边栏以获取完整示例），如果不了解可以且应该使用的存储设备，就会无法满足要求，无法满足要求。成本效益，或系统的可扩展性失败。可扩展性的共同目标确保了文化的普及；当出现问题或危机时，由于共同所有权，所有人都会齐心协力。 This JAD approach is not limited to waterfall development methodologies whereone phase of product development must take place before the other. JAD can and hasbeen successfully used in conjunction with all types of development methodologiessuch as iterative or agile, in which specifications, designs, and development evolve asgreater insights are gained about the product feature. Each time a design is beingmodified or appended to, a JAD can be called to help with it. The type of architecturedoes not preclude the use of JAD either. Whether it is a traditional three-tier Webarchitecture, Service Oriented Architecture, or simply a monolithic application, thecollaboration of engineering, operations, and architects to arrive at a better design issimply taking advantage of the fact that solutions arrived at by teams are better thanindividuals. The more diverse the background of the team members, the more holisticthe solution is likely to be. 这种 JAD 方法并不限于瀑布式开发方法，在瀑布式开发方法中，产品开发的一个阶段必须在另一个阶段之前进行。 JAD 可以并且已经成功地与所有类型的开发方法（例如迭代或敏捷）结合使用，其中规范、设计和开发随着对产品功能的深入了解而不断发展。每次修改或附加设计时，都可以调用 JAD 来帮助完成。架构类型也不排除 JAD 的使用。无论是传统的三层 Web 架构、面向服务的架构，还是简单的整体应用程序，工程、运营和架构师的协作来实现更好的设计，只是利用了团队得出的解决方案比个人更好的事实。团队成员的背景越多样化，解决方案可能就越全面。 The actual structure of the JAD is very informal. After the team has been assignedto the feature, one person takes the lead on coordinating the design sessions; this istypically the software engineer or the project manager, if assigned. There are usuallymultiple design sessions that can last between one and several hours depending onpeople’s schedules. For very complex features, multiple design sessions for variouscomponents of the feature should be scheduled. For example, a session focused onthe database should be set up, and then another one on the cache servers should beset up separately. JAD 的实际结构非常非正式。团队被分配到该功能后，由一个人牵头协调设计会议；这是，通常是软件工程师或项目经理（如果指定的话）。通常有多个设计会议，根据人们的日程安排，可持续一到几个小时。对于非常复杂的功能，应该为该功能的各个组件安排多个设计会话。例如，应该建立一个针对数据库的会话，然后在缓存服务器上单独建立另一个会话。 Typically, the sessions start with a discussion covering the background of the fea-ture and the business requirements. During this phase, it is a good idea to have theproduct manager present and then on call for any clarifications as questions come up.After the product requirements have been discussed, a review of the architecturalprinciples that relate to this area of the design is usually a good idea. Following this,the teams brainstorm about various solutions and typically arrive at a few differentpossible solutions. These are written up at the end of the meeting and sent around forpeople to ponder over until the next session. Usually only a session or two arerequired to come to an agreement on the best approach for the design of the feature.The final design is written down and documented for presentation at that ARB. 通常，会议首先讨论功能背景和业务需求。在此阶段，最好让产品经理在场，然后在出现问题时随时进行澄清。讨论产品需求后，通常会审查与该设计领域相关的架构原则。好主意。此后，团队集思广益，讨论各种解决方案，通常会得出一些不同的可能解决方案。这些内容会在会议结束时写下来，并发送出去供人们思考，直到下一次会议为止。通常只需要一两次会议就功能设计的最佳方法达成一致。最终的设计被写下来并记录在案，以便在 ARB 上演示。 #####Image Storage Feature 图像存储功能 At our fictional company AllScale, a feature for the human resource management (HRM) appli-cation has been requested that will allow for the storage of pictures of personnel to be dis-played in their personnel folders that the HR and hiring managers bring up to conduct reviews,salary adjustments, and so on. The software engineer, Sam Codur, who has been assigned to thisfeature, has very little idea of the hardware or storage devices that are used in production. He hasoverheard the operations folks talk about a SAN or NAS but he is really clueless about the dif-ferences. Furthermore, he has never even heard of different classes of storage and has nevergiven a single minute of thought to backup and recovery of storage in the event of data corrup-tion, hardware failure, or natural disasters.Figure 13. 1 depicts Sam trying to decide on all thenuances of hardware, software, and network devices alone without any other experts to aid him 在我们虚构的公司 AllScale，需要人力资源管理 (HRM) 应用程序的一项功能，该功能允许将人员照片存储在人力资源和招聘经理调出的人事文件夹中显示。进行考核、薪资调整等。负责此功能的软件工程师 Sam Codur 对生产中使用的硬件或存储设备知之甚少。他无意中听到运营人员谈论 SAN 或 NAS，但他对其中的差异一无所知。此外，他甚至从未听说过不同类别的存储，也从未考虑过在发生数据损坏、硬件故障或自然灾害时备份和恢复存储。图 13. 1 描述了 Sam 试图在没有任何其他专家帮助的情况下独自决定硬件、软件和网络设备的所有细微差别  The product manager has specified for this feature that any standard image format beacceptable, that all past profile images be available, and that the size be less than 500KB perimage. To Sam, the software engineer, this seems reasonable and instead of soliciting guid-ance from the operations staff, he decides that he can code the feature and let ops worry abouthow and where the images actually get stored. The result, after ten days of coding and anotherfive days of quality assurance testing, is the feature gets noticed in the notes for the upcomingrelease by Tom Harde, VP of operations. Tom sends a set of questions to Mike Softe, VP ofengineering, asking how this feature was designed, the response time requirements, and thestorage estimates per year. After this email gets passed back and forth several times, it eventu-ally gets escalated to Johnny Fixer, the CTO, with both sides demanding that the other is beingunreasonable. Johnny now has to get involved and make some hard decisions to either delaythe release in order that the feature be redeveloped to meet the operation team’s standards(images less than 100KB, no multiple images, timeouts coded for response times greater than200msec, no guarantee of image storage, etc.) or push the feature out as developed and worryabout it causing issues across the site. 产品经理已为此功能指定任何标准图像格式都可接受，所有过去的个人资料图像均可用，并且每个图像的大小小于 500KB。对于软件工程师 Sam 来说，这似乎很合理，他决定自己编写该功能，让操作人员担心图像实际存储的方式和位置，而不是征求操作人员的指导。经过十天的编码和另外五天的质量保证测试后，运营副总裁 Tom Harde 在即将发布的版本的注释中注意到了该功能。 Tom 向工程副总裁 Mike Softe 发送了一系列问题，询问此功能是如何设计的、响应时间要求以及每年的存储估算。这封电子邮件来回传递了几次后，最终升级到了 CTO Johnny Fixer，双方都指责对方无理取闹。 Johnny 现在必须介入并做出一些艰难的决定，要么推迟发布，要么重新开发该功能以满足运营团队的标准（图像小于 100KB，没有多个图像，响应时间编码的超时大于 200 毫秒，不保证图像存储等）或将已开发的功能推出并担心它会导致整个站点出现问题。 Johnny decides to pull the feature from the release, which requires some retesting to beperformed and the delay of a day for the release date. Instead of just fixing this single feature,Johnny decides that he needs to fix the process to make sure there are not more features likethis one in the future. Johnny gathers Mike and Tom to introduce the Joint Architecture Designprocess. He explains that when an engineer is developing a feature and it is either part of thecore modules/services of the HRM system or it is estimated to take more than five days ofdevelopment, then a JAD must take place. The participants will be the engineer developing thefeature, a systems architect, and an operations staff member assigned by Tom or his manag-ers. Johnny continues to explain that this team of individuals own the design and will be heldaccountable for the success or failure of the feature in terms of its performance, availability, andscalability. Tom and Mike see this process as a way to achieve a win-win situation and departquickly to explain it to their teams. Johnny 决定从版本中删除该功能，这需要进行一些重新测试，并将发布日期推迟一天。约翰尼决定不只是修复这一单一功能，而是需要修复流程，以确保将来不会出现更多类似的功能。约翰尼召集迈克和汤姆介绍联合架构设计流程。他解释说，当工程师正在开发一项功能，并且该功能是 HRM 系统核心模块/服务的一部分，或者估计需要超过五天的开发时间时，则必须进行 JAD。参与者将是开发该功能的工程师、系统架构师以及 Tom 或其经理指定的运营人员。约翰尼继续解释说，这个由个人组成的团队拥有设计，并将对该功能的性能、可用性和可扩展性方面的成功或失败负责。汤姆和迈克认为这个过程是实现双赢的一种方式，并迅速离开并向他们的团队解释这一点。 #####JAD Checklist JAD检查清单 Here is a quick checklist for how to conduct the JAD sessions to ensure you do not skip any ofthe most important steps. As you feel more comfortable with this process, feel free to modifythis and create your own JAD checklist for your organization to follow: 以下是有关如何进行 JAD 会话的快速清单，以确保您不会跳过任何最重要的步骤。当您对此流程感到更加满意时，请随意修改此流程并创建您自己的 JAD 检查表以供您的组织遵循 1.Assign participants. 1、分配参与者。 2.Mandatory. Software engineer, architect, operations engineer (database administrator, systems administrator, and/or network engineer). 2、强制。软件工程师、架构师、运营工程师（数据库管理员、系统管理员和/或网络工程师）。 3.Optional. Product manager, project manager, quality assurance engineer. 3、可选。产品经理、项目经理、质量保证工程师。 4.Schedule one or more sessions. Divide sessions by component if possible: database, server, cache, storage, etc. 4、安排一场或多场会议。如果可能的话，按组件划分会话：数据库、服务器、缓存、存储等。 5.Start the session by covering the specifications. 5、通过介绍规范来开始会议。 6.Review the architectural principles related to this session’s component. 6、回顾与本次会议组件相关的架构原则。 7.Brainstorm approaches. No need for complete detail. 7、头脑风暴法。不需要完整的细节。 8.List pros and cons of each approach. 8、列出每种方法的优缺点。 9.If multiple sessions are needed, have someone write down all the ideas and send around to the group. 9、如果需要多次会议，请有人写下所有想法并发送给小组。 10.Arrive at consensus for the design. Use voting, rating, ranking, or any other decision technique that everyone can support. 10、就设计达成共识。使用投票、评级、排名或任何其他每个人都可以支持的决策技术。 11.Create the final documentation of the design in preparation for the ARB. 11、创建设计的最终文档，为 ARB 做准备。 Don’t be afraid to modify this checklist as necessary for your organization. 不要害怕根据您的组织的需要修改此清单。 ####Entry and Exit Criteria 进入和退出标准 With the JAD process, we recommend that specific criteria must be met before a fea-ture can begin the JAD process. Likewise, certain criteria must be met in order forthat feature to move out of JAD. By holding fast to these entrance and exit criteria,you will preserve the integrity of the JAD process and not weaken it. Some examplesof how allowing these criteria to be bypassed are introducing features that aren’tlarge enough to require a team effort to design or allowing a feature without an oper-ations engineer on the team to start JAD because the operations team is swampedhandling a crisis. Giving in to these one off requests will ultimately devalue the JADand participants will believe that they can stop attending meetings or that they arenot being held accountable for the outcome. Do not even start down this slipperyslope; make the entrance and exit criteria rigorous and unwavering, no exceptions. 对于 JAD 流程，我们建议在功能开始 JAD 流程之前必须满足特定标准。同样，必须满足某些标准才能将该功能移出 JAD。通过严格遵守这些进入和退出标准，您将保持 JAD 流程的完整性而不是削弱它。允许绕过这些标准的一些例子包括引入不够大、不需要团队努力设计的功能，或者允许在团队中没有运营工程师的情况下启动 JAD 的功能，因为运营团队忙于处理危机。屈服于这些一次性请求最终将使 JAD 贬值，参与者会相信他们可以停止参加会议，或者他们不会对结果负责。甚至不要从这个滑坡开始；严格准入和退出标准，毫不动摇，无一例外。 The entrance criteria for JAD are the following: JAD 的入学标准如下 * Feature Significance. The feature must be significant enough to require the focusof a cross-functional team. The exact nature of significance can be debated. Wesuggest measuring this in three ways: * 特征意义。该功能必须足够重要，需要跨职能团队的关注。重要性的确切性质是可以争论的。我们建议通过三种方式来衡量这一点 1.The first is size. For size, we use the amount of effort to develop as the mea-surement. Features requiring more than 10 days of total effort are consideredsignificant. To calculate this for features that have multiple engineers assignedto them, sum all engineering days estimated for the feature. 1.首先是尺寸。对于规模，我们使用开发的努力量作为衡量标准。需要超过 10 天的总工作时间的功能被认为是重要的。要为分配了多名工程师的功能计算此值，请汇总该功能的所有估计工程天数。 2.The second is potential impact on the overall application or system. If thefeature touches many of the core components of the system, this should beconsidered significant enough to design cross functionally. 2.第二个是对整个应用程序或系统的潜在影响。如果该功能涉及系统的许多核心组件，则应将其视为足够重要以进行跨功能设计。 3.The third is complexity of the feature. If the feature requires components thatare not typically involved in features such as caching or storage, it should gothrough JAD. A feature that runs on the same type of application server asthe rest of the site and retrieves data from the database is not complexenough to meet this requirement. 3.第三是功能的复杂性。如果该功能需要通常不涉及缓存或存储等功能的组件，则应通过 JAD。在与站点其余部分相同类型的应用程序服务器上运行并从数据库检索数据的功能不够复杂，无法满足此要求。 * Established Team. The feature must have representatives assigned and presentfrom engineering, architecture, and operations (database and system admin,possibly network). If needed, members from quality assurance, project manage-ment, and product management should be assigned. If these required teammembers are not assigned and made available to attend the meetings, the featureshould not be allowed to participate in JAD. * 成立团队。该功能必须有来自工程、架构和运营（数据库和系统管理员，可能是网络）的分配和代表。如果需要，应指派来自质量保证、项目管理和产品管理的成员。如果未分配这些所需的团队成员并让他们可以参加会议，则不应允许这些功能参与 JAD。 * Product Requirements. The feature must have product requirements and a busi-ness case in order to participate. The reason is that tradeoffs are likely to bemade based on different architectural solutions, and the team will need to knowthe critical requirements from the nice-to-have ones. Also understanding the rev-enue generated by this feature will help when deciding how much investmentshould be considered for different solutions. * 产品要求。该功能必须具有产品要求和业务案例才能参与。原因是，可能会根据不同的架构解决方案进行权衡，并且团队需要了解关键需求和可有可无的需求。此外，了解此功能产生的收入将有助于决定不同解决方案应考虑多少投资。 * Empowered. The JAD team must be empowered to make decisions that will notbe second-guessed by other engineers or architects. The only team that canapprove or deny the JAD design is the ARB, who gets final review of the archi-tecture. In RASCI terminology, the JAD team is the R (Responsible) for thedesign and the ARB is the A (Accountable). * 赋权。 JAD 团队必须有权做出不会被其他工程师或建筑师事后猜测的决策。唯一可以批准或拒绝 JAD 设计的团队是 ARB，他们对架构进行最终审查。在 RASCI 术语中，JAD 团队是设计的 R（负责），ARB 是 A（负责）。 The exit criteria for a feature coming out of JAD are the following: JAD 功能的退出标准如下 * Architectural Principles. The final design of the feature must follow all architec-tural principles that have been established in the organization. If there areexceptions to this rule, they should be documented and expected to be ques-tioned in ARB, resulting in a possible rejection of the design. We will talk moreabout the ARB process in the next chapter. * 架构原则。该功能的最终设计必须遵循组织中已建立的所有架构原则。如果此规则存在例外情况，则应将其记录在案并预计会在 ARB 中受到质疑，从而可能导致设计被拒绝。我们将在下一章详细讨论 ARB 流程。 * Consensus. The entire team should be in agreement and support the finaldesign. Time for dissention is during the team meetings and not afterward. Ifsomeone from the JAD team begins second-guessing team decisions, this shouldbe grounds for requiring the JAD to be conducted again and any developmenton the feature should be stopped immediately. * 共识。整个团队应该达成一致并支持最终设计。提出异议的时间是在团队会议期间，而不是之后。如果 JAD 团队中的某人开始事后批评团队决策，这应该成为要求再次进行 JAD 的理由，并且应立即停止该功能的任何开发。 * Tradeoffs Documented. If there were any significant tradeoffs made in thedesign with respect to the requirements, cost, or principles, these should bespelled out and documented for the ARB to review and for any other team mem-ber to reference when reviewing the design of the feature. * 记录权衡。如果设计中在要求、成本或原则方面做出了任何重大权衡，则应将这些内容详细说明并记录下来，供 ARB 审查，并供任何其他团队成员在审查功能设计时参考。 * Final Design Documented. The final design must be documented and posted forreference. The design may or may not be reviewed by ARB, but the design mustbe made available for all teams to review and reference in the future. Thesedesigns will soon become system documentation as well as design patterns thatengineers, architects, and operations folks can reference when they are partici-pating in future JADs. * 最终设计已记录。最终设计必须记录并发布以供参考。该设计可能会或可能不会经过 ARB 审核，但该设计必须可供所有团队将来审核和参考。这些设计很快将成为系统文档以及设计模式，供工程师、架构师和操作人员在参与未来的 JAD 时参考。 * ARB. The final step in the JAD process is to decide whether the feature needs togo to ARB for final review and approval. We will talk in more detail in the nextchapter about what features should be considered for ARB but here are ourbasic recommendations. If this feature meets any of the following, it should pro-ceed through ARB: * ARB。 JAD 流程的最后一步是决定该功能是否需要提交给 ARB 进行最终审查和批准。我们将在下一章中更详细地讨论 ARB 应考虑哪些功能，但以下是我们的基本建议。如果此功能满足以下任一条件，则应通过 ARB 继续进行 1.Noncompliance with architectural principles. If any of the architectural prin-ciples were violated, this feature should go through ARB. 1.不符合架构原则。如果违反任何架构原则，则该功能应通过 ARB。 2.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. 2.设计无法达成共识的项目。如果团队未能达成共识，可以将其重新分配给新的 JAD 团队，也可以将其发送给 ARB 对竞争设计做出最终决定。 3.Significant tradeoffs made. If tradeoffs had to be made in terms of productrequirements, cost, or other nonarchitectural principles, this should flag afeature to proceed to ARB. 3.做出重大权衡。如果必须在产品要求、成本或其他非架构原则方面进行权衡，则应标记一个功能以继续进行 ARB。 4.High risk features. We will discuss how to assess risk in much more detail inChapter 16, Determining Risk, but if the feature is considered a high risk fea-ture, it should go through ARB. A quick way of determining if this is highrisk is to look at how many core components the feature touches or how dif-ferent it is from other features. The more core components that are touchedor the greater the difference from other features, the higher the risk. 4.高风险特征。我们将在第 16 章“确定风险”中更详细地讨论如何评估风险，但如果该功能被认为是高风险功能，则应通过 ARB。确定这是否是高风险的一个快速方法是查看该功能涉及多少个核心组件，或者它与其他功能有多么不同。触及的核心组件越多或者与其他功能差异越大，风险就越高。 ####Conclusion 结论 In this chapter, we covered the Joint Architecture Design (JAD) process. We startedby understanding the dysfunction in technology organizations that causes features tobe designed in silos. We revisited the experiential chasm as it played a role in this dys-function. We also saw how differing goals among different technology teams can addto this problem. The fix is forcing the teams to work together for a shared goal. Thisoccurs with the JAD process. 在本章中，我们介绍了联合架构设计（JAD）过程。我们首先了解技术组织中导致功能设计孤岛的功能障碍。我们重新审视了体验鸿沟，因为它在这种功能障碍中发挥了作用。我们还看到了不同技术团队之间的不同目标如何加剧这个问题。解决办法是迫使团队为了共同的目标而共同努力。 JAD 过程中会发生这种情况。 We then covered in detail the JAD process, including who were mandatory partic-ipants in the process and who were some of the optional team members. Wedescribed how the design meetings should be structured based on components andhow important it was to start by making sure every team member was familiar withthe business requirements of the feature as well as the applicable architecture princi-ples of the organization. 然后我们详细介绍了 JAD 流程，包括谁是该流程的强制参与者以及谁是一些可选的团队成员。我们描述了设计会议应该如何基于组件进行组织，以及首先确保每个团队成员熟悉该功能的业务需求以及组织的适用架构原则是多么重要。 We shared with you a JAD checklist that will be useful to get you and your organi-zation started quickly with the JAD process. Our recommendation for using this wasto start with our standard steps but fill it out as necessary to make it part of yourorganization. And then of course document the process so it becomes fixed in yourorganization’s culture and processes. 我们与您分享了一份 JAD 检查表，它将有助于您和您的组织快速开始 JAD 流程。我们建议使用它是从我们的标准步骤开始，但根据需要填写它以使其成为您组织的一部分。当然，然后记录该流程，使其固定在组织的文化和流程中。 We closed the chapter with the entry and exit criteria of JAD. The entry criteriaare focused on the preparation to ensure the JAD will be successful and to ensure thatthe integrity of the process remains. Letting features slip into a JAD without all therequired team members is a sure way to cause the process to lose focus and not be aseffective as it should be. The exit criteria are focused on ensuring that the featuredesign has been agreed upon by all members of the team and that if necessary it isprepared to be presented in the Architecture Review Board (ARB), which we will dis-cuss in the next chapter. 我们以 JAD 的进入和退出标准结束了这一章。准入标准侧重于确保 JAD 成功并确保流程完整性的准备工作。在没有所有必需的团队成员的情况下让功能溜进 JAD 肯定会导致流程失去焦点并且无法达到应有的效果。退出标准的重点是确保功能设计已得到团队所有成员的同意，并且如果有必要，准备将其提交给架构审查委员会（ARB），我们将在下一章中讨论这一点。 #####Key Points 关键点 * Designing applications in a vacuum leads to problems; the best designs are doneinvolving multiple groups offering different perspectives. * 在真空中设计应用程序会导致问题；最好的设计是由多个提供不同观点的团体参与完成的。 * The JAD is the best way to involve a cross-functional team that may not beincented to work together. * JAD 是吸引可能不愿意一起工作的跨职能团队的最佳方式。 * The JAD team must include members from engineering, architecture, and opera-tions (database administrators, systems administrators, or network engineers). * JAD 团队必须包括来自工程、架构和运营的成员（数据库管理员、系统管理员或网络工程师）。 * The optional members of the JAD team include project management, productmanagement, and quality assurance. These people should be added to the teamas required by the feature. * JAD 团队的可选成员包括项目管理、产品管理和质量保证。应根据功能要求将这些人员添加到团队中。 * JAD is most successful when the integrity of the process is respected and entryand exit criteria are rigorously upheld. * 当流程的完整性得到尊重并严格遵守进入和退出标准时，JAD 才会最成功。
没有评论