预先考虑一些背景：

想象一下，一家200多家开发商公司最终成立了一个或者多或者少的独立架构团队/部门。
由20多个"项目" /生产规模不同的应用程序组成的软件产品组合由团队负责人/技术负责人负责，他们还负责并负责"架构"项目。

出于巩固和控制体系结构并在整个系统上进行某些需要的大量返工的必要性，除了所有必要的知识交流之外，该公司决定成立一个体系结构部门。

• 这项工作有哪些要做和不要做的事情？
• 组成这样的架构团队的人是谁？
• 他们的责任是什么？
• 什么超出了他们的范围？
• 对公司有用的过渡策略是什么？
• 当有人甚至提到"建筑团队"时，如何防止那些烦恼？
• 贵公司是否已经成功进行了此类更改？为什么失败了？为什么成功？

那不应该是关于"什么是architecutre？"(这是非常相关的；)的讨论。

真正有趣的一点是可以接受的/现实的，甚至可以毫无摩擦地组建这样的团队，当然，除了一些关于战斗的警告，最好甚至不要开始。

解决方案

以下是一些应考虑的问题：

• 架构团队的确切职责是什么？
• 架构团队的交付物是什么？框架，指南，实施帮助...还是仅仅是建筑宇航员？
• 这是仅适用于未来的应用程序，还是会成为反向端口？
• 谁将负责反向移植？ (我们的意思是这里的预算...)
• 是否会分配资源来测试反向端口？
• 当第一小组抱怨实施变更需要四个月的时间时，架构团队是否有真正的力量，或者管理层会折叠吗？
• 我们将如何处理各个项目组与架构团队之间的摩擦(并且会发生摩擦？)。机会主义者将以此为契机争取职位。
• 请注意，这将主要是一场政治游戏。

我的朋友，前进道路艰辛...

第一步是明确架构团队应该实现的目标。
我们为什么要组建团队？
我们是否要统一所有应用程序，开发一个通用框架，是什么？
这个团队的任务和愿景是什么？

谁能更好地领导这支球队，谁就应该具备人际交往能力。
不应吹嘘《星球大战》主题曲并发出轻剑声的精明编码员，但他应该以技术能力加入团队。

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

有趣的问题。

首先，我们必须对这个"架构"团队正在解决的问题有一个清晰的认识。如果我们不能明确定义团队的"任务"，它将失败，并且会发生巨大的爆炸。 :)

话虽如此，第一步是定义我们要解决的问题。我们是否要跟上技术发展？我们是否在尝试在项目之间合并一些代码重用？我们是否正在努力利用开发人员以取得最佳效果？实施架构团队的原因有很多，并且根据设置，其中任何一个都足够了。从问题来看，目标似乎是重新设计现有应用程序，因此这是一个不错的第一步。

由于我们已经拥有一组对应用程序具有特定知识的潜在客户，因此从它们开始是一个好主意。将它们聚集在一起，并弄清楚新的全局体系结构应该是什么样子。此时，我们可能还需要一名顾问来帮助促进对话。确定返工的目标，并提出每个人都可以同意的"全局"。

之后，我将挑选一些线索，并将其提升(从开发人员池回填线索)到架构团队。然后，他们将与潜在客户会面，以确保一切按照"大局"进行。

我不会从外面引进一个全新的小组。那会造成不必要的美国与他们之间的动态关系，这永远是不好的。局外人也不知道应该如何工作或者为什么事情不能按照逻辑暗示的方式工作。 :)

总的来说，要特别注意与建筑团队相关的政治和政治上的激励措施。 "架构审查委员会"(或者任何我们想称呼的)很难成为发展的障碍。它所需要的只是对事物进行改进的零激励，而在事物发生变化并且没有立即改进时则具有消极激励。

意识到会犯错误，一些"伟大的新技术"将变成半生不熟的时尚，生态的变革和创新。这可能会导致偶尔的短期剧变和失败的转换，但这比停滞好。

替代方案不可避免地导致停滞；在大型组织中，我看到了职业生涯的失败，因为一位经理相信他的团队足够支持他们对新技术的建议，一直到最高级，提供案例研究来证明它，并将其付诸实践。当这项新技术最终获得批准(经过近一年的政治内斗之后)，CTO(一直反对该技术)声称对这项创新表示赞赏，并将经理移交给了落后地区。在另一起事件中，提出了一项新技术，其中列举了在同一业务领域取得成功的许多例子，并成立了委员会来研究该问题。五年后，他们仍在研究该问题，但未做任何事情

在这种情况下，"架构"本身没有任何意义。它的意思是"横向主题专家"。

只要我们有"架构团队"，就会有一个横向团队，该团队将为许多项目提供服务。

如前面的答案所述，我们需要知道诸如"建筑部门"必须解决的主题。

现在，这是一个基于几个主题的组织架构团队的示例：

• 业务和功能体系结构团队：编写许多与业务相关的规范，并检查现有应用程序和功能工作流之间的一致性，以完成应用程序的连贯制图。
• 应用程序架构团队：提供制图，但也决定如何将业务和功能架构团队确定的功能规范组织到应用程序中。例如，我们需要一个用于"投资组合过程"的功能模块，但是应用程序体系结构团队可以决定将其拆分为"启动器"，"调度程序"，GUI等。
• 开发架构团队(工具评估和支持，技术调查，版本和配置控制的存储库管理)
• OA(操作架构)，用于使环境"可执行"(也就是说，了解正确的流程，正确的服务器和正确的网络，以便将系统部署用于认证或者生产)

