企业级业务架构设计：方法论与实践 学习笔记
一 摘要
本篇还是基于《企业级业务架构设计：方法论与实践》一书，探讨业务架构与IT架构之间的关系，以及业务模型。个人和身边的人，通常会把IT架构称为技术架构，技术架构的表现形式通常还包括诸如4 1视图等等。所以换句话说，就是讨论业务架构和技术架构之间的关系，也就是如何把抽象的业务，落地为具体的技术实现。
二 业务架构的作用及与IT架构的关系
2.1 业务架构的作用
”业务架构的作用通常被认为是连接业务与IT的纽带，用于实现业务需求到IT的顺利传导。对于TOGAF等企业架构理论来说，业务架构也承担着将企业战略落地的职责。“
但时代发展到现在，业务架构还应该承担帮助企业完成”数字化“转型，使企业通过信息技术将内部、业务与IT连接起来，称为”数字化“企业的作用。
2.2 业务架构与IT架构之间的关系
在TOGAF框架中，业务架构被视为IT战略的一部分。但事实上业务架构应该属于企业战略，而不是IT战略。业务架构不同于业务需求，是企业业务战略的实现方法。包含企业战略的系统化和非系统化部分，是企业业务战略的全景描述；而IT架构是企业战略的系统实现部分。在书中，业务架构和IT架构，被形容为”灵魂“与”容器“的关系。
在书中，IT架构包含 应用架构、技术架构、安全架构，以及数据架构。 4种架构的特点及关系如下：
（1）应用架构关注功能布局，与业务架构关系紧密；
（2）技术架构主要关注分层结构；
（3）数据架构主要关注数据模型，数据模型与业务架构关系密切，甚至可以归类为业务架构的组成部分；
（4）安全架构与业务架构一般关系不是很紧密，但目前安全架构设计的一个发展趋势是向业务架构靠拢，甚至是向企业战略靠拢，使得安全架构设计更符合实际业务需要。
三 业务模型
3.1 业务模型简述
业务架构是战略、流程、组织等业务元素的结构化表达，因此， 说起业务架构，自然离不开结构化表达的基本方式——业务模型。
关于模型的定义很多，我们选择其中一种易于理解的描述：模型是所研究的系统、过程、事物或概念的 一种表达形式，也可指根据实验、图样放大或缩小而制作的样品。
业务模型最主要描述的就是组织及其运作过程。企业的业务模型有一个最高阶抽象的三角形，如下所示：
这个模型代表了所有盈利性企业的基本行为，企业为生产而投入成本，产品或服务销售后获得收入，而衡量企业业绩的最基本方法就是计算收入减去成本所得的利润。q企业的所有行为都会产生数据，这些数据是我们做系统设计时的必要 输入，是结合业务流程做架构分析的基础。
3.2 常见建模方法
3.2.1 ISO9000
ISO9000质量体系认证是由国家或政府认可的组织以ISO9000系列质量体系标准为依据进行的第三方认证活动，以绝对的权力和威信保证公开、公正、公平及相互间的充分信任。
1992年，中国等同采用ISO9000系列标准，形成GB/T19000系列标准。欧共体提出欧共体内部各国企业按照ISO9000系列标准完善质量体系，美国把此作为“进入全球质量运动会的规则”。
申请ISO9000质量认证的企业，通常要绘制企业的业务流程图，流程图的样式为垂直职能带型，通常使用Visio等工具进行绘制。对业务人员非常友好，但如果想应用到软件设计领域则有所不足，表达能力过于单一。
3.2.2 BPMN
BPMN（Business Process Modeling Notation）指业务流程建模与标注，包括这些图元如何组合成一个业务流程图（Business Process Diagram），是BPM及workflow的建模语言标准之一。
BPMN定义了一个业务流程图（Business Process Diagram），该业务流程图基于一个流程图（flowcharting），该流程图被设计用于创建业务流程操作的图形化模型。而一个业务流程模型（Business Process Model），指一个由图形对象（graphical objects）组成的网状图，图形对象包括活动（activities)和用于定义这些活动执行顺序的流程控制器（flow controls）。
对于业务人员来说，BPMN需要一定的学习过程，但掌握难度不大，并且还可以将其应用到业务工作中；BPMN对技术人员来说，除了可以正常辅助业务分析之外，还可以用于工作流引擎设计。
在工具上，Visio，Processon等工具都提供了对BPMN的支持。
3.2.3 UML
UML即统一建模语言（Unified Modeling Language），由模型元素(Model Element)、图(Diagram)、视图(View)和通用机制(General Mechanism)等几个部分组成。技术人员（开发者、程序员）对这个运果果非常熟悉。
UML作为一种统一的软件建模语言，具有广泛的建模能力。UML是在消化、吸收、提炼至今存在的所有软件建模语言的基础上提出的，集百家之所长，是软件建模语言的集大成者。UML还突破了软件的限制，广泛吸收了其他领域的建模方法，并根据建模的一般原理，结合了软件的特点，因此具有坚实的理论基础和广泛性。UML不仅可以用于软件建模，还可以用于其他领域的建模工作。
UML的三个（三类）主要的模型：
- 功能模型：从用户的角度展示系统的功能，包括用例图。
- 对象模型：采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类别图、对象图。
- 动态模型：展现系统的内部行为。包括序列图，活动图，状态图。
业务架构是搭建业务与技术之间的桥梁，所以作为业务架构在结构化表达方面不可或缺的工具，业务模型必须同时照顾业务与技术双方的感受，即表达能力丰富、兼具业务和技术友好性的建模方法对业务架构而言更为合适。
如果企业在以往的技术实现中已经习惯于采用某种建模方法，而犹豫是否要进行模型方法层面的大调整，则要考虑如下因素以判断是否进行该调整：
1) 是否可以对原有方法进行改造以弥补缺陷。如果原来的方法太过面向技术，那么能否增加面向业务端的合适的展现方式?如果对改造效果的评估或者试验不乐观，那么建议还是切换建模方法
2)原有的模型成果是否还有复用的价值。如果企业决心进行大规模转型，那么原有的模型成果除了提供初期分析的信息输入之外，基本上再不会有多大的复用可能性，切换建模方法也就没什么不可以的了。
3.3 建模原则与模型思维
3.3.1 建模原则
主要包括两个：整体性原则 和 合适性原则。
整体性原则是指：一定要将问题域(或者说建模对象)通盘考虑清楚，先有整体轮廓再考虑局部设计。企业中常见到的“竖井式”开发，就是因为没有按照整体进行过设计，所以才出现这样的情况：每个子系统独立工作时都很正常，协作起来就不行。
合适性原则是指，模型中所包含的各个部分、各类元素要有机地结合在一起，而不能在设计时为了图新潮、赶时髦，甚至为了建模者个人的“执念”，放大需求、胡思乱想、生搬硬套，只想进行“理想”的实现。
3.3.2 模型思维
(1)把握整体
摸清事情的来龙去脉、前因后果，这样才能控制好工作的度，以免过犹不及。
(2)穿透现象
即“透过现象看本质”，找到解决问题的最佳方案。
(3)保证落地
“一切不考虑落地的架构设计都是耍流氓”。我们见到过很多架构设计，看起来很复杂很完美，但实际上并不可行。真正能够解决实际问题，能够落地的架构设计，才可能被称为好的架构设计。空中楼阁要不得。
