赵鹏从这之后，越来越多人发现白山科技的价值所在，从而影响很多人的选择。
白山云合伙人
it经理人联盟特邀演讲嘉宾
很高兴有这个机会跟大家分享一下在中国的数字化转型里面，我们以api视角入手探索的一些最佳实践。从api的角度来说，这个api跟我们在十年二十年前认识到的那个“api”有什么区别，为什么在西方国家尤其是以英美为首的国家api大行其道，包括我们构建的这个“api战略中台”的产品具体是什么，以及我们这几年积累的一些成功案例和最佳实践跟大家分享一下。
刚才也听到了很多cio的分享，大家谈的最多的是在数字化转型之下cio这个角色的转变，中间的“i”从首席的信息官到首席的创新官再到首席的协作官，最近这半年很有意思的一件事发生，我发现美国现在又开始重新定义cio中间的这个“i”，它叫“imagination”。我做了这么多创新，我不缺技术，在座的cio不缺人脉，不缺甲方乙方的资源和最佳实践。我们走向业务的时候更希望往前跨一步，我们有很多的想象空间所以叫首席想象官。
首先数字化转型各位最清楚，它最重要的一点就是客户体验的升级，所有业务的转型，我们的数字化都是为了我们的客户，不管我们的客户是b2b模式还是b2b2c，最终都是要客户或者最终用户的体验感受升级。
另一方面cio每年这么大的it开销，都开销在什么地方、换来了什么？最终可能想象力最大的一个空间就是在收入的增长，其实这有两个纬度：第一个增长是在原有的赛道里怎么通过技术能够实现一些降本增效，同时能让收入有增长。
第二个是通过我们创新的技术跟我们生态的思维，能不能在现有的赛道上扩充，再开辟另外的赛道，在整个数字的生态，我们是不是能创造更多的收入来源，跟我们的合作伙伴增加收入。
除了降本增效以外，我们的cio在应用那么多新技术的时候，首先面临的挑战就是你的风险到底在哪儿？五年前大家都是很快的失败很快的再往前走，我们能再掉头调整方向，从而走到正确的路上，这对风险的控制和管控，在创新的时候必须要有一定的风险意识。
其实我们看到这几项与其说是cio更关注的，其实更多的是企业的ceo或者企业的董事长，或者董事会最关注的问题。这些问题跟cio联结在一起的时候，其实无所谓转型的道路了，我们就自然而然的，就像我们做产品一样自然而然的迭代，迭代是我们的职责。
说到底，cio是我们很美好的诗和远方，不可否认的是在座的cio有的已经偏向业务了，或者其他的角色，但是大部分仍然还是管理it的团队。有了诗和远方我们一定会面临眼前一些没被解决的“苟且”的事情，那就是我们要业务落地、创新落地，一定会涉及到一直没被解决或者没解决的很好的问题，可持续交付能力一直没有得到很大的发展。
具体来说就是it的需求，内部是企业的平级部门、分/子公司、收购的部门，很多可能也来自于it部门本身有科技创新、it创新的需求。更多的是来自于我们的合作伙伴，供应链的上下游包括我们的客户。他对我们it提出了很多的要求，这个时候it一直在增进我们的能力，云、大、物、移各种各样新的技术我们都在应用。有越来越多的技术在应用，对我们的需求越来越多，我们可持续的交付能力并没有等比的往上涨，这个就回到我们从世界的角度来讲，it首先一定会有一个旧世界，这里面是老系统，涉及到我们数据的格式不一样，调用的方式也不统一，系统跟系统之间的耦合性，还有架构风格的不同。新的技术跟老的技术如何能够衔接在一起，异构的问题怎么解决，我们说创新其实恰恰就是说我们的新技术不在于应用了多少，而是说我们是不是能应用正确的技术解决一个现实的具体的问题，这个其实才是我们所创新的，并不意味着我们应用了云大物移我们的it技术就创新了。
再往下落一步就是在座各位专家最熟悉的系统架构风格的改变，从九十年代初期大家做的是点对点的互连，这里我们叫紧耦合，系统和系统之间就像齿轮一样紧紧的咬合在一起，这个时候系统之间是孤岛的，谁跟谁都是割裂的。第三个系统、第四个系统放在一起点对点的集成这个事就做不了了，到了2000年的时候soa架构出现的时候，最典型的代表叫esb的产品。soa的架构到今天仍然没有错，仍然是我们追寻的方向，但是问题在于这种总线的技术要求对系统强的耦合性，而且对于原厂代码的依赖，对于我们调整起来的困难，包括接口的方式，用特有的协议跟系统做对接的时候，都造成了企业集成或者应用创新的时候很困难。
到2015年以后，soa架构做了进一步的升级，就是微服务，系统的方式从紧耦合过渡到了松耦合，到现在的解耦合，现在又有一个名词重新出现在it的世界里，就是api，这个时候不是一个接口而是一种架构的风格，这种架构的风格实现解耦也好，非侵入的方式跟自主的创新，把it的能力交到it团队手上而不是交到厂商手上，这个时候应运而生的api开始大行其道。idc在今年第一季度出的时候就提了一个预测，在2021年的时候，70%的cio将通过api连接他所有的系统进行敏捷的连接，连接的是什么呢？连接企业内部的系统、外部的合作伙伴、创新的解决方案以及各种架构的应用。
gartner也预测，在2022年的时候65%的企业会应用api战略，其实就是今天我们的主题，尤其我们在座的cio不仅仅应该把企业的api当成一种技术，一种参数，一种指标，而是更多的变成一种商业模式，一种数字的战略跟整个生态系统的底层的核心的平台，作为一种基础的核心平台来建设。听起来api战略好像很吓人，其实并不是。先举一个简单的案例跟大家分享一下，我们在服务某大型制造业集团，规划它的api战略的时候，通过四期或者三个大阶段的方式来规划，第一个阶段其实很小，就是把它的it能力补足。一开始我们找它两个相对做起来最简单的hr系统和它的业务接口平台集成，解决最难的两个点对点之间的集成。
第二期我们把财务的模块，包括各个板块的业务系统跟它的业务，把它集成上来，第三期基于此来构建它整个api的生态，最后把这个能力开放出来。
具体是什么呢？其实也很简单，各种供应链的系统、生产制造的系统，可能分布在云上，可能分布在本地环境，也可能是中国的阿里巴巴，这么多的系统分散在云上云下，以及各个厂商的不同系统，比如sap在跟非sap集成的时候，it人员可能无法非常有效的完成这个工作。那么怎么办？我们规划了一个api的战略中台，把各个异构系统之间的数据和业务逻辑集成，当它开放它的app给它的合作伙伴一个创新应用的时候，就在中间这个平台里通过所有的点选拖拽式的工作来完成。
一期的时候涉及到六个系统，七大部分的hr的能力，这一个个场景串起来解决了企业最重要的怎么样快速做交付，快速做集成，快速做创新的问题，这里面涉及到一期里面超过45个接口，跟云上云下的环境。到我们现在做到二期的时候开始构建以sap、bpm的核心能力，做这个能力中心，通过api的方式，它是分步而走，一开始很小，慢慢逐步扩大。
这里讲的最多的api，api到底是什么？从我们的角度来看，从能力可以分成四个纬度，最简单的我们说十年前的时候api只能做有限的，实现一个数据的存储。到基础跟高级的时候它可以做数据的转换，到基于微服务架构的api的时候做数据的集成、编排，基于soa的方式。从企业的外部来看，生态的角度来讲，api就分两部分，一部分对内，对各个分/子公司，对我集团的各个平行部门，对对外我们的生态，对合作伙伴，对我们上下游的供应商，对我们的客户，这个时候我开放的不只是一个数据的调用，而是一个业务逻辑，这个业务逻辑后面可能对应十个二十个系统，无数复杂的数据和逻辑之间重新的组合和编排。
没有api中台的时候企业可能遇到更多的问题是这些异构系统之间的协作是不是变的更多，我们说这些bi也好，因为有的朋友在讲bi，讲我们的驾驶舱，这些数据都来源于各种不同的异构系统之间的数据要做组合，要做集成，是不是我们各个系统之间的数据也存在非常规的调用方式，如果有的话其实api的中台提供的就是一种把以前从最低端的系统到中间件再到上层的ui、ue的展示，之间完全紧耦合的数据业务开发的模式把它进行了升级。我们在企业以后可能就看不到erp了，看不到企业的oa系统，看到的是一个一个能力的api，比如支付api、搜索api、crmapi，进到战略中台里面都变成一个一个的能力中心，当我要交付一个b2b应用的时候，比如一个ar/vr跟企业生态合作伙伴的对接，比如一个crm的系统跟汽车、保险公司是不是能直接结合上，其实我交付的是一个能力，通过中间自定义的服务编排，编排之后交付的就是一个一个的能力，它其实解决的就是当我们做随需而动的应用的创新的时候，可以很敏捷、很灵敏的，而且中间的所有api中台的部分都是一个个组件，超过三百个组件都是拖拽的方式，可以达到很完美的复用，这就是从api入手的中台给大家带来的价值。
从战略就一定要有实施的阶段，其实我们把客户的战略分成四个阶段，第一步我们在制造的api，第二步我们重新组合，第三步是我们做的货币化，第四步我们说把api的市场化。在制造的部分在设计api的时候是以复用为最终的目的，复用就是我们生产的api并不是我们的目标，我们的目标是为了使用。使用就一定要有复用率，如果api得不到复用，一定程度上api战略就失败了。
这个时候我们在企业里解决的是一个很具体的问题，比如两个部门、两个系统之间的接口频繁调用，没有管理、没有组织、没有授权、没有控制等等。在第二步，我们关注的就是跨服务，服务api定义出来之后，这些服务之间怎么重新组合，提供给企业一个新的业务逻辑，一个行业是一个生态的模式，这个时候我们解决的问题是在企业里，重点关注的是企业里内部集成的效率如何变的更高。
第三是api的货币化，这不是指收取两毛或者三毛api调用的费用，更多的是把api作为一种生态的探索，一个合作伙伴触达的对象去看。就像说我们云计算的公司，谷歌、亚马逊跟微软，都是通过api把它所有iaas层的服务去卖给它的客户。企业是不是也可以把它的能力，比如说在地产、汽车，在制造、物流，都可以通过这种方式来实现。这个时候我们更关注的是解决别人的问题，而不是自己的问题。
最后一步说市场化，这个还有更长的路要走。我们设想有一个api的市场，能够让大家把我的能力注册上来，我可以提供付费，同时调用方可以进行付费，中间的平台运营商可以通过运营的方式来分成。从美国来讲这个仍然需要很长的时间，我相信在中国也一样有一条比较漫长的道路要走。
讲完了api战略通过四步怎么从最小一点一点做大，那它是如何落地的呢？是通过在人员、流程、产品之间做一个平衡或者做一个聚焦，人员是定义我们的api战略，流程在四个阶段怎么样让它进行精细化设计，同时再落地。包括有什么产品，会用到支撑我们api整个的战略，包括输出的运营的文档、技术规范、应用指南等等。
再往后，跟大家简单分享一下，我们定义的api中台的产品，它基于的三层架构，第一层架构是基于现在企业所有的系统、数据库、各种的服务，我们把它api能力化，这个是做的解耦，在中间的平台里实现拖拽、点选式的编排，我们叫服务的编排，编排的就是数据加逻辑，其实就是企业的业务，之后我们把它作为能力开放给我们的合作伙伴，开放给我们内外部的生态。基于此实现整个的产品化，通过我们对接各种企业内部的系统，在中间我们生成各种能力中心，比如我们这些第三方的服务中心、运营的中心，包括对接bi的数据展现的中心、流程的中心，之后再把它开放给我们前端的应用系统，比如bi、bpm、合作伙伴等等。
这里面从三个维度，谁是api或者服务的生产者，谁是管理者，谁是api的消费者，也就是我们的使用者，都可以通过我们不同的权限分别把它定义清楚。
从产品的角度来讲，第一就是设计中心，设计中心其实提供的就是7大类13小类超过300个拖拽、点选、复用的组件的方式来构建企业的业务，这个其实是对传统的it研发人员写代码方式的一种升级。再之后这些api这些服务如何去进行管理，进行管控，包括我们说项目环境跟多租户的控制，里面有各种维度的监控、报表、展现中心，以及我们是不是能够开放我们做api的门户，开放给我们各个需要调用的使用者、管理者和生产者，中间是有一个运行时，把所有的组合放在一起，用容器的方式来实现。
简单的分享一个案例。天正电气，我们的伙伴碰到企业架构的问题，点对点的连接，调用获取的方式不统一，交付的周期太长。客户问六个月交付的项目能不能六个星期完成，对厂商的依赖程度又很大，api中台正是解决这样的问题。在现在的时间里我们可能超过了将近200个api部署，里面有些调用的信息，包括一些跨平台、跨企业的，包括对接aps、srs这些系统的集成跟展示。交付之初给我们的伙伴设置了七个编排流程的api，交付了30个，到五个月的时候他已经自主编排了100个业务，五个月的时间已经自己有能力运营整个api的中台产品来交付企业的业务。从数据交互，原来是20万条被宕机，现在怎么保证平台的稳定性，包括我们现在想的新应用场景如何在供应链的协同等等新的业务上能发挥它更大的价值。
这是我们这几年积累的一部分的客户案例，行业的客户一直在帮助我们不断的成长，打磨这个api战略中台的产品。
api战略中台其实并不是我们作为一家产品制造商的战略，而是在座的cio企业的战略，如何把战略中台从小到大慢慢发挥它的价值，我相信这里面需要更多的工作，有很多我们需要跟在座的各位请教学习的，如果大家有兴趣的话可以加微信我们会后可以一起跟大家畅想，谢谢大家。