当我们谈论微服务架构时，在我们眼前是一组自治的，几乎彼此独立的组件。 绝缘是任何微服务系统的基石。 但是，即使我们对创建微服务的能力充满信心，问题还是出现了-组织结构为完成这项任务准备了多少？ 我们是否能够利用微服务带来的机会和局限性？ 如何使团队适应这种架构而成功工作？ 在本文中，我们将尝试讨论开发微服务系统的组织方面。
传统方法
大型商业公司历来被组织为一组职能部门：财务，市场营销，运营，人力资源等。 业务流程数字自动化的需求促使该公司成立了另一个职能部门-IT部门。 反过来，IT部门随后根据将具有一定知识和功能集合的专家组合并为原则，分为程序员，测试人员，系统管理员的职能团队。 组织思维的模式很清楚。 它的稳定性与其不愿分析管理有效性的努力无关，而是与流程的巨大惯性以及不存在会危害组织成功的明显挑战有关。
但是，根据人员的职能进行人员隔离不可避免地会在团队之间造成距离。 当软件测试由独立的测试人员团队进行时，开发人员仅专注于编写代码，而很少关心其可测试性。 结果，该软件产品在规格上存在许多偏差，更糟糕的是，团队正在逐渐变成独立的团队。
注意：筒仓心态是不愿意分享的。
与同一组织中其他部门的员工的信息。 这样的
行为通常会导致组织有效性下降，最糟糕的是
案件导致企业文化的破坏。此外，在严格职能部门中，决策过程不可避免地会放慢速度。 协调团队工作计划的成本正在增加。 例如，同一位测试人员的资历和经验需要不断平衡，同时要考虑到开发团队的要求。 是的，较高的入门门槛和对知识转移的需求减慢了该过程：外部专家需要不断切换任务上下文以服务于各个团队的请求。
因此，当具有传统组织结构的公司面临对业务持续产生的挑战几乎即时做出响应的需求时，其IT部门将无法确保解决方案的有效性。 技术的飞速发展只会加剧这种滞后，并使为开发服务的专业团队保持所需的动力和专业水平的任务变得复杂。 而且，由于IT的主要目标是并且一直是有效地确保独立产品（包括微服务）的整个生命周期，因此将团队从水平方向的功能团队重组为垂直方向的，自给自足的自治团队的需求变得显而易见。
跨功能命令
根据Wikipedia的说法，跨职能团队是一群承担各种职能任务并朝着共同目标努力的人。 在当今的业务中，创新是领先的竞争优势。 跨职能团队通过团队内部以及与组织中其他团队的创造性协作来促进创新。
图1.职能和跨职能团队。跨功能微服务开发团队由开发人员，数据库工程师，测试人员，基础架构工程师和其他专家组成。 这样的团队比功能团队进行修改的速度更快，因为它们可以做出自己的决定并可以独立于其他团队工作。 通过专注于缩短开发周期并实施持续部署，这些团队几乎可以立即解决问题。
CarMax的IT主管Shamim Mohammad说：“在一个快速发展的世界中，建立灵活的，跨职能的产品团队以快速解决问题的解决方案非常重要。 他们拥有所有必要的权力，而管理层从不告诉他们如何解决问题，而只会告诉他们解决问题的方式以及可以使用的关键绩效指标。 这种方法使您可以改善反馈，显着加快开发过程，通过反复试验最终为客户和合作伙伴找到最佳解决方案。 我们还发现，团队在实现目标方面更具风险，并且更具创造力。 如果您没有这样的完全集成的团队，请仔细考虑一下，您是否准备好成功进行数字化转型？”
根据麻省理工学院的调查和德勤全球人力资本趋势，在创新开发中流程数字化水平很高的公司非常依赖跨职能团队的存在。 83％的成熟公司承认他们使用跨职能团队。 尽管运营复杂性增加了（附加成本高达16％），但公司的运营指标却得到了显着改善（高达53％），资源和资产的获取得到了改善（高达37％），灵活性更高（高达12％）以及官僚主义程度下降了由于减少了组织结构的层次结构（最多11％）。
图2.适应跨职能团队的好处。 统计资料。从职能团队到跨职能团队的平稳过渡是很有可能的。 第一批跨职能团队是围绕最有价值的业务机会组建的，这些机会需要IT部门不断关注和快速响应。 职能团队的成员转入跨职能团队，同时加深了他们的经验并总体上改善了团队自治和决策过程。 在某些时候，功能命令会完全转换为一组跨功能命令。
图3.过渡到跨职能团队。平台团队的出现
但是，仅跨职能团队的存在并不意味着我们为创建微服务提供了最佳条件，并且最有效地满足了业务需求。 仍然有许多与开发，支持和维护相关的任务，其中最重要的是：
- 数据同步（一致性）；
- 数据过时
- 安全性
- 服务间通信；
- 服务发现；
- 分布式日志记录和监控；
- 服务和调试之间的循环依赖关系；
- 测试；
- 可靠性和容错能力；
- 性能。
它们中的大多数不是任何特定微服务的本地任务。 这些是整个系统级别的任务，并且与微服务系统的基础结构有关。 许多组织将这种基础架构称为“平台”，即创建和开发微服务的基础。
实际上，随着组织的成长，其对所使用技术的依赖性也越来越高。 出现不一致的地方越来越多，这导致组织失去了快速进入市场，评估新兴机会和创新的能力。 解决这种情况的一种可能方法是在组织活动的最重要领域（例如交付解决方案或与客户互动的基础结构）过渡到使用由“机会块”组成的“数字平台”。 数字平台使概念和投资之间的差距最小化； 改善系统稳定性，更重要的是，改善组织内部的小气候。
许多IT组织都在想：需要分配多少员工才能直接在“产品”上工作，哪些应该在“平台”上工作？ 实现人员分离的最重要论据之一是：数字平台需要拥有者，这些拥有者致力于确保遵守平台宣布的原则，并在平台的开发，实施和维护方面拥有丰富的经验和高水平的专业知识。
为了说明将数字平台作为独立产品引入的必要性，我们转向微服务的基本原理之一：使用智能过滤器和简单通道。
无论通道多么简单，它仍然需要所有者。 而且，如果有很多团队，每个团队“拥有自己的微服务”，那么谁来负责他们的交互？ 为了发现服务，为了安全性，在整个系统级别（甚至在组织级别（如果涉及系统间级别））进行监视？ 谁负责全面测试？ 如果我们开始将这些职责分配给特定的微服务开发团队，那么我们的策略和选择标准是什么？ 最后，这样的团队（开发人员，我提醒您）是否会在产品上保持灵活性和自主性？ 似乎平台开发团队应该出现在舞台上的时候到了！
平台开发团队（简称平台团队）是管理数字平台的专业跨职能团队，该平台是API，工具和服务形成的基础，API，工具和服务的知识和支持被组织成一个独立的内部产品。
数字平台战略专注于提供业务价值。 为了消除在构建微服务生态系统中的不一致之处，该策略着重于技术解决方案交付的五个主要领域：
- 交付基础设施；
- API架构和修复；
- 自助服务数据；
- 实验基础设施和遥测；
- 与客户的互动。
图4：数字平台战略独立的微服务团队有机会使用该平台来加速对其产品功能的支持，同时降低必要的跨团队协作的程度。
毫无疑问，专门的专业平台团队的概念既有优点也有缺点：
好处包括：
- 沟通渠道的统一和顺序；
- 提供控制权，同时保持各个开发团队的灵活性。
缺点包括：
- 调整组织中策略的时间成本；
- 需要额外的资源-平台团队需要研究各个微服务团队的细节，以及创建统一平台的形式要求；
- 如果平台实施不正确，它将成为组织流程中的瓶颈。
因此，在计划组织内的团队和跨团队活动时，我们必须考虑可能的问题和风险。
互动协同
那么，如何与平台团队进行互动呢？ 有几种可能的方法，其中可以区分两种：
- 使用平台作为产品。 平台团队会定期更新平台版本，并将其作为产品API提供给微服务团队。 这可以是虚拟机的映像，也可以是具有改进功能（与以前的版本相比）的容器，或者是可扩展的框架。
- 当平台团队的代表出现在微服务团队中时（或分配微服务团队的成员之一与平台团队进行通信），渗透到微服务团队中。 使用这种方法时，微服务团队将有机会与平台团队进行更快的反馈，并可以启动将更改引入平台的过程。
图5：与平台开发团队的互动：左边是平台产品，右边是渗透到团队中。结论
最后，我想再次强调，组织结构应使有效利用建筑和技术选择的优势成为可能。 康韦（Conway）的法律规定，一个组织寻求创建作为组织结构副本的项目。 但是我也倾向于相信相反的说法是正确的：系统的结构告诉组织最适合其实施的结构。
为了确保响应业务需求的必要质量，现代IT行业必须具有最高水平的组织灵活性。 为了不失去我们正在努力创建的系统的有效性，我们必须考虑组织变革的必要性和可能性。