数字化企业敏捷建模之组织建模( 五 )

团队的技术架构师们讨论和识别了模板之间可复用的模块，希望能够开展重构，强化整个系统的组件化设计，但这样的重构工作被需求开发工作挤压，一直都没能落地。
面对越来越低下的效能，团队领导让我们来为模板库领域的技术落地建立技术架构的团队结构，从而能够推动该领域的技术架构优化。下图是针对目标技术架构梳理的组织建模结果。

文章图片
（“模板库领域”的组织建模结果展示，形成针对该领域的“技术架构地图” ，除了三类型模板各自一个团队外，完成了“模板市场”和“模板工厂”的平台和组件团队建模。）
上面的建模结果形成了5个小团队：
每类型的模板团队仍然保留，采用业务流团队定位，明确针对客户和市场需求进行功能开发。
建立“模板市场”团队，定位平台团队，统一客户界面的展示和互动，通过标准化API调用不同的模板，为客户生成对应的线上协同空间。
针对技术架构已经梳理出来的可复用模块，成立专项的“模板工厂” ，采用复杂子系统团队。预期很多的技术细节需要磨合，紧密的“协作”模式在所难免，伴随着较高的交流沟通成本。
这样的团队结构明确了我们针对该领域建模的技术架构，其中“模板工厂”存在一定不确定性，是否能够真正成功有待验证，所以在WardleyMap中也放到了相对靠初创的位置。 “模板市场”应该说是现在典型前、后端分离架构的标准配置，确定性较高，由此也直接定位为平台团队。
在这样的团队建模下，相应的技术架构治理要点也变得逐步清晰，比如：
各个模板团队需要进行API层面的统一，保证“模板市场”能够高效调用，形成合理的前后端契约。
“模板工厂”需要调用技术骨干形成专项小组，建立迭代的重构和合并机制，并采用轻量级的架构决策机制，如ADR（https://github.com/joelparkrhenderson/architecture-decision-record）
各个模板团队本身的演进阶段不同，比如3D模板完全自研，处于初创阶段，需要更快的迭代验证闭环。
我们利用了WardleyMapping完成了针对团队结构的组织建模，形成了面向逆康威定律的“技术架构地图” ，从团队结构视角来展现了技术模块的组合。当然各个模块内部的具体技术实现，比如“模板市场”采用Vue.js还是React ，这样的实施决策我们可以相信对应的实施团队来评估。
随着云原生和微服务架构逐渐成熟，各种配套和支撑的工具框架越来越完善，研发团队未来必然更加关注建模本身，而不必被服务路由、监控日志等基础琐事分心。由此也要求我们的技术架构师们更加关注团队的划分，更多考虑逆康威定律的实现落地。
技术架构的动态治理开篇提到为了保证大家能够思考架构的演进，我们希望把“时间”纳入架构治理的一个重要维度。利用团队拓扑建立基于团队划分的技术架构地图后，坚持做好动态治理就是关键的下一步，否则我们又会回到过去“画图很美好、现实很残酷”的老路上。
强调组织建模，从团队结构入手的一个好处是缩短了感知闭环。从团队的视角观察技术架构中的“坏味道”更加直接，比如团队实现一个需求需要修改多个模块，定位一个改动需要花非常多的时间，这些可能就说明我们的技术架构存在值得去分析的问题了。
而如果我们有一些技术架构方面的改进需要落地，调整团队结构也是最显式的意图传递，比如上一个案例中，成立了“模板工厂”团队，就能够让大家理解我们技术架构上调整的意图。而相关的团队也能够名正言顺地开展工作，并帮助其他团队快速理解与之合作的目的。