在展开企业架构的介绍之前，以终为始，回归初心，暂且放下企业架构是什么怎么做，先聊聊企业架构的价值和成效度量。
做事之前定目标和考核要求是项目管理里再简单不过的逻辑，换到企业架构这个事儿上，却发现很难定出来一个公允的标准，价值度量极其困难！
有些企业架构师可能会说，企业架构是个方法论，方法论不能度量。
确实是，很多人听到“企业架构”一词时，很多情况下脑海中首先浮现的画面就是：一群自称是企业架构师的人做着一系列所谓的企业架构实践活动，例如分析商业模式，调研业务流程，整理应用系统，盘点数据资产……
当你去问他们在做什么的时候，往往劈头盖脸的就是一堆抽象的概念和陌生的方法论（企业架构方法论对架构师来说是必需的技能，但对企业内很多人来说，作为方法论的企业架构其实是看不到和难以理解的）
最终大多数人选择在心里骂一句“太虚了”，然后选择敬而远之……你搞你的我搞我的，听不懂，也不想听……
其实在我看来没有那么复杂。
简单理解，企业架构的相关方法就是在给企业建模，让我们能看清企业的结构。打个比方，就像是在给企业拍个 CT，就像我们去医院，医生为我们拍的 CT 一样，通过拍片子，让我们能看清楚企业和个人现在的内部结构是什么样的，从而诊断和分析问题，寻找解决方案。
有意思的是，像给企业做企业架构建模一样，给一个人拍 CT 也是不便宜的，做一个 CT 动辄成百上千块钱，那我们是为什么心甘情愿地为拍 CT 这件事情刷卡付钱的呢？甚至有时候花重资拍个 CT 还要排好几个月的队才能做上？我们是为了什么？
难道是因为周围的邻居去医院拍了，所以我也要拍一个？
难道是因为这个医生有名气，拍片子技术好，动作娴熟，服务周到？
难道是因为拍出来的照片清晰，底片用料好，或是用的仪器好，是进口的大医院都用的仪器？
对于个人拍个 CT，这些答案看起来很荒唐是不是……
我们肯定不是为了拍 CT 而拍 CT，我们是为了解决问题；例如身体不舒服了，需要通过拍 CT 明确问题所在，从而针对性地解决问题。
拍 CT 只是手段和方法，并不是目标本身！
这个道理看起来异常简单和清晰，以至于我在写上边这段的时候都觉得自己像个傻子……
但讽刺的是，在企业实施企业架构的时候，却很容易陷入这样的混沌漩涡，滑入这些荒唐的答案里：
因为其他企业都在做企业架构，所以我们也要做……
因为某家公司做企业架构很有名，方法论成熟，产出物很完备，所以我们也请他们做一下企业架构吧……
因为某家公司做企业架构用的方法很好，是现在最流行企业架构框架，名企都在用，所以我们也请他们做一下企业架构吧……
相同的场景，放到企业架构上，就感觉将所有的滑稽隐藏了起来……
其实，大多数企业也并没有这么草率，本着“你有我也要”（EA Envy，企业架构红眼病）的方式在实施企业架构，毕竟是要花钱的，而且一般成本并不低……
更真实的情况则是，往往企业高层在思考面对企业的相关“问题”的时候，学习和思考后觉得企业架构可能是一种“解题思路”，但是将“做企业架构”任务移交和下发到具体的实施部门的时候，这种“问题”的目标慢慢模糊、淡化甚至丢失，只留下了“要做企业架构”的举措、任务和命令。
至此，真正的目标“要解决的问题”丢失，而手段“要做企业架构”则上位变成了目标本身！
不要觉得这种情况应该是少数个例，在我的经验里这种情况比比皆是，以至于我现在每和一个新的企业开始聊起企业架构，第一个问题永远是：咱们企业希望通过企业架构方法的引入，解决什么具体的问题？
而得到的答案往往：
要么就是：“降本增效”、“推动战略转型业务创新”、“促进业技融合”、“推动数智化转型”、“实现业务再造”、“构建平台化”等大词儿……
要么就是：“我们也不太清楚，上边儿领导想推动企业架构，让我们找找行业里的专家多学习交流，你们能不能告诉我们企业架构能解决什么问题？呃……”我们想办法去直接和企业的管理层沟通，探究他们期望解决的具体问题，而结果往往是不同的领导有不同的期望……
企业架构就像是前几年的“中台”一样，变成了另一个许愿池，仿佛像是，只要企业做了企业架构，所有的愿望都可以实现，所有的问题都可以解决。
这就造成了一个特别有意思的现象，在企业高层眼里有问题，心中有目标，但问题很多，目标很多，不同的领导想解决的问题也不一样，管理层寄希望通过企业架构解决所有问题实现所有的目标；而真正落地实施部门，仿佛又失去了目标，迷失了方向，说不清要解决的问题，因为压下来的是做企业架构的任务，则自然而然把做企业架构当成了目标本身。
企业架构承载的是企业管理层对于企业的顶层管理视角，所以往往是一个自上而下的推动过程，在向下层层传递的过程中，初衷和目标很容易发生偏移，让度量的思考角度也随之发生了偏移。甚至不排除在管理层眼里，看到的也只是问题，没有过多考虑如何度量和验证，这就让度量这个事情变得越发模糊和困难起来。
看清楚了这一点，我们再问自己：谈企业架构的度量，到底我们到底要度量什么？想必答案也变得越来越清晰：
因为，企业架构是手段，应用企业架构手段解决企业的问题才有价值。
所以，我们并不是要度量企业架构这个手段本身做得怎么样，而是要度量问题是否通过企业架构方法被解决或有改善！
因为，技术上要解决的非功能性问题比较明确和固定。
如果我们仔细看上边技术从质量维度的指标，我们发现，其实当我们在谈一个指标的时候，背后一定有一个系统的非功能性需求和目标。
可用性指标 -> 如何提升系统的可用性？
性能指标 -> 如何提升系统的性能？
安全指标 -> 如何提升系统的安全？
可维护性指标 -> 如何提升系统的可维护性？
……
而无论是什么领域的什么系统，不管是财务，人力，渠道，销售，仓储、物流……无论是谁用的系统，无论什么领域的系统，从技术的非功能性需求角度以上指标都适用，无非是指标的基线要求和侧重不一样。
之所以技术指标可以复用，其本质是因为大多数系统要解决的“非功能性问题”或要达到的“非功能性目标”都是相似的，所以指标体系和价值度量也是相对明确和固定的，可以直接借鉴和应用。
而反观企业架构，因为其要解决的“问题”和达到的“目标”对于不同的企业，甚至是对于一个企业的不同发展阶段，往往都是不同的，所以指标体系和价值度量也无法统一和固定，无法直接借鉴和应用，例如：
公司希望通过企业架构助力组织架构优化，解决组织上的一些问题和痛点
公司希望通过企业架构助力流程再造，通过对于业务流程的数字化改造降本增效
公司希望通过企业架构助力 IT 投资组合优化，实现 IT 投资的 ROI 最优化
公司希望通过企业架构助力 IT 规划与治理，界定清楚现有系统边界，指导 IT 架构决策
公司希望通过企业架构助力业务能力梳理，从而实现内部能力商品化，扩展业务
公司希望通过企业架构助力数据资产盘点，为了数据驱动决策或数据要素入表
……
这里可以是不同公司应用企业架构各自想解决的问题，也可以是同一家企业期望应用企业架构能同时解决的问题……
像我们前面提到的，我们应该度量的是“问题的解决”或“目标的达成”，不同的企业和场景应用企业架构解决的问题的多样化和个性化，就决定了对于企业架构价值的度量，也是多样且个性的。
这就是为什么企业架构一直没有一个像技术指标一样的，统一明确可通用的价值度量体系和指标体系的根本原因。
当然不是，管理大师德鲁克有句名言：“没有度量就没有管理”，无法管理就无法验证其价值和改进，所有的行动也就失去了意义。
其实，聊到这里，问题的答案就非常简单了，我们来一起复盘梳理一下思路和观点：
企业架构是手段，应用企业架构手段解决企业的问题才是价值。
我们并不是要度量企业架构这个手段本身做得怎么样，而是要度量问题是否得以解决。
企业架构作为企业建模和分析的手段，能解决很多类不同纬度和层面的问题。
因为企业问题的多样性和独特性，导致企业架构没有一个通用的度量标准。
企业架构本质上在对一家企业建模然后讨论和分析，而企业是复杂的也就决定了企业架构的复杂性，困难问题没有简单解，这就导致企业架构看起来是一个即抽象又庞杂的体系，看不见摸不着，只有一堆模模糊糊抽象的概念，一不小心，就很容易被卷入到方法和各种概念之中，迷失方向。
最后想借用最近在听的，费勇老师在 B 站《金刚经》中的几个子标题作为本文的收尾和总结：
把问题还原为发心
把手段还原为目的
把存在还原为缘起
把观点还原为事实
把个体还原为系统
把困境还原为成长
作为以价值导向为初心的企业架构工作者和实践者，无论是内部企业架构师还是外部咨询师，只有保持住发心，时刻铭记我们的目标，承认和尊重企业发展的约束和缘起，基于事实，从系统的高度和角度看待企业，才能解决企业正在面对的挑战和困境，促进企业的成长，让我们的工作和付出对企业有价值。
注：本文来自于“架构三人行”公众号，作者 王健，经授权同意后发布。
InfoQ 数字化经纬正策划一项专题《央国企数智化转型与创新》，希望通过本专题，探讨央国企的数智化转型现状、挑战和路径，寻找变革路上的成功案例，为数字经济下的产业焕新提供样本参考，为未来智能产业发展探寻路径。
福利通道
-
关注「InfoQ数字化经纬」公众号，回复「案例」领取 《行知数字中国数字化转型案例集锦》。 -
关注「InfoQ数字化经纬」公众号，回复「进群」加入数字化读者群交流。 -
关注「InfoQ数字化经纬」公众号，回复「抽奖」可以参与本周活动，有机会获得精美礼品。
今日好文推荐