谈服务治理与组织架构的关系

经过前面几章的讨论，我们对 S++ 基本上有了一个全面的了解。

• 每天都在谈 SOA 和微服务，但你真的理解什么是服务吗？
• 服务的技术架构之争
• 服务应该去版本化，不管是微服务还是 SOA
• 任何架构的调整只是拆了东墙补西墙，无法解决效率问题

简单回顾一下：

1. 服务是业务行为的抽象，是与技术无关的，并具有多态性。
2. 服务是去版本化的，具有时空唯一性和稳定性。
3. 服务通过不同的接口来适应不同的外延的需求，从而友好的实现服务的变更和兼容。
4. 通过 S++ 的特性，还可以生成稳定的业务流程，降低系统的维护成本。
5. 通过本征服务，解耦微服务后台应用，提高系统可靠性，实现微服务异构化。
6. 基于 S++ 的特征，实现异步并行组合引擎，提高微服务化带来的系统效率问题。

以上都是从概念和技术的角度来分析 S++ 的特性以及应用，但是一个企业如何才能更好的利用服务来改善业务呢？接下来，我们从管理的角度来看服务，也就是我们常说的服务治理。本章会从宏观的视角来探讨谁是服务治理的主体，组织是如何形成的、组织和架构之间的关系，以及服务治理能为组织提供什么样的帮助。

谁来给服务建模 - 服务产品经理

我们将商品社会的基本行为抽象为服务的消费者和服务的提供者模式，在这个模式下几乎可以涵盖所有的商业行为。但是，问题来了，到底谁是服务的所有者（owner）？大多数人会认为提供者是服务的所有者，所以在传统的企业中，IT 应用系统对服务的生命周期负责，应用系统的产品经理来定义应用系统对外的服务接口。这带来一个问题，同样的一类应用，由于实现的厂商不一样，所以各自的产品对外提供的服务千差万别，这就造成了服务的消费系统无所适从。

于是，我怀疑服务的提供者作为服务的 owner 来决定服务的生命周期甚至服务的定义是否具有合理性。首先，我认为服务的消费者真正决定了服务的内涵，也就是需求决定服务，从这个意义上讲服务是消费者定义的，提供者只是根据消费者对服务的定义通过技术手段实现了服务，只是服务的外延。这样看来，消费者是服务的理论上的定义者，而提供者是服务事实上的定义者，这两者在定义权上是有冲突的。

我认为，商业社会中解决冲突的最有效方法就是订立契约。假如有一个虚拟的服务提供者从大量消费者的需求中抽象出共同的行为模式，这个行为模式因为能涵盖消费者某些消费需求，就能隐式的和消费者签订提供服务的契约了。所谓隐式意思是说，虽然没有和消费者正式的签订合约，但是服务的合约内涵已经满足甚至超过任何一个消费者对此类服务的需求。可以将这个单方面定义合约的角色称为服务产品经理，服务产品经理在一个企业中的角色更像一个真正的产品经理，他们对自己的产品（服务）负责，他们定义并描述服务在各个维度上的属性，并不断寻找合适的服务提供者提供更优质的服务水平。

我们有理由相信，在后 SOA 时代，随着社会分工的进一步精细化，企业内部的 IT 系统将逐步的减少，取而代之的是更专业化的外部专业系统。而企业内部将会出现专职的服务产品经理来定义企业所需的服务，这些服务通过灵活的接口与外部专业系统对接，从而低成本、灵活高效的为企业提供高质量的 IT 服务。

从治理到管理 - 服务的注册制和核准制

我们都听说过服务治理这个名词，也知道治理很重要，但是治理和管理到底啥关系？关于这个话题，要想讨论清楚我们需要引入一些的概念，为了更好的了解我们要说的这个话题的本质，我们需要追溯到问题的原点。

为什么要形成组织和社会？社会分工是什么？

与他人合作是我们形成组织的基础，形成组织的目的是更好的、获得更大的收益。举例说明：假如 AB 两人，在合作之前每人的净产出是 1（记作 A=1,B=1），如果合作之后两人的净产出小于等于独立净产出之和（A+B<=2），那么凭直觉就可以判断这种合作是维持不下去的（组织败坏）。所以，AB 合作的必要条件是 A+B>2，即合作净产出大于独立净产出之和。

为什么社会分工变得越来越细致越来越普遍呢，答案就是因为精密分工会导致 A+B>>2，也就是远大于独立产出的总和。举个例子，一个自然状态的人，凭个人能力每天工作 10 小时可能只能抓到几只兔子，想独立的去狩猎大型动物基本不可能；但是两个分工合作的猎手，通过埋伏、驱赶等协作策略，可能每天花 8 小时就能捕获几只羊。这个例子中，合作的人付出的劳动时间减少了，收获（或称为分工红利）却远大于独立状态，所以社会分工就成为人生存的必然选择。

当然，社会的形成远没有这么简单，社会分工合作只是其中的必要条件之一。

形成组织的要素——对自由的让渡

