其实只是术语变了，但需求还是一样的。在SOA炒作的鼎盛时期，厂商们都宣扬他们的产品支持SOA治理。有些时仓库，有的是网关，还有的两者皆有。

现今，同样的这些厂商（有一些新的）正在谈论API管理。我们不关心它是否对重塑品牌的努力、技术革新还是技术创新。相反，这表示在企业中仍然存在着一项基本需求，即对以消费为主导、基于服务的思考的需求。

企业及企业以外的SOA架构

我们要认清一个事实，企业IT是非常以项目为中心的一种文化。IT中的管理主要强调两件事情：及时交付项目以及使项目经理按照预算进行， 和通过从事经理给这些人分配项目。

几乎没有概念，如果有的话,产品管理和服务管理的想法可能会受到IT运营组织的限制。当系统进入到生产阶段时，支持就会受到限制，除了保持正常以外，更不要说一些基本的保养了。员工继续进行到下一个项目。有些应用程序已经好几年没有使用了。当触及到新功能交付时，系统升级和服务集成更新就会被忽略。新功能所带来的潜在收益胜过每次底层应用服务器的更新。但这只是冰山一角。

事实上，项目比以往更加复杂。想让项目经理感到畏缩？只需要告诉他或她，另外一个团队的解决方案的交付过程需要他/她的参与。最重要的是，它很可能是新团队，而且对于他们需要做什么没有正式的参与模型。

当然，假设你是第一个能决定出哪一个团队合适的人。如果该团队负责web服务，这一服务的描述充分了吗，消费系统的开发人员能正确使用它吗？常常这一描述是从上一个项目开始的，这是适应于人们构建这一服务，而不适用于人们使用这一服务。

回到首字母缩写而成的SOA架构治理和管理，他们集中关注这一问题，但却只限于企业内部。应用程序编程接口把这一概念扩展到的企业以外。我曾经经历了业务API这一术语的使用，但业务接口这一术语更准确，因为我们真的不在编程业务，我只是在与它交互。

糟糕的API管理的风险

业务中所有的东西都有接口；只是有些得到了更好的存档，更好的管理。缺乏管理的接口最终会产生矛盾，给使用它们的人带来不好的体验。

糟糕的接口管理的业务的风险会变得越来越严重。我还没有看到任何一家公司声明其项目越来越简单及涉及系统也较少。相反，我们所面对项目跨越多个渠道、用户群体、团队和系统，公司从内部到外部。

现在是时候改变这一文化，拥抱服务和接口管理这一概念。亚马逊的做法是对的：为一切创建API，让你的交互趋于接口化。第一次，它可能并不正确，所以确保你的投资机制允许接口持续演化。

你无法管理接口，除非项目允许。相反，努力使一切尽可能地使用所有接口易于使用。API管理工具已经接受的一个关键功能，而且SOA架构鼎盛时期没有突显出来的是身份标识供应。完全文档化API，允许消费系统编码是回事，但是你是打算使用API的服务获得身份识别，从而使你的运行速度尽可能地快，还是使用需要你的团队等待四周的人工流程的服务，又是另外一回事。

然而，有一个厂商曾经告诉我，“管理功能不能销售产品，”我很高兴看到厂商仍在努力推进技术，来协助服务和接口管理工作。越来越多的在这方面做的好的公司都取得了成功。你只需要看看，亚马逊云服务产品造成的中断，就会知道这种改变发生的有多么的快。

关于作者：

Todd Biske是位于圣路易斯的大都市的财富50公司的一名企业架构师。在他的20年的职业生涯中，他具有多领域的架构经验，包括保健机构、金融服务、出版和制造业。