建立一个架构部门

一些上下文:

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

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

什么是DO和DO不是这样的事业？

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

他们应该承担什么责任？

什么超出了他们的范围？

公司有哪些有用的过渡战略？

每当有人提到"建筑团队"时,如何防止那些歪歪扭扭的样子？

贵公司是否已成功进行此类更改？
为什么会失败？
为什么成功？

这不应该是关于"什么是建筑师？"(这是非常密切相关的)的讨论.

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

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

架构团队的具体任务是什么？

架构团队的可交付成果是什么？框架,指南,实施帮助......或者他们只是建筑宇航员？

这仅适用于未来的应用程序,还是这是一个后端？

谁将负责向后移植？(我们的意思是预算......)

是否会分配资源来测试backports？

建筑团队是否具有真正的实力,或者当第一组抱怨实施变更所需的4个月时,管理层是否会弃权？

您将如何处理各个项目组与建筑团队之间的摩擦(并且会产生摩擦？).机会主义者将此作为一个抓住职位的绝佳机会......

请注意,这将主要是一场政治游戏......

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

在第一个步骤是将晶体什么架构团队应该实现清晰.
你为什么要把团队安置到位？
您是否正在尝试统一所有应用程序,开发一个通用框架,什么？
这个团队的任务和愿景是什么？

无论谁带领这支球队更好地发挥**人际交往能力.
它应该不会是辉煌的编码器,可以吹哨星球大战主题曲,让光剑的声音......但他或许应该是对球队的技术能力.

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