一些前期背景：

设想一个200多个开发人员的公司最终建立了一个或多或少独立的体系结构团队/部门。由20多个不同规模的"项目/应用程序"组成的软件组合由负责和负责项目"架构"的团队领导/技术领导负责。

由于需要巩固和控制体系结构，并能够对整个系统进行某些必要的大规模修改，除了所有必要的知识交流外，公司决定设立一个体系结构部门。

• 这样的事业有哪些应做和不应做的？

• 组成这样一个架构团队的人是谁？

• 他们的职责是什么？

• 什么超出了他们的范围？

• 公司有哪些有用的过渡策略？

• 每次有人提到"体系结构团队"时，如何防止这些讽刺的表情？

• 贵公司是否已经成功地经历了这种变化？
  为什么失败？
  为什么成功？

这不应该是关于"什么是Architecutre"的讨论。(关系非常密切；)。

真正有趣的一点是可以接受的/现实的，甚至是安装这样一个团队的无摩擦方式，当然还有一些关于战斗的警告，最好不要开始。

以下是一些需要考虑的问题：

• 架构(architecture)团队的确切任务是什么？
• 架构(architecture)团队的可交付成果是什么？框架、指导方针、实施帮助…或者他们只是建筑宇航员？
• 这只适用于未来的应用程序，还是将是一个反向端口？
• 谁负责备份？(我们的意思是预算…)
• 是否会有资源分配给测试后端端口？
• 架构团队是否真的有实力，或者当第一组抱怨大约4个月后，管理层是否会屈服…
• 您将如何处理各个项目组和架构团队之间的摩擦(会有摩擦？)机会主义者会把这当作一个很好的机会来抢占职位…
• 请注意，这主要是一场政治游戏…

我的朋友，你前面的路很艰难…

第一步是清楚地了解架构团队应该实现什么。你为什么要让团队就位？您是否试图统一所有应用程序，开发一个通用框架，什么？这个团队的任务和愿景是什么？

无论谁是这个团队的领队，谁都能踢出**的人际交往技巧。它不应该是聪明的编码器，可以吹出星球大战主题曲，发出光剑的声音…但他可能应该以技术能力加入团队。

您可能应该向团队中填充熟悉大多数项目的人员。我会谨慎地选择所有当前的潜在客户，因为这可能需要当前团队的大量知识。让我们面对现实，当体系结构团队提出自己的可交付成果时，这些团队必须富有成效。

建筑是很难纠正的。

"架构师"需要权力来完成事情，但需要足够的机智，不要滥用权力，完全疏远公司的其他人。

我在两个实现架构团队的地方工作过——一个是成功的，另一个看起来不太好。在成功的地方，这是一个相对较小的环境，首席架构师被公认为技术领导者，团队的其他成员具有出色的写作和政治技能。每个人的行动都是为了组织的最大利益。

在效果不太好的地方，建筑师明确地代表了组织中的特定派别，并没有赢得整个地方的信任或尊重。其结果是，花更多的时间来编造绕过架构的借口，而不是从中收集任何价值。在这种情况下，挫折变成了被动/攻击性和其他反社会行为。

我认为你对范围/责任/过渡所提出的其他问题都是"视情况而定"的。这取决于公司、人员、资金和时间表。

在这种情况下，"建筑"本身毫无意义。意思是"横向专题专家"。

每当你有一个"体系结构团队"，你就会有一个横向的团队，为许多项目提供服务。

正如前面的答案所述，您需要知道这样一个"体系结构部门"需要处理哪些主题。

下面是一个基于以下几个主题的架构(architecture)团队组织示例：

