当前国内企业软件平台的建设重点


 2015-04-14 16:06:29       753

作者:王程志, 

 

摘要:建设软件平台的业务目标是什么?最核心的应该是“重用”

整个软件平台建设的核心业务目标应该是“重用”。这种重用是在企业战略层面上可重用的一套完整体系,而且强调是一种强制的重用,比如我们经常提到的平台中内置了SOA架构、企业的标准、技术规范以及一些软件管控体系等等。

很多企业都在谈建设软件平台的业务目标是什么?有的说要提高建设质量、降低建设成本、实现应用快速交付、降低维护难度等。我认为,这都是很重要的业务目标,然而整个软件平台建设的核心业务目标应该是“重用”。这里讲的重用是软件平台一个核心的内涵,也就是说软件平台是一种战略性的、有计划的、能够实现的、强制的重用。在此,我们特别强调的是在战略层面上要能够实现的重用,包括企业技术的战略、商业的战略两个层面。然而我们这里所说的重用,不是仅仅指可以复制的一些服务/代码或一个可复用的集成开发环境,也不是我们所经常提到的应用服务器或者数据库等基础中间件软件,也不是可配置化的一个业务框架。我们所讲的重用是在企业战略层面上可重用的一套完整体系,而且强调是一种强制的重用,比如我们经常提到的平台中内置了SOA架构、企业的标准、技术规范以及一些软件管控体系等等。

技术平台建设的三个关键问题

在建设技术平台时,我们需要考虑三个关键的问题:其一是我们要考虑如何在现有的复杂的IT环境下,保证整个业务应用的高效稳定。众所周知,在当下企业环境中,整个企业IT基础设施的复杂度已经相当高。其二是如何在复杂环境下解决快速交付问题。其三是如何解决在这种高度复杂的环境下,降低整个应用开发的复杂度,以及保障软件应用的质量。

在复杂的IT系统环境里,我们会面临前端的大量请求和压力,与后端打交道时又可能面临被访问系统不稳定、不可靠的问题。之所以会出现这些问题,是因为IT系统建设的早期我们基本上通过建设一个部门级的或者说领域级的业务应用就可以满足需求。但是现在,在这样复杂的IT环境下,我们往往不得不与其他的信息系统打交道来满足业务需求。

解决这个关键问题的方案就是S-EDA架构,通过S-EDA这种分段式的平台架构,把整个IT系统以及与外部的交互进行分段,并通过异步模拟同步,规避高压力或不稳定而造成的系统崩溃。同时,还可以将请求进行合理分组,从而可以为核心业务提供更多的资源,确保业务的可连续性。

另外,还有一个核心问题,在这种架构模式下,应用实现的模式或者说技术的编程的模式会发生很大变化。我们往往很难要求每名开发人员都能达到很高的水平。所以我们需要在平台中简化这种模式的应用开发,以同步的方式来开发这种异步的应用。

在当前要求持续交付的时代,要达到快速交付,必须要实现软件的开发和系统运维能够更紧密地结合。传统的情况下,往往是开发中心负责开发,测试中心负责测试,然后再交付给数据中心来负责运维,整个链条比较长。我们需要通过平台支撑一个更紧密的链条,缩短时间的同时,达到快速交付的效果。也许会有人提到:可以通过持续的集成和自动化的测试来实现。这确实能一定程度上解决问题,但是在这种模式下,仍然面临一个较复杂的问题。比如说我们做自动化测试,对于后台程序来说,做起来相对容易。但是对于前台界面,如果采用传统的录制自动化测试脚本的方式,当应用功能发生变化后,需要对自动化测试脚本进行调整,依然会存在大量的工作量。那我们提出一种以“测试组件化”的方式来实现,比如:只要我们把登录的的功能通过一个“登录测试组件”来实现,该测试组件需要实现多个步骤,包括点击登录按钮、重置用户名密码等测试功能。当登录界面发生变化时,只要去更改测试登录这样一个测试组件就可以了,而其他依赖本测试组件相关界面的测试脚本都不需要发生变化。

在数据批处理和自动化处理的测试方面,往往我们需要从原系统抓取很多数据,经过一系列的处理步骤生成最终的数据。此时我们就会面临对原系统数据的抓取,以及数据处理结果的验证等问题。比如如果发生数据处理结果不准确的问题,如何快速的验证?在此之前,我们往往需要把原有系统数据用DUMP的方式转出,然后再做测试,然后再用手动的方式去检查数据处理的结果。实际上,我们可以通过平台以更智能化的方式来配置数据抓取的规则。在检查时,我们也可以采用规则化方式,在平台中去累计数据检查的规则。通过这种方式就可以做到对这种批处理测试的自动化。

我们再来谈谈数据处理的复杂度问题,数据的处理一般需要经过从源系统、到ODS、到DW、到DM几个转换步骤。比如说,最终要展现一个企业报表,或者企业的管理驾驶舱。在整个转换过程中,我们会面临多层次、多种转换模式的问题,需要较大的复杂度方可实现转换逻辑。在此,我们提出了数据处理的工艺自动化概念,把数据处理的原表结构和目标表的结构以及中间处理的一些方法进行抽象。抽象之后,我们根据相关处理规则的配置,自动生成最终要做的数据转换的过程,这里包括数据处理过程的质量检查,最后生成完整的数据处理的过程。这样可以极大的提升数据处理转换过程开发的效率与质量。

上述介绍的是技术平台的几个关键问题以及解决的方案与思路,普元也提供了技术平台相关的组件来支撑。比如说应用开发平台、工作流、数据平台等等。

集成平台的三个不一样的做法

我们再来看集成平台,集成平台一般支撑展现方面的集成、流程方面的集成、服务方面的集成等。我们来看看在集成平台支撑这些目标时,会有哪些关键的问题和不一样的做法。

第一方面我们来看企业流程集成。不管是在银行、电网,还是在电信企业,其实都在做大集中。大集中时,有一个典型的做法叫做企业流程中心,或者称为企业流程的集约化管理/企业流程库。以前,每个系统会有相应的流程。在这种环境下,我们提倡客户按照企业流程中心的方式来实现对企业所有或某业务域的流程来进行统一管理。这其中包含几个核心概念:第一个在这种模式下可以达到流程管理的集约化管理,把原来分散的各个系统的流程集中。第二可以根据业务需要,按照不同的业务域或不同流程的类型用企业流程中心中不同的域来支撑。这是我们在做企业软件平台建设时典型的做法,银行、电信、电网等大型企业都在进行实践。

第二方面我们来看企业服务集成。在当前阶段,基本上大部分企业都实现了信息系统的互联互通,实现了服务的集成。但是,仍然存在企业集成服务在管控和治理方面的诸多问题,比如应用之间集成的关系是不可见的,到底哪些系统之间进行了集成、通过那些服务的调用进行了集成;另外,服务集成的运行情况如何,哪些服务运行质量比较高,哪些会经常发生数据丢失、无返回等问题。而解决这些问题需要我们从服务治理的角度提出平台建设的新的思路,通过服务治理的平台提供对服务集成全生命周期的支持,包括前期的服务注册、部署、管理等,后期的服务运行情况监控、干预等。

第三方面我们来看综合展现集成。大家可能又会提现在的做法,比如已经通过Portal实现了展现的集成,比如说已经实现了单点登陆、信息系统的统一入口。那么在此,我们提到的企业的综合展现集成,可能更多强调的是如何以客户为中心来实现个性化的集成、如何以渠道整合的方式来实现多渠道的整合,以及我们如何来做到集成之后的安全审计。当然我们也会借鉴互联网一些做法去做一些个性化,比如说集成之后的跨域互动等。那么在这种情况下,我们往往需要平台不仅仅提供简单的展现集成能力,还需要支持这些高级的展现集成需求。

上述介绍的是集成平台的几个关键问题以及解决的方案与思路,普元也提供了集成平台相关的组件来支撑。比如说业务流程集成平台、服务治理平台、综合展现集成平台等等。

业务平台实现的理论与方法

首先,我们来谈谈业务平台建设的必要性。在当前软件平台建设的过程中,越来越倾向于建设分层和分域的平台体系,包括技术平台、业务平台等,而业务平台又会根据技术需求特征的不同分为多个业务平台。那么业务平台建设的目的和必要性主要是什么呢?归纳起来看,主要包括三点:一是实现应用的快速构建,因为业务平台中往往内置了特定领域的业务模型、并实现了配置化,所以相比技术平台能够支持更快速的业务构建;二是实现沉淀积累,包括业务模型、业务组件等;三是实现持续的演进优化,包括业务平台所具备的可变性扩展、个性化定制、智能学习模型等。

那么业务平台的实现的核心理论与内涵是什么?业务平台实现的核心理论是“领域模型理论”,其包括三个核心内涵:业务模型化、模型参数化、实现配置化。

业务平台建设落地的方法包括五个层次:第一是明确业务目标;第二是梳理核心流程;第三是分析业务元模型;第四是设计业务框架;第五是实现应用的开发与治理。我们以实现一个“企业运营管理监控的业务平台”为例来说明:业务目标是要实现对企业风险进行管控、进行决策支持、实现绩效考核。核心流程是从源系统采集数据、经过流程还原与指标计算、形成预告警信息、支持未来趋势预测,支持更高级的经营目标测算、风险控制测算、绩效提升分析等。业务元模型包括指标库元模型、风险树元模型等。业务框架的核心是要支持模型参数化与实现配置化,即固化不可变因素,可变因素通过参数方式实现可配置。

上述介绍的是业务平台实现的核心理论与方法。实际上,普元在多个行业都提供了业务平台,例如燃气业务平台、电力企业运营管理监控业务平台、企业协同业务平台等都属于普元的业务平台范畴。 

相关阅读: