以应用架构的可持续保障信息化持续发展

发布日期：2017-07-04来源：本站编辑：邵慧平

[摘要]

文/申启杰

　　由于建筑施工对象的单件性、一次性、分散性等天然特点，以及行业内一直普遍存在的粗犷式管理模式，信息化在施工行业内普遍存在实施难，持续更难的困境。特别在后特级资质时代，不少行业内的企业都在反思自身的信息化历程。在经历过大干快上的信息化建设后，为什么没有彻底改善企业内部的信息化水平，反而很多与管理现实不适应的系统需要推倒重来。在这里有需求没有搞清楚，就开始购买、实施系统的原因，但更深层次，是缺少了对一个企业整体应用架构的思考。应用架构是一个企业信息化的“龙骨”，只有稳健的龙骨，才能够支撑和链接企业的各业务信息化的开展，才能够支撑企业信息化这艘大船的顺利启航和远行。

　　应用架构的定位

　　信息系统的架构，分三个层次：业务架构、应用架构、技术架构。业务架构是战略发展需要的体现，反映企业管理的实际情况，属于宏观层面;应用架构是对企业实际业务形态的体现，反映企业某业务领域专业的管理工作，它用于承上启下，一方面保证业务架构的实际落地，另一方面，影响技术架构的选型和实现方式;技术架构是软件系统对应用架构的具体实现，反映整体软件系统的灵活性、扩展性、整合性，属于系统的微观层面。

　　从宏观层面上看，一个企业的发展战略是相对稳定的，所以这个企业的业务架构是相对稳定的;从微观层面上看，系统的技术架构，是对于软件系统的实现逻辑和技术，它通常受同时代的开发技术，以及应用架构的设计影响，不同的应用架构设计，通常会决定所采取的实现技术。在企业信息化的实施过程中，更注重的是应用架构。

　　应用，在企业内通常表现为一个软件，是信息系统中可划分的最小单元，通常以是否可以独立部署为标志。它明确划分了应用与应用之间的边界，也就是通常所说的系统边界。

　　在早期，单机应用的阶段，不同的应用之间几乎都是没有关联的，并没有什么应用架构。随着企业信息化的发展，从工具软件阶段向管理软件阶段发展时，在一个软件系统里面已经无法容纳所需要的所有功能，这就涉及到将大的需求切分到不同相互协同的应用里面去，并逐渐形成了动态稳定的企业内部应用组织形式，体现为这个企业中的系统应用架构。

　　应用架构主要体现在应用粒度大小以及划分形式。在现代企业的柔性应用架构中，通过将一个大的业务，划分成为不同大小的、合理的应用，实现整个系统架构的柔性，一方面，将大化小，降低技术架构的实现难度，另一方面，降低了业务的复杂度，使整个系统更加有序，保证了信息化更好落地。应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统的可持续。

　　应用架构的松耦合提高信息化可持续能力

　　回顾不少推倒重来的信息化实施案例，这些失败的案例中，几乎都上了完整的一套系统。而致命的是，这一套号称囊括了所有功能的系统，就是一个应用软件。由于是一个单一的应用，它的部署模式、系统升级能力，都严重遏制了系统的生命力。单一应用的部署模式，基本上都无法做到分布式部署，当用户多、使用的功能多时候，服务器硬件的性能就严重影响应用的可用性，直观的感受就是系统响应速度很慢。同时，大而全的软件有个弊端，就是当某一块功能不能满足用户的需求，需要对此功能升级的时候，单一化的应用往往无能为力。这时，用户往往需要重新购买或者开发一套系统，以取代原有的功能，在原有弃用的功能继续浪费硬件资源的同时，也带来了后续的一系列系统整合问题。

　　合理的应用架构设计，将紧耦合的一套完整系统，根据企业业务的特性和管理现状，逐步分解成各松耦合的多个应用，会提高系统适应需求变化的灵活性，从而提高整个企业信息化的可持续能力。建筑施工企业处于激烈的市场竞争环境当中，整个行业的信息化水平还在初级阶段，尚有很多业务没有实现标准化和信息化，在这种没有很多信息化系统作为参考的情况下，一定有很多实际的管理情况会在系统设计的阶段没有得到充分的考虑。所以不可能一开始就设计出一套完整的系统，满足企业管理中的所有需求。单从理论出发，设计一套理想化的系统，必然带来信息系统和实际管理的“两张皮”问题，严重影响企业的信息化进程，甚至推到重来。建筑施工企业搞信息化不可能强制管理去适应信息化，而是应当用信息化去反映管理现状，逐步用信息化实现业务替代，将线下的业务流程搬到线上来处理，继而通过信息化流程优化，来逐步提高管理及信息化的水平。

　　相反，通过设计良好的应用架构，在整个企业的业务架构下，将功能需求进行划分，化解了开发大型系统的复杂性。各独立的应用支撑独自的一块业务，当某一业务的需求调整时，只需要对这一应用进行迭代升级，并不影响其他应用的正常使用，将系统升级的影响降到最低。当某一业务做大时，承载该业务的应用，可以根据业务量等因素划分成更细粒度的应用，只要保证新增加的应用对外接口与原有应用一致，就能够无缝接入到原有的应用架构中。同理，当某一业务不需要的时候，也可以动态地将这个应用从当前应用架构中剥离，也不会对整个信息系统及其他应用造成影响。