• 业务和功能架构团队：编写许多与业务相关的规范，并检查现有应用程序和功能工作流之间的一致性，以完成应用程序的一致性绘图。
• 应用架构(architecture)团队：提供制图，同时决定业务和功能架构(architecture)团队决定的功能规范如何组织成应用程序。例如，您需要一个用于"组合过程"的功能模块，但是应用程序体系结构团队可以决定将其划分为"启动程序"、"调度程序"、GUI等。
• 技术架构(architecture)团队，始终由以下人员组成：
  • 执行架构团队，针对所有非业务纯技术主题(日志、关键绩效指标、框架等)
  • 开发架构团队(工具评估和支持、技术调查、版本和配置控制的存储库管理)
  • OA(操作体系结构)，用于使环境"可执行"(即，了解正确的流程、正确的服务器和正确的网络，以便部署系统以供批准或用于生产。)

您可能需要添加一个后勤团队，负责服务器和网络的所有管理，并执行备份和DRP策略任务。以及基于良好案例系统的支持策略。

你很高兴去。

现在，不要忘记，当您开始一些"大的重做"时，您的功能架构将有任务来加强以下两者之间的一致性：

• 改造后的项目要确保它们保持在固定的功能范围内。
• 与应用于返工项目的项目相比，确保其维护不涉及相反的选择的遗留项目。

这种规模的车间中的任何返工都意味着，在等待返工生成第一个版本时，确实能够对遗留项目进行必要的改进。(在2-3年的返工过程中，遗留的问题不仅是等待和保持不变)

大型返工应涉及三个主要里程碑：

• 1/与传统对话
• 2/完成遗产
• 3/取代传统

这意味着任何给定的组件实际上已经开发了三次！；

祝你好运，晚安。

有趣的问题。

首先，您必须清楚地知道这个"体系结构"团队正在解决什么问题。如果你不能清楚地定义团队的"任务"，它就会失败，并伴随着巨大的爆炸。：)

也就是说，第一步就是定义你要解决的问题。你想跟上技术的步伐吗？您是否试图在项目之间合并一些代码重用？你是否在尽可能地利用你的开发人员？实现体系结构团队有几个原因，考虑到您的设置，其中任何一个都可能是足够的。从你的问题来看，你的目标是重新设计现有的应用程序，这是一个很好的第一步。

既然你已经有了一组对应用程序有很好特定知识的潜在客户，那么最好从他们开始。把它们放在一起，讨论新的全球体系结构应该是什么样子。您可能还需要一位顾问来帮助您在这一点上促进对话。定义返工的目标，并提出一个大家都能同意的"大局"。

之后，我将采取一些线索，并促进他们(回填从开发人员池的线索)到架构团队。然后，他们将与潜在客户会面，以确保事情按照"大局"进行。

我不会从外面引进一个全新的团队。这将创造一个不需要的我们和他们的动态，这是永远不会好。局外人也不知道事情应该如何运作，也不知道事情为什么不按逻辑所暗示的方式运作。：)

考虑阅读/从ACM购买本文：软件架构师。这里有很多参考资料，作者对这样一个漫无目的的话题非常清楚。他不会直接回答你的问题，但这篇文章将集中讨论你的策略。

对你的问题排名第一的答案是一个很好的观点：专注于软技能和定义目标。我会对你的组织中的事情是如何完成的加深理解。

建筑本身就可能把人变成宇航员/僵尸。所以，即使这是基本的原型设计，他们也应该有一些编码工作要做。事实上，他们的原型的成功必须是明确的审查因素。

他们应该每月发表一次演讲/经常发表博客来跟踪他们的工作，这样组织中的其他人就可以学习了。

应该有一些学术目标，比如熟悉某些平台/工具/书籍和设计理念。

如果他们愿意，他们应该有时间在现有项目中寻求新的工具/项目/责任。

他们将有责任对关键模块进行至少3-4次代码审查，并提出代码风格的指导方针。

他们有责任至少审查关键模块的低级设计。

作为个人或团队，他们应该有空余时间来构建他们认为可能有用的东西。

他们应该可以选择放弃体系结构，如果他们愿意的话，可以回到正常的工作中，而不需要惩罚。

他们应该知道组织中运行的所有项目中发生了什么。至少应该密切关注一个项目，这样他们就可以将其他地方发生的事情通知自己的同行。这可能是他们执行代码评审等的项目。

