业务架构、信息架构、技术架构三位一体

1、业务架构、信息架构、技术架构三位一体客户天天打电话要修改产品功能，简单的一个需求可能要做一个月。产品越改越 笨重，为了赶工期bug越来越多。头疼！产品从初级版到现在已经四个年头，相关的程序员来去换了三批，在补丁上打 补丁是常有的事，很多功能只是开了个头，换个项目经理就被遗忘。我们总是害 怕客户在这个产品上提出新的需求，只要客户还用得过去，能不改就不改。即使 到了非改不可的地步，也会容忍这些僵化的代码带来的种种限制。昨天才刚上的功能，忽然又要去掉。客户在使用产品中的这些流程，难道事先 就没有人考虑到么？现在说这个功能重要，又说要做各种的接口和延展，需求积 压到这个程度，对不起！代码已经改不动了。

2、出来混，早晚是要还的。在初期，我们的客户并不了解信息化可以为他带来什么、改变什么。随着时间 的推移，企业信息化层层深入，甚至已经演变成企业在市场竞争中的利器，逆转 的情况就出现了。企业客户的业务流程从之前的顺应软件，逐步的变为让软件去 顺应该企业的发展。于是同一款软件的客户们提出了各种个性化的需求，加功能、 改流程、维护优化等等。那么，我们如何避免这些头疼的问题出现呢?这些问题出现的根本原因是商业软件的设计与开发方式已经不符合企业信息 化的发展要求。现在市面上大多数软件，是几个程序员凭自己对业务的理解，把 各种功能拼凑起来成的，在初期这些软件因为弥补了空白，企业确实看到了收获， 随着项目的推进

3、和新需求源源不断的产生，系统的维护压力越来越大，而且软件 中的业务流程与企业发展过程中的现实流程开始产生偏差，于是软件为了迎合企 业信息化的要求不断的修改，最后软件越来越笨重，导致很多新的业务流程无法 实现，代码已经改不动了，所以这套所谓企业信息化的系统能解决的大部分是固 定程式的业务，企业信息化进入纠结期。但是，企业已经尝到了信息化的甜头，在强大市场利益的驱动下，越来越多的 软件厂商并不一味的纠结下去，开始推出所谓的“客户化”，即以客户为导向， 收集客户的需求，搭建业务框架之后再开始编写代码。这种理念并没有被快速的 模仿，因为所谓的“客户化”往往把软件厂商弄得筋疲力尽，软件业是个靠大量 复制

4、用户而生存的行业，要做到真正的个性化服务需要承担的成本将非常大。所 以这种“客户化”的理念，还只是技术架构层面的范畴。最近在“客户化”的基础上，提出了“业务基础架构平台软件”按计世资讯的定义：业务架构平台软件是指以业务导向和驱动的、可快速构建 应用软件的平台。其包括集成应用平台、开发体系两个部分。从技术角度分析， 该平台软件为复杂应用软件系统的开发提供了一个基本框架，并有与之相应的、 方便易用的开发与维护管理工具。这个框架给出了一些复杂应用软件的基本组成 部分和实现方法，并且预置了很多供参考的软件模块。有了这样的准备，在业务 基础架构平台软件之上开发管理软件就可以降低复杂性，省去很多基础性的研

5、发 工作，从而大大缩短研发周期，提高研发效率。这种“业务架构平台软件”其实就是功能模块形式下的“客户化”。通过客户 的业务基础框架，软件会有很多模块化的功能和可扩展接口，一方面客户可根据 自身的业务特点从模块化的功能池子中选择需要的功能；另一方面，当池子中的 功能还不能满足客户需求时，通过模块化的扩展接口，程序员可以在基础平台上 迅速的开发新的功能。举个大家熟知的例子：WordPress这款博客软件正是这种 “业务基础架构平台软件”的典型，一方面提供很多栏目模块和功能供博主选择， 并且提供自定义；另一方面，因为这是一个开源的平台，所以会有各种各样的应 用被迅速的兼容进来。我们的软件不需要向客户

