建立一个架构部门

Question

预先提供一些背景信息：

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

由于必须整合和控制架构并在整个系统上启用某些必要的大型返工，除了所有需要的知识交换之外，公司还决定建立一个架构部门。

• 此类承诺的 DO 和 DO NOT 是什么？

• 构成这样一个建筑团队的人是谁？

• 他们应该承担什么责任？

• 他们的范围是什么？

• 公司有哪些有用的转型策略？

• 每当有人提到“建筑团队”时，如何防止那些歪歪扭扭的样子？

• 贵公司是否已经成功进行了这样的改变？
  为什么会失败？
  为什么会成功？

那应该不是关于“什么是架构？”的讨论（这是非常密切相关的;）。

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

Answer 1

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

• 架构团队的具体任务是什么？
• 架构团队的可交付成果是什么？框架，指南，实施帮助......或者只是Architecture Astronauts？
• 这仅适用于未来的应用程序，还是这是一个后端？
• 谁将负责向后移植？ （我们的意思是预算......）
• 是否会分配资源来测试backports？
• 当第一组抱怨实施变更所需的4个月时，建筑团队是否具有真正的实力，或管理层是否会弃权......
• 您将如何处理各个项目组与建筑团队之间的摩擦（并且会产生摩擦？）。机会主义者将把这作为一个抓住位置的绝佳机会......
• 请注意，这主要是一场政治游戏......

我的朋友，你前面有艰难的道路......

第一个步骤要清楚地了解架构团队应该达到的目标 你为什么要把团队安置到位？ 您是否正在尝试统一所有应用程序，开发一个通用框架，什么？ 这个团队的任务和愿景是什么？

无论是谁，这支球队的领导者都能更好地发挥**人际交往能力 它应该不成为能够吹响星球大战主题曲并发出轻剑声的精彩编码器......但他应该以技术身份加入团队。

您应该与熟悉大多数项目的人员一起填充团队。我会谨慎选择所有目前的线索，因为这可能需要当前团队的大量知识。让我们面对现实，这些团队必须高效，而架构团队才能提供自己的可交付成果。

Answer 2

架构难以正确。

“建筑师”需要有能力完成任务，但需要足够精明，不要滥用这种权力，并完全疏远公司的其他部分。

我曾在两个实施架构团队的地方工作过 - 一个是成功的，另一个看起来不那么好。在成功的地方，这是一个相对较小的环境，首席建筑师被认为是技术领导者，团队的其他成员具有出色的写作和政治技巧。每个人的行为都符合组织的最佳利益。

在它没有那么好用的地方，建筑师清楚地代表了组织中的特定派系，并没有赢得整个地方的信任或尊重。结果是花费了更多的时间来找借口绕过建筑而不是从中收集任何价值。在这种情况下，挫折感变成了被动/侵略性和其他反社会行为。

我认为你提出的关于范围/责任/过渡的其他问题都是由“它取决于”来回答的。这取决于公司，人员，金钱和时间表。

Answer 3

有趣的问题。

首先，您必须清楚地了解这个“架构”团队正在解决的问题。如果你无法清楚地定义团队的“使命”，那么它将会失败并且会发生巨大的爆炸。 ：）

话虽如此，第一步是确定您正在解决的问题。你想跟上技术吗？您是否尝试在项目之间合并一些代码重用？您是否正在尝试利用您的开发人员以获得最佳效果？实现架构团队并给出您的设置有几个原因，其中任何一个都可能足够。从您的问题来看，您的目标似乎是重新编写现有应用，这是第一步。

由于您已经拥有一组对应用程序具有良好特定知识的潜在客户，因此从一开始就是一个好主意。将它们组合在一起，找出新的全局架构应该是什么样子。您可能还希望获得一名顾问，以帮助促进此时的对话。确定返工的目标，并提出每个人都同意的“大图”。

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

我不会从外面引进一个全新的小组。这将创造一个永远不会好的不受欢迎的Us vs. Them动态。外人也不知道事情应该如何运作，或者为什么事情不会像逻辑意味着他们应该的那样运作。 ：）

Answer 4

在这种情况下，“建筑”本身并不意味着什么。它意味着“横向专题专家”。

每当你拥有一个“建筑团队”时，你就会拥有一个横向团队，为许多项目提供服务。

正如之前的答案所述，您需要了解“建筑部门”必须解决的主题。

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

• 业务和功能架构团队：编写许多与业务相关的规范，并检查现有应用程序和功能工作流程之间的一致性，以便完成一致的应用程序制图。
• 应用程序架构团队：提供制图，但也决定如何将业务和功能架构团队决定的功能规范组织到应用程序中。
  例如，您需要一个“组合流程”的功能模块，但应用程序架构团队可以决定将其拆分为“启动器”，“调度程序”，GUI等。
• 技术架构团队，始终由以下人员组成：
  • 执行架构团队，适用于所有非商业纯技术主题（日志记录，KPI，框架......）
  • 开发架构团队（工具评估和支持，技术调查，版本和配置控制的存储库管理）
  • OA（操作架构），用于使环境“可执行”（即，了解正确的流程，正确的服务器和正确的网络，以便部署您的系统以进行认证或生产。）

