当前位置：首页 > news >正文

聊聊“企业架构”这个连很多IT老兵都陌生的词

news 来源：原创 2024/5/4 5:07:42

为什么要谈企业架构

对很多人来说，哪怕是对很多IT业内的老人来说，企业架构都是一个十分陌生的名词。“架构”是对一类存在共性的问题解决方案的抽象，这个词我们都很熟，搞IT的同学，经常聊着聊着，就开始聊到这个架构那个架构。但我们常聊的那些都叫软件架构，英文写作Software Architecture，简称SA，而本文接下来要介绍的叫企业架构，英文写作Enterprise Architect，简称EA。

企业架构不能简单地理解成“企业级的软件架构”，其内涵要更大，也更为重要。可以说，在信息化和数字化转型的大背景下，企业架构对企业来说，是一种非常重要的“软实力”。

北京大学教授、工业和信息化部原副部长杨学山老师对企业架构的重要性有过一段论述，我听完醍醐灌顶。杨老师说：与西方发达国家相比，国内的信息化建设在硬件方面已经不相上下，在软件方面有5年的差距，在信息化管理方面有大概10年的差距，在企业架构方面则有20年的差距。

在我们进入IT行业之前，大多数人都会认为搞IT就是搞技术，不过入行久了，就会发现技术很重要，管理同样不容忽视。

我们都知道：国内的IT行业相对发达国家来说，起步要晚一些，有不少短板要补齐，经过这些年的奋力追赶，我们正在朝着跟跑、并跑、领跑的目标稳步迈进。

同时我们也发现了：硬件上的短板是最容易补齐的，软件上的短板则要难一些，管理上的短板则要更难一些，在网络安全方面甚至还有三分靠技术，七分靠管理的说法。现在杨老师告诉我们，在管理之上还有一块短板亟待我们重视，这就是企业架构。

什么是企业架构

企业架构很重要，短板也很突出，那我们很自然就要问：什么是企业架构呢？

这是个好问题，但要回答好这个问题，很难。这个问题是这篇文章的重点问题，也是难点问题。我费了很多功夫，也翻了很多资料，我可以引经据典地告诉大家现在都有哪些主流的企业架构，这些企业架构各有又有发展历程和优势短板。但是，想用几句话就能清晰简洁地让大家建立起对“企业架构”这个陌生名词的准确概念，却十分困难。

我有两种选择，一种是列举各家对“企业架构”的定义，搞一些名词解释，贴几篇论文，最后附几份画得花里胡哨的图和表，这样做省时省力，看起来也挺像回事。不过，大家看完以后该不懂的还是不懂。当然，不是说这些资料写得没水平，而是大家还没建立对企业架构的基本概念，就好比拿着“龙书”请一位清朝的状元看，看完以后他肯定连什么是编译器这个最基本的问题也答不上来。

另一种选择自然就是首先建立起什么是企业架构的基本概念。这是一条陡峭的路，很难，而且在当下这个企业架构远算不上瓜熟蒂落的阶段，很容易挂一漏万甚至以偏概全，但是很有价值。这个部分我考虑了很久，改了好几稿，最终还是想朝着这条路的方向努力试一试。

好了，回到我们的问题，什么是企业架构？

我的回答很简单。软件架构我们都熟悉，那么，现在你要做的只有一件事：把由一个个活生生的人和部门所构成的企业，想象成一套超大型的软件。那么，这套超大型软件的“软件架构”，就叫企业架构。

有了这个类比，我们可以尝试回答大家都要问的第二个问题：为什么需要企业架构？

前面我们说，企业架构在信息化建设、数字化转型扮演了重要角色，而且国内在这一块上还有短板要补。但是，企业架构之所以讨论门槛高，是因为我们很多人都从没听过“企业架构”这个词，没有概念。我们不知道什么企业架构，这么些年也把活干完了，是不是说明这个玩意不过就是个看起来不错、实际没啥作用的学术玩具？

答案和为什么开发软件需要软件架构是一样的。企业架构也好，软件架构也罢，“架构”这种东西并不是从来就有的，在最开始的洪荒年代，人们怎样开发软件？都是一边做一边想，正所谓草鞋没样，边打边像。这种充满了手工小作坊气息的开发方法，注定不能适应现代对软件工程化工业化的要求。

原来都以为软件开发就是写代码，后来软件越做越多、越做越大才知道，写代码只是整套流程中的一个环节，而且未必就是最重要的那个环节。有很多的问题需要前后协调组织，于是有了软件架构。同样，从更宏观的整个企业的角度来看，软件开发也只是整套流程中的一个环节，于是就有了企业架构。

简单吗？简单，也不简单。

复杂在哪里？人不是机器。这个类比咋一听简单，但是你仔细一想，就会觉得总有一些违和感。我举一个例子，假设这家企业有一百个员工，这要怎么类比？语句？函数？功能库？显然都不是。算什么呢？最沾边的是运算单元，相当于一套大型系统，需要在一百台不同配置的机器上进行并行运算。