他们应该有一个技术性很强的人作为他们的经理。

一旦架构师非常熟悉其中一个项目，他们就应该在项目之间进行切换，并允许他们在处理原始项目的过程中遵循他们遵循的任何原型。

每1年至少有一个真正的目标(比如将项目之间的所有共性合并到一个库中)

投入时间和培训以确保架构师不受自我约束，并且行为相当专业。冲突解决和其他软技能培训以及技术会议和培训的预算也将是绝对必要的。

您需要完成业务场景a)和b)

a)如果你不设置它，也就是说，什么也不做：正在进行的维修成本的返工估计

b)您需要设置：因资源转移而中断近期可交付成果。风险多重产品可能在短期内消失。感知到的额外人力成本。如果产品被运动削弱了，谁会上旗(性能或感知到的不灵活)

接下来让产品团队进行相同的练习，比较结果。

如果你证明了这一点，我看到了两条路线：1。选择一个主导产品来驱动体系结构并向该项目添加资源。然后准备增加更多的资源，耐心等待，否则主导产品会受损。你可以通过这种方式进行风险划分，当主导产品占收入的40%时，它就起作用了。2。启动一个小团队，从内部发生的最有希望的讨论中汲取经验，逐步在每个产品中包含新的体系结构。把这个团队的工作编织成产品工作。

您需要考虑的一些问题：1。您需要多久才能实现架构的融合才能获得业务收益。2。谁是团队成员已经在谈论架构融合，他们是否在询问/建议其重要性，您需要将这个问题放在80%的团队领导的"次要"位置。

不该做什么*从外部聘请专家(除非你现在真的陷入困境)*几个月后放弃，这是长期的。*一次更改所有项目。*从三个核心开始，直到你能做到这一点。*让建筑部门变得比原来更大*让人感觉到体系结构部门将解决产品团队的问题*让任何产品看起来都是"等待新架构"*让架构(architecture)部门"定义全部"或进行范围渐变*强制所有产品进入架构，有些可能不适合(例如，不在同一国家开发)

怎么办：*有充分的理由第一个问题得到高级管理层购买并询问产品要报告进度的团队*在产品与架构的一致性方面进行逐步的更改地图*协调最有前途或低风险的产品线第一*设置指标，以便演示增值(请参见第一组的理由问题)*有一个路线图，让所有产品都能聚合或不聚合。*想想核心架构提供了什么以及谁维护了它人工制品*允许产品团队在以下方面为核心做出贡献：规范、代码和维护核心的*设置如何使用架构(architecture)团队工作的培训新员工和现有团队

我认为架构团队需要有足够资深的人员，他们知道所有开发团队的内部工作，并且能够拒绝请求/指导线。我在团队中拥有优秀的开发人员，但是没有足够的权限，最终跟随来自不同团队的高级开发经理，产生了不一致的框架。

总的来说，对于政治和其他方面与体系结构组相关的激励措施要非常小心。对于"体系结构审查委员会"(或任何你想称之为"体系结构审查委员会")来说，很容易成为阻碍进展的障碍。它所需要的只是零激励来改善事情，当事情发生变化而不立即改善时，它是一个负激励。

认识到将要犯的错误，一些"伟大的新技术"将变成半生不熟的时尚，以及经济变革和创新。这可能导致偶尔的短期动荡和失败的转型，但这比停滞要好。

另一种选择不可避免地会导致停滞；在更大的组织中，我看到了职业生涯的毁灭，因为一个管理者对他的团队有足够的信心来支持他们对新技术的建议，一路走到最高层，提供案例研究来证明这一点，然后回到最高层。当新技术最终获得批准(经过近一年的政治斗争)后，首席技术官(CTO)(一直反对)声称这项创新值得称赞，并将经理调到了一个边远地区的部门。在另一个事件中，一项新技术被提出，在同一个业务领域有许多成功的例子，并成立了一个委员会来研究这个问题。五年后，他们仍在研究这个问题，什么也没做。