聚合架构-晓岩企业架构系列讲座整理(30-50)

2-01聚合架构第三十一讲:数字化企业的未来形态

背景要素:

融合架构四句引言:全书的思维宗旨,用这四句引言构思这本书和定位的。

正确的思考方式本来就是一个逻辑体系,如果思考方式不正确很容易在整个体系上产生很大瑕疵。

从哪些方面去考虑架构方法论呢?

企业与企业架构的关系:

我本将心照明月,怎奈明月照沟渠

企业架构以企业为核心去思考问题,但是企业并不是以企业架构为核心;

面向数字生态的时候企业形态会发生变化,企业形态发生变化随之研究企业的结构为主的企业架构的方法论自然也要调整。往大点说:农业时代自耕农,小农经济,一个农户一个农户的生产走进了工业,工业里面有工业化的大生产,也有中小企业的生产,但这种企业的组织方式和之前农户自耕,地主雇佣写佃农种地是不一样的。企业管理方式也不一样,看企业的方式也不一样,如果:工业企业很多是合伙人制,企业的形态变化或组织形态的变化以研究组织结构,组织构成以及他们的运作机理为核心的响应的理论方法也会改变,因此面向数字化时候的时候企业方法论应该发生变化。变化的基础是在这个高度互联的数字经济环境下企业形态是要发生变化的。企业生活在环境里,要随着环境变化而变化。大部分企业只能作为环境变化的追溯者,大部分都是受影响特别大的,毕竟不是造浪的企业。

面向数字时代企业会发生什么变化呢?

数字生态是一种高度互联的生态链式的一种形态,并在数字技术的加持下这个生态连接更加紧密了,这种情况下每个企业都是生态中一个构建,企业与企业间连接会更紧密,过于也有这种连接,由于技术不发达这种连接是线下的合同型的,这种连接也不是那么紧密范围也不那么大。随着数字时代的发展这种线下合同型连接变成线上的接口型连接。比如现在银行搞生态银行,很多企业搞大平台,搞来搞去企业越绑越紧,目的就是为了连接更迅速更容易。在技术加持的这种连接要求每个企业的结构化程度要比以前高。结构里面的标准化程度、内部结构的清晰程度也要比以前高,因为它要映射在软件结构上去根别的企业进行连接。比如零售服装的智能制造,生产端和消费端联合已经非常紧了,生产的编排系统跟需求系统之间,结合已经非常紧密了。这些雏形又可能向所有行业去扩展。

每个企业都是一个生态的构件,每个企业的内部也应该是构件化的.

业务视角业务思维结构化:(业务构件化【线上化】,服务编排化)和 技术视角软件设计标准化:(构件业务化,编排服务化)

把业务拆成一个个构建;同时业务服务要具有编排能力,可以透出给客户。当企业有很大一部分服务基于软件去提交的时候,就会面临这样的问题业务的创新和软件的灵活变化程度之间有很大关系。

业务数据化/数据资产化

业务不仅仅要数据化,数据要资产化,也就是数据的标准,定义,价值的确定评估,包括以后的交易这一切不是技术定的,数据标准是业务问题,不是技术问题。包括数据资产的定义,是否有价值是由业务来定而不是技术。

如果业务侧提供比较好的构件,技术侧不用发挥那么多的想象力。保证技术实现的理解和业务的理解是一致的。从数字化大生态来讲工业化的实现比艺术化的实现要重要得多。现在软件行业最欠缺得就是软件得标准化,不是技术因素,因为业务得标准化程度有限。有些技术得标准化来源于业务的标准化。当两侧能够对称发展的时候技术侧不要把是要搞微服务还是SOA服务看得那么重,而是要把两侧的对应看得重一些。因为这样才能支持业务灵活组装而不是技术自己的灵活组装,这个趋势本来就已经有了,我们的服务治理本身就是编排化的,就是可编排的,后续我们要做的是业务和技术两侧设计对称起来,把你的编排能力作为服务透出给业务侧,这样业务就具备了组合它自己业务的能力。就是通过一些产品研发平台,产品的模型平台,组装技术侧的服务。当然这是比较理想化的程度,其实是需要较长时间的打磨,甚至是行业级的打磨才能最终实现的,但这个一定是未来的方向。

运维带出来的数据逐渐业务化,在银行侧有人开始用的了,比如一个业务链条全链路的视图去观察它,服务时间在哪停留比较久它反应了业务问题是什么?

当全链条理清楚了,技术可视化尤其是把服务能力透出到业务侧进行编排的可视化能力也会越来越强。

基础设施弹性化:

比如东数西算,在双碳的要求下数据中心要求越来越高,中小企业也越来越不适合独立发展数据中心。

