企业API战略的八个思维误区

无处不在的API即将引发软件工程的一场革命

今天人们出门最不会遗忘的就是手机了,手机俨然已经成为我们身体的一部分。实际上,不仅仅是手机,还有更多的移动智能设备已经进入到我们的日常生活之中。这些设备加上云服务和人工智能,正在为客户创造出了前所未有的体验。

正是现代的API让这些曾经不可能的事情成为现实。同时 API 也成为了数字经济时代的基础设施。

越来越多的企业已经认识到,API对于企业数字化升级非常重要。有些企业已经开始制定API战略并付诸于行动。不过在启动 API 战略之初,很多企业还是走了 不少弯路,犯过不少错误。

比如依旧沿用传统的项目模式来开发 API,这就是一种非常普遍的错误。这样做一定会阻碍API发挥出应有的商业价值,也很难将 API 战略与企业整体战略默契 起来,最终一定无法真正推动企业的数字化转型升级。

下面列举出八个常见的思维误区,希望对企业的API战略规划和实施有所帮助。

一、新技术老思维 

传统的思维习惯要改变确实很难。

过去十年里,企业 IT 系统的投资实际上是在解决再之前的遗留问题。这十年的IT工作重点是系统整合和数据资源整合。

而今天,企业面临的挑战却是如何提升业务敏捷性,如何快速地应对市场变化,如何更好地为客户提供服务。

那些习惯于系统整合的技术人员,无论是他们的技术能力还是工作流程,都不太能适应当今的业务节奏。单纯的系统连接和数据集成,已经无法满足前端应用的快速变化和发展。

以数据抽取为例,过去的做法通常是对既有应用进行反向工程分析,进而直接 访问数据库。而企业API的方式完全不同。让应用系统以自有的结构化方式对外提供数据服务,既避免了粗暴的数据抽取过程,同时也为深入的数据分析和流程提供 了可能,而且还可以提升新应用的开发效率。

如果企业仅仅把 API 看成是IT工具的话,API 的价值也无法充分地发挥出来。 怎么判断企业对API的看法呢?其实看看企业管理层的KPI考核体系就一目了然了。如果考核体系中没有关于如何利用 API 来提升客户体验,没有关于如何利用 API 连接更多的合作伙伴,没有关于利用 API 优化内部流程等指标的话,多半就说明管理层对API非常局限了。

API 早已成为了超越IT范畴的热门话题。而现代 API 更是以一种形象的方式, 帮助使用者利用企业的能力和数据资源。API 可以让企业和客户、企业和合作伙伴 以及企业和开发者之间,进行全面实时的业务互动。这也是为什么 API 已经被看成是企业重要商业资产的原因。API 战略成功的关键,不在于企业拥有多少 API,而是 有多少企业API切实发挥了作用。

成功的企业把API看成是产品,而不是一个一个的项目。企业把内部和外部的开发者看成和客户一样重要。企业极力去吸引他们、取悦他们并维系长期紧密的关系。

成功的企业还把API看成是渠道。通过制定市场推广计划,企业试图让API最大程度地延伸市场覆盖。

一些企业对API的理解甚至超越产品和渠道层面。他们有更大的野心,要通过API来构建一个商业生态系统。

产品和渠道其实还是传统商业思维的范畴,强调的还是通过生产销售的规模获 得成本优势。但是今天,能够主宰生态系统的数字化企业,他们才具有绝对的竞争 优势。他们基于网络思维进行战略布局,所谓网络思维,讲究的是尽可能多地连 接,连接得越多、被使用得越多,就越有价值。生态系统的网络效应一旦被激发, 投资也将获得几何甚至指数倍的回报。

二、领导力不足

更积极更强势的领导会极大地提升 API 战略成功的几率。过于内向温和的人, 恐怕很难推动 API 战略的落实。

千万不要以为只要开发好 API,自然就会有人跑来主动使用。要推动企业API的发展,就要主动去和其他部门协同起来,充分地满足 API 使用者的需求,并且对 他们的支持和服务要到位。

企业 API 负责人应该从“由外而内”的角度看待 API 的开发。所谓“由外而 内”的意思是,应该从API使用者的角度开始设计API,然后再考虑API的具体开 发实现,这才是开发API的最佳实践。

