几年过去了，我能够在实际的业务应用程序分析领域有所突破。在这段时间里，我学到了很多东西，不仅仅是关于基本架构(数据库结构、web服务器、应用服务器等)，还有第三方集成和适量的网络和系统管理，所有这些都是为了更好地测量。这种早期教育对我很有帮助，我开始仔细研究市场上流行的和小众的消费管理应用程序。这就是为什么在消费分析领域的新进入者能够如此成功地扩大他们的客户群并击败现有的竞争者。在这种情况下，事实证明，围绕分类的体系结构和设计——以及将任何类型的数据集分类为多个分类法的能力，而不需要等待数小时或数天来更新数据集——在现实世界中对于希望灵活地进行分析部署的组织来说确实很重要。
然而，在更广泛的企业应用程序领域，包括P2P系统，我相信真正面向服务的体系结构(SOA)的重要性，在推动部署灵活性和外部集成方面，是极其重要的。缺乏SOA模型是该领域最知名的供应商之一在其基于SaaS/云的产品中进行外部系统和数据集成时遇到如此困难的原因，更不用说在假定的相同代码库中为CD客户提供最新的SaaS增强功能了。也许这个组织应该听从亚马逊首席执行官杰夫·贝佐斯的意见。据一位前员工在给下一任雇主的内部备忘录中说，他的前老板在提出以下要求时改变了一切:
- 从此以后，所有的团队都将通过服务接口公开他们的数据和功能。
- 团队之间必须通过这些接口进行通信。
- 不允许其他形式的进程间通信:不允许直接链接，不允许直接读取另一个团队的数据存储，不允许共享内存模型，不允许任何后门。唯一允许的通信是通过网络上的服务接口调用。
- 他们使用什么技术并不重要。HTTP, Corba, Pubsub，自定义协议——不重要。
- 所有服务接口，无一例外，都必须从头设计为可外部化的。也就是说，团队必须计划和设计能够向外部世界的开发人员公开接口。没有例外。
当然，正是这样的理念使技术组织能够真正构建一个平台，而不仅仅是一组松散耦合的应用程序或web店面。在消费管理领域，我们面临着缺乏这种定义意义上的真正平台。然而，当他们寻求构建他们的支出管理架构时，通过优先考虑一个真正意义上的平台——而不仅仅是业务应用程序暴露的特性/功能能力——组织可以开始在真正的可配置性、虚拟化、集成、更低的总拥有成本、可用性和UI层的最终灵活性上进行设计。
当然，如果你沿着传统的支出管理应用路线走下去——即使是今天流行的“云”解决方案——你也将浇上可以随着业务增长而增长的混凝土。也就是说，如果你把大锤砸到旧的顶层，然后在新的表面上倾倒，希望不要破坏它下面或周围的任何东西，更不用说困住那些在更新的“倾倒”时拼命支撑基础的人的尸体了。当我在下一篇文章中再次探讨这个话题时，我将深入探讨真正的平台和面向服务的架构模型是如何驱动CPOs、副总裁、主管、类别经理、分析师以及任何接触采购的人所寻找的价值类型的，但在传统的推出和部署、SaaS、云计算或其他方式之后，这些价值通常是不需要的。
杰森·布希
讨论: