业务架构是战略、流程、组织等业务元素的结构化表达，因此，说起业务架构，自然离不开结构化表达的基本方式——业务模型。
模型与业务模型
业务模型也是模型的一种，因此我们需要先从模型讲起。关于模型的概念，各位读者可以查到很多种定义，不过，笔者觉得百度上有一种定义比较容易理解：模型是所研究的系统、过程、事物或概念的一种表达形式，也可指根据实验、图样放大或缩小而制作的样品。
很多人一谈起模型就认为模型是抽象的，模型最重要的就是抽象，这种说法对软件开发人员而言并无不妥，但是对于理解模型的概念而言，还是有些狭隘了。模型也可以是具象的，可以是实物，比如售楼处常见的楼盘模型，古时的工匠为皇家修建故宫、亭台楼榭时，也会先做出精巧的木制模型，而且是与实物构造一模一样的“高精度”模型。模型不仅可以是真实的事物，也可以是虚拟的，只要想象力足够强大，即可创建虚拟模型，比如时下很流行的高达玩具模型、变形金刚等。模型当然也可以是抽象的，比如软件开发中常用的实体模型、时序图、状态图、用例图等。几种不同类型的常见模型。
模型就是一种表达形式，其实我们所说的话也可以视为一种模型，它是我们头脑中某种想法的表达，表述的过程即可看作是建模的过程，同时我们的表述还遵循了一定的语法规则。所以，模型其实并不神秘，对于业务人员而言，工作时经常会画的业务流程图也是一种模型，与软件开发中所用的模型相比，无非是存在建模视角和抽象程度的差别。
理解了模型，我们再来看一下业务模型。套用上文所述的概念，业务模型就是对业务的表达，至于这个业务的范围就要看实际需要了。如果只是针对一个产品，那么业务模型可能就是对产品的设计、生产、销售、使用、售后管理过程的描述，其中还要包含所有参与方的目标、活动、角色、职责等。如果针对的是一个大型企业，那么业务模型的范围就可能包含多条产品线，每条产品线都有不同的业务过程，而所涉及的参与方也会更多、更复杂。
所以，业务模型最主要描述的就是组织及其运作过程。企业的业务模型有一个最高阶抽象的三角形。
这个三角形可以说是一切盈利性企业的基本行为，企业为生产而投入成本，产品或服务销售后获得收入，而衡量企业业绩的最基本方法就是计算收入减去成本所得的利润。
所有企业的行为都可以从这个三角形出发进行分析，比如，一个企业的基本流程可以概括如下。
企业确定向哪些人销售自己的产品或服务，这就体现了企业自身的价值定位。
- ·企业准备组织哪些人进行生产、销售，在什么样的渠道上销售，为此投入什么样的资源，这就是企业的生产和销售流程。
- ·收入和成本都需要记账，这就是财务会计的流程。
- ·对利润实现情况的衡量、盈亏原因的分析等，都体现在管理会计中。
所有的行为都会产生数据，这些数据是我们做系统设计时的必要输入，是结合业务流程做架构分析的基础。从这个最高阶的核心模型出发，我们可以演化出整个企业的业务过程，可以模型化地创造一个企业，这就是所谓的“大道至简，衍化致繁”。
常见的建模方法
1.ISO 9000模型
业务人员在业务学习过程中很容易接触到流程模型，比如ISO 9000质量体系中会使用的流程模型。ISO 9000质量管理体系是国际标准化组织（ISO）制定的国际标准之一，是指由ISO/TC 176（国际标准化组织质量管理和质量保证技术委员会）制定的所有国际标准。该标准可以帮助组织实施并有效运行质量管理体系，是质量管理体系通用的要求和指南。
1992年，我国等同采用ISO 9000系列标准，形成GB/T 19000系列标准，随后，各行业也将ISO 9000系列标准转化为行业标准。申请ISO 9000质量认证的企业，通常要绘制企业的业务流程图，流程图的样式为垂直职能带型，通常使用Visio工具进行绘制。
ISO 9000模型对业务人员非常友好，但是，将其应用到软件设计领域，则会出现表达能力比较单一，对技术分析而言有所不足的问题。
2.BPMN模型
BPMN（Business Process Model and Notation）即业务流程建模与标注，是由BPMI（The Business Process Management Initiative）开发的一套建模标准语言。2004年5月，BPMI正式发布了BPMN 1.0规范，其后，BPMI并入到OMG组织，OMG于2011年推出BPMN 2.0标准，该标准对BPMN进行了重新定义。
BPMN的主要目标是为所有业务用户提供一些易于理解的符号，支持流程的创建、分析和实现，直到最终用户的管理和监控。开发BPMN的核心目标就是要构建从面向业务流程建模到面向IT执行语言的一座桥梁，因此BPMN的出现填补了从业务流程设计到流程开发的空白。
BPMN的工具较多，图元比较丰富，网上可以很容易地找到一些范例和工具介绍。
作为建模语言而言，BPMN的表达能力很强，其元素的核心集包括含事件、活动和网关在内的流对象（Flow Objects），含顺序流、消息流以及关联在内的连接对象（Connecting Objects），含数据对象、文字注释和组在内的工件（Artifacts），以及作为图形化容器的泳道。
BPMN对于业务人员而言需要一定的学习过程，业务人员通过学习不难掌握BPMN，并且还可以将其应用到业务工作中；BPMN对技术端而言，除了可以正常辅助业务分析之外，还可以用于工作流引擎设计。
3.UML（统一建模语言）
技术人员非常熟悉UML（Unified Modeling Language，统一建模语言），UML是非专利的第三代建模和规约语言。UML可应用于一系列最佳工程实践，这些最佳实践在对大规模、复杂系统进行建模方面，特别是在软件架构层次中已经被验证有效。
UML体系中包含了3个主要的模型，具体说明如下。
1）功能模型：从用户的角度展示系统的功能，包括用例图。
2）对象模型：采用对象、属性、操作、关联等概念展示系统的结构和基础，包括类图、对象图。
3）动态模型：展现系统的内部行为，包括序列图、活动图、状态图。
由于UML在开发中已经广为使用，因此本书不再赘述其示例。UML对技术人员比较友好，但是其缺点也十分鲜明，就是对业务人员非常不友好。
业务架构的任务是搭建业务与技术之间的桥梁，所以作为业务架构在结构化表达方面不可或缺的工具，业务模型必须同时照顾业务与技术双方的感受，也即表达能力丰富、兼具业务和技术友好性的建模方法对业务架构而言更为合适。如果企业在以往的技术实现中已经习惯于采用某种建模方法，而犹豫是否要进行模型方法层面的大调整，则要考虑如下因素以判断是否进行该调整。
1）是否可以对原有方法进行改造以弥补缺陷。如果原来的方法太过面向技术端，那么能否增加面向业务端的合适的展现方式？如果对改造效果的评估或者试验不乐观，那么建议还是切换建模方法吧。
2）原有的模型成果是否还有复用的价值。如果企业决心进行大规模转型，那么原有的模型成果除了提供初期分析的信息输入之外，基本上再不会有多大的复用可能性，切换建模方法也就没什么不可以的了。
建模原则与模型思维的应用
既然业务模型对业务架构、系统设计如此重要，那么建模是否存在什么“秘籍”呢？很遗憾，没有。这不仅是笔者个人的理解，不少关于建模的书中也都提到过，建模看似有很多种方法、标准可以遵循，但是模型质量尤其依赖建模者的经验，是一个“熟练工种”，经验丰富很重要。
虽然没有捷径，但还是有两个原则需要读者时刻注意。
第一，整体性原则。做模型切忌快速上手，不要轻易被业务细节吸引，更不要被立马解决问题的冲动所左右，一定要将问题域（或者说建模对象）通盘考虑清楚，先有整体轮廓再考虑局部设计。管理课上讲沟通时经常会列举一个“做飞机”的例子，先将听课的学员分成若干组，每个组设计飞机的不同部分，比如机首、机身、机翼、机尾，而不给出整体要求，组间也不允许沟通，然后将各组的设计拼接起来，最终很可能就会看到这种结果。
没有整体性原则做指导，就真的可能会做出不仅飞不起来，而且还极其“丑陋”的飞机。企业中常见到的“竖井式”开发，也会出现这样的情况，每个子系统独立工作时都很正常，协作起来就不行，因为原本就没有按照整体进行过设计。
第二，合适性原则。读者可能听过这样一个比方，将世界上最美的五官凑在一起，并不会成为世界上最美丽的脸，这就是合适性原则。美丽的脸通常是五官比例好、搭配好的脸，也就是说，模型中所包含的各个部分、各类元素要有机地结合在一起，而不能在设计时为了图新潮、赶时髦，甚至为了建模者个人的“执念”，放大需求、胡思乱想、生搬硬套，只想进行“理想”的实现，而不进行“合适”的实现，漠视客观现实和循序渐进而导致设计结果的“无用”。
业务模型是为业务架构服务的，所以细心的读者也一定注意到了，上文所述的这两条原则其实也是架构设计的重要原则。建模唯有不断练习，不断参与项目实践，以获得对建模成果的重要反馈，才能有所提高。设计上经常将不管实现结果的架构师称作“PPT架构师”，其实建模也是一样，若不能在生产环境中得到反馈，那么建模者也会成为“PPT模型师”，所以说，实践是理论之源。
做过建模的人都能理解，认真建模是一件枯燥又繁琐的事情，前文中也曾提到过，业务架构设计可以帮助业务人员提升逻辑思维能力，应该让业务人员多参加。那么对于广大业务人员而言，投入这么大的精力参与这么枯燥的工作，完结了项目之后，这技能还能用得上吗？答案是肯定的，虽然业务人员不会在项目结束之后还继续建模，但是重要的模型思维却是终身受用的。
如下3点模型思维是在各类工作中都值得借鉴的。
（1）把握整体
关于把握整体的重要性这里不再赘述，关于其应用场景，举例来说就是，对于领导交办的任何工作，尽可能不要第一时间就“Just do it”，而是要先抽出点时间，考虑下事情的来龙去脉、前因后果，这样才能控制好工作的度，以免过犹不及。时间和人力是企业最宝贵的资源，不是任何事情都值得投入最大的精力去追求满分效果，要从整体着眼来评价工作事项，尽量杜绝过度“敬业”对时间和人力的浪费。
（2）穿透现象
露出水面的往往是冰山一角，能够透过现象看本质是对建模人员工作能力的基本要求。这种注意事物内在联系、本质差别的能力，有助于读者拨开笼罩在现象表面的“迷雾”，找到解决问题的最佳方案。这种思维方式在任何工作中都是可以用得上的。
（3）保证落地
曾经有句流行语：“一切不为业务目的服务的技术都是耍流氓”，这里套用一下，“一切不考虑落地的架构设计都是耍流氓”。架构不能只是停留在口头上，纸面，真正了解架构本质的人，无论做出什么样的设计方案，都会以落地实施为前提。对应到日常工作中，就是无论何时何地，各位提出的工作建议都不能只是“空谈”，都要为其实现而负责。落地靠的是经验、方法、能力，而不完全是信心，所以，工作要慎重，胆大的同时更要心细。
关于模型的一些基础性介绍先到此为止，本书所讲的业务架构都是使用业务模型来构建的。虽然业务架构与模型之间关系紧密，但是必须明白的是，架构不等同于模型，模型也不等同于架构，不要将二者混为一谈，架构相当于思想，模型只是表达。实践中如果遇到问题，一定要先想清楚原因，不要因为模型表达方式不理想而认为架构无用，也不要因为架构设计不理想而埋怨模型。
目前主流的软件设计方法其实都是MDD（Model Driven Development，模型驱动开发）形态的，无非是建模工具、建模方法的差异，即使是火热的中台模式，其设计过程也离不开模型方法。
