600字范文 > 企业级业务架构设计

企业级业务架构设计

时间：2024-02-04 02:23:16

相关推荐

企业级业务架构设计

一切有为法

如梦幻泡影

如露亦如电

应作如是观

--《金刚经》

一、业务架构与IT技术架构的关系

1、业务架构的任务是搭建业务和技术之间的桥梁

2、每个人都具有一个有趣的灵魂，人如果脱离了灵魂则是无生机的行尸走肉

3、IT技术架构也一样，IT技术架构就像一个容器，业务架构则像灵魂，注入了灵魂的技术架构才会富有生机，更有自己的独特的特色，脱离了则会变成了生搬硬套

4、业务架构是包含IT技术架构的，技术架构是业务架构的系统化表现，IT架构根据灵魂的需要来设计容器，业务架构是从企业战略出发的，按照企业战略设计业务的过程，业务架构是企业战略的全景图

5、中台战略实际上可以理解归结为一种业务架构的设计

6、应用架构重点关注的是功能的布局与业务架构的关系非常紧密；

7、技术架构主要是关注分层结构，通过业务特征、业务量等多因素综合考虑分层的合理性和平台选型；

8、数据架构重要的组成是数据模型，与业务架构关系紧密，一般可以归类为业务架构的组成部分

9、安全架构（网络安全，信息安全等防护型工作）目前也在向业务架构和企业战略靠拢的趋势，使得安全架构更贴近实际业务的需要，符合企业的发展方向

10、将灵魂注入容器，能否顺利注入，让灵魂有一个适宜的居所，则需要充分理解灵魂，业务架构则可以引导这一认知的过程，让朦胧神秘、纷繁复杂的灵魂清晰可见

11、业务人员学习业务架构是有好处的，可以更贴近技术可实现的方案，例如买茶叶，基本大部分人对于茶叶的知识都来自于茶叶商或者茶农，让客户更了解产品，会让客户产生更浓厚的兴趣，拓宽市场

二、业务模型

1、业务模型：结构化表达的基本方式

2、大道至简，衍化致繁

3、BPMN 业务流程建模与标注，工作流引擎设计，时序图，流程图，用例图，状态图等

4、UML 统一建模语言，功能模型（从用户的角度展示系统的功能，例如用例图）；对象模型：采用对象、属性、操作、关联等概念展示系统结构和基础，例如类图、对象图；动态模型：展示系统内部行为，

（例如序列图、活动图、状态图）

5、建模方法是否调整需考虑：是否可以对原有方法进行改造以弥补缺陷；旧的模型是否还有复用价值；

6、建模原则：

（1）整体性原则：切记快速上手，不要被业务细节左右，不要为了解决问题产生的冲动左右，要整体考虑清楚（拼装飞机例子）

（2）合适性原则：世界上最美的五官拼凑在一起，并不会成为世界上最美丽的脸，需要有机结合

7、不要做PPT架构师，PPT建模师（不管实现结果的设计），不断参与项目实践，不断练习和提升，建模的思维是终身受用的

8、模型思维总结：

（1）把握整体（Don't just do it）

（2）穿透现象（露出水面的往往只是冰山的一角，透过现象看本质）

（3）保证落地（一切不为业务目的而服务的技术都是耍流氓，一切不考虑落地的架构设计都是耍流氓）

9、架构是思想，模型是表达，架构和模型并不等同，相辅相成（有一个好点子，则需要准确的语言表达出来，反之亦然）

三、业务架构设计起点

1、业务架构是面向企业战略和企业整体的，设计和落地是不断的交替上升的过程

2、实施中对业务架构进行基于实现的最终调整，确保业务架构与IT实现之间的一致性，落地后则会依靠业务架构管理企业需求、处理战略迭代的业务

3、以前业务推动技术，现在的趋势技术引领业务，对新技术的理解通过业务架构设计引发业务变化，用新技术理念推动业务模式演变，再进行IT技术开发，业务和技术融合的理想模式

