系统业务架构

1、系统的特性

百科中对系统的定义是"系统就是若干相互联系、相互作用、相互依赖的要素结合而成的，具有一定的结构和功能，并处在一定环境下的有机整体"。这句话还算好理解，大概知道表达的意思，似乎少了一点什么，对"系统"的含义要进一步提炼：系统的特性是什么。

现有的系统是很复杂的，复杂源于问题域的复杂、管理过程的复杂、需求灵活扩展的复杂。既然是复杂的，难道就不能应对么，肯定能的，应对复杂系统有一套方法，这个在本文的第三部分会着重提到。到目前我们知道系统是复杂的，复杂的来源是有哪些因素。

经过长期的实践和观察，人们有一个非常重要的发现：系统是具有分层的特性。如植物，它是分层的，有细胞、组织.....。这种层次代表的不同的抽象级别。一层构建在另一层之上，每一层可以分开理解，每一层为更高层提供服务。我们的计算机也是具有这种层次的，站在每一层上，可以独立的去理解它。

后面的内容都是通过系统具有分层的特性展开的，如何、怎样去分层，分层的方法思想是什么，结合券实例业务架构来说明。

2、架构

架构一词，我们可能每天都听到，那什么是架构呢？百科中的定义是"又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计"。这个听下来好像收获不大，个人觉得技术一定要内化自己的理解。经过长时间的思考，我对架构的理解是按照架子把它构建出来。问题来了，什么是架子、怎样构建呢？

架子是"大图"(架构的产出物)，通过这个"大图"我们就可以知道整体的内容，当前所做的东西处于大图的位置。架构是为了解决协同开发问题，这个可能我们有点难理解，什么是协同开发呢。如果软件开发是串行的，你要等着别人开发完了再去开完，那效率太低了，软件开发一定是并行开发的，就要解决协同的问题。所以也有人说架构的本质是解耦，协同开发也是为了解决解耦问题，不同的表达，在低层的含义是相通的。

怎样构建是一套标准和规范，用于指导"大图"的落地实现。架构也分为业务架构、应用架构、部署架构等，所以架构的产出物对应也不同，构建的方式也不一样。如业务架构的产出物是业务架构图，要描述出用户视角、业务场景、产品功能。

3、业务架构方法

通过前面二部分的阐述，到目前我们知道系统具有层次特性，虽然是系统的通用属性，那我们现有的系统也一定具有这个特性。从系统的层次性性出发，有方法去理解系统。

在经过自己的思考，总结业务架构的方法：分解、抽象、层次结构。

层次结构：这个最好理解，上面多处提及这个，所以我们在画业务架构图的时候，一定要体现出层次结构的特性。越往下层，越抽象，越往上层，越具体。

抽象：层次分好了，那每一层的内容应该是相似的。什么抽象？我自己的理解是抽象是抽出来要像，也即是要反映本质。根据实验表明，人接收的信息大概在7个左右，太多了记忆不住，一定要提及核心。

分解：既然系统具有分层，那是要找出这个分层，这个分层的指导就是分解。常用的分解方法有算法分解、面向对象分解。

综上，根据上面的方法，对业务架构的步骤如下：

1）业务流程分解，不断细化业务子流程
2）当子流程细化完后，对相同、相似的进行抽象合并
3）按照层次特性画出最终的业务架构图

4、总结

本文先从系统的分层特性谈起，然后根据分层特性，探讨方法：分解和抽象，最后总结业务架构的步骤。