独立于技术的业务系统

摘要

本文阐述了两个观点，一是IT产品生命周期都不长，随着时间的流逝，企业的业务系统不可避免的会变得更加复杂，更加难以维护，最终由于过时而需要更换。二是存在一种业务系统开发方式使得业务系统本身可以独立于实现该业务系统的特定技术，当底层技术由于过时需要更换，或者由于业务改变需要升级业务系统的时候，可以较快、较方便地更换底层技术，或者实现业务系统的升级。

目标读者

企业和机构的CIO/CTO,主管科技的政府领导

(一）

苹果公司创始人乔布斯在IT行业是一个传奇，他对IT行业的特性有着真知灼见。在他很年轻的时候，他就已经注意到IT产品的更新换代非常快，一般10年，最多20年，一件产品就会完全过时，被时代所抛弃，这跟一位画家画成一幅著名的油画并能够流传几百年有很大不同。

如今Apple II, Macintosh这些早期的苹果电脑早已不见踪影，2001年发布的Windows XP，微软早已不再提供安全漏洞的补丁更新，也不再提供其他技术支持服务，虽然由于这样那样的原因还有不少PC上运行着Windows XP,但是支持Windows XP的硬件和软件越来越少。

曾经风靡一时的索尼Walkman

企业的IT主管们对IT系统的老化过时应该深有体会，当年花费了大量预算，大量人员参与开发和实施的，采用了当时最新、最流行技术的，轰轰烈烈上线的业务系统，不到几年时间就变得臃肿，复杂，僵化，性能变差，维护成本变高，对业务部门的需求反应变慢。而在当时看来是非常新、非常酷的技术，如今是昨日黄花，已经被更新、更酷的技术所超越。

通常情况下这类IT系统是支撑一个企业核心业务的应用系统，要完全替换谈何容易！

另外，就算企业下决心替换这样一个系统，花费巨大的人力物力，冒着业务连续性受到影响的风险，重新上了一套更先进的系统，是不是过了几年这样的大拆大建又要重来一次？

（二）

一个企业在市场上要面对两种变化，一种变化是商业竞争环境的变化，对这类变化，企业需要及时调整业务战略，改变业务流程，推出新的产品或服务，另一种变化是新兴信息技术的涌现，比如移动互联网，物联网，人工智能，区块链，对这类变化，企业需要及时评估新兴技术对本行业的潜在影响，因为很可能有另类竞争者利用这些技术进入市场，比如金融科技公司对金融业原有市场格局的影响。

企业面对这些市场变化在业务上的应对措施传导到CIO/CTO那里，就需要CIO/CTO相应地改造IT系统以配合应对措施的顺利执行。

如今大多数IT系统已经采用了分层架构和模块化的设计，这样设计的好处在于可以比较容易的更换模块或者底层架构组件，例如：

• 把关系型数据库从Oracle换成MySQL
• 把缓存服务器从Memcached 换成 Redis
• 把云存储服务商从Amazon Web Service换成Microsoft Azure

但是有一些较大规模的更换就不是那么容易了，例如：

• 把基于微软.NET Framework应用平台的系统换成基于开源Java框架的系统
• 把桌面应用换成Web应用（从C/S架构到B/S架构）
• 把SAP CRM本地应用（on-premise)换成 Salesforce CRM云服务

更多的情况是，IT部门需要对现有系统做定制化开发或者扩展开发。业务部门提出业务需求，IT部门负责对现有IT系统进行改造或升级以满足这些业务需求。因为新的业务需求频繁，而IT部门人员常常短缺，这就造成IT系统改造无法满足业务部门对时间的要求。

（三）

我们需要检讨业务系统的开发方式，是否可以让业务系统与其所采用的特定技术之间不要耦合的那么紧密？当然所有业务系统最终都是采用某种特定的技术来实现的，但是我们是否可以在概念中的业务系统与这种最终技术实现之间建立某种隔离机制？

事实上这是很容易理解的，当一个业务人员使用一个业务系统的时候，他并不了解也不关心这个业务系统到底采用了哪种技术，他使用这个业务系统是为了完成某个与业务相关的任务或者流程，他关注这个业务系统的功能和操作性。如果业务系统更换了某项技术，只要功能和操作性上没有明显的变化，业务人员是不会注意到这个系统升级的。

一般大型的IT项目开始于一个产品需求文档，在用户确认了该产品需求文档里面的内容正是用户所期望的IT系统的所有功能之后，开发人员开始根据产品需求文档编写代码，测试人员根据产品需求文档进行测试，最后用户根据产品需求文档进行验收。

产品需求文档是关于业务的，跟业务系统具体的实现技术无关，它可以说是待建的业务系统的一张蓝图，唯一的问题是，这张蓝图是Word文档或者pdf文档，而不是一个真正数字化的、具有结构的信息。作为对比，我们参考一辆汽车的蓝图，这张汽车蓝图是完全数字化的信息，它可以直接输入到自动化生产线上，指导生产线上的工业机器人对汽车进行生产和组装。

汽车自动化生产线

在业务系统被编程人员开发出来之前，我们需要有一份这样的业务系统蓝图，而不仅仅是一份产品需求Word文档。

（四）

如果像一辆汽车的蓝图那样，对一个待建的业务系统，我们也有一份这样的业务系统蓝图，另外，再假设我们有像汽车自动生产线上的工业机器人那样的各种自动化编程工具，那么，软件编程就跟汽车生产非常相似了，我们可以把这份业务系统蓝图输入到业务系统的自动生产线上，通过生产线上的各种自动化编程工具，自动生成业务系统所需的各种组件，最后将业务系统组装而成。

汽车制造	业务系统开发
汽车蓝图	业务系统蓝图
工业机器人	自动化编程工具
汽车自动化生产线	业务系统自动化编程流程

有了这个业务系统蓝图，在业务部门和业务系统之间就有了一份隔离，那就是这份蓝图，蓝图与具体技术无关，蓝图与业务系统是因和果的关系，根据蓝图可以采用不同的技术生产出不同的业务系统。当然它们的功能应该是一样的，只是实现的具体技术不同。

如果需要更换某个技术，可以根据蓝图重新生产出一个新的业务系统，由于生产流程是自动化的，这个重新生产的过程无需花费大量的人力、物力和时间成本。

如果需要增加功能，则需要调整蓝图，当得到新一版的蓝图后，将新的蓝图输入自动化生产线，就生产出一个新的包含新功能的业务系统。同样的，由于生产流程是自动化的，这个重新生产的过程无需花费大量的人力、物力和时间成本。

在这种开发模式下，我们可以快速响应业务部门的需求了。

我们可以快速变换技术架构了。

我们再也不会出现文档和产品不符的情况了。

我们可以保证我们最后生成的系统完全是业务部门所期望的那样。

我们的产品质量提高了，因为我们不需要大量的手工编程，大部分编程工作都自动化了。

由于同样的原因，我们不再需要那么多开发人员和测试人员了。

这种开发模式就是模型驱动开发(Model-Driven Development，简称MDD)。

敬请关注本系列的后续文章。