继“中台”和“低代码”后，我的烂大街系列又把“企业架构（以下简称为EA）”和“业务架构（以下简称为BA，通常是EA中的业务部分）”盯上了。
按说我自己是“企业架构”理念的长期鼓吹者，很多年前我就靠着鼓吹企业架构的思想去销售并交付IT战略规划类咨询项目（参见《中国企业信息化规划方法演进（二）—— 架构和管控》），近年来，我更是热衷于推广企业架构管理工具（EAM，参见《企业架构管理的利器 ｜ 打开BCG Platinion架构师的工具箱》）。
非常多的中国企业，尤其是大型企业，目前的确非常缺乏能够衔接业务和IT，分析需求轻重缓急，规划技术蓝图，指导项目建设的角色，即所谓的“企业架构师”（Enterprise Architect），为啥我就突然开始“黑”企业架构了呢？
我目前对于企业架构“烂大街”的担忧，来自对一些现象的观察：
一是我最近参与了一些业务架构师或者企业架构师的讨论，感觉他们谈理论概念多，谈具体业务问题少，很少听到他们提到用企业架构或者业务架构解决了什么具体业务问题，有些其他业界朋友也有同感（参见《行业观察 | “中台”之后，言必称“数字化XX”和EA概念滥用》）。
二是国内某些大型企业在应用EA方法中，积累了一定的经验，在社会上以研讨会或者管理培训的方式推广咨询服务，而中国企业管理圈一向有爱盲目跟风的习惯，例如一窝蜂地“学华为”就是典型现象，他们没有了解那些声称成功实施EA的公司的组织上下文环境以及所投入的资源，试图照抄照搬。
三是我深入观察了至少三家知名企业（大几百亿到千亿级规模），在过去三年期间请某些号称成功应用了EA的企业输出成果做咨询，在一通猛如虎的操作后产出的文档，看起来就是传统的信息系统和业务流程的分级分类原则而已，并没有感觉到使用EA方法或者不用EA方法的差别，其中一家企业的CIO跟我说，他们弄出来的EA框架根本就用不起来。
所以，趁EA和BA还没烂大街前，我先来给企业管理者们泼下冷水。
企业架构并不是新概念，从计算机进入到企业开始，企业就面临着如何将业务应用需求和软硬件系统设计相匹配的挑战，IT公司和咨询公司开发出了相应的方法。学者Svyatoslav Kotusev（这位年轻学者是反EA的主要意见领袖，实际上，他并不反EA思想，而是反对所有的现有EA框架）将EA发展分为三个阶段：
早期阶段：从60年代到80年代末，代表性方法是IBM的业务系统规划（简称BSP）方法，同时，当时的安达信（也就是埃森哲的前身）也提出了称为Method/1的类似方法（IBM和埃森哲不愧是企业IT服务的鼻祖，参见《2000年的IT咨询行业地平线》）。
前EA阶段：1987年IBM工程师Zachman提出以他本人名字命名的框架，并正式引入了“企业架构”这个名词。
现代EA阶段：2000年后，早期阶段的各个方法论经过演化，在军队、政府、企业等EA应用中形成了几个框架。其中由非营利组织Open Group所倡导的TOGAF在企业环境中的EA应用最为普及，其框架以及方法论体系（称为ADM）目前成为了全球企业应用EA的事实性标准：
尽管很多大型企业宣称已经成功实施了 EA，一些IT服务商和管理咨询公司也大力鼓吹企业导入EA，不过，对于EA的争议、批评从未停止过。批评者认为无论哪一个阶段的EA方法，都存在共同的缺点：
1. 需要投入大量的人力、物力来进行EA规划和管理。
2. EA活动产出的文档过于抽象，追求不必要的琐碎细节，管理者和业务人员难以理解，因而实际也难以实施。
3. EA相关的业务活动只存在于“象牙塔”中——带有学术性质，不接地气。有研究者经过实证研究发现EA方法需要企业付出不可理喻的成本，产出一堆没用的文档，最后被束之高阁。
在言辞激烈的批评声中，有人将EA框架称为管理理论的“世纪性赶时髦”（fad of the century），有人把EA框架称为“高管的毒品”（ cocaine for executives）。2011年底，当时的美国联邦政府CIO ，在美国政府信息化过程中大力倡导大数据分析和云优先理念的Vivek Kundra，在一次管理信息系统学术会议上公开评论EA是“比没用还糟糕（worse than useless）”，招致了EA之父Zachman的争议反弹。
我认为，在评论一项管理方法的好坏时，要回到事情的本质：我们需要这个管理方法的初心是啥？
在EA领域最有影响力的学术著作之一，Ross等人所著的《企业架构作为战略》一书中，将企业架构定位于：是衔接业务战略举措的运营模式设计，定义业务核心能力，输出到业务流程设计以及IT系统建设的战略执行，并且接受反馈，调整企业架构（下图）：
我将自己对企业实施EA目的的理解画成下图，包含如下要点：企业架构体系是用信息技术来支持企业战略举措执行的过程；企业架构核心是一套结构化的信息组，又分为相互衔接的两个组：业务架构和IT架构。企业要建立一套业务和IT之间衔接的治理机制，无论是叫BT/IT（参见《FCT模型 ｜ 大型企业业务流程和数据的治理体系》），还是叫“EA治理”，道理其实是一样的。
企业架构的目的是指导IT项目建设的范围定义、优先级衔接，确保系统建设间不产生冲突、误差；企业架构存在若干以时间轴分布的状态（state）：现在状态、未来状态，从现在看未来叫“规划”，推进从现在状态到达未来状态的过程，叫“变革管理”。
当我们将“企业架构”作为一套管理体系来谈论时，这实际上包含了自上而下的三层意思：
1. 它是一套管理理念，指导行动。
2. 它是一套标准化的方法，包括术语、模版和开发方法（也称为“框架”），用共同语言来协调EA的各干系方：企业架构师团队内部、业务部门、IT部门、企业高层管理者、外部供应商等。
3. 用软件工具来承载、记录上述框架，支持架构开发的方法过程，这样的工具称为企业架构管理（EAM）软件。
企业实施EA的必要性和好处很多，我这里引用一个视频，不展开说：
而在企业具体实施EA中，的确存在这样一些问题：首先，EA最被人诟病的是“不说人话”。随着EA理论不断发展，EA框架（例如TOGAF）包含了一套自成体系的术语，普通业务人员难以理解，因此批评者直指要对企业架构“去神秘化”（demystification）。
企业架构解决的是战略执行中业务和IT对齐的问题，这本身并不是啥神秘的事情，当前不同流派EA框架的源头几乎都可以追溯到60年代就有的IBM 业务系统规划法，这个“V模型”方法本身很直观，能被大多数人理解。
TOGAF声称整合了众多大公司开展EA的最佳实践，然而在我学习TOGAF过程中，我确实感到TOGAF的不少术语跟众多企业或者社会上已经被广为接受的管理术语不兼容，很是别扭。
例如《TOGAF系列指南》里跟业务架构相关的商业模式、价值流和业务能力的文档，其中商业模式就是在精益创业（Lean Enterprise）中广泛使用的“商业模式画布”而已，这个模型是否适合大型企业，本身就值得探讨，大型企业更为接受的战略执行模型，是IBM BLM（参见《战略管理｜ 正本清源谈BLM的真相》）一类的模型。
更让我困惑的是“价值流”（value stream），我好歹也是全球排名前列MBA项目二十年前的毕业生，做了二十多年的管理咨询，企业业务分析工具用过价值链、用过业务流程，也懂企业级业务流程框架（EPF，参见《从业务流程到知识管理到自动化 | 走出业务流程的丛林》），在制造业做工厂运营提升的精益分析时还用过“价值流图”，可是第一眼看到TOGAF下图这个“价值阶段-价值流-价值”模型时，还真是一头雾水，这些“价值-价值流-价值阶段”都是什么鬼？
仔细读完文档，我终于明白TOGAF说的“价值流”就是我用了二十年的“端到端流程”的意思，跟精益分析的价值流也完全是两回事（虽然TOGAF指南中声称其概念来源于精益的价值流图）。
价值链、端到端流程、流程分级这些概念，通过管理学教育以及我们咨询顾问对企业都普及了几十年了，又来旧瓶装新酒，整出些稀奇古怪的名词，我觉得在企业内除了混淆视听、增加实施难度外，有百害而无一利。
说起企业内管理语言的兼容问题，TOGAF自己也承认EA框架和企业的其他管理体系，包括战略和业务规划、运营管理、项目群和项目管理、IT解决方案开发等有区别，又具有互操作性。
在我来看，企业的这些领域内都存在一些和TOGAF出发点类似、试图规范管理术语和流程的管理框架（Framework）或知识体系（BOK）。
运营管理领域里，例如供应链管理的SCOR、APICS知识体系，业务流程管理的APQC体系等等；项目群和项目管理领域里，例如PMP PMBOK，PRINCE2体系等；IT解决方案开发领域里，例如SAP ERP的实施方法论，或者敏捷软件开发的Scrum方法。
这些方法论体系每套都号称是一把手工程，都定位于企业级流程，EA体系再掺合进来，每套体系各说各话，互相打架，不把业务部门、IT部门和高层领导搞晕才怪。可以设想下，供应链部门说“OTD流程”，架构部说“价值流”，其实是一回事，大家究竟听谁的？
市面上有不少EA管理工具，称为EAM，用来做企业架构的建模、管理，主要产品及厂商有：
Open Group官方认证了九款工具符合TOGAF规范，其中就包括在中国国内较为知名、在业务流程建模领域里普及多年的SoftwareAG的ARIS（参见《业务流程建模和企业架构应用于企业管理的误区》）。
这些工具的实施需要基于EA管理在企业内的定位，它究竟是架构部门内部使用的一个IT工具，用于架构部门内部统一语言、统一工作方法、提高工作效率和精确性；还是用这种工具产出的模型、图纸，去跟业务部门和高层领导沟通？这是企业引进企业架构工具所要思考的问题。
我跟在欧洲做企业架构咨询的同事交流，他们的经验是这些工具虽然对企业的EA管理来说不是必须的，也的确有很多欧洲的政府机构、大公司甚至是系统集成商在使用这类工具，顾问在项目中一般也就跟着客户用这种工具就好了，并没有特殊的倾向性选择。
研究EA的学者们还提出一个观点，EA本身并不能降低企业业务管理和IT管理的复杂性。EA产生的初衷是解决业务和IT对齐、战略和执行对齐之间的复杂性的，然而由于前述实施EA本身的复杂性，又带了新的管理复杂性，包括：架构治理、架构模型的开发和维护、在组织内对架构方法和内容的沟通等等，用EA的术语“能力”（capability）来说，EA本身就又成为了企业一个新的能力。管理学家最新研究认为，EA进入到企业组织中是非常困难的，EA部门也不应该进入到企业的决策流程中。
这真是企业为治理复杂成立一个“复杂问题整治办公室”，而这个办公室本身就变成了一个超级复杂的组织，并成为造成企业新的复杂的源头。
正是为了简化企业IT建设复杂性的原因，在大数据、云、用户体验等等大行其道的今天，EA本身被批评者认为是一种不敏捷的做法，这也难怪上述的前美国联邦政府CIO（1974年10月出生，他从联邦政府CIO任上辞职后曾担任Salesforce负责新兴市场的执行副总裁）在大力倡导美国政府机构的IT应用应该全面上云、采用敏捷方法时，有意无意地言语间贬低EA，引来了可能比他父亲年龄还大的EA之父（1934年12月出生）的反对，这多少反映了企业级IT发展的代际差异。
企业在今天思考数字化转型战略时，值得思考是否应用企业架构方法、怎样用，总结一下本文，我的观点是：
1. EA思想本身是有价值的，企业要形成战略导向的IT规划和IT治理机制。
2. EA框架仅仅是实施EA方法的参考，切不可照搬任何现成的EA框架，对TOGAF一类框架要进行适当的裁剪和修改，融入到企业现有的业务管理和IT管理体系中。
3. 切不可照抄其他企业或组织的EA实践，每个企业的基因、投入力度都不同。
4. 市面上宣传的EA理论或实践大都是理念培训性质的，企业要从最简单可行的EA原型做起，形成自己的EA方法，持续改进，切不可一上来就追求尽善尽美、复杂庞大。
5. 最后强调一下，企业任何管理手段最重要的因素是人的因素，EA实施成功的关键是变革管理（参见《变革管理 ｜ 为什么大多数企业架构最后都成了花架子》），对人的理念和行为的转化的促成，而不是采用了什么高大上方法和工具。
免责声明：
文章系本网编辑转载，会尽可能注明出处，但不排除无法注明来源的情况，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与本网联系.
[声明]本站文章版权归原作者所有，内容为作者个人观点，不代表本网站的观点和对其真实性负责，本站拥有对此声明的最终解释权.