6、开源，不奢望客户参与开发，但 是如果这个平台有良好的业务架构和技术架构，软件的项目团队在做功能增加和 修改的时候只要模块化就行。于是，业务架构和技术架构被放到同一个高度上来， 避免出现开发过程以技术架构为主，业务架构为辅，业务进行架构设计之前过早 的进行大规模的代码编写。以上一直在强调模块化，这是“业务架构平台软件”的关键所在，但是这个模 块化，现今还处在摸索阶段，三百六十行，每一行的业务流程都不同，但是我们 通过大量的流程对比，是能够发现一些规律的，这些规律的组合就形成了模块。业务架构和应用架构这篇文章的作者无处查找，但是其中有一段话对业务架 构的模块化说明值得借鉴：“初看架构这个词容易理解

7、为静态的事物，但是广义 的业务架构一定是静态和动态分析的集成和融合，在分析过程中相互影响又相互 促进。动态的信息即我们说的普通的价值链分析的思路，从企业端到端的一级流 程到各个业务领域二级，三级等流程的分析。形成一级流程-子流程-活动-活 动单元-任务-事件的主线；而对于静态信息则包括组织，人员，岗位，角色， 业务对象和表单，规程，模板等各种信息。静态信息的重点是业务领域和业务对 象，即形成业务领域-业务主题域-业务模块-业务单元-业务组件的静态数据 逐层分解。静态信息+动态信息+交互点和接口分析后形成完整的业务架构。可以 看到流程再细粒度分解后的活动单元的组合可能形成业务组件和业务模块，同时

8、 业务模块本身又存在更细粒度的流程和活动分解，业务组件本身又是多个流程的 组成部分，因此静态和动态相互融合，形成交互，所以必须分析交互和接口。”除去以上这些，业务架构和技术架构下的模块化平台软件还具有以下特质:1、以用户为中心用户将成为信息化的主导，他们不用去考虑技术如何实现，只需要了解自身业 务流程，只需要利用模块池中的功能组装成符合自身需要的目标软件即可。这样 用户可以彻底改变以前信息化过程中的被动地位，从而有效保证软件和需求二者 之间的平衡。2、敏捷开发因为具备模块化的接口和延展性，所以程序员不需用从零开始逐步开发，只要 利用原有的模块为基础进行开发。3、集大成说到功能池的概念，这种软件

9、必将是一个集成了多种系统的平台，它就像PC 主板一样，会有很多插槽，无论你要建立什么样的管理系统，这些功能都将轻松 整合在一起。4、生命周期很长因为建立了业务架构和技术架构协调一体的机制，所以其生存的根本就在于能 够顺应企业的发展，通过敏捷开发的方式来实现软件的生命周期模型。这些因素 都有效地驱动了软件的持续完善，从根本上保证了管理软件和企业发展的动态平 衡关系，使软件具备较长的生命周期。在业务架构和技术架构协调一体的同时，渐渐发现，因为企业的应用越来越多， 企业应用的多样性、复杂性以及它们直接相互关联交互的需求增强，已经越来越 多的企业从应用层上升到了数据层，如果还是像传统软件一样，将数据存

10、储在系 统文件中，那么这个所谓模块化的“业务基础架构软件”仍然无法发挥他的威力。这时候就应该将信息系统架构提到业务架构和技术架构的高度，协同解决。我 们称之为“业务架构、信息架构、技术架构三位一体”很荣幸，从2022年开始，我主导了一款餐饮行业应用软件的设计和规划工作。 这一年半的时间里，在项目组摸索寻找这种一体化的工作方法。其实并不是三种 架构都在同一个地方等你，而是走着走着发现问题，然后一个一个的捡起来，最 后发现其实一开始三者是可以结合成一体的。在信息架构中，我们不仅将企业数据存储到数据库中，而且将这一数据库存储 到统一的服务器中，作为数据层开放。采用C/S结构，让客户和服务器实时交互， 系统记录客户的操作数据，通过对这些数据的分析归纳，做出行业通用的业务模 型。客户通过与服务器的链接，可以任意的在功能池子中选择自己需要的模块。IBM在介绍其DB2pureXML时曾经提到：“由于这种开放的服务特性，这类核 心信息在服务各种业务的过程中必然需要考虑很大的差异性和复杂性，必然需要 把数据的存储和数据的访问隔离。数据的差异性和复杂性将对数据模型的灵活性 和可扩展性提出更高的要求，而数据的访问和底层存储的隔离，将直接导