您可能希望为服务器和网络的所有管理添加Logistic团队，其中包括备份和DRP策略的任务。以及基于良好案例系统的支持策略。

你很高兴。

现在，不要忘记当你开始一些“大型返工”时，你的功能架构将有责任在以下两者之间强制执行一致性：

• 重新设计的项目，以确保它们保持在固定的功能范围内
• 传统项目，以确保他们的维护不会涉及相反的选择与应用于重新设计的项目相比。

在这样大小的商店中进行任何返工意味着确实能够在等待返工生成第一批版本的同时，对遗留项目进行必要的演变。 （遗产不能只等待并在2 - 3年的返工期间保持不变）

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

• 1 /与遗产的对话
• 2 /完成遗产
• 3 /替换遗产

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

祝你好运，晚安。

Answer 5

总的来说，要非常小心政治和与建筑群有关的激励措施。 “建筑评审委员会”（或任何你想称之为）的障碍很难成为进步的障碍。所需要的只是改善事物的零动机和当事情发生变化而不立即改善时的负面激励。

意识到会犯错误，一些“伟大的新技术”将成为半生不熟的时尚，以及改变和创新。这可能会导致偶尔的短期动荡和失败的转型，但这比停滞更好。

而替代方案不可避免地导致停滞不前;在大型组织中，我看到职业生涯被毁了，因为一位经理在他的团队中足够相信支持他们对新技术的建议一直到顶部，提供案例研究来证明这一点，并将其归还给他们。当新技术最终获得批准（经过近一年的政治内斗）后，CTO（一直反对它）声称对创新有所贡献，并将经理转移到了一个偏僻的部门。在另一个事件中，提出了一项新技术，在同一业务领域有许多成功案例，并成立了一个委员会来研究这个问题。 五年后他们仍然在研究这个问题，并没有做任何事情

Answer 6

我认为架构团队需要让人员足够高级，以便他们了解所有开发团队的内部工作方式，并且能够对请求/指导线说“不”。我一直与优秀的开发人员合作，但没有足够的权限，最终跟随来自不同团队的更高级别的开发人员经理并产生不一致的框架。

Answer 7

您需要完成业务方案A）和B）

A）如果你没有设置它，即什么也不做，怎么办？ 估计维修费用的返工

B）你确实设置了：
由于资源转移导致近期可交付成果中断 风险多种产品可能在短期内被解散 感知额外人力的成本。
如果产品因练习而变弱，谁会举起旗帜 （表现或感知缺乏灵活性）

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

如果你确实证明了这一点，这里有两条我见过的路线：
1.选择一个主导产品来推动架构并为该项目增加资源 然后准备添加更多资源，并耐心等待主导产品受损 你冒着使用这条路线的风险，当主导产品占收入的40％时就有效 2.从内部发生的最有希望的讨论中抽出一个小团队，逐步包装每个产品的新架构。
将这些团队编织到产品工作中。

您要查看的一些问题：
1.您需要多久才能实现架构融合以获得业务收益。
2.谁已经在讨论架构融合的团队成员，他们是在询问/暗示它的重要性，你需要在80％的团队负责人的“背后燃烧”上提出这个问题。

什么不该做
*聘请外部专家（除非你现在真的很乱）
    *几个月后放弃，这是长期的     *立即更改所有项目     *开始，直到你有三个核心可以实现这一点     *让建筑部门变得比它更大     *让人感觉建筑部门将解决产品团队的问题     *让任何产品看起来“等待新架构”
    *让建筑部门“定义所有”或具有范围蔓延     *强制所有产品进入架构，有些可能不适合（例如，不在同一国家开发）

做什么：
*有充分的理由武装起来     第一个问题得到高级管理层     购买并询问产品     团队报告进展情况     *逐步改变产品与架构的一致性     地图
    *致力于协调最有希望或低风险的产品线     第一     *设置指标，以便您可以演示增值（请参阅     从第一套的理由     问题）
    *制定所有产品的路线图，以便融合或不融合     *考虑核心架构提供什么以及谁维护它     文物
    *允许产品团队在核心方面为核心做出贡献     具体规定，代码和维护     核心     *设置如何使用架构团队的工作     新的先发球员和现有球队

Answer 8

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

他们应该每月发布一次频繁的博客来跟踪他们的工作，以便组织中的其他人可以学习。

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

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

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

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

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

他们应该可以选择放弃建筑，如果他们觉得没有处罚，可以回到正常工作。

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

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

建筑师一旦熟悉其中一个项目，就应该在项目之间进行切换，并允许他们在使用原始项目时遵循他们所遵循的任何原型。

每1年至少有一个真正的目标（比如将项目中的所有共性整合到一个库中）

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

Answer 9

考虑从ACM阅读/购买这篇文章：The Software Architect。那里有几个参考文献，作者对这样一个分散的主题非常清晰。他不会直接回答你的问题，但文章将重点关注你的策略。

对你的问题排名靠前的答案是一个很好的观点：专注于软技能和定义目标。我会深入了解您的组织中的工作方式。