尽管与我们所认识的一些真正的极客技术专家相比，我们在应用程序和平台方面的写作资格略低，但对于普通的Spend Matters读者(在采购和供应方面)来说，了解应用程序和网络市场在未来10年将如何发生巨大变化是很重要的。这将发生在公司对构建应用程序的网络和平台(和/或与之集成的网络和平台)做出购买决策时，就像供应商提供特定的适合用途的工具(例如，电子采购)的功能能力一样。
这代表了平台或堆栈的出现，甚至对业务用户也是如此。从历史上看，大多数采购人员并不关心解决方案构建在什么底层平台上。有一个例外:一个解决方案可能会因为基于微软技术而不是Java、Ruby或其他技术(谢天谢地，我们都已经克服了这一点)而受到损害。除了有偏见的软件公司自己，没有人——我重复一遍没有一个人-曾经购买过基于其开发领域的采购技术。相反，功能性、可用性、规模、体验、声誉、互操作性和许多其他因素在过去的技术购买决策中发挥了作用。谢天谢地，微软的问题也不再重要了。
然而，展望未来，情况将恰恰相反。“应用程序”——而不是应用程序——将在平台(与过去的开发平台不同)之上被购买，最好的平台(或实现最大规模和覆盖面的平台)将成为胜利者。这已经在B2C商务和物流领域发生了，亚马逊凭借其更广泛的平台商户游戏(现在扩展到融资、仓储、物流和其他增值服务)成为赢家，更不用说它的亚马逊网络服务(AWS)云托管和虚拟化功能了。在移动领域也是如此，苹果通过其App Store界面成为开发者最重要的把关人(游戏邦注:Android也属于这一观点，尽管是基于不同的立场)。
然而，到目前为止，我们还没有看到企业对企业或采购/供应链环境中的公司将平台决策置于购买应用程序之前，尽管有明显的优势。我们相信，这种变化将比你想象的更快，因为有了正确的“看门人”模型，平台可以确保所有数据模型、工作流和应用程序之间的互操作性——无论是第三方应用程序还是平台公司自己构建的应用程序。例如，想象一下，在一个平台上为电子发票、电子采购、供应链融资、合同管理和相关应用程序提供即插即用连接，而不管哪个提供商构建单个应用程序。
稍微讲一下技术，这需要一种外部化的面向服务的体系结构(SOA)方法。正如我们过去写过的，平台:这样建造的平台有很多优点:
- 集成(外部系统)——外部系统集成(例如，ERP)可以在一套或一组应用程序之间简化一个数量级，给定一个公共的底层数据模型和简化的API/web服务集成环境。集成也可以是更好的由于能够在应用程序的任何地方公开第三方系统数据，因此可以使用外部系统
- SOA和Web服务通常是一个设计原则，而不是事后附加的。这本身就为套件带来了简单的集成方法。套件提供商认为传统的复杂集成只需要一两个星期，而不是几个月
- 集成(在平台套件本身内)。不要低估开箱即用的好处，例如，建立在相同底层数据模型和架构上的集成供应商管理和采购功能，或者是特定平台生态系统的原生功能
- 降低产品/模块之间的集成成本。例如，连接供应商门户、供应商管理工具集、供应商主机和产品主机的项目或供应商主机集成。在多套件/工具集环境的情况下，即使只是在与采购相关的应用程序中，这些集成成本也会非常大
- 第三方应用程序和开发能力，使外部个人和组织(甚至客户端)能够快速开发跨平台环境完全集成的自定义“应用程序”;包括由内部IT部门开发的应用程序!
通过网络交付的真正平台方法将允许每个应用领域中最适合的供应商(针对特定客户)在平台之上为客户提供所有数据协同工作(例如，在应用程序级别和网络级别同时发生工作流、权限、匹配、验证、存档和同步)。
例如，这样的模型将允许公司进行选择Coupa或Ariba进行电子采购，Basware或者ReadSoft的电子发票，CombineNet或BravoSolutionAravo或Hiperos用于合作伙伴/供应商管理，SciQuest (Upside)或Novatus用于合同管理，所有这些未来的“应用程序”都可以开箱互操作。它还将允许更多的小众解决方案与网络以及这些更广泛的功能应用程序一起工作(例如，折扣/支付，总成本建模，转移定价优化器，风险警报等)。
在本文的第2部分中，我们将探讨这一愿景的连接性和多层组件如何开始进入网络/平台方程式，并在此过程中证明对我们的业务具有变革性。
采购和供应链领导者应该如何思考系统架构?订阅用户还可以阅读: