菡萏如佳人
企业级业务架构设计
基础篇
业务架构发展历程
Zachman模型
5W1H模型
TOGAF模型
将企业架构分为两大部分：业务架构和IT架构，目前最为流行的业务架构模式
DODAF模型
美国国防部体系架构框架，8个视点，52个模型
业务架构定义
以实现企业战略为目标，构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法
企业级业务架构一般都跨越产品线、业务领域，实现业务与技术的深度融合
业务架构与IT架构
业务架构作用
- 企业战略落地
- 业务需求到IT的顺利传导
传统行业的先行者已经实现了数字化，成为科技公司(美团、滴滴、星巴克)，后觉者至少应该利用好现有的技术，转变思维方式，架起一道跨越数字鸿沟桥梁，这座桥梁就是业务架构起的核心作用。
业务架构可以帮助业务人员整体化、结构化的思考问题，从业务和系统的整体视角，结合技术去理解业务和技术；帮助技术人员理解、归纳业务人员的想法和目标，让业务和技术人员形成统一语言(处于同一个语境下沟通)，顺利帮助企业完成数字化转型。
业务不管技术如何实现，和技术听懂需求就足够的时代即将(已经)过去了，现在是深度融合的时代。如果业务无法被很好地结构化、模块化，技术人员也很难做出一个具有良好架构的系统。
业务架构与IT架构关系
业务架构是企业战略的一部分，而不是IT战略的一部分，它是企业战略的实现方法；IT架构是用于企业信息化建设的，是企业战略的系统实现部分。
业务架构是灵魂，IT架构是容器，是灵魂载体，没有灵魂的容器是毫无生机的，所以技术人员需要关注业务和业务架构。
业务架构从企业战略出发，按照企业战略设计业务及业务过程，业务过程需要业务能力来做支撑。
IT架构的4种架构特点：
- 应用架构：关注功能布局，与业务架构关系非常紧密，是业务架构的紧后工序
- 技术架构：关注分层结构，对于大型业务系统来说，一个逻辑分层可能需要多种平台才能实现(业务架构师一般不参与该架构设计工作，但需要了解)
- 数据架构：关注数据模型，与业务架构关系密切，甚至可以说是业务架构的组成部分
- 安全架构：关注网络安全、信息安全防护，具备明显的规划特征，随着信息安全重要性提升与重视，与业务架构关系也将越来越紧密
IT架构中的应用架构和数据架构与业务架构的关系是最为紧密的。从实践的角度来说，如果企业没有那么多的架构设计人员，那么应用架构与业务架构可以合并，毕竟业务能力规划清楚之后，向部署延伸一点就是应用架构。
如果将业务架构与应用架构合并，那么让经验丰富的技术人员担任此项工作会更为合理，但要求相关人员必须具有良好的业务思维。
架构伴侣：业务模型
业务架构是战略、流程、组织等业务元素的结构化表达。而业务架构结构化表达的基本方式就是业务模型。
模型与业务模型
模型是所研究的系统、过程、事物或概念的一种表达形式，也可指根据实验、图样放大或缩小而制作的样品。
模型可以是抽象的，也可以是具象的。
业务模型就是对业务的表达，它的范围需要根据实际产品业务需要去确定，最主要描述的就是阻止及其运作过程
企业业务模型的最高阶抽象三角：它是一切盈利性企业的基本行为
企业为生产而投入成本，产品或服务销售后获得收入，而衡量企业业绩的最基本方法就是计算收入减去成本所得的利润
从这个最高阶的核心模型出发，我们可以演化出整个企业的业务过程，可以模型化地创造一个企业，这就是所谓的“大道至简，衍化致繁”。
常见建模方法
- ISO 9000模型：带职能泳道的业务流程图
-
BPMN：Business Process Model and Notation (业务流程建模与标注)，包含事件、活动、网关在内刘对象、连接对象等
-
UML：统一建模语言，主要包含功能模型(用例图)、对象模型(类图)、动态模型(活动图、序列图、状态图)
建模原则与模型思维
建模没有秘籍，建模有标准可以遵循，但是模型质量尤其依赖建模者的经验与水平。
做好建模要遵循两个原则：
- 1 整体性原则：先从全局入手，再到局部，不要被业务细节吸引(思考下分组做飞机模型很难成功的例子)
- 2 合适性原则：契合实际的业务特点和战略规划，不要生搬硬套、放大需求、过于理想化(将世界上最美的五官凑在一起可能是个怪胎)
避免自己成为PPT模型师的3个模型思维：
- 1 把握整体：弄清楚任务来龙去脉与前因后果
- 2 穿透现象：注意事物的内在联系，透过现象看到本质，抓住问题本质，找到问题的最佳解决方案
- 3 保证落地：一切不考虑落地的架构设计都是耍流氓
目前主流的软件设计方法其实都是MDD（Model Driven Develo-pment，模型驱动开发）形态的，无非是建模工具、建模方法的差异，即使是火热的中台模式，其设计过程也离不开模型方法。