此外,API 战略要不断迭代发展,也需要足够的资金支持。企业API战略负责 人需要有能力获得充足的预算,如此才能保证API体系的建设。最好把企业API预算从传统的 IT 项目预算区分开来。之前谈到过,企业更应该把API看成是产品,既 然是产品就需要不断的迭代开发,也需要像产品管理那样的预算管理方式。

企业 API 战略要想成功,还需要推动企业文化和思维理念的转变。无论是工 具、技术和流程,还是员工的观点,都必须转向新的思维模式。企业API战略负责 人一定要有足够的能力,这样才能够推动这些变革,推动新的企业文化建设。

三、错误的考核指标 

对大部分企业来说,常用的指标其实无非是收入、利润、客户满意度和创新能 力等等。随着行业的格局改变,企业数字化成熟度也逐渐成为了新时代重要的绩效考核指标。

API 战略正在为企业带来持续的增长动力和价值。因此对API的考核也应该纳 入企业整体KPI体系中。但是API的考核体系与传统IT工作的考核体系不同,我们 要规避一些常见的思维误区。

简单地以开发了多少API作为一个指标,这可不是一个好主意。不管是10个还 是100个API,这都不是最主要的。开发了多少API和创造了多少价值并不能直接 划等号。一旦以 API 的数量作为衡量指标,那么用不了多久,就会有一大堆 API 冒 出来,但是再多的 API 也许都不会创造什么真正的价值。

实际上,用任何一个孤立的指标都会导致偏颇。比如不应该以单独用直接收入 作为指标,因为 API 毕竟更多的是支持手段,常常需要和整体业务流程配合才能创 造收入,还可能是间接的收入;单独用成本节约多少做指标也不合适,API 虽然可 以提升价值链效率,但是在某个具体的局部未必总是降低成本。

一个经常犯的错误是把 API 看成独立的业务单位来考核财务损益。这样做很容 易让 API 游离于核心业务之外。这种方法如果用在传统IT系统建设也许是行之有效 的,但如果用在考核API战略上,就显得不合时宜了。

在当今互联网节奏的市场环境中,对 API 最重要的衡量指标也许是速度。只有 关注敏捷性和响应市场的速度,才可以帮助企业聚焦商业价值创造。

API 是数字价值链的核心技术。无论是企业自己的移动应用和网站,还是合作 伙伴的应用,都可以通过调用企业 API,获得数据资源或者业务处理能力。要实现 这样的目标,企业 API 必须精心设计,还要安全稳定并且性能卓越。与此同时,企 业后台系统的能力也必须要相应地提升。

围绕价值创造和速度的综合指标,才能够更好地衡量考核API。恰当的绩效考 核体系也会反过来进一步推动 API 的发展。

如果考核API的开发速度,开发团队就会更及时地响应市场需求;考核开发者 规模的发展速度,开发者门户的易用性、审批速度、服务响应、业务授权和文档品质就会有所提升;考核API的调用规模,API的性能、稳定性、可靠性就更有保 障;考核API的重用数量,开发团队就会集中力量整合那些关键的业务系统;考核 合作伙伴的数量,企业的生态网络就会蓬勃发展,API 团队还会推出各种培训、活 动和比赛来激发合作伙伴的热情。

总之,只有围绕着创新速度和商业价值来综合地制定考评体系,企业才能够更 好地发展 API 战略。

四、不恰当的工作方式 

API的开发和传统 IT 项目不一样,不要动不动就花费几个月来写可行性研究和需求文档。API 团队需要做的事情是快速原型设计,和客户密切的沟通,以及经常 性的 A/B 面测试。

API不但需要持续不断的迭代开发过程,还需要快速灵活地响应来自企业不同部门的需求。API 团队应该由来自不同领域的专业人士组成,诸如产品管理、架构 设计、API 开发和系统集成。拥有这种具有综合能力的团队,才能够敏捷地应对随时产生的新需求。

然而很多企业的API团队却依然沿袭既有的 SOA 工作模式。他们过于强调集中式的管理和控制,而且总是追求标准和完美。这样的做法很容易让API团队成为瓶 颈,难以响应快速的市场变化。

 成功的API团队架构是复合式的。既有集中的协调,又有灵活的特性;既能够鼓励主观能动性,又可以标准规范的执行。

