摘要
企业的内部需求和外部环境一直在变,软件研发、交付和使用的方式也一直在变,相应地,企业架构的方法论也一直在演进。数字化时代如火如荼,传统的企业架构方法需要引入新的思维模式,才能满足企业发展需求。 作者结合自己在架构领域多年的实践经验和思考总结,针对数字化转型大背景下企业的架构需求,对TOGAF等传统企业架构方法论的不足进行了改进与创新,提出了一套面向数字化企业的企业架构方法论——聚合架构(ABAE),是管理数字化企业的新思维,在企业架构方法的发展史上或有划时代的意义。
三大主流企业架构体系核心点
Zarchman核心
6横6列,多视角设计架构
TOGAF的几个核心
1 ADM 方法过程:葫芦图(麦圈图)
2 4A架构,业务架构、应用架构、数据架构、技术架构
3 元数据和视图
4 架构治理
CBM核心点
CBM是听诊器,是根据业务战略作为输入、分析IT战略存在改进方向
DoDAF核心点
1 引入数据为中心
2 架构(体系结构)业务管控引入架构思维
3 八个视点
第一讲 开篇
聚合架构第一讲:开篇啦-2021-11-20 22:41:46_哔哩哔哩_bilibili
第二讲 企业架构的认知历程
聚合架构第二讲:企业架构的认知历程-2021-11-20 22:41:46_哔哩哔哩_bilibili
第三讲:从包饺子看工程与架构
聚合架构第三讲:从包饺子看工程与架构_哔哩哔哩_bilibili
第四讲1-3:工程方法的进步也不容易
聚合架构第四讲1-3:工程方法的进步也不容易_哔哩哔哩_bilibili
四个价值观:见敏捷宣言
工程方法论三次演进:1970年瀑布模型 1988年螺旋模型 2001年敏捷开发
聚合架构第五讲1-4:架构方法的进步也不容易
聚合架构第五讲1-4:架构方法的进步也不容易_哔哩哔哩_bilibili
DoD 美国国防部 最先提出企业整体架构的
IBM:CBM(IT能力模型)=》BIAN(开放银行服务标准化、接口、微服务化)
企业级业务架构(EBA)方法源自Zachman框架和TOGAF理论,是晓岩大神提供的唯一国内的企业架构
1-5聚合架构第六讲:聊聊开山祖Zachman框架
1-5聚合架构第六讲:聊聊开山祖Zachman框架_哔哩哔哩_bilibili
列是不同视角,行是利益相关者。同一视角下的行分层是松散的,没有分层关系也没有必要的关联和约束
各个cell之间是松散的,上下层也没有必然关系
企业架构是对企业的一种观察,是一种观察的结果。对企业的观察结论,可以叫企业观(套用世界观)
架构不是Single of Archtechure,而是Set Of Archtechure (架构不是单一的架构,而是一套架构)
按Zachman理论结合不同利益相关者和视角维度,架构图至少要有6*6=36张图,所有很多讲架构的只是把业务和应用整合到一起展示的职能叫概念图。
Zachman评价:
优点 1) 开创先驱 2)多视角架构的统一,解决了盲人摸象;
缺点:缺少过程讲解,全是道理没写怎样做;缺少交付,没有介绍每一个格子里面视图内容
1-6聚合架构第七讲:聊聊togaf的发展历程
1-6聚合架构第七讲:聊聊togaf的发展历程_哔哩哔哩_bilibili
togaf 内容比较多9.0版本有中文版700+页;9.2压缩很多 500+页,但是没有中文版的文档
togaf的模型设计工具ArchiMate
建议学习资料:Togaf 9.0 有中文版,或9.2英文版;金蝶软件口袋书(80多页,可以有个概览)
学企业架构方法论,不要有批评思维去看,而是要先理解吸收。 起于思维止于思维,企业架构方法论是尝试建立一个通用的方法。对一个方法论在整体深入认知之前急着拿着实例去看一个方法论的执行的话会产生很大偏差,因为实例都是个性化的。所以方法论和个性化实例之间有很多不对称需要有很多折中。
1-7聚合架构第八讲:ADM被骂的冤吗?
1-7聚合架构第八讲:ADM被骂的冤吗?_哔哩哔哩_bilibili
麦田圈,葫芦图:是面向企业架构的过程的内容(Zachman架构方法缺失的)
架构变更管理:架构和计划是可调的,根据落地执行情况修改。计划的作用是用来修正的,帮你来评估修正计划的代价,是否值得修正以及该不该修正。计划不是毛病,架构也不是毛病,但是把计划和架构做死了才是毛病。文档里面有描述思想是拥抱变化的,不是常规理解的固化的,各个步骤都是以需求为中心的。一个坏的执行结果不能归咎于方法的好坏。
togal设计方法具有一致性:如左图,大的战略计划可以用这个圈过程,细化子层小的范围也可以使用这个方法过程。从认知的角度逃不过这个圈:认识业务,认识应用架构,认识技术架构的实施方式,到评估方案是否可行,以及对旧系统的影响。这些思维过程都是绕不过的。
1-8聚合架构第九讲:我们聊聊4个A?
1-8聚合架构第九讲:我们聊聊4个A?_哔哩哔哩_bilibili
4A就是TOGAF的四个架构,业务架构、应用架构、数据架构、技术架构
4A 架构于Zarchman提出的架构应该是多视角多维度的思想一致
左侧框图是ADM(麦圈图方法过程)解释下来的
架构原则、愿景、需求包含两个前置一个步骤:(预备阶段、架构愿景、架构需求)
设计阶段:包括三个步骤,业务架构、信息系统架构、技术架构
架构实现:包括三个步骤,机会与解决方案、迁移计划;实施治理
企业架构就是4A架构的设计(元模型)和实施(架构资产管理平台)过程。
架构设计是软件工程中的一环。
业务架构:定义了业务战略、治理、组织和关键业务流程
数据架构:描述组织的逻辑和物理数据资产、以及数据管理资源的结构
主要是数据分布和模型定义;先把逻辑和物理数据资产定义出来,然后再看管理资源结构(分布)。
应用架构:为将要部署的单个应用程序、他们的交互及它们与组织的核心业务流程的关系提供蓝图。
业务流图转换到应用设计上之后形成服务流,服务分布和之间的调用顺序。
技术架构:描述支持业务、数据、应用程序服务部署所需的逻辑软硬件能力,即平时说的平台的分布。包括IT基础设施、中间件、网络、通信、处理、标准等
4A之间的关系:业务驱动模式推导应用=》数据=》技术的过程转向以应用为纽带连接业务与技术架构的模式(所以具体方案可能会多多考虑下技术资产中心位置)
按togaf和
下图是本人自己简单初步描述4A结构关系:
技术架构目前是很独立了,尤其是很多开源的技术构件出来之后整个技术体系变得非常独立,而且在资金到位的情况下可以买一整套的技术栈。不大需要从应用系统的架构去推技术架构应该什么样,比如:分布式技术栈已经都准备好了,直接考虑怎样切除来功能在上面设计就行了,而不用从应用角度来推应该用什么样的技术平台,而是我有这样技术平台应用功能是如何在上面进行设计。因此反而应用架构就退化成业务架构和技术架构的连接器。虽然现在都提倡技术驱动业务,现状是业务架构和技术架构都很独立,只是应用存在诸多不确定性。
企业设计要从4A 视角这种全景视角来看企业内部系统设计比单一从某个某几个技术视角看更合适
togaf使用场景:1) 全企业级别;2) 只要超过两个系统就可以使用不一定要到全企业时候才使用。
1-9聚合架构第十讲:即使枯燥也得聊聊概念
1-9聚合架构第十讲:即使枯燥也得聊聊概念_哔哩哔哩_bilibili
TOGAF中定义的企业,与工商系统的企业不是一回事,有共同目标的组织单元集合体就算企业。比如为实现某个目标的相互协作的两个部门就可以合称为一个企业。
基于TOGAF 对企业的定义,就应该有企业架构设计和顶层企业架构设计的说法了。顶层企业架构是单位最高级别的企业架构
架构:系统的基本组成部分、组成部分之间的关系、治理原则
架构这个定义是从ISO上引入过来的
企业架构晓岩大神的另一种说法: 披着数学外衣的语文课。表面上看着很有逻辑性,也希望能学建筑行业长处能把结构和关系都做好,但实际真做到里面的时候全是某一个语境下的语义问题,在某个语境下把某个语义考虑清楚了在拿某个语法去表达,几乎全是这种我呢提。
1-10聚合架构第十一讲:不服?那得治!架构治理
1-10聚合架构第十一讲:不服?那得治!_哔哩哔哩_bilibili
架构治理在TOGAF中将近有7~8章的章节来介绍,从45章以后全都是,占篇幅不少
治理环境:
角色的分工、描述运作背景,怎么让架构运作起来
架构师只管项目,不管实施。PMO来负责,这里项目实施和Devops分开的(假设有Devops这情况)
企业连续统一体概念:
TOGAF 里面没有定义,教程里面晓岩大师的解读:
是个泛用的概念,架构有架构的连续统一体,解决方案有解决方案的统一连续体,连续统一体讲的更像一个:一般性架构到一个特定架构的设计过程.,一个比较粗糙的提炼了一个共性的架构元素到一个细化的过程,然后两者之间来回迭代互补。循环往复的过程:粗的一版基础上做了一般具体的,这个具体的版本又作为下一个循环的起点,成为下一次架构的一般性架构。一般架构库<=>解决架构库
我本人的理解:这里是从上到下箭头是指导填充,从下往上的箭头是指遵从的意思
治理机构:
管理角度来讲,治理机构(架构委员会或高层的架构管理办公室)指导整个架构运作环境的管理。
给架构专业人员通过培训提供架构技能和知识(技能和知识的定义没有明确的解释,不知道这个知识和TOGAF里面的技能成熟度中第三级知识是不是一回事),但TOGAF有一张架构师的技能框架(罗列内容很多,做一个合格架构师不太容易),其中把架构人员的技能成熟度分四级:背景、认知、知识、专家。
架构设计师要配合PMO进行项目管理和项目治理
架构师的角色和职责(一般的或项目特定的,后续课程晓岩大神会专门来讲)
治理六大特点:企业项目管理的与之相去甚远,是公司级别的了。纪律性、透明性、独立性(不受公司经营的特殊的左右)、追责(相关人违反契约时要进行追责)、负责(对承担的工作负起责任)、公平。是从公司治理角度套用特点了这样的六个特点来描述架构治理的
IT和业务之间的关系:目前看是IT治理和业务运营是分野的,长期来看的趋势讲更深层次的融合的,在企业的管理层、业务侧把架构师引进来,而不应该是内部的甲方乙方的关系。
企业架构应该成为新时代即数字时代的企业管理语言,成为企业管理思维。不仅仅是IT设计思维。如果仅停留在IT范围内进行IT治理的话是不够的,这也不符合公司对IT的期望。反过来说胆子也不应都在IT测,管理层要把企业架构引入到业务侧。
1-11聚合架构第十二讲:聊聊啥是企业架构师吧
1-11聚合架构第十二讲:聊聊啥是企业架构师吧_哔哩哔哩_bilibili
企业架构师:
1)覆盖所有利益相关者的所有关注(多视角)
2)对利益相关者之间的冲突进行关注,做出权衡(权衡设计不是最优设计)
3)对架构视图的权衡受实用性和适用性约束
4)与企业管理人员充分合作,保障架构设计可追溯到业务决策
5)架构师不是建造者,必须保持一定程度的抽象,以确保不妨碍实施
6)架构师关注重要细节,但不可以因此过载(细节失控和整体掌控的辩证关系)
职责:
1)理解并解释需求
2)创建有用的模型,必须理解所有必要的业务组件
3)确认和细化扩展模型,评估源于现场的增强解决方案的价值
4)管理架构,促成改变
特点:
1)产生技能和经验
2)具备一个或几个技术领域的深度和广度
3)设计方法论的能力;
4)项目全周期的经验
5)具备一个或多个行业的工作经验
1-12聚合架构第十三讲:该总结下togaf的优缺点了
1-12聚合架构第十三讲:该总结下togaf的优缺点了_哔哩哔哩_bilibili
TOGAF既不是教科书也不是论文。不是教科书因为没有考虑缺乏工程经验的人使用,不是论文是因为没有在某些细节写的很深。所有容易被人从各种角度去攻击。所以在学习某个方法论的时候一定要分析优点和不足,以便总结自己的理论,从TOGAF中要学到作为一个方法论要考虑哪些方向。我们自己的经验该怎样去总结,让我们的经验成体系,而不只是一些散的知识点。
不足:
1)ADM方法每个步骤怎么设计,构建块怎样诞生没有说明
2) 架构统一体怎样来保证,难以实现行业级连续统一体
3)难以让企业架构超越技术标签,所以推行自己的企业架构方案一定要考虑业务友好性。业务友好性是决定某个方法使用的基础。
1-13聚合架构第十四讲:CBM的专业化
1-13聚合架构第十四讲:CBM的专业化_哔哩哔哩_bilibili
1-14聚合架构第十五讲:为啥咨询公司就能从高往低打
1-14聚合架构第十五讲:为啥咨询公司就能从高往低打_哔哩哔哩_bilibili
1-15聚合架构第十六讲:聊聊CBM能干啥
1-15聚合架构第十六讲:聊聊CBM能干啥_哔哩哔哩_bilibili
1-16聚合架构第十七讲:CBM的分析过程和结果是啥样的
1-16聚合架构第十七讲:CBM的分析过程和结果是啥样的_哔哩哔哩_bilibili
右侧矩阵图很有价值,每个格子与信息化系统关联矩阵
可以描述信息系统对对应关系(可以分析哪些系统是缺失的,哪些是支持过度的)
1-17聚合架构第十八讲:聊聊CBM哪好哪差吧
1-17聚合架构第十八讲:聊聊CBM哪好哪差吧_哔哩哔哩_bilibili
1-18聚合架构第十九讲:道听途说DoDAF之历程篇
1-18聚合架构第十九讲:道听途说DoDAF之历程篇_哔哩哔哩_bilibili
1-19聚合架构第二十讲:今天聊聊DoDAF的主要概念
1-19聚合架构第二十讲:今天聊聊DoDAF的主要概念_哔哩哔哩_bilibili
企业架构的概念:
架构思维进入管理思维
数字化转型一个企业要同时管理包括IT行业和自身两个行业,把业务架构视角和技术架构视角整合起来看整个企业的架构思维
业务融合
数据共享
DoD 数据为中心、企业管理引入架构思维(架构能反应基线、能够反应变化和成长路径和计划[目标]、分布实施)
目标:适用(fit-to-purpose)