意思有点那个意思，但是，还有一点明显不同，那就是每个人都有不同的视角，这是机器所无法具备的。这个话题展开了可以写一篇科幻小说，不过，这里我们可以给刚才的类比打上第一个重要补丁：视角。

企业架构是一套框架的集合

什么是视角？同样一件事，从不同视角观察，可能看到并不相同的东西。这里我举《聚合架构》书中引Zachman架构论文的一条例子：同一座房屋，业务看到的是外观，建筑师看到的是结构和成本，承包商看到的是施工方案，完了还有材料商等等各种角色，看的是同一样东西，看到的却又不是同一样东西。

视角是可以进一步细分的。同一个角色视角下，还可以分出不同的观察维度，譬如Zachman框架就使用“5W1H”（分别是What、When、Why、Who、Where和How）来描述同一角色视角下的不同观察维度。

看不懂上面在说什么？不用担心，需要明白的只有一点——我们经常说要正确看待问题，但正确看待问题的角度有多少种呢？很可能不止一种。角度与角度之间不一定都是排它性的，企业架构要做的事，就是从不同层次不同角度观察同一件事情，然后尽可能把所有的这些不同，都统一到同一个框架里面来。

不同的视角，就会看到不同的问题，就需要完成不同的事情，就会产生不同的方法和流程。这就自然而然地得到第一个对于理解企业架构很重要的结论：企业架构不是一个框架，而是一套框架的集合（a set of architecture）。

主流企业架构介绍

前面提到Zachman框架，这是企业架构的开山鼻祖，由John Zachman在1987年首次提出。当时知道了这个我的心情是复杂的，想到开山鼻祖也才三十郎当岁，要学的东西不会太多，但又一想：总共才发展30来年的新科目，我们落后了20年，四舍五入相当于才刚起步，前面要追赶的路肯定挺多。任重道远，诸君加油。

Zachman名气很大，只要你去查企业架构的资料，一定都能看到这个名字，是企业架构里面的“名牌”。Zachman框架是由John Zachman通过一篇名为《A framework for information systems architecture》的论文提出来的，这当然是一项开创性的工作，从此我们就有了新的角度看待企业问题。不过，个人的局限毕竟摆在那里，很多东西只能说起了个头，创造了一些概念，并且拢起来形成了一套框架，实际要用起来还需要补充一系列的工具，盲目追名牌在企业框架这里也是不可取的。

在实践中谈的比较多的是TOGAF，全称The Open Group Architecture Framework ，前身是美国国防部制定的TAFIM，或者叫充分借鉴了TAFIM的精华。相比起Zachman，TOGAF具有几个特点。首先，这套企业架构是由组织而不再是个人制定，组织的名字就叫Open Group，是一个跨行业的论坛型组织。其次，TOGAF更为完整，将架构过程具体分为八个阶段，而且明确了每个阶段的交付物。最后，TOGAF的可操作性强，如果说Zachman更多的还是在玩概念，那到了TOGAF这里，就变成了一套套的说明手册。

TOGAF具有这些优势都为业界所看重，因此市场占有率很高，我看到的好几个数据都很漂亮，譬如说福布斯全球排名前50的公司，八成都在在使用TOGAF。但是TOGAF不但有点突出，缺点也突出，例如交付物繁多。前面我们说TOGAF分成了八个阶段，每个阶段都规定了交付物。具体内容当然也在不断迭代，我数了一下，在TOGAF 9.0中，流程图、事件图、软件工程图等等名字里带“图”的交付物就多达30余个，对企业来说，光完成这些显然也需要不小的资源成本。

其它的企业架构还有一些，譬如DDD、BIAN，还有当下很热的中台架构。篇幅有限，就不一一展开了，有兴趣的朋友，推荐阅读付晓岩老师的新作《聚合架构》。这本书的封面设计得很有寓意，是我们叫叠叠乐的积木游戏。叠叠乐有个特点，如果架构没构建好，后面就会稍微有点风吹草动，看起来风光无限的高塔就会马上垮得一塌糊涂。

在《聚合架构》这里，付老师不但对Zachman这些传统的企业架构进行了梳理分析，还结合付老师多年的实践经验，搭建了一套“新”的企业架构，这就是聚合架构。

付老师比较谦虚，说聚合架构并没有提出新的概念，而是站在前人的基础上进行加强整合，所以这里我也把这个“新”字打了引号。不过，这也是我觉得这本书难得的一个地方。企业架构是有门槛的，业内能长期从这个方向考虑问题的人恐怕不会多，而付老师不但长期研究企业架构，而且还分享，这种分享不是简单地重复前人的成果，而是经过消化理解，并加以二次创造——付老师很谦虚，不过这里我还是想用“创造”这个词，读这本书，处处都能感觉到付老师是运用了智慧和经验去帮助我们消化知识，我想，这本身就是一种创造。

作者简介

莫凡，网名木羊同学。娱乐向机器学习解说选手，《机器学习算法的数学解析与Python实现》作者，前沿技术发展观潮者，擅长高冷技术的“白菜化”解说，微信公众号“睡前机器学习”，个人知乎号“木羊”。

相关文章：