对于标准的过分追求会导致分析纠结症。有些企业号称要实施 API 战略,却一直在反反复复地讨论标准、规范和流程,结果迟迟无法真正启动任何实际行动。

 而成功的企业往往是先启动起来,再逐步完善。基于适度的访问控制,尽早地开放后台系统数据,让开发者先用起来,先去满足业务需求,然后再逐步地根据实 际需要制定相应的标准。

优秀的 API 团队总是有些共性。他们可以从管理层获得强大的支持,有充足的 预算和资源;他们明白 API 可不仅仅是关于架构和技术,更是业务的加速器;他们 愿意去培训其他的团队,让他们更多地参与到 API 战略中来;他们直接和业务部门 交流,努力去理解商业目标和计划;他们更积极地协调企业内部资源,大力推动 API 战略的落实和发展。他们主动总结 API 开发管理的最佳实践,并在企业内部推 而广之。

五、缺乏投资的决心 

发展 API 既可以帮企业更好地整合系统资源,又可以快速应对瞬息万变的市场需求。但是如果缺乏充足的投资,再好的目标和愿景也无法实现。

我们反反复复地强调,API 不仅仅是 IT 战略,更是业务驱动的企业数字战略。因此不能把对API战略的投资,直接等同于传统的IT投入和资本开支。

没有资金承诺的 API 战略注定不会成功。口头上唱着API战略的高调,实际却 没有真的落实预算,那么一切都只会是空谈。

另外,很多企业习惯对所有的项目单独评估其投入产出。项目的预算也往往会 来自项目的收益部门。但是由于API的范围很广,会涵盖企业的方方面面,如果还是按照这样的模式处理API的预算,就会容易导致预算来源纠缠不清。

更合适的处理方法是将API作为战略性投资,进行单独的预算管理。

企业的战略投资不应该被短期的利益牵制。API战略可以提高企业的敏捷性、 加快市场反应速度,并提升客户体验。这些都是长远的战略性目标,不仅仅是眼前的具体收益。

就像股市投资一样,一旦确定了长期上涨的趋势,就不要过于关注短期的波 动。众所周知,长期投资策略的三个原则是:尽早开始投资、要不断的投资并设计投资组合。这样的投资策略和企业对于API战略的投资其实非常相像。

六、不合时宜的开发流程 

要用产品思维来开发API,更要取悦使用API的开发者。

开发API时,别一开始就试图堆砌太多的功能。功能越多,API的独特性和价值就越难说清楚,也更难在应用场景脱颖而出。

如果企业仍然采用传统的瀑布式开发流程来开发 API 的话,那就与现代API轻量级和快速灵活的创新原则背道而驰了。

API一定要走敏捷开发和不断迭代的方式。很多企业在写第一行API代码前, 总是纠结太多的设计细节。这样的方式对于API的开发并不合适。

在遵循核心设计原则的基础上,企业要更加务实地专注在 API 的一致性和开发者体验上。现代REST风格的 API 为什么广受欢迎?就是因为用 GET、PUT、POST 55 和 DELETE 这种简单的动词,可以更直观地表达出 API 的能力。此外,与核心功能 一致的命名方式也可以给开发者提供易懂易用的体验。

发布API之后,企业就可以通过分析 API 的使用情况,获得实时的用户反馈, 企业应该基于这些信息不断改善 API。

企业的API门户也是和开发者沟通的好渠道。通过API门户,企业可以很容易 地得到开发者的建议,并随时进行调整。

七、过于苛刻的治理管控 

早期的 SOA 体系强调统一的系统架构和尽善尽美地治理。但是这样做常常容易 脱离应用开发的实际情况。

而今天的应用开发者,他们大都是互联网一代的技术人员。他们更追求快速、 多产和灵活。一个 API 从设计到投产,可能必须在几个小时内完成。如果在过于苛 刻的治理体系里,这样的目标可不容易实现。过严的治理会削弱 API 开发的敏捷 性。如果还是延续传统的瀑布开发模式和追求完美的项目管控,再加上追求一步到 位的项目目标,就很容易让企业 API 战略胎死腹中。