由5大视角:基础设施弹性化、(业务数据化、数据资产化)、(技术可视化、运维业务化)、(业务构件化、服务编排化)、(构件业务化、编排业务化)视角融合到一起才是构件化企业的企业架构的视角。进而让业务更好的支持商业模式的变化。

商业模式取决于企业内外部的连接,商业模式是由你企业自身能力决定的在生态环境中的定位。

2-02聚合架构第三十二讲:大规模软件构建能力的需要

​​​​​​2-02聚合架构第三十二讲:大规模软件构建能力的需要_哔哩哔哩_bilibili

数字化建设三大核心抓手:软件、数据、网络

软件就是新的生产工具。

架构资产的明确性:定义明确,作用,用途等

架构资产的清晰性:软件关系清晰,关系在它存在的那一刻是不动的。两个理论典故:飞矢不动,薛定谔的猫

架构资产的灵活性:重建灵活性

架构资产的高效性:高效指沟通,架构满足前三个特性:明确、清晰、灵活,依据这些就能够做到高效沟通,尤其是业务和技术两侧的沟通。

架构资产的友好性:企业架构要突破技术圈,数字化转型要整体做顶层设计,要整体推动,意味着管理层要有架构思维,业务人员要有结构化思维,这样才能让整个企业真正变成逻辑一体化,所以架构资产不能描述成只有技术人员能看懂。

做到以上五点,软件的标准化产出能力就可以上升,才可能应对超大规模的软件需求。未来综合国力的之一就是快速大规模构件能力。现在是软件进入工业化生产的时代,软件越重要越是基础行业,工业化标准化要求就越来越高

2-03聚合架构第三十三讲:聚合架构框架包含什么

2-03聚合架构第三十三讲:聚合架构框架包含什么_哔哩哔哩_bilibili

方法论本身是逻辑体系。

架构定义:一个系统的内部结构、及它与外部环境的关系,以及决定这些关系演进的设计原则。

架构的核心:结构、关系、原则 

2-04聚合架构第三十四讲:从元模型看架构方法论

​​​​​​2-04聚合架构第三十四讲:从元模型看架构方法论_哔哩哔哩_bilibili

推荐机械出版社的《世界观》:目的论和机械论。

架构方法论抽象出最重要的东西,然后再去扩展对事物的认知,就是先抓牛鼻子,核心问题,有了核心的认知再去扩展世界的认知,也就是元模型在方法论里的作用。

元模型:描述观察对象最基本元素及其相互关系。

架构观:基于对观察对象结构、行为的观测和发展过程、方向的认知所形成的对设计对象结构、关系、规律的观念。

架构观=》架构元模型=》元模型实例化

架构观的认知:一生二、二生三、三生万物

现象=》抽象=》方法论

方法论=》方案=》产品是比较好的过程。

2-05聚合架构第三十五讲:聚合架构的元模型与关键链条

2-05聚合架构第三十五讲:聚合架构的元模型与关键链条_哔哩哔哩_bilibili

过程元模型和内容元模型合在一起

组织单元 内外部都要考虑,不能只考虑内部???

组织要体现对岗位的聚合,而不是人的聚合。也有企业因人设岗,人不在了岗位也不在了,这是特殊情况。

岗位要具有标准化,岗位要有一个能力化的成长体系。人根据这个去培养自己,不能指望人啥都学,会把一个人给学费了。组织不仅要包含外部岗位,还要包含自动化岗位。这就要在岗位上体现出人机协同。

关键链条

2-06聚合架构第三十六讲:架构设计的几条总体原则

​​​​​​2-06聚合架构第三十六讲:架构设计的几条总体原则_哔哩哔哩_bilibili

1 尽可能遵循康威定律,以弥合组织与系统之间的差异

2 在总体上尽可能考虑基于构件的设计,以有利于扩展

3 企业架构的分析过程尽可能保持行为(业务)与数据的强关联

4 企业架构设计尽可能保持简洁,突出关键要素,不要在企业复杂度上额外叠加架构复杂度

5 企业架构设计本身不会替代需求分析,不必增加过多细节

6 企业架构设计最终要形成企业能力地图,因此企业架构与业务系统的实现和演进过程紧密相关,业务系统的实现和演进都要基于企业架构设计进行。 

2-07聚合架构第三十七讲:聚合架构的四个特点

2-07聚合架构第三十七讲:聚合架构的四个特点_哔哩哔哩_bilibili

灵活有弹性的架构

架构居于核心的方法论

抽象度较低的元模型

与过程结合的元模型

2-11聚合架构第四十一讲:战略设计之设计过程

2-11聚合架构第四十一讲:战略设计之设计过程_哔哩哔哩_bilibili

2-12聚合架构第四十二讲:战略设计之战略与业务模型关系

