用友UAP平台让业务与技术分离的奥秘

提起业务与技术分离这个话题其实今天已经不再新鲜，似乎也不是传统意义上的CIO们所关心的核心话题了，但是这确实是一个企业信息化项目成熟与否的标志之一。很多时候评价企业信息系统的成功与否，能否健康长远发展与否都取决于业务与技术到底有多深的耦合关系。

让业务懂技术其实并不难，反之亦然，这其中不是难易的问题，而是有没有必要这样做。在传统模式下开发出来的业务系统姑且不论交付到最终用户的认可程度，单纯在实现层面就要经过多少次反复这已是一个不争的事实了。而通过用友UAP平台开发业务系统到底能在这个层面为企业带来哪些巨大的价值呢?而拉开业务和技术二者距离是不是一定要付出巨大的代价呢?其实并不一定，而且也不用挑战固有的软件工程理论。

正如用友集团UAP中心技术支持部总经理彭立东所说的通过用友UAP平台实现企业管理，首先能够快速准确的把握企业的需求是至关重要的。尽管用友在很多场合下都一再强调用友UAP开发平台预制了包括企业模型，特征模型，组织模型等众多模型，但这并不意味着完全不需要进行编码的工作，而是通过业务模型的建立让编码的工作简化，让业务与技术能够从一种看似互为“充分必要条件”的能够剥离出来。

元数据驱动让业务与技术分离

业务与技术的分离已经是现在企业用户在考虑具体实施的过程中必须谨慎操作的问题，但是如何实现真正的分离却并不是所有的人都能够清楚，用友集团UAP中心Java应用平台开发部经理刘昆鹏则认为用友UAP开发平台主要源自以下几个特点而对于业务和技术的剥离产生作用：

一是全产业链开发;

二是对整个开发过程的管理;

三是重视计划、最佳实践积累和固化，并提供多种展现形式的开发。

用友UAP平台是一个模型驱动的开发平台，同时也是一个元数据驱动的开发平台。在用友UAP平台上进行开发，首要环节就是进行元数据设计。而彭总认为经过需求调研、模型搭建、框架设计等前期的项目的铺垫进行元数据的设计是十分关键的。同时，元数据又是系统中数据实体的载体。他不仅仅标志着当前项目的数据“宽度”、“精细度”也影响着未来企业信息化大厦的基础，因此这个阶段的设计非常关键。但也正因如此，用友UAP平台有着独到的扩展方式能够满足未来的扩充。据彭总介绍严格意义上讲，项目进入元数据设计阶段已经是经过需求、架构、分析、建模等步骤，甚至经过架构师和领域架构师的设计之后很少有因为考虑不周而造成元数据进行修改的可能性，而即使是以阶段性目标而产生了元数据的偏差，而通过扩展机制可以自己加进来。而另一个层面来说，客户化定制开发才是这个问题的关键所在，任何一个平台、系统已有的功能、数据、模型等都不可能完全符合企业的需求，所以在做客户化定制开发的时候这种情况将会凸现出来，而恰恰正是因为这样的元数据机制让客户可以在版本迭代的时候不断的“随需而改”。

过去，做信息系统开发或者纯粹的一个编码人员会考虑到底走怎样的技术路线，走微软的“.Net系”还是走“JAVA系”路线，而恰好用友在这两种技术线路上都有各自的产品，但是这并不是问题所在。无论是从“存在即合理”的角度出发，还是从适应市场需求的角度出发这本身不是问题，而用友UAP选择了Java平台来提供支持也是一个无可厚非的路线。

企业采用信息系统肯定不会仅仅走“独木桥”，多种系统在对接集成的时候势必会出现不同技术体系的产品对接和集成。异构系统的对接其实并不是说一定要统一编译语言，系统集成也不是必须重构。彭总解释道Java编译的程序的基础是Jar的调用，而通过这样的方式调用C的程序并不是难题，只是通常意义上不会通过底层的接口来实现。如果真的面临Java需要和其他语言的系统对接的问题，一般通过标准化的服务实现。虽然前者看似是系统底层实现是高效，但平台相关性的问题可能会造成其他平台无法部署的情况出现，所以用更加开放的服务方式来进行。

提到这个技术路线问题不得不说在用友UAP平台上的集成管理功能，作为一个开发平台，如果不能很好的集成周边环境，很容易造成一个兼容性问题出现。单纯就平台本身的集成，用友可以说煞费苦心，从第三方测试工具的选择与集成便可窥见一斑。不仅仅是用友自身平台的集成与其他商业化产品的集成同样如此，包括其他知名品牌的测试工具，都能够进行整合。

小结：关于平台的发展不是技术问题是商业模式问题

从技术角度讲，用友UAP平台可以把CPU、网络等看做透明的虚拟化的，而从实验室到客户的商业化运用这不是技术问题，如何做大做强其实是一个商业模式的问题。谷歌、亚马逊同样有开发平台，但他们都有自己的特色和侧重点，所以现在看来用友UAP平台的普及与深入不是技术问题更多的是在于商业模式的升级，这也正是用友转型之所在。而对于用户来说，让业务和技术实现“分而不离”似乎是一个难题，而通过用友UAP能够帮助用户实现的不再是概念，而是一种新的方法。一种卓有成效的开发方法和工具。