软件开发的去流程化设计原理与应用

王鸿捷

在企业软件开发管理部门的日常工作中，常常需要组织与开展大量的软件开发需求定义、需求架构评审和IT架构设计审查工作。总结既往软件用户企业与IT之间所存在的问题，本文阐述了基于微服务技术理论和技术架构下的、应用软件开发过程中的、去流程化设计的技术原理，分析了这一技术理论的提出背景，创新提出了“业务流程”、“流程要素”、“流程要素知识库”等认识论，论述了该技术理论的核心意涵与应用条件，简要介绍了实践中应用的情况，以促使更多的软件开发管理同行或软件开发服务商，对企业流程软件的开发管理与架构设计获得新的思路，提升面向企业业务流程类软件的业务粘度和使用弹性。

一、概述

企业软件开发管理的模式是多样而复杂的。

第一类情况，在缺乏专职管理部门和运行机制所保障的企业，面临企业级、部门级、专业级三个层级的软件开发工作时，通常采用了开发工作外包或者在商业软件基础上做定制开发的组织模式。

第二类情况，企业配置了专职或分管机构，也具备了软件开发的管理流程与管理制度，在软件自主开发组织与部分业务外包过程中，按照业务需求部门的委托或要求，组织开展业务流程梳理，并将梳理完成的业务流程作为招标技术要求的一部分或整体，进行选商、定商和软件开发。

上述两类情况，就软件开发组织工作而言有着共同的思维特征和行为指向：

以业务流程为核心构建软件的开发需求；

招标技术文件所指明的软件架构设计重点以及IT服务商的工作重点侧重于业务流程的IT化。

从笔者自身的从业经历来看，导致软件后期运行过程中产生大量新增定制服务、乃至软件生命周期较短难以可持续应用的问题根源，很大原因可能恰恰来源于此。

为此，本文试图站在一个软件开发管理者的视角，对这一问题产生的原因进行分析和总结，提出并阐述“软件开发的去流程化设计原理”的核心意涵与运用方法，从而找到一种更为科学软件开发管理的方法，并使软件具有更好的使用效果。

二、问题的提出与分析

正如前文所述，将线下流程IT化以后抽象成软件并交付用户使用，这一传统的软件开发管理与组织策略，很可能带来软件在业务层面的使用弹性和可持续性问题。

分析这一问题产生的根源，需要对“流程”这一概念的理解入手。

笔者总结了“流程”的认识论与逻辑，主要包括以下几个核心论点：

“流程”的形成，来源于“制度”和“生产组织方式”，而这二者不可能在一个企业的生产与经营过程中保持永久不变。

一个流程的形成，是由多个“流程要素”构成，而“流程要素”的实质是“企业管理要素”，而“流程要素”的多少，取决于软件用户对于特定管理对象的定义，因此，不应该试图用一个特定的“流程”去表达对多种管理形态的抽象。

与其说软件用户关注“业务流程”，倒不如说软件用户本质关注的是“适用的业务流程要素环境可能提供的自定义流程的灵活性和便捷性”。

基于以上三点认识，软件用户、软件开发组织者、IT承包商等软件开发工作的干系人，应将对“流程”的关注，转移到对“流程要素”的关注。

三、理论的提出与核心意涵

按照上述认识论，笔者于2014年提出了“软件开发的去流程化设计”思想，并应用于企业“协同办公系统开发”、“工程项目文档编码系统”、“企业数据云”等一系列软件开发工作中，取得了良好的效果。

2018年，将上述思想和应用结果加以总结，提出了“软件开发的去流程化设计原理”技术理论，即：

企业的业务流程，是由企业管理制度和企业生产组織方式所决定的，将随着企业管理制度创新、生产工具与新技术应用而不断演化，没有理由不应用一种业务流程的IT化去表达这一演化过程中所面临的同类需求；

信息化工作的任务不是将现有的业务流程软件化而是对流程要素加以关注和总结，推动不同流程要素知识库的形成；

表达在具体的软件开发组织与架构设计中，应采用基于类似于SOA微服务架构的“第二次抽象”基础上的“第三次抽象”（若流程的软件化定义为“第一次抽象”的话），考虑实施“流程要素”的模块化和知识化，同时在传统软件设计的基础上，增加用户“自定义流程”的软件界面，并选择适当的流程引擎，作为软件架构设计的核心思想；

用户使用软件时，按照“自定义流程”的方式，勾选“流程要素知识库”中的“流程要素”，将本次使用的业务流程加以预置，通过软件平台内的流程引擎快速实现特定流程的定制。

这一技术理论的核心意涵是：将软件的“第三次抽象”中原来由软件或其开发承包商完成的工作，交还给用户自定义完成，以满足当前或未来业务的适应性；而软件开发架构设计的要点，在于给用户创建一个满足其“自定义流程”或者“自定义规则”的快捷掌握和灵活高效的使用环境。

四、应用条件

这一技术原理的应用条件是需要基于SOA微服务架构。微服务架构的理念是将应用解耦成多个可完成独立功能的服务组件，每个微服务仅关注于完成一件任务并可很好地完成该任务，具体表现为：

软件被分为不同的功能模块，功能模块之间是相对独立、松耦合的关系，并可复用；

分解的功能模块是一个可独立维护、可替换的部件（Replacement Parts）。每个服务都可以作为单独的进程运行，不会造成整个应用的失败；

每个服务都定义了明确的边界，并且独立部署存在、易扩展 。

因此微服务是一个弹性的应用架构，可为实现软件的去流程化提供支撑。

五、实践与应用

案例1： 企业协同办公系统设计

该系统的研发，是立足一个商业协同平台、开展的一系列业务流程的定制工作。研发团队按照笔者提出的“自由流程”指导思想，设计并创建了“企业级人力资源数据库”、业务类型库、作业代码库、审批流程节点要素库，作为用户基于特定权限范围内的信息传输方式和业务流程自定义的关键。目前该系统已经平稳运行了4年。

案例2： 工程项目文件编码系统

工程项目的图纸或文件通常面对建设投资方、EPC总包商和本企业多个档案管理系统所要求的文件编码，如何快速有效保障项目的同一份文件、按照多个编码体系提交给对应的文档管理系统，成为长期困扰工程公司和设计单位的一个问题。传统的解决方案是采用一个项目配置多个文控人员的方式，成本和编码错误率高。

研发这一系统的目的，是想要实现“一个文控、随时自定义编码规则、所有文件编制人软件化使用”的目标。

本系统采用了“文件编码审批流程自定义+人力资源公共数据库+编码层级知识库+代码知识库”等流程要素的IT整合手段，实现了研发目的，目前已经在企业正常运行2年，优化了生产质量、提高了生产效率。

该技术理论还在很多企业绝大多数与业务流程相关的软件开发设计中得到了应用，应用效果良好。

六、结论

作为一种创新的技术理论，“软件开发的去流程化设计”的思想核心是关注流程产生的原因、流程软件化后当前的使用效果和未来可能的变化。

“软件开发的去流程化设计”所表达的，不能被简单理解为“软件开发不用关注流程”，而是对“流程要素”的关注远远重要于流程本身。

该技术理论不能被理解为“基于SOA微服务架构的技术理论”，软件设计中，两者只有依托关系，而不是等同关系。

该技术理论应用中有一项重要的工作：将“流程要素”知识库化。

作者单位：中国石油工程建设有限公司西南分公司