2-12聚合架构第四十二讲:战略设计之战略与业务模型关系_哔哩哔哩_bilibili

2-13聚合架构第四十三讲:战略设计之战略能力分解

2-13聚合架构第四十三讲:战略设计之战略能力分解_哔哩哔哩_bilibili

2-14聚合架构第四十四讲:战略设计之对标分析

2-14聚合架构第四十四讲:战略设计之对标分析_哔哩哔哩_bilibili

2-15聚合架构第四十五讲:战略设计之成熟度分析

2-15聚合架构第四十五讲:战略设计之成熟度分析_哔哩哔哩_bilibili

 

 

 

 

 

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
晓岩:虽然做了六年的企业级业务架构,但是总觉得业务架构不是个好讲的东西,业务架构离不开业务模型,所以讲它就会搬出一堆枯燥的模型来,甚至会让人觉得业务架构就是建模。但建模只是个手段,建模的目的是把现象总结成模式,再从模式中找到结构,将业务上看到的结构传递给技术,如果二者能够基于同一结构思考,沟通上将产生最大的便利,这就是通用语言的基础,其实说通用语言,还不如说通用结构,因为说语言,经常会把人带到语法层面,纠结于规则、概念、标准之类似是而非的东西。所以,我总结建模的原则无非是把握整体、穿透现象、保证落地,建模即不能死守规则、冥顽不化,也不能脑洞大开、信马由缰,必须从一开始就关注如何落地。建模不是建个自圆其说的乌托邦,而是传给后续过程的设计图纸。业务建模可以有前瞻性,但是所谓的前瞻性是能够看清分阶段实施路径的前瞻性。 业务架构是不断演进和迭代的,它有生命力,可以成长,如果架构管理工具本身支持历史记录和模式比对,你也可以看到企业架构的演进历史,而不是只看得到现在,只能听别人讲讲过去,过去是可以看见的。这种可视化的历史是一种宝贵的学习资源,人是从历史中学习未来的,毕竟有很多行业还是需要积淀的。 但是,业务架构的形成过程的确是在一种看起来科学的方法论下,不完全科学地操作的,这点我曾经也很纠结,后来软件架构的书看多了,再加上到项目中的观察,也逐渐释然了。软件架构其实很羡慕建筑架构,觉得建筑架构有力学基础做支持,有很多可以计算的东西,但是软件架构却没多少能算出来的。在开源思想时兴之前,行业内部交流分享较差,都比较愿意看别人的架构,而不想亮出自己的,很多研究者都抱怨这个非常需要标准的行业反倒是很隔离的。开源为架构和软件带来新的成长方式,共享让思维发展更快、普及更快,但是,软件架构本身却只是增加了大量的案例,依旧难以标准化,哪怕是同一个行业的企业,给这家做的软件也不一定能直接搬到另一家去,很多商用化了的系统软件也还是离不开个性的本地化改造过程。云计算带来的 SaaS 虽然让软件应用省去了许多部署过程,但是,依然难以改变这个行业个性化程度严重的局面。软件架构尚且如此,业务架构也就不需要纠结了。 业务架构设计可以很快,也可能很慢。快无非是两种情况,一是架构师自身炉火纯青、天生慧眼,设计能力超强;二是原有业务模型已经很清晰,可以快速分析业务变化,形成架构设计,我们可以追求的是第二种,这也意味这首次建模,尤其是首次建设企业级模型,不要过快,对模型设计方法、业务流程分析、标准化过程,都要细致点儿,基本功扎实了,才有后边的“敏捷”。企业级转型没有轻松的,不少企业是把转型仅当成一个项目,而忽视了对自身的调整。一个普通士兵变成一个特种战士,不是因为给了他一身价值 10 万的装备,而是经过了地狱般的训练。上至最高管理者,下至普通员工,人的思维不转变,哪来的企业转变呢? 为了推动企业真正的数字化转型,业务架构设计人员永远不要忘记,业务架构最重要的职责不是传递需求,而是藉由自身的努力,推动业务和技术的深度融合,桥梁作用才是业务架构最重要的职责,如果不能实现这一目标,也就不能真正实现一个快速响应内外部变化的企业级业务系统。 其实中台并非万能,客观地讲,一个优秀的架构设计人员是不会“迷信”于任何一种架构设计方式的,也不会执着甚至偏执于方法间的争论,没有哪种设计方式是完美无缺的,软件行业没有“银弹”,任何一种方法都需要坚持与灵活的结合,都需要通过长期的实践不断总结和改良,如果一个方法没有被坚持数年以上,可能连入门都谈不上吧。我对中台认识更多还只能算个一般观察者,论述中难免有失,感谢读者朋友们能够宽容地看我一路“叨叨”下来。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值