成功的企业都是通过迭代和不断的优化,来逐步提升品质和开发者体验的。尽 快地创造商业价值才是关键。所以企业一定要转变传统的开发思想。只要可以在实 56 践中动态调整,企业就能应对 API 发展过程中的挑战。先做起来!让 API 团队从苛 刻的管控体系中解放出来,开发和推进效率就会大幅度提升。

一定会有人担心宽松的管控会带来风险。实际上,我们可以通过好的的方式方 法来消除这些顾虑。API 管理平台可以帮助企业提升 API 治理的能力。API 平台可以 给每一个使用 API 的应用颁发安全密钥,并提供工具实时地分析 API 的使用情况, 包括使用 API 的应用数量、API 的访问量以及一些关键数据指标。这样一旦发现问 题,企业可以随时屏蔽掉带有恶意企图或者具有攻击目的的API使用者。

成熟的 API 管理平台还提供更多的安全策略来提升整体的安全等级,诸如身份 验证、威胁保护和流量管理。其实,API 技术在本质上就会提升企业信息安全的管 理能力。

宽松的治理并不意味着没有治理。API 的设计和开发是在基于身份验证和治理 规则的前提下来提升可用性和一致性的。只是这些标准和规范要尽可能精简,尽量以快速响应市场为目标,让 API 在迭代中逐步完善和完美。

八、过于迷信开源 

如果用百度搜索“API 管理平台”,可以得到超过 1,200 万条搜索结果,其中的 前 10 页里,至少 70%的内容会是关于开源免费的 API 平台。相比较传统的ERP和CRM,API领域的开源代码显得更多更杂。

如果自身是科技型企业或者互联网企业,开源也许是好事情。研发本身就是这 些企业的核心工作,免费开源恰恰可以满足互联网创业型企业的早期诉求。基于开 源的API管理平台代码,企业至少可以省去一些摸索成本,也可以加快自有平台代 码开发的速度。

但是且慢!对于大部分传统企业来说,过于迷信开源就不一定是好策略了。毕 竟企业的战略重点是发展业务,而不是给技术极客搞科研。既然是搞业务,就不要在 API管理平台这种专业性很强的工具上花钱花精力,更不要拿公司整体战略的成 败开玩笑。那些经历了市场考验并且技术成熟的商业化 API 管理平台,其实才是企业API战略的优先选择。

免费的 API 开源平台看似很美,但是整体成本却是无底洞。

比如 MuleSoft的Anypoint平台,其本身自带超过300个连接器,直接就可以连 接几乎所有企业常见的数据库和 ERP、CRM、HRM 系统。试问如果企业自己开发这 些连接器,需要付出的多少人工成本和多少时间呢?

理论上讲,商业化的 API 管理平台功能确实并没有多少尖端科技的壁垒。有些 年轻的程序员也许会信誓旦旦地说,只要5个人6个月就可以开发出一个差不多的平台。先不论开发出来的成果如何,就说这30个人月的人工成本也是一个不小的数 字,说不定和商业软件的成本已经不相上下。可一个是试验室的研发成果,一个千锤百炼的商业化产品,哪一个才能够成为企业赖以支撑的基础建设呢?更多情况下,我们并不值得为了追求开源的极客精神,就以企业的生存和发展来冒险。

技术在不停地演进升级换代。可是开源软件从来没有明确的责任人站出来承诺 未来。对于大多数非IT企业而言,多做生意、少做科研,企业不是极客大学。

第一时间获取面向IT决策者的独家深度资讯,敬请关注IT经理网微信号:ctociocom

   
除非注明,本站文章均为原创或编译,转载请务必注明出处并保留原文链接: 文章来自IT经理网
相关文章:
标签: ,


关于作者

新保科技(上海)有限公司董事长,IBM PC在中国的第一任产品经理,曾作为中国保险保准化委员会技术顾问主持编写四部保险数据标准。作为金融科技连续创业者,曾创办新锐互动和保联网络等多家金融科技企业,其中新保科技创建于2002年,专注企业级API领域,是全球保险标准协会ACORD在中国的首家会员单位。邮箱:mahongyu@me.com

写评论

忘记密码

X