一些上下文：
想象一下，一家拥有 200 多名开发人员的公司最终成立了一个或多或少独立的架构团队/部门。由 20 多个不同规模的“项目”/生产应用程序组成的软件组合由负责和负责项目“架构”的团队负责人/技术负责人负责。
出于整合和控制架构以及对整个系统进行某些必要的大规模返工的必要性，除了所有急需的知识交流之外，公司决定成立一个架构部门。
这种事业的“做”和“不做”是什么？
组成这样一个架构团队的人是谁？
他们的职责应该是什么？
什么超出了他们的范围？
对公司有用的过渡策略是什么？
每当有人提到“架构团队”时，如何防止那些歪歪扭扭的表情？
贵公司是否已经成功地进行了这样的变革？
为什么失败了？
为什么会成功？
那不应该是关于“什么是架构？”的讨论（这是非常密切相关的；）。
真正有趣的一点是可以接受/现实的，甚至是安装这样一个团队的无摩擦方式，当然除了一些关于战斗的警告，最好不要开始。
这里有几个需要思考的问题：
我的朋友，你的前路很艰难...
第一步是明确架构团队应该实现的目标。
你为什么要安排团队？
你想统一所有的应用程序，开发一个通用的框架，什么？
这个团队的任务和愿景是什么？
无论谁在这支球队中担任领导者的人际交往能力更好。可以吹口哨星球大战主题曲并发出光剑声的不
应该是才华横溢的程序员……但他可能应该以技术身份加入团队。
您可能应该让熟悉大多数项目的人员组成团队。我会谨慎选择所有当前的潜在客户，因为这可能需要当前团队的大量知识。让我们面对现实吧，当架构团队提出自己的可交付成果时，这些团队必须富有成效。
架构很难做到正确。
“架构师”需要完成工作的权力，但需要足够精明，不会滥用这种权力并完全疏远公司的其他人。
我曾在两个实施架构团队的地方工作过——一个很成功，另一个看起来不太好。在成功的地方，这是一个相对较小的环境，首席架构师被认为是技术领导者，而团队的其他成员则具有出色的写作和政治能力。每个人都为组织的最大利益行事。
在效果不太好的地方，架构师清楚地代表了组织中的特定派系，并没有赢得整个地方的信任或尊重。结果是花更多的时间来编造借口绕过架构，而不是从中收集任何价值。在这种情况下，沮丧变成了被动/攻击性和其他反社会行为。
我认为您提出的有关范围/职责/过渡的其他问题都由“取决于”来回答。这取决于公司、人员、资金和日程安排。
有趣的问题。
首先，你必须清楚这个“架构”团队正在解决什么问题。如果你不能清楚地定义团队的“使命”，它就会失败并以巨大的爆发力来完成。:)
话虽如此，第一步是定义您要解决的问题。你想跟上技术的步伐吗？您是否尝试在项目之间合并一些代码重用？您是否正在努力利用您的开发人员以达到最佳效果？实施架构团队有几个原因，并且根据您的设置，其中任何一个可能就足够了。从您的问题来看，您的目标似乎是重新设计现有的应用程序，这是一个很好的第一步。
由于您已经拥有一组对应用程序具有良好特定知识的潜在客户，因此从他们开始是一个好主意。将它们放在一起，并讨论出新的全球架构应该是什么样子。此时，您可能还想找一位顾问来帮助促进对话。定义返工的目标，并提出每个人都同意的“大图”。
在那之后，我会挑选一些潜在客户并将他们（从开发人员池中回填潜在客户）推广给架构团队。然后，他们将与领导会面，以确保事情按照“大局”进行。
我不会从外部引入一个全新的团队。这会产生一种不受欢迎的“我们与他们”的动态，这种动态永远不会很好。局外人也不知道事情应该如何工作，或者为什么事情不能按照逻辑暗示的方式工作。:)
在这种情况下，“架构”本身没有任何意义。它的意思是“横向主题的专家”。
只要你有一个“架构团队”，你就会有一个横向团队，为许多项目提供服务。
正如前面的答案所述，您需要知道“建筑系”这样的主题必须解决的问题。
现在，这是一个基于几个主题的架构团队组织示例：
您可能希望为服务器和网络的所有管理添加一个物流团队，负责备份和 DRP 策略的任务。以及基于良好案例系统的支持策略。
你很高兴。
现在，不要忘记，当您开始一些“大型返工”时，您的功能架构将承担以下任务：
在这种规模的商店中进行任何返工确实意味着能够在等待返工生产第一个版本的同时对遗留项目进行必要的演变。（遗产不能在 2-3 年的返工中等待并保持静止）
大型返工应涉及三个主要里程碑：
这意味着任何给定的组件实际上都经过了三次开发！;)
祝你好运，晚安。
一般来说，要非常小心与架构组相关的政治和其他方面的激励措施。“建筑审查委员会”（或任何你想叫它的名字）成为进步的障碍绝非易事。所需要的只是零激励来改进事物，而当事情发生变化并且没有立即改进时，则需要负激励。
意识到会犯错误，一些“伟大的新技术”将变成不成熟的时尚，并鼓励变革和创新。这可能会导致偶尔的短期动荡和失败的转型，但这总比停滞好。
而替代方案不可避免地会导致停滞；在较大的组织中，我看到职业生涯被毁掉，因为经理对他的团队有足够的信心来支持他们对新技术的建议一直到最高层，提供案例研究来证明这一点，并支持它。当新技术最终获得批准时（经过近一年的政治内讧），CTO（一直反对它）声称对这项创新功不可没，并将经理调到了一个偏远地区的部门。在另一个事件中，提出了一项新技术，在同一业务领域有许多成功的例子，并成立了一个委员会来研究这个问题。五年后他们还在研究这个问题，什么都没做
我认为架构团队需要有足够资深的人来了解所有开发团队的内部运作，并且能够对请求/指导方针说不。我曾与优秀的开发人员一起工作，但没有足够的权限，最终跟随来自不同团队的更高级别的开发人员经理，并产生了不一致的框架。
您需要完成业务场景 A) 和 B)
A) 如果您不进行设置，即什么都不做怎么办：
估计返工的持续维护成本
B）您确实设置了：
由于资源转移而中断近期可交付成果。
风险多个产品可能在短期内被淘汰。
感知到的额外人力成本。
如果产品因锻炼而变弱（表现或感觉不灵活），谁会举报
接下来让产品团队进行同样的练习，比较结果。
如果你证明它是合理的，这里有两条我见过的路线：
1. 选择一个主导产品来驱动架构并向这个项目添加资源。
然后准备添加更多资源，并耐心等待，否则主导产品会受到影响。
你用这条路线冒险，当主导产品占收入的 40% 时，它就起作用了。
2. 建立一个小团队，从内部发生的最有希望的讨论中汲取灵感，逐步将新架构包装在每个产品中。
将这个团队的工作融入产品工作中。
您需要考虑的一些问题：
1. 您需要多长时间才能实现架构融合才能获得业务利益。
2. 已经在讨论架构融合的团队成员是谁，他们是否在询问/建议其重要性，您需要将这个问题放在 80% 的团队负责人的“次要位置”。
不该做什么
* 从外部聘请专家（除非你现在真的一团糟）
* 几个月后放弃，这是长期的。
*一次更改所有项目。
* 开始，直到您拥有可以实现这一目标的三个核心。
* 让架构部门变得比它必须的更大
* 让人们认为架构部门将解决产品团队的问题
* 让任何产品看起来都在“等待新架构”
* 让架构部门“定义所有”或范围蔓延
* 强制所有产品进入架构，有些可能不适合（例如，不在同一个国家开发）
做什么：
* 从第一个问题得到充分的理由，让高级管理层接受并要求产品团队报告进度
* 逐步改变产品与架构图
的一致性 * 致力于最有希望或低风险的一致性首先是产品线
* 设置指标，以便您可以展示增值（请参阅第一组问题的理由）
* 为所有产品制定路线图以实现融合或不融合。
* 思考核心架构提供了什么以及谁维护其
产品 * 允许产品团队在核心规范、代码和维护方面为核心做出贡献
* 为新手和现有团队设置如何使用架构团队的工作的培训
仅建筑就有可能把人变成宇航员/僵尸。因此，即使这是基本的原型设计，他们肯定也应该进行一些编码。事实上，他们原型的成功必须是明确的审查因素。
他们应该按月发布报告/经常发布跟踪他们工作的博客，以便组织中的其他人可以学习。
应该有学术目标，例如熟悉某些平台/工具/书籍和设计理念。
如果他们愿意，应该给他们时间在现有项目中追求新工具/项目/职责。
他们将有责任对关键模块进行至少 3-4 次代码审查，并提出代码风格指南。
他们有责任至少审查关键模块的低级设计。
作为个人或团队，他们应该有空闲时间来构建他们认为可能有用的东西。
如果他们愿意，他们应该可以选择放弃建筑并返回正常工作，而不会涉及任何处罚。
他们应该有关于组织中运行的所有项目发生的事情的信息。至少应该密切关注一个项目，以便他们可以将其他地方发生的事情告知自己的同行。这可能是他们执行代码审查等的项目。
他们应该有一个技术含量高的人作为他们的经理。
一旦架构师非常熟悉其中一个项目，他们就应该在项目之间切换，并允许他们在处理原始项目时遵循他们所遵循的任何原型。
每 1 年至少有一个真正的目标（比如将项目中的所有共性整合到一个库中）
投入时间和培训，以确保建筑师不会受到自我约束并以相当专业的方式行事。肯定也需要解决冲突和其他软技能培训以及技术会议和培训的预算。