4、战略作为业务架构分析的起点，业务架构设计必须透彻理解其战略，工欲善其事必先利其器，学习优秀的模型设计方法

5、无法衡量的目标只能是个精神口号，不能转化为行动，口号必须可以被分解成可以指挥行动的具体度量

6、对标分析：分析同行业优秀业务架构或技术架构模型，寻找并绘制符合本企业战略的模型

7、组织架构：通过企业的系统架构可大致了解企业的项目运营模式，单体应用还是分布式应用，人员是多组织协同作战还是各自为战

四、业务架构的设计过程

1、价值链分析：迈克尔·波特1985年首次提出的，主要包括基本活动和支持性活动，价值链主要描述的是企业价值的创造过程，通过价值链分析可以横向审视自身的业务能力

（1）基本活动：主要的生产过程

（2）支持性活动：对基本活动的辅助作用及维持企业基本运转的各类活动

2、行为分析：业务领域和业务流程

3、业务领域：从客户出发和从产品出发，取决于企业关注点，横轴（价值链）纵轴（业务领域），企业确定已某类产品服务与某类客户的一个业务范围，为实现这一价值定位，企业在整个价值链上的各种业务活动的有机结合

4、业务流程（活动、任务、角色）：BPMN工作流，根据价值链拆解企业活动中的价值点作为流程结点

5、业务数据

6、业务组件

7、总结：通过价值链拆解企业行为活动为价值链环节，业务活动通过工作流可以拆分为多个任务，数据域将关系紧密的数据实体进行聚类，结合任务则形成了业务组件，那么这一类的业务组件就可以提供同一类的业务能力，对组件能力的开放共享，实现企业级能力复用（不同活动中的任务复用），使得数据得以在不同业务组件中进行流动，实现互联互通

五、业务架构设计难点

1、标准化工作：数据标准化和任务标准化

（1）数据标准化：保证数据实体和属性的唯一性，避免造成数据的同义不同名

（2）任务标准化：流程模型与数据模型语义对接；分析重复的业务动作；做出关于标准化的建模判断（抽离出标准化组件，完成标准化过程）；

2、避免过度整合：数据实体颗粒度过小会放大业务差异，颗粒度过大则会忽略业务差异，流程模型与数据模型的语义互查是进行合理标准化的关键，需反复锤炼

3、何以解忧，唯有融合：建模依赖业务人员的经验和高质量的建模输入，需要业务人员和技术人员更好的融合

4、应当是在技术人员与业务人员的不断融合、反复的标准化与去重过程中沉淀

六、业务架构落地方案

1、建立通过业务模型设计的企业级业务架构模型，经过标准化、模型化的过程，形成了企业级业务组件、数据主题域的划分

2、从战略的角度出发，首先要分析企业的目标以及为实现目标所需要的业务能力，然后按照业务领域，将能力需求落实到实际的业务流程中，并根据架构设计方法，划分出能力组件，行程企业能力视图，产生了高阶架构

3、制作业务架构方案：将模型转化为业务架构设计方案，包含三部分文档：企业级架构方案的整体描述、分领域或分应用的方案描述、业务组件的方案描述

4、业务组件的目标和范围即业务组件主要支持的能力方向和边界的描述

5、熵增：熵代表了无序性，熵增则为有序向无序的发展，大型企业消耗巨大能量沉淀文档为了对抗熵增，小型企业则无需消耗能量，只需创建独有的通用语言，让各方可以快速理解掌握模型的表达和模型所具备的能力,熵增定律并没有我们想象的那么复杂，它是热力学第二定律，是德国人克劳修斯提出的理论。在1865年，德国物理学家克劳修斯首次提出了“熵”这一概念，他认为：在一个封闭的孤立系统内，热量总是从高温流向低温，从有序走向无序，而且这一过程是不可逆转的;1943年，伟大的物理学家薛定谔就曾在其著作中提出：生命以负熵为生，人活着就是为了对抗熵增定律

