Architecture 成立建筑系

一些预先的上下文：

想象一下，一家200多名开发人员的公司最终建立了一个或多或少独立的体系结构团队/部门。 由20多个“项目”/“生产中不同规模的应用程序”组成的软件组合由负责并负责“架构”项目的团队领导/技术领导负责

出于整合和控制体系结构的必要性，以及在整个系统上实现某些必要的大规模返工，除了所有必要的知识交流之外，公司决定成立一个体系结构部门

• 这样一项事业的应该做什么和不应该做什么

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

• 他们的责任是什么

• 什么超出了他们的范围

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

• 如何防止每次有人提到“架构团队”时都会出现这种扭曲的表情

• 你的公司已经成功地经历了这样的变革吗？
  为什么失败了？
  为什么成功了

这应该而不是讨论“什么是建筑？”（这是非常密切相关的；）

---

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

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

• 架构团队的确切任务是什么
• 架构团队的可交付成果是什么？框架、指南、实施帮助。。。还是他们只是
• 这是只用于未来的应用程序，还是作为一个后端口
• 谁将负责后台移植？（我们这里指的是预算…）
• 是否会分配资源用于测试后端端口
• 架构团队是否有真正的实力，或者当第一个团队抱怨实施变更需要4个月的时间时，管理层是否会屈服
• 您将如何处理各个项目组和架构团队之间的摩擦（会有摩擦吗？）。机会主义者会把这当作一个极好的机会来争夺职位
• 请注意，这将主要是一场政治游戏

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

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

无论谁是这个团队的领头羊，都应该具备良好的人际交往能力。
它应该而不是是能吹奏《星球大战》主题曲并发出光剑噪音的杰出程序员。。。但他应该以技术能力加入球队

您可能应该让团队中有熟悉大多数项目的人。我会小心选择所有当前的潜在客户，因为这可能会占用当前团队的大量知识。让我们面对现实，当架构团队提出自己的可交付成果时，这些团队必须是高效的。

有趣的问题

首先，您必须对这个“架构”团队正在解决的问题有一个清晰的概念。如果你不能清楚地定义团队的“使命”，它将失败，并以巨大的爆发力完成任务。：）

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

既然你已经有了一组对应用程序有很好专门知识的潜在客户，那么最好从他们开始。把他们聚在一起，讨论一下新的全球架构应该是什么样子。此时，你可能还想请一位顾问来帮助促进对话。定义返工的目标，并提出一个大家都同意的“大局”

之后，我会将一些潜在客户推广到架构团队（从开发人员池中回填潜在客户）。然后，他们将与潜在客户会面，以确保事情按照“大局”进行

---

我不会从外部引进一个全新的团队。这将创造一个不必要的美国对他们的动态，这从来都不是好的。局外人也不知道事情应该如何运作，也不知道为什么事情不能按照逻辑所暗示的方式运作

总的来说，要非常小心与建筑集团相关的政治和其他方面的激励。“架构审查委员会”（或者你想叫它什么名字）成为进展的障碍远不是一件容易的事。它所需要的是零激励来改善事物，当事物发生变化而没有立即改善时，它是负激励

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

而另一种选择必然导致停滞；在更大的组织中，我看到职业生涯被毁掉，因为一位经理对他的团队有足够的信任，支持他们对新技术的推荐，一路走到最高层