我们可能想要为服务器和网络的所有管理添加一个物流团队，并执行备份和DRP策略的任务。以及基于良好案例系统的支持策略。

而且你很好。

现在，不要忘了，当我们开始一些"大修"时，功能体系结构将具有在以下两者之间增强一致性的使命：

• 返工的项目，以确保它们位于固定的功能范围内
• 与用于重做项目的选择相比，确保遗留项目的维护不会涉及相反的选择。

如此规模的商店中的任何返工确实意味着在等待返工以产生第一版时，能够对遗留项目进行必要的改进。 (遗留物不能仅在2-3年的返工中等待并保持静止)

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

• 1 /与旧版对话
• 2 /完成遗留
• 3 /取代传统

意味着任何给定的组件实际上都是三次开发的！ ;)

祝你好运，晚安。

我认为架构团队需要有足够的高级人才，以使他们了解所有开发团队的内部运作，并能够对请求/指导说"不"。我曾与优秀的开发人员一起工作，但他们没有足够的权限，最终却跟随了来自不同团队且产生不一致框架的高级开发人员经理。

架构很难正确。

"建筑师"需要有能力将事情做好，但需要足够的机智，以免滥用该权力并完全疏远公司的其他部门。

我曾在两个实施架构团队的地方工作过-一个很成功，另一个看上去不太好。在成功的地方，这是一个相对较小的环境，总设计师被公认是技术主管，团队的其他成员具有出色的写作和政治技巧。每个人都为组织的最大利益而行动。

在效果不佳的地方，建筑师清楚地代表了组织中的特定派系，并且没有赢得整个地方的信任或者尊重。结果是，花费更多的时间来为绕过该体系结构找借口，而不是从中获取任何价值。在这种情况下，挫折感变成了消极/攻击性和其他反社会行为。

我认为我们询问有关范围/职责/过渡的其他问题都由"取决于"来回答。这取决于公司，人员，金钱和时间表。

我们需要通过业务场景A)和B)进行工作

A)如果我们不进行设置，即不执行任何操作，该怎么办：
维修费用返工的估计

B)然后我们进行设置：
由于资源转移，中断了近期可交付成果。
短期内可能会冒多种产品的风险。
感知到的额外人力成本。
如果产品因锻炼而变弱，谁来举报
(表现或者感觉上的僵硬)

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

如果我们能证明其合理性，这是我看到的两条路线：
1.选择一个主导产品来驱动体系结构，并向该项目添加资源。
然后准备增加更多的资源，并耐心等待主产品遭受损失。
我们需要冒险使用此方法进行划分，但当主营产品占收入的40％时，该方法就起作用了。
2.从内部进行的最有希望的讨论中组建一个小团队，逐步将每种产品的新体系结构打包。
将这个团队的工作编织到产品工作中。

一些问题供我们查看：
1.我们必须多久实现架构融合才能获得业务收益。
2.谁是已经在讨论架构融合的团队成员，并且他们在询问/建议架构融合的重要性，我们需要在80％的团队负责人的"后援"上提出这个问题。

不该做什么
*从外部聘请专家(除非我们现在陷入困境)
*几个月后放弃，这是长期的。
*一次更改所有项目。
*开始，直到我们拥有三个可以做到这一点的核心。
*让建筑部门变得比原来更大的规模
*让我们知道架构部门将解决产品团队的问题
*让任何产品看起来都在"等待新架构"
*让建筑部门"全部定义"或者扩大范围
*将所有产品强制用于建筑，某些产品可能不合适(例如，不是在同一国家/地区开发的)

怎么做：
*拥有充分的正当理由
第一个问题得到高级管理人员
购买并询问产品
团队报告进度
*逐步更改产品与架构的一致性
地图
*致力于调整最有前途或者低风险的产品线
第一的
*设置指标，以便我们可以证明增值(请参阅
拳头论证
问题)
*制定一个路线图，使所有产品融合或者不融合。
*考虑核心架构提供了什么，以及谁维护了它
人工制品
*允许产品团队在以下方面为核心做出贡献
规格，代码和维护
核心
*设置关于如何使用架构团队的工作的培训
新手和现有团队

光是建筑就可以使人们变成宇航员/僵尸。因此，即使这是基本的原型制作，他们也绝对应该做一些编码。实际上，其原型的成功必须是明确的审查因素。

他们应该每月发布演示文稿/经常跟踪他们工作的博客，以便组织中的其他人可以学习。

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

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

他们将负责对关键模块进行至少3-4次代码审查，并提出代码样式指南。

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

应该给他们以个人或者团队的空闲时间来构建他们认为可能有用的东西。

他们应该选择放弃建筑，并在不受到任何处罚的情况下选择重返正常工作。

他们应该掌握有关组织中所有正在运行的项目中发生的情况的信息。至少应密切关注一个项目，以便他们可以将其他地方发生的事情告知自己的同行。这可能是他们执行代码审查等的项目。

他们应该有一个技术含量高的人作为他们的经理。

一旦建筑师对其中的一个非常熟悉，就应该在项目之间切换，并允许他们在处理原始项目时跟随他们要跟随的任何原型。

每一年至少有一个实际目标(就像将项目中的所有共同点合并到一个库中一样)

投资时间和培训，以确保建筑师不受自我约束，并进行相当专业的操守。肯定也需要解决冲突和其他软技能培训，以及技术会议和培训的预算。

考虑从ACM：软件架构师那里阅读/购买本文。那里有几本参考书，作者对这样一个分散的话题异常清醒。他不会直接回答问题，但本文将重点介绍策略。

问题排名最高的答案很有意义：专注于软技能并定义目标。我将对组织如何完成工作有更深入的了解。