七、业务架构方案的实施过程

1、业务架构将业务能力经过企业级规划后传导给IT端，并不会限制IT端实现方式，IT端适配业务架构的规划

2、业务架构实施过程（指挥棒）即为IT细化企业级业务架构设计，并基于企业级业务架构进行实施协调与管控的软件过程

3、基于业务架构模型进行IT架构设计，具体方法上可以依据自身企业的文化习惯和特点决定实施工艺，但其过程本质上是对业务架构的细化和继承

4、建模时了解细节为了有助于判断抽象的正确性和合理性，但是模型中却不能表达太多的细节，设计阶段的细化就是基于业务架构方案的需求分析过程，过程中允许对原有的工作流进行拆分或重构，但是要显性的标明继承关系，保证设计的连续性

5、企业能力视图不能仅局限于业务侧或者仅到组件层级，而是应该延伸到最终的实现，业务与技术的深度融合是今后企业发展的大趋势，业务技术一体化视图

八、建立转型后的长期应用机制

1、业务架构是推动业务与技术深度融合的重要方法，目的是要在各种场合下推广模型的使用和模型的思维方式，已促进通用语言的建立

2、企业级项目转型必然会经历一段时间的过渡期，开发建立新架构的同时，旧的架构还需要承接新需求，此时需要考虑的是新旧的兼容，如何保障后续可以顺利的迁移到新架构中，基于已经建好的业务模型做新需求的整合与职责分配

3、固化模型工具、建立长期架构仲裁者、业务架构深入业务条线，推动业务与技术的融合，同时避免过于中心化

4、提升技术人员的比重，使技术人员与业务人员多沟通和探讨深入交流，业务与技术人员实现数字化思维转型

5、架构师轮岗，保持企业级思维理念，与企业架构的集体性工作交流，增强业务架构师对企业级的把握和企业架构对业务端的理解

6、工作过程中时刻注意使用模型工具分解需求，通过模型工具把控企业级设计

7、企业级项目的建成其实就是其崩坏的开始，崩坏就是由一个个看似微不足道的需求分配过程形成的，没有项目是可以万年长青的，考验的是企业的应用、保持、维护机制

九、业务架构与敏捷开发模式

1、双模开发：敏态加稳态，可预见性的业务使用的是传统瀑布式开发（稳态），探索性的业务使用敏捷开发（敏态）

2、敏捷开发的敏捷和特事特办的敏捷：

（1）正宗敏捷宣言：

4个核心价值：

1）个体和互动优于流程和工具

2）工作的软件优于详尽的文档

3）客户合作优于合同谈判

4）相应变化优于遵循计划

（2）业务模型自身必须具备一定的简洁性，需要恰当的概括性的文档作为项目的总体目标

（3）业务模型不应该承载太多的业务细节，而是要保持适当的抽象度，大的原则是，可以基本解释清楚任务对数据实体的创建和变更，以便划分任务及组件的边界，模型需具备快速应用的潜质，模型作为作战地图，通过模型可以更快的摸清项目的范围，涉及的组件和团队以及潜在的影响

（4）敏捷不应该是不顾一切的敏捷，更不是牺牲企业级架构一致性的敏捷，否则敏捷项目就成了为短期利益而有意忽视长期影响的盲目行为，无论多紧急，不看地图就冲向战场的行为是很危险的

（5）敏捷开发的速度来自于节省不必要的步骤和提高协作的效率，所以个体和互动优于流程和工具，注重面对面的直接交流，以减少分歧，需要业务架构师必须参加敏捷项目，在项目中快速完成架构分析，把控项目引起的架构调整

（6）敏捷开发团队要在业务架构师的参与下，在项目的一开始就根据需求描述快速的使用模型工具澄清项目范围，列出对架构的改变事项，考验企业通用语言的构建效果，应用业务架构和业务模型驱动的开发过程，可以转变为敏捷过程，并为敏捷过程提供更好的分析依据

