企业级业务架构设计读书感想

企业级业务架构设计读书感想

对于非工具类的书，个人觉得最好是可以尝试将文中的观点再次阐述总结，来将书中的思想尽可能选择有益的进行吸收。

业务架构是什么?

就像字面意思一样，是业务的架构，但是这么直白的解释，往往一下子就把人给搞晕了。

我们先不说为什么会这样，让我们来举一些其他架构的例子。

建筑自己的小房子

假如我们拥有了一块儿日朗风清，山水相依的土地，希望在这儿停留，搭建一个房子。那么我们会怎么做呢?

我们会先设计房子的结构。我们需要先画一个四方形，然后加上屋顶、窗户和门，简单来看就是一个小房子了。

如下图所示:

这里我们有了"部件"的概念。部件就是整体的一部分，并且各自拥有独立的功能用途。

从这里我们好像有了一点架构的感觉，用不同的部件构建一个整体。这个也在于人的思维能力，无法一下子

把握太多的细节，只能使用总分的结果进行分解。

系统架构

让我们回来我们的老本行，如果让我们设计一个系统，那么大概我们会画出如下的图:

从这里我们又体会到了架构的一些感觉，架构是建立在构件之上。如果没有构件，那么我们就只能以字面上去解释

系统架构就是系统的架构。

回到业务架构主题，业务架构也是一样的思路。只不过业务架构比较宏观，所以一般人难有这样的经验，更不知道需要做业务架构。所以这里我们先下一个结论，引自Bizbok的业务架构定义，业务架构包括四部分: information(概念信息), value chain(价值链), organization(组织), capability(业务能力)。接下来我们试图理解一下为什么是这四个部分。

首先，我们思考一下企业存在的本质是什么？ 是科技？是人和？很明显这些都不是。作为社会化协作的一份子，企业也秉持了几千年以来的"以物易物"的传统，是生产价值。这也是人协作本质的关系。

价值链

我们要生产价值，那么就会需要生产价值的流程，也就是价值链(value stream或者value chain)。比如说设计产品，到开发产品，到出售产品，到产品反馈。

这里要注意的有两个点:

1. 价值通常都会被称之为产品，不论是实物还是虚拟的服务。
2. 价值链不仅仅需要包括生产流程，需要包括其他的支撑环节，形成一个闭环，这样才能够不断增长。

业务能力

从价值链的分析来讲，已经划分成了各个环节。如果不追求颗粒度，那么每个环节就可以称之为业务能力。比如设计产品能力，开发产品能力等。但是这么粗粒度的划分，往往会出现复用度不够，也不能直接用来指导能力实现。

概念信息

于是我们对业务能力进行分解，比如设计产品，会生成出两个概念，设计者和产品；销售产品则会引出两个新的概念，客户和合同。这些抽象出来的业务概念，是业务领域和流程的重要元素，不随着时间或者技术的改变而改变，

并且经常参与到多个领域之中，所以也是业务架构中很重要基础的部分。

组织架构

如果我们把上面三个元素认为是业务相关的，那么接下来这个就是怎么组织人干起来了。为什么会把组织架构提到业务架构的核心元素之中，我相信一开始都会有这个疑惑。在读了一些关于组织架构能力的书籍后，就发现无论想做什么事儿，都是需要合适的组织架构来支撑，尤其是跨部门的，组织架构负责了权责分配。所以组织架构相对于其他三个元素来看，反而成了最重要的部分，人的因素。

这四个部分回答了业务架构的内容，虽然没有回答业务架构是什么的问题，但是从分析的过程中我们发现，业务架构帮助了企业如何去设计业务模型，如何去更好的落地战略目标，所以业务架构的概念也大概如此。我们这里还是引用一下两个定义，作为结论。

以实现企业战略为目标，构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。 摘自《企业级业务架构设计方法论与实践》

Business architecture represents holistic, multidimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders” .

业务架构代表了业务能力，端到端价值流，信息概念和组织结构的多维度视图，也紧密地把企业战略，产品，政策，解决方案和客户连接起来。

摘自《bizbok_v8.5》

业务架构设计步骤大纲

首先还是业务架构的起点，企业战略。这一层主要定义企业要做什么，是愿景之下的具体可量化的目标。这里引用文中的企业战略分析:

无论是世界级企业所设定的改变全人类的宏大誓愿，还是小企业期盼明天还能够在市场上生存的小梦想，都必须要“量化”出来，成为可执行的目标。这一点是业务架构设计人员在分析企业战略时必须要特别注意的，千万不要将战略只当作华而不实的口号，而是要能够像一棵参天大树一样，坚实地向上生长、开枝散叶

决定了目标之后，就可以从价值链入手进行具体的分析。

价值链主要包括基本活动和支持性活动，基本活动就是必要的生产过程，支持性活动则指对基本活动起辅助作用。比如基本活动包括生产、销售、售后，支持性活动则是企业基础设施、人力资源管理、研究与研发。

这里的活动是出自于BPMN，一个流程就是一个活动

价值链设计之后，就可以根据设计的活动进行业务领域的划分，进行业务流程的设计。这里需要注意的点是企业最好使用统一的语言语法，否则会带来很高的沟通成本。到了这里，我们就感觉很熟悉了，领域建模及时序图。

在分工确定后，那么组织架构的模型也就呼之欲出了。但是怎么设计横向和纵向的权责，也是一个比较困难的问题。

接下来就是传到给IT架构去实施，blablabla… 当然也能够将业务架构设计优化一下，更清晰地传到给技术，比如架构"构件"的元素。

业务架构的注意事项

这个部分，主要是从干货满满的书中进行节选，挑选了一下个人觉得比较有启发的点。

1. 业务人员与技术人员融合得越好，就越能产生高质量的模型和系统，这也难怪高盛、大摩这些金融机构中数字化转型的坚定执行者，会引入占员工比例约15%甚至20%的技术人员，并直接派驻到业务部门与业务人员共同工作。相比之下，国外金融机构技术人员占比一般不足8%，国内通常为4%左右，近几年才刚刚有所增加。目前似乎也可以说，除了科技企业，其他行业中还很少有哪个企业真的达到了与信息时代、数字化时代相称的人员结构。
2. 业务架构更关注的是企业的整体设计，是典型的“不谋全局者不足以谋一隅”。如果再加上对战略的分析，就可以形成以战略为导向的整体企业能力规划，这种分析方法非常适合于做企业转型规划，尤其适合于传统企业进行数字化演变。企业既可以根据这一设计结果启动整体转型，也可以在通盘考虑的基础上进行试点建设。
3. 企业级业务架构是一种规划，它要求IT设计继承这套结构，继续向下分解为IT设计元素。企业级业务架构是一座桥，业务通过这座桥以更加结构化、逻辑化的方式进入到软件过程当中。
4. 业务架构方案主要包含3个部分的文档：企业级架构方案的整体描述、分领域或分应用的方案描述、业务组件的方案描述。
5. 业务架构建模过程并不能代替对架构方案的解释。如果建模完成之后，没有业务架构设计人员到项目中去以模型沟通需求、以模型宣讲企业级理念，那么模型的传导是极可能会出现“信号衰减”的。架构设计人员的缺位可能会导致方案失效。
6. 业务架构师非常适合作为与业务人员接触的“技术第一人”，在工作中，业务架构师可以及时调动需求分析人员、产品经理、开发人员提早参加到需求的形成过程中，将需求管理直接转变为业务规划，这才是各方都希望实现的融合与快速反应。
7. 企业级项目的建成其实就是其崩坏的开始。
8. “敏捷宣言”中提出的4个核心价值：个体和互动优于流程和工具、工作的软件优于详尽的文档、客户合作优于合同谈判、响应变化优于遵循计划。
9. 如何衡量企业级业务架构的价值: “转型”转的就是行为习惯，转型项目成功与否，只需要观察企业中各级领导、员工的行为习惯是较之以前是否发生了变化。

读后感

读完之后，觉得书中的满满的都是干货，似有所得，但也好像无法把握，大概就是纸上得来终觉浅的原因。而文中的一些观念，也与之前读的书，思考过的观点，甚至于生活，人生都有丝丝缕缕的关系，所以自己现在应该还属于看山是山的阶段，距离下一段还是需要砥砺前行。2021年已经出发，希望大家可以达成定下的目标，一起加油!