两个纯粹自然状态的人是无法形成合作的，这是因为他们拥有最大限度地自由，他们可以随心所欲的做任何事情，甚至杀死合作伙伴，因此合作随时都可能被破坏掉。那么组织就出现了，组织是合作的产物，同时进入组织的所有自然人必须让渡部分自由（比如随便杀人的自由）。社会是一个巨大的组织，愿意进入社会的自然人必须让渡大部分自由，并自愿将自己置于法律之下。

这样，在组织内部就会形成一个个的机构，用于管理自然人让渡出来的自由。根据人类历史社会实践的经验，我们可以知道，分工红利的大小和对自由让渡的程度是相关但不是线性的，随着自然人对自由让渡的扩大获得的收益也会急剧变大。但是随着自由的让渡加大权力也会的不断集中，分工红利会达到一个峰值，随后权力过渡集中导致的败坏就会削减分工红利，如下图：

组织的缺陷以及架构的引入

形成组织可以利用社会分工来产生巨大的分工红利，但是也可能会因为组织的不合理导致败坏，于是组织引入架构来进行平衡，这就带来了我们最开始讨论的架构之争。IT 是为组织服务的，IT 架构也是为组织架构服务的，什么样的组织架构就决定的什么样的 IT 架构。我们的 IT 架构总是在一遍遍的轮回，从分散到集中，再从集中到分散，每次变革都有非常堂皇的理由，这就是我们常说的一抓就死一放就乱。所以，我们现在从另外一个角度来理解架构之争。

注册制与去中心架构

无（去）中心架构出现在组织创建之初，组织的业务目标不明确，方法论不确定，甚至连对错都在争论之中。这个时候，组织需要通过试错的方法来确定目标和方法论，这样组织应该最大限度地释放自由，让每个人都有可能去创新，从而在最短的时间内解决共识问题。

这个时候，组织是一个非常松散的管理中心，除了杀人放火这样破坏性的行为被禁止之外，几乎所有行为都不会被禁止，这就是注册制。每个个体向组织提交业务行为必须的材料，组织只进行材料是否虚假、误导或有遗漏等形式上的审核，但是对材料实质的内容不做任何限制，哪怕这些东西看起来毫无商业价值。

核准制和中心架构

但是一个组织不可能永远没有方向和成熟的方法论，随着组织对业务不断的理解，弱中心就会向强中心发展转化。个体的自由度不断地被削弱，组织对个体的干涉逐步从形式上的审核，过渡到对实质内容的干涉，这就是核准制，核准制带来了强制管理的需求，同时也带来了效率的几何级数提升，比如我们看到的工业流水线大工业生产替代传统手工工业作坊。

混合制和多中心架构

绝对的注册制事实上放弃了合作红利，而绝对的核准制可能会导致败坏，其实现实社会都是混合的，完全极端的架构都是不存在的。

组织内往往希望通过加强管理的方法，让相对成熟的业务更成熟，从而获得最大限度地合作红利，这里管理是强制性的核准制；而对希望拓展的不成熟的业务，就会放开管理的束缚，给予业务拓展者最大限度地自由，甚至连目标和方向都不限制，这就是宽松的注册制。

那么一个企业就是这样一个混合体，无论企业的规模和成长阶段。组织会根据业务的成熟度和分工职能划分内部机构，形成不同松紧度的架构中心节点，这种对组织架构的调整就导致了组织治理的产生。

从治理到管理

综上我们看到，企业组织形式的一个必然趋势就是从注册制走向核准制，这标志着一个企业的从草创到逐渐成熟稳定，这个过程就是从治理走向管理的过程。管理和治理之间的区别和联系在于：

1. 治理是非强制性的，是一个循序渐进的过程。管理是强制性的，是已经成熟的固定业务流程和规范。

治理关注对业务方向性的引导，管理者并没有足够的经验告诉业务的实现者如何去达成业务目标，所以管理者在治理阶段只能尽可能的给出方向和方法论上的指导，并用一系列的手段（比如激励、考核等）引导业务实现者不要偏离既定的业务目标。所以，治理会贯穿于整个业务发展的过程之中，不断的优化业务发展。

管理往往是一些经过长期社会实践被验证的经典规范和制度，比如财务制度。依照这些经典制度，企业在大部分的领域无需去探索，只需要按照经典理论经验去执行，就可以非常高效的实现业务需求。
2. 治理过程中会不断的形成管理规范

对于企业特色业务来说，治理是从创新中形成生产力的一个必要手段。我们不断的进行假设、实践、试错、纠正这样的迭代过程中，对被证明是正确的方法进行综合抽象，并固化到管理流程中去，从而逐步缩小治理的范围，扩大管理的覆盖度，最终形成成熟的、理想的业务模式。

S++ 服务治理