（7）敏捷过程与瀑布式主要区别：

1）大周期开发改为小周期冲刺

2）多线程并发的组织模式

3）分阶段投入资源改为一次性投入资源，减少二次传递，提升信息共享

十、企业级的五难

1、捷径难寻：企业级建设的难度与企业所在行业的特点有直接关系，没有一个通用的企业级业务模型可以随便套用，别人的经验只能借鉴，自己的路还需自己摸索前进

2、文化难建：企业文化的冲击，部门的内战，如何冲破部门壁垒和边界

3、预期难控：管理好企业和用户的预期，项目周期长、建设过程曲折、不断的对现实的妥协会让预期大打折扣；真正的预期应该是企业文化的建设和整体转型（行为习惯的转变）

4、权责难定：组织中，一件事情可以做好，前提是做事的人应该权责匹配；好的架构师可以帮助企业实现合理的整体规划

5、长志难立：员工要自觉去维护企业级，维护公司的文化与战略，思想与行为上要进入数字化时代

十一、实战：实现了快速设计的案例

1、企业级分析是项目的先导和开发任务分工的依据

2、案例总结：

（1）对原有业务架构和模型的充分复用

（2）模型化的业务架构工具对企业级需求分析的加速作用

（3）业务架构师必须非常熟悉项目情况

（4）业务架构还可以对提高项目的效率发挥更大作用

3、建立了企业级业务架构，就可以向敏捷过程看齐

十二、如何支持面向构件的设计

1、乐高积木式的软件设计：CBD（基于构件的开发），比如代码片段可以通过标准化接口自由的组装，可以大大提升灵活性，实现资源的复用和快速相应

2、CBD：

（1）基于UML改良，在分析用例、顺序图、类图的基础上，分析构件的关系并建立构件图，再通过部署图描述构件的部署位置，从而形成一个完整的构件建模过程

（2）基于Catalysis改良，相比UML增加了对构件间交互模式的建模，将建模过程划分为理解上下文、定义构架、提供解决方案三个环节；其中定义构架环节需要决定如何将行为包装成一个独立的单元，该单元可在不同项目间共享

3、CBD实现方式：SOA（面向服务的体系结构），SCA（服务组件的体系结构），SOA是包含SCA的范畴

4、SOA是一个并不是十分明确的架构概念，SCA具有清晰的内涵和规范标准，提供了构件粗粒度组件的机制，粗粒度则是由细粒度组件组装而成

5、颗粒度很重要，处理不好，业务人员无法明白IT再做什么，IT人员也无法解脱

6、业务模型的建模过程很注重标准化，标准化是一个去重的过程，其会尽可能的保证流程构成元素的唯一性，以免重复建设

7、构件模型的设计方式，包含模板、构件、参数三个部分

（1）构件：构件化开发要求更强的结构化，设计时应将设计对象切分成零件，通过组装零件调整零件来快速实现新设计

（2）参数：构件模型中的参数与一般项目上所做的参数化设计类似，可以通过参数配置快速刷新产品；这些参数应该都是数据模型中的属性，可以在数据模型的属性上增加参数标识，以便在数据模型中可以很容易识别出来

（3）模板：带有参数的构件组装在一起就形成了一个有结构的装配模板，用于组装业务实例或产品，这样的模板即表达了构件化设计，又可以用于参数配置，而模板本身也可以起到另一个作用，就是服务的编排或粘接

8、业务需要的可能不是面向操作步骤的过细的服务划分，而是面向如何更好的响应变化的服务划分方式，基于已完成标准化的业务架构模型，在对任务进行实现时，从企业级视角通盘考虑，设计出更有业务含义的构件

9、将构件聚类为业务组件的方式也相当于基于数据模型对任务进行聚类，良好的构件模型对于实现开发风格的一致性也是由很大的帮助

