企业级架构设计-读书笔记

2020-07-04  本文已影响0人  大胃菜

一企业架构方法论

知行合一

二企业架构框架发展史

1987年最早的企业架构框架:

1995年TOGAF开放组架构框架:

最新的理解:

IT架构是业务架构的容器,业务架构是IT架构的灵魂

三常见的业务模型:

1.流程图

2.BPMN图,常见于流程引擎

3.UML图,技术友好,业务不友好

建模原则:

1.整体性

比如特斯拉与传统车厂的区别,除了驱动方式,还有电气一体化

2合适性

不能做PPT架构师,要在生产环境中得到反馈。

把握整体、穿透现象、保证落地

主流的建模方法:MDD 模型驱动开发

所谓的“技术引领业务”并不是指由IT人员直接抛出新技术给业务人员去琢磨和研究,而是指将对新技术的理解首先通过业务架构设计引发业务变化,用新技术理念推动业务模式演变,再进行IT技术开发。

四企业架构的设计起点

1战略分析

2组织结构的影响

业务架构设计的着眼点是企业级能力规划,希望能够突破壁垒、形成合力。也正是因为这个“初心”,组织结构对业务架构设计的反作用力也是极大的,要注意企业组织结构的影响!

做出来的模型,凡是公用的部分,应该照顾到所有利益相关方的需求;凡是已实现的功能都应该对新的需求方开放并支持必要的扩展,这是企业级设计应该追求的目标,但是,实现起来常常困难重重。企业无论大小,一旦系统的设计边界跨越了单个部门的职能范围时,都会出现部门利益问题,无非是企业规模、文化差异造成的协调难度的差别。

在企业内部,部门利益是部门需求的天然边界,即便要做企业级,各方肯定也是要先说清楚自己的需求,再去考虑别人的需求,“种了别人家的田,荒了自家的地”是绝对不行的。所以,各部门在参与到企业级谈判中时,都是首先要满足自己所在部门的业务诉求。

这就要求,作为业务架构的设计者,拿出来的方案最好是以一种更有效的方式来满足所有相关方的需求,而不是单纯做抽象、归并,要各部门“你让一陇地,他少一棵树”的方式搞折中,这样做实际上就失去了做企业级的核心价值,因为这样的折中既无法保证系统的先进性,也无法保证用户体验,甚至还可能发生退步。部门利益是做企业级的最大障碍,跨越这个障碍是对业务架构师设计能力的最高挑战。当然,客观地说,没有更好的解决方案时,不动也是一种选择,因为,同样接受这个挑战的还有企业文化。

企业的组织结构在业务架构的设计与实现过程中具有很重要的影响,理想的企业级系统建设与组织结构转型是相辅相成的,应当一同展开。一个在组织结构上高度部门化的企业是很难建成一个真正的企业级业务系统的,这一点在做业务架构设计时务必要提前考虑到,方案与组织结构要匹配,否则在落地时很可能会困难重重、面目全非。企业级转型大多数是需要时间来适应的,休克疗法、瞬间跨越都很难,在这一点上,业务和技术要通过业务架构设计过程互相影响、互相协作、互相改变。企业级建设是一个“砸烟囱”的过程,其实无论你砸得多卖力,“烟囱”总还是会有的,对于企业级设计来讲,这是实践者必须面对的问题。

五企业架构的设计过程

1价值链分析

价值链主要描述的是企业价值的创造过程,引入价值链分析主要是为企业横向审视自身的业务能力提供分析框架。因此,价值链如何设计完全可以是个性化的,只要确认能够符合企业的特点,覆盖其价值创造过程即可。比如,极度简化的价值链设计,也可以将支持性活动整合后并入到基本活动中,形成只有一个维度的价值链。生产企业价值链:

2划分业务领域

从客户出发或从产品出发

3分析业务流程

4企业级数据模型

IBM的金融服务数据模型

5组件划分

在软件设计上,通常会考虑将关系较近的数据实体聚合在一起,按照行为接近数据的原则,再将相应的功能聚合成一个组件。从业务模型的角度来看,就是按照主题域划分边界,将与主题域内实体相关的任务聚在一起构成业务组件。聚类过程中需要注意如下几点事项。

第一,数据关系中存在一个主题域引用另一个主题域的数据实体的情况。比如A主题域引用了B主题域的数据实体,在对A主题域进行任务聚类时,不会考虑将B主题域中被引用的数据实体相关的任务聚类进来,因为它们应当由B主题域进行聚类时考虑将其聚合起来,这样做可以保证在企业级业务系统中,数据生成职责的唯一性,这是应用企业级数据模型时非常重要的一点。

第二,与数据实体相关的任务主要是指对数据实体进行新增、修改、删除的任务,对同一数据实体进行新增、修改、删除操作的任务应当归属于同一组件,这也是一个标准化的过程。只有这些任务具有数据的写权限,而其他任务只具有读权限,这也是保证企业级数据一致性的重要措施。实际设计中也会出现必须要建立主副本的情况,这时,主本数据是主要设计方,副本数据的设计方必须考虑如何保持与主本数据的一致性。

六企业架构的设计难点

数据标准化、任务标准化、作出关于标准化的建模判断

七企业架构落地

1从业务架构模型到业务架构落地:

将模型转化为方案的过程实际上是一个导读和解释的过程,方案主要包含3个部分的文档:企业级架构方案的整体描述、分领域或分应用的方案描述、业务组件的方案描述。

2对架构师的要求

实践经验、不断宣讲、参与项目

3什么情况下进行架构调整

架构设计疏漏、出现了更好的设计、有等价的架构方案、向现实妥协

4什么情况的架构调整不可接受

明显违反既有的架构、不必要的重复造轮子、

5企业级架构的真正价值

不惜血本去做企业级开发,其实最重要的是转变企业文化,打破部门边界,让企业融为一体,让业务与技术也融为一体。这种一体化带来的内部变化、清晰分工和高效协作才是最有价值的,是未来长期竞争力的关键,也是打造“数字化”企业的基础。

八如何建立长效架构机制:

统一的模型工具、架构仲裁、参与条线的项目设计

九案例一 互联网黄金销售

业务架构关系图

十案例二  金融产品竞价功能

业务流程与数据模型图

非构件模式拆分的开发结果

构件模式拆分的开发结果

构件模式的流程图

业务架构整体逻辑关系图

文化影响;让构件的设计者、开发者成为业务专家

十一 基于构件模型的传统企业创新

1.构建产品目录,传导产品信息

2、为产品目录创造标签,通过标签分析产品能力

总结:

企业架构的道:企业架构是企业文化、企业能力的技术体现,优秀的企业架构设计将通过呈现和提炼IT的技术能力帮助业务找到发展之路,这才是技术引领业务的真正内涵。

企业架构的术:企业价值链分析、流程、构件、数据领域、MDD、DDD……

术为道服务,找到最适合自身企业的道路。

上一篇下一篇

猜你喜欢

热点阅读