机器最终取代人力去完成不需要创新的事务性工作，这是历史的趋势和必然，我们谈论的不是科幻，而是在加速到来的现实。越来越多的自动售货机，无人值守停车场，自助超市等等。现实的社会有史以来就是被虚拟社会所规范和管理的，比如我们写在纸张上的法律，我们签订的各种合约，流行的各种商业规则和商业模式等等。

IT 在其中起到的作用就是让虚拟的规则更彻底和精确的被执行，由于人的非理性存在所以人作为规则执行的载体是不可靠的，比如你可以贿赂交警但是你无法贿赂电子眼。作为一个企业，IT 化程度越高那么它的可量化程度就越好，如果能够把一个企业中所有的行为抽象为服务，并建立稳定的模型，那么其生产率将会得到巨大的提升并极大的降低败坏的产生。

微服务需要治理吗？

从目前的理论和实践来看，微服务架构是不强调服务治理的（甚至可以说没有服务治理）。微服务架构更关注系统的自由程度，按照前面分析的结果看，微服务架构属于注册制的组织形式。但是，我们知道任何组织需要让分工产生合力创造更高的价值，就必须进行组织规划，放到 IT 系统这个环境来看，就是说约定系统边界、系统间交互接口、策划业务流程等等这些必要的需求。

所以，放任绝对自由的微服务不是一个正确的选择，对微服务进行逐步深入的治理是 IT 组织架构的必然要求。

什么是服务治理？

简单说，服务治理就是独立于服务系统之外的，以服务模型最优化为目的的组织化行为。

无论是对于大服务还是微服务来说，每一个业务系统都可以看做组织内部一个独立的个体，他们每一个个体都首先对自己负责，试图获得组织内最大的自由度。相对应的，为了这些个体之间更好的分工合作，必须有人能跳出自己独立的业务系统，从组织整体的视角来看问题，这些人就是服务产品经理。

运用 S++ 的方法论，服务治理在整体和个体之间建立了业务与技术分离，对于组织而言服务治理提供了纯粹的业务语言描述的服务模型，对于个体（业务系统）而言服务治理提供了业务到技术的规则映射和差异适配。

服务治理的目标和组成

服务治理的执行可以是自上而下的，也可以是自下而上的。

自上而下的方式适合于全新的企业，组织可以按业务条线划分治理团队内部成员职责，每个人作为相关业务的服务产品经理负责组建相关业务条线的业务系统，治理团队内部整体的服务模型由各个服务产品经理相互妥协形成。然后，服务产品经理或自己组建开发团队，或技术外包或通过整体采购的方式来完成服务模型的落地实现。

自下而上的方式适合于有大量存量系统的企业，组织可以采用类似代议制的方式由各个业务条线自己选举服务产品经理，这些产品经理成为各个业务条线在服务治理团队中的代理人，由代理人之间的协商妥协来形成组织整体的服务模型。

总的来说，服务治理对组织负责的同时，每一个业务代理人（产品经理）也会对自己的业务负责，这个过程就是个体让渡自由的过程。其目标就是建立有利于组织效率最大化的模型，从而使每个个体获得最大的利益。

小结

本章从宏观的角度探讨了服务治理与组织目标和架构的关系，从另外一个视角重新审视不同的架构。从 SOA 实践的历史看来，SOA 架构强硬的要求各个业务系统进行统一的规范性管理，这不符合组织自然发展的客观规律，所以必然造成反弹；而反弹的结果是走向另外一个极端，微服务架构采用了完全的去中心化。

因此本文的结论是，更均衡的多中心的架构才是适应组织各阶段需求的一个普遍架构。另外，架构是需要人来对应的，对应多中心架构本文提出了服务产品经理这样一个新的角色。

S++ 的特性赋予了服务产品经理在业务和技术之间桥梁的作用，并且更明确的是，企业的核心资产不是一个个的业务系统，而是独立于业务系统之外的业务服务模型。业务系统不过是模型的某一个实现，随着技术的进步，实现是可以随意替换的，不变的是企业长期沉淀下来的或者创新的业务模型。

作者介绍

李东，14 岁开始学习计算机语言，作为课外兴趣自学了 BASIC 和汇编，利用放假期间编写了贪吃蛇、打飞碟等游戏。高中、大学期间继续自学软件编程，曾将 C 和汇编结合使得从高级语言中能够调用绘图功能，并模仿 Borland C++ 开发了一套适合学校机器的图形化开发环境的原型。

93 年大学毕业后在西门子合资公司作为交换机软件安装人员工作两年，然后来到 JInfonet 公司先后参与 4GL 的研发和 JReport 的研发。作为 JReport 的第一代主要研发人员，编写了从原型一直到 3.0 版本的核心引擎部分。2000 年与合伙人一起创建了 Bi-Soft 公司，主营业务是商业智能软件 Bi-Pilot，负责整个产品的研发及管理工作，从最基本的查询一直到多维分析模型和引擎都是产品的涵盖范围。

2007 年 Bi-Pilot 被神州信息收购合并，李东开始在神州信息研发 SmartESB 产品，用 SOA 的方法论为客户提供底层产品服务。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。