十三、构件轻量级架构管理工具

1、构件模型有利于提升设计效率，是业务架构的另一种表达形式

2、构件模型的抽象要素及逻辑关系：

（1）模板与构件：模板可以包含若干个构件，组装式开发可以表达为业务实例或产品与模板、模板与构件间的对应关系

（2）构件与参数：构件中可以记录复用推荐度，以及复用的场景，以方便业务人员后续做设计时使用；以及构件中包含的参数的使用，参数应尽量使用数据模型中的数据项，不可直接配置的参数则不提供面向业务人员的配置界面

（3）构件与服务：一个构件可以对应一到多个实现上的服务，构件代表的是一个服务集合，构件的复用是构件对应的服务整体对外提供的一种能力，这是零件的含义

（4）服务与报文：服务可以被调用，因此服务会对应报文（请求报文和响应报文），报文中包含与构件对应的参数

（5）实例化：模板在生产中会派生为业务实例或产品，在产品销售前及销售过程中，所有的参数都将完成赋值

（6）产品目录：每个业务实例或产品都会有描述性的标签信息，这些信息通过集合形成产品目录

3、轻量级架构管理工具的设计原理

（1）业务实例或产品由模板配置而成，模板实际上是一种领域模型，不同领域的产品可能差异较大；

（2）模板之下是构件，构件代表了一个领域的具体组成部分，是零件；构件中包含数据，也就是参数；

（3）构件又可以进一步分解为服务，服务实际上就包含了行为，微服务设计，会包含对应的数据；服务作为设计上的底层核心元素，可以从统计角度包含服务归属的物理组件、引用该服务的用例、语言类型、代码行数、初始开发或积累的人月数、归属的开发团队等可用于项目管理的信息

4、采集项目信息的价值：累计起来的项目信息库对于大型企业的项目管理而言是非常有价值的，如果信息采集过程可靠，那么以这个逻辑建立起来的平台不仅可以用于支持快速的架构设计，还可以将项目成本分解至服务层面，甚至基于这一点来比较团队的开发效能，需要考虑设计一套逻辑进行项目信息的有效收集和分析，使得项目开发得以向精益方向靠拢

5、轻量级架构管理工具的优缺点：工具化之后，可以基于构件模型建立起一个从业务直通底层实现且信息量丰富的轻量级架构工具

（1）便于业务人员理解深层设计，从而提高业务人员的参与度，加深业务与技术的融合度

（2）能够有效展现系统的构件化程度和组装方式，加快系统分析、定位和设计的速度，提高沟通的效率，尤其是对于跨组件、跨部门、跨团队的设计，实际上是将业务架构和应用架构结合在了一起

（3）对底层服务进行详细描述，可以累积项目自身的数据信息，以便进行加速成本测算、可行性评估，这种方式可以提升评估的准确性，减少项目预估结果的波动性，再基于实际支出情况不断进行调整，可以逐渐提升其精确性

（4）不足之处：需要投入一定的精力取维护，可以将这种精力的支出与项目同步，不要变成后补之类的处理方式

6、应用轻量级架构管理工具管理新需求

（1）原有功能改造需求：通过产品与模板的对应关系，找到实现产品的构件模型，分析产品需求的实现位置，对原有产品进行改造，可以根据构件的切分，快速找到需求的实现位置，进而定位到需要改造、新增的服务及数据

（2）新增功能需求：会产品构件级别的新增，但是基于原有的业务环节，可以很快定位出新增环节与原有环节的关系，设计前后构件间的数据关系、构件接口

7、业务架构的设计成果要想具有生命力，最重要的莫过于经常使用，这一点对于任何架构设计模式来说都是一样的，目的是将业务架构变成连接业务与技术的通用语言，使用越多则沟通越容易，也越容易被各方接受以用于沟通，是一种正向循环

十四、基于构建模型谈谈传统企业的产品创新