　　应用架构的松耦合设计，关键在于识别业务架构中的各应用边界。可以通过纵向、横向两个维度来划分应用。

　　纵向维度的主要划分依据是组织机构以及工作量。组织机构中的各部门，基本是某一类业务的承担者，这些业务部门天然地就将整个企业的业务进行了纵向划分。通过归纳各业务部门的工作内容，形成设计应用架构的基础。比如说，采购部门，主要负责物资、分包等采购，可以设计采购系统来支撑该业务;工程部门，主要负责项目执行过程的监管，可以设计一个项目管理系统来支撑该业务。然后，在组织机构划分的基础上，考虑工作量以及工作复杂度的因素，从复杂程度来进一步对系统中的应用进行划分。比如，采购系统涉及到物资采购、分包采购，如果现实情况中，这两种采购类型的采购量很大，而且负责这两种采购有专门的岗位，可以进一步将采购这个应用分拆成物资采购、分包采购两个应用。再比如说，工程管理部的项目管理系统涉及的内容非常多，比如产值、进度、安全管理、质量管理、竣工、催收等等，那么，根据这些业务内容，宜进一步将应用进行划分，以保证各应用更好落地，保证核心业务能够得到信息化的充分支持，而这一核心业务的信息化能够真实反映管理的实际情况。

　　横向维度，用于识别跨部门协同的应用。有一些业务，并不是以某一个部门完成所有的流程环节，而是不同的部门，都在同一条业务链接上进行协同。这些业务在企业中并不多，但往往更重要。比如说支付流程。整个分包支付流程经历过工程部、安全部、质量部、合约部、审计部、财务部等各部门的处理，宜设计成一个软件系统，来支撑该业务流程。

深圳盐田港

　　应用架构的再分层提升信息化整合能力

　　松耦合的应用，实现了相互的隔离，使企业信息化体系能更好落地。在客观条件下，整个企业的信息化不是一蹴而就的，而是一个逐步的过程，应用系统的建设步伐，也是从核心应用开始建设，再逐步实施不那么重要的应用这样的模式。由此，不同应用可能建设时间相差很远，也可能由不同的实施团队来开发的，造成了异构系统的存在。企业的业务是需要交互和协同的，对于这些应用来说，也需要交互和协同，需要数据共享和所有应用的整合。

　　应用架构的再分层，是在应用架构这一层次，对应用进行再次划分，划分成基础应用和业务应用。通用的基础应用，实现企业内支撑基础数据的应用的相对稳定;业务应用用于支撑各种灵活多变的需求。通过再分层，将各应用间的随机的、不确定的交互协同，转变成业务应用与基础应用间的稳定交互。

　　从数据流的角度看，企业中的人员、机构、合同、项目、消息等数据属于基础数据，其余的数据，如项目的每月产值数据、计划数据、船机数据、采购数据等，可以看成是业务数据，业务数据之间通常不会直接发生关联关系，但业务数据可以与基础数据进行关联，实现业务数据与基础数据的直接关联，以及业务数据之间的间接关联。

　　应用架构的再分层，分析企业中的数据流，划分基础数据和业务数据，用基础应用封装基础数据，对外提供数据接口;用专业业务应用来支撑业务流程，管理业务数据。当业务应用间需要交互时，它们不是直接调用对方接口，而是通过基础应用，实现业务应用之间的间接交互。

　　比如各应用系统都有消息传递及流程审批机制，单独进入各系统来审批业务显然不能提高业务工作效率。通过设计和开发一个消息流转的基础应用，各业务应用需要消息提醒和流程审批时，将相应的数据推送到同一个消息流转基础应用上，以实现消息的整合，便于用户从同一个界面中进行业务审批。

　　基础应用、业务应用之间的接口规范，进一步降低了应用间的耦合程度，将原本无序的应用交互，转变为规范的应用交互。无论应用如何升级、优化、更换，直接符合设计好的接口规范，就能实现应用的交互，实现系统的整合。

　　建筑施工企业信息化落地并持续发展，受到当前行业信息化水平和管理现状的制约，在持续发展过程中面临了许多问题。合理设计企业信息化应用架构，实现整个信息系统的松耦合、分层次，通过逐步实施、持续优化的方式，提高了整个信息系统拥抱需求变化的能力，实现系统整合和可持续的发展。

　　(作者单位：中交第四航务工程局有限公司信息中心)

　　版权声明：本文系工程建设网独家稿件，版权为工程建设网所有。转载须注明来源及作者，否则将追究法律责任。

【相关阅读】

• 建筑施工企业信息化的定位与发展
• 打造互联网浪潮下的传统业务管控新模式
• 顶层设计与实践探索相结合 ——中交四航局信息化探索
• 中交四航局信息化： 逐“浪”前行
• 岳口汉江特大桥主塔成功封顶
• 大数据提速招投标改革、加快企业转型