为什么工作日因设计而不同，为什么它很重要

在Workday，我的大部分时间都花在解释我们在设计上的不同。我们有一长串的要点来描述我们不同的方法，但在核心上，Workday的云应用程序和传统企业应用程序之间的主要区别在于我们如何将对象模型作为我们架构的核心。

我们使用对象模型来定义应用程序的结构(类、关系和属性)以及应用程序的逻辑(方法)。对象模型的所有部分都定义为元数据。与用于定义传统企业软件的数千个关系表和数百万行代码不同，Workday应用程序由数百万个元数据定义组成。Workday使用关系数据库来存储所有元数据和所有应用程序数据。为了优化应用程序性能，Workday将所有应用程序元数据和大多数应用程序数据保存在内存中。

将应用程序结构定义为元数据意味着可以在不重构数据库的情况下更改Workday应用程序的结构。将应用程序逻辑定义为元数据意味着可以在不编码或重新编译代码的情况下更改逻辑。不使用数据库来表示应用程序的结构可以显著减少支持应用程序所需的表数量。

虽然故事的“如何”部分很有趣，但我更想关注架构背后的“为什么”问题。为什么要采取不同的方法，为什么这很重要?对于Workday和我们的客户来说，答案涉及四个关键领域:速度、安全性、洞察力和变革。

速度
当你想到传统上被称为企业资源计划系统(ERP)，速度可能不是你首先想到的。但是，当你是一家决定与大型ERP软件供应商竞争的初创公司时，你确实需要考虑快速行动的必要性。我们在2005年使用对象模型推出了Workday，这使我们能够显著加快应用程序的开发速度。到目前为止，开发人员可以快速更改Workday应用程序，而不必担心更改底层数据库，或者在构建新功能和产品时执行任何数据库管理操作。华体会体育注册

这就是为什么我们能够每年为客户提供三个Workday更新，而不是行业标准的一年半或更长时间的传统软件升级。我们可以快速响应新的客户需求，更短的开发周期让客户更容易成为设计合作伙伴。(等待一年半或更长时间才能看到你的想法付诸生产，可能会让最热情的客户望而却步，而Workday可以在四个月内获得回报。)

安全
Workday的架构方法意味着我们的开发人员和客户——包括为他们工作的任何人——无法访问存储客户数据的数据库。所有客户数据都是加密的，只能由应用服务器访问。

这是对企业空间整体安全性的巨大改进。将数据的访问点限制在应用服务器上并不适用于任何内部部署的ERP实现，对于托管的企业应用程序实现也可能不适用，即使提供这些实现的供应商将其称为“SaaS”。

洞察力
由于Workday将数据关系定义为对象之间的关系，而不是从数千个表中挑选数据的传统方式，因此我们能够提供其他企业应用程序无法提供的对事务数据的报告和分析。

当运行分析报告，我们的系统使用与报表中主要对象(如“worker”)的关系来收集与该对象相关的所有数据。对于传统的ERP系统，等效的方法是连接与“worker”相关的所有表中的所有数据，并将结果发送到应用程序服务器的内存。Workday不需要进行连接，数据已经在内存中了。这使得Workday可以快速呈现所请求的报表，并让客户可以快速地向下钻取报表的选定维度。

例如，Workday的客户可以运行一个报告，不仅显示所有研发人员的信息，还显示有多少高级开发人员在旧金山工作。这种类型的分析只能发生在传统应用程序中，当数据已经“预连接”并加载到单独的报告系统中时。虽然这是商业智能的常用方法，但它增加了报告的成本和复杂性。必须为单独的系统实现安全性，并且加载到其中的数据在查看时可能已经过期。由于我们的报告运行在执行事务的相同对象结构上，因此我们避免了单独报告系统的问题。

改变
也许我们采用不同方法的最重要的驱动因素是构建可以随时更改的应用程序的能力。即使在30年后，企业软件的需求仍在快速变化。供应商仍然必须满足长期存在的需求，如可靠的事务处理、可伸缩的批处理和大容量的数据导入，但我们在满足新需求(如内置分析、可配置和协作工作流以及移动访问)方面面临越来越大的挑战。

在Workday，我们已经证明了我们有能力满足旧的需求并处理新的需求。在短短两年内，我们的iPhone应用程序已经收到了五个新的功能更新和一个完整的UI刷新。这种程度的变化在企业软件中是闻所未闻的，但它是消费技术的标准，这是大多数创新的来源。

复杂的关系数据库体系结构不够灵活响应企业应用程序的新需求。对于在这些体系结构上编写的应用程序来说，获得新功能的途径是代价高昂的集成和重写，而不是平滑的演进。

我们行业的变化速度使得关于应用程序架构的讨论比以往任何时候都更加重要。这让解释Workday的不同之处变得更加令人满意。