1、企业能够长期存续的基本条件是其能够为客户持续创造价值，无论以客户为中心多么重要，价值传达的载体依然是企业提供的产品或服务，服务能力

2、构件模型可以面向产品或服务提供简洁、直观的设计蓝图，从而提升开发效率，创新管理离不开信息传导、信息分析、创新平台三方面，而构件模型及其架构管理工具为基础的实现模式，有助于增强这三个方面的能力

（1）信息传导：打造信息传递高速公路，产品目录：每个业务实例或产品都会有描述性的标签信息，这些信息通过集合形成产品目录，构件海量标签库，形成庞大的图谱，一张通过产品目录连接起来的信息网，让海量信息分门别类的流向信息需求方，成为一个高效的信息传输渠道

（2）信息分析：创造高维数据

1）用标签打造高维数据：形成信息归集、整理和传导能力的关键因素是数据维度，而最能有效支持信息分析的也是数据维度，只有具备高纬度特征的产品信息库才具备构成产品大数据能力的基本条件，维度才是描述对象特征最重要的手段，而每一个标签都是一个产品维度，加大对标签的研究力度，丰富标签信息，增加标签产生和应用的方式，以便更好的建设大数据能力和AI能力

2）标签比分类更容易做企业级推广：标签可以根据需要灵活的进行定义，每一类不同的需求都可以转化为不同的标签集合，为产品赋予大量的标签，可以满足在不同视角展示和应用需要

3）构件业务与技术兼顾的产品目录：构件模型本身就是IT侧需要看到的产品目录

（3）创新平台：扩展构件模型，产品是一个企业的价值载体，是为客户服务的实例化表现形式

业务延伸到技术的链条：业务信息->产品目录（标签化）->业务实例或产品->模板->构件->服务->项目信息

1）核心域：平台的核心域为产品设计域，产品设计域包括产品目录和构件模型两部分。

2）支持域：

a、产品创意域：创意是产品的设计来源，如果具有产品目录和构件模型，则可以更好的对产品创意进行分类

b、产品评价域：产品评价难点在于指标体系，制作一套各部门都认可的企业级指标体系不大容易，DDD建模理念，从单个领域出发，一个领域一个领域的构件评价模型，领域内部则要一个产品一个产品的进行分类，归类后，再一个类别一个类别的与业务人员取尝试建立评价模型，单产品的评价模型确立之后，再逐渐汇集领域视角的评价方法，企业级的评价最终应当来自于可靠的领域评价指标体系的汇总与整合

c、产品运行效率检测域：主要依赖于构件模型的特殊性，构件与服务之间拥有明确的联系，而构件可以按照执行顺序形成设计视角的流程模型

（4）构建模型及其应用设想的不足：在业务组件内部以面向构件化开发的视角重新精炼业务架构模型，更加有利于强化业务与技术之间的沟通，并且可以通过对产品设计的关注，进一步提升企业的创新效能，但是以下为不足之处：

1）不易于再企业级项目初期产生相对成熟的设计，需要经过反复精炼

2）架构设计的模型形态与业务人员较容易理解的流程模型形态之间存在较大的差异，因此需要一定的学习成本

3）构件类型作为架构管理工具，需要经过一定时间的数据积累才能实现，且成本统计可能会由于数据录入结果等人为因素而不准确

4）产品目录的信息传导能力也需要较长时间的建设才能形成

十五、中台之上

1、从业务架构的角度来看，中台只是企业级业务架构规划会导向的结果之一

2、阿里中台简介：阿里中台是持续积累、演化的过程，大型架构、好的架构都不是一蹴而就的设计，而是根据实践不断磨合、调整得来的

（1）高内聚、低耦合，数据完整，业务可运营，渐进的原则

（2）阿里采用去中心化（ESB，企业服务总线）的HSF分布式服务架构，支持服务的点对点调用，用于解决ESB可能产生的瓶颈问题；

（3）分布式设计方式提高变化相应，融入DDD设计模式，提升设计效率；