你在开玩笑吗？

当涉及到想象力时，生活总是胜过小说。最近，一家大公司要求我展示再次实施 EA 功能的 ROI 证明。

这家公司过去曾聘请过架构师，但在他们选择大型企业资源规划 (ERP) 解决方案作为公司的运营信息系统 (IS) 主干时，他们就被淘汰了。这在某种程度上是有道理的：IS 是围绕所有 ERP 功能组织的。那么在这种情况下，企业架构师的需求是什么？此外，我们可能认为公司的 EA 架构师实际上是 ERP 编辑的。

没有企业架构师的公司会获得默认的企业架构。因此，在这种情况下，此默认 EA 由 ERP 编辑器的策略驱动。只要公司的战略以卓越的商品服务实施为基础，它就可以奏效，而且在这种情况下也奏效了。这意味着公司的竞争优势基于成本削减和运营生产力。再加上最终在 ERP 之外的孤立的 IS 中管理的一两个业务创新。

这家公司最近完成了一项业务和 IT 审查，发现 ERP 是部署新业务线和所需 IT 推动力的瓶颈。因此，他们决定在许多 IS 战略领域推翻 ERP。但是他们现在缺少企业架构师。项目和项目负责人现在有一个长期的习惯，主要是为了他们自己的需求而做架构，并且不想改变这种做法。因此，EA ROI 证明的问题是为了有机会获得一些高水平的赞助，以应对变革的运营阻力。

我的回答不是“你在开玩笑吗？”但听起来很像。我失去了这笔交易。

危险

想大点。快速失败。我尝试了几个不成功的想法。

• 第一个是：如今，信息系统是每个业务战略运营实施的核心。如果没有人来推动 IS 架构，你怎么能想象取得成功的战略成果？答案是：“到目前为止，我们已经没有架构师了，一切都很好。这个论点并不能证明 EA 的价值”。客观地，由于情况会改变，答案并不真正适用……但它是客户，我不能这么说。
  
• 第二个论点是关于迄今为止从 ERP 编辑器自己的 EA 中受益。既然 ERP 的使用打算减少为非战略性商品服务，那么 ERP 架构师将不得不被公司的架构师取代。相同的答案：项目负责人不会让架构师对他们的业务嗤之以鼻。
  
• 第三个论点：让我和 C 级的人谈谈，我相信他们知道 EA 的价值，并且会支持再次将其引入内部。没有反应。也许我的对话者尝试过但没有被倾听。或者很可能他们不敢尝试没有数字。
  

然后光来了。危险。EA 的答案是什么？为什么又要 EA 回来？当你想到它时，这不是一个笑话：你确实想要 EA，为什么？

EA成本太高的想法是怎么来的？

越抽象的事物，就越难以将独家收益与它联系起来。所以 EA 投资回报率的回报部分肯定是难以阐述的。我们大概可以粗略计算出公司新业务战略部署的预期投资回报率。但是很难（委婉地说）隔离它的一部分，这要归功于企业级别的良好架构方法。即使使用不好的或默认的 EA 方法，我们仍然可以获得一些收益。并且，如果管理良好的 EA 实施，收益会更大，这一事实可能（委婉说法）永远不会被评估。

计算成本很容易（似乎是这样，但让我们从简单的角度来看）。企业架构的成本是多少？主要是花费时间的劳动力成本：架构工作、架构组合学、架构治理、架构支持和传播。最终还与架构工具相关的成本。此外，延迟上市时间的间接成本也可能被视为收入延迟过多（我们可以说安全工作流也是如此）。

即使使用默认 EA，也会发生这些成本！如果不做出架构决策，任何人都无法构建信息系统。问题是：我们是否想以一种有管理的方式组织这些决策？还是我们想让个人在每个决策点做出决定？考虑或不考虑其他地方做出的架构决策？在这种“默认”方式中，不会编译 EA 成本，因此我们看不到它们。

对 EA 的误解

EA 最大的错误当然是认为架构师必须做所有的架构工作。架构师是唯一能够使用架构材料来讲述“真相”的人，因为架构很复杂。

这种情况被称为象牙塔综合症。在这种情况下，架构师一起工作并生成仅供架构师使用和使用的架构文档。最终他们产生了一些转型影响分析：通常生产成本为 80% 的 20% 的部分。这些架构工件需要经常与“现实世界”保持一致。使用昂贵的工具。

总成本的 20% 的 80% 部分，对于其他任何人来说都足够了，要么由架构师或其他人生产，要么甚至不生产或部分生产。这一切都取决于利益相关者对架构问题的看法。碰巧的是，核心架构描述是在没有架构师负责的情况下做出的，并做出了相关的决定！

我们不想再去那里了。可以理解。这种没有重大影响的“无底井”成本来源是对 EA 不信任的主要原因。

如何让 EA 再次伟大？

让我们尝试以仅 20% 的 EA“大图”成本获得 80% 的 EA 收益。

这个想法是在战略/组织级别上重新控制架构决策。并避免让这些决策在本地子级别或全局元级别做出。

让我们来说明这个想法。

在进行任何重大战略转型之前，最好先解释一下我们想要做什么、为什么、如何等。企业架构如何在构想中发生？

让我们用 5W2H 方法来说明这一点：

• 什么？：我们将改变什么到IS组织（架构）？
  
• 为什么？: 我们怎么会改变 IS 架构？
  
• 在哪里？：IS的哪一部分会受到关注？
  
• 什么时候？: 有没有设想的路线图？
  
• 谁？：什么构建组织将操作更改？（以及如何在构建组织和 IS 构建块之间获得精益映射）
  
• 如何？：是否有任何 IT 推动者可以实现更轻松的更改？
  
• 多少？：与减少建筑债务相关的成本是多少？设置新的 IT 功能？
  

是的，这与 TOGAF 架构开发方法中的阶段 A：架构愿景非常相似。相似但不一样。在这里，我们不关注架构的架构，但我们希望将架构作为整体的一部分来关注。架构与任何其他考虑因素一样参与转换。

这里的想法是：让我们与大家分享架构愿景。就像我们对业务愿景、产品愿景、组织愿景所做的那样……

企业架构是业务需求、运营业务的 SI 产品以及人员和其他资源的组织之间的粘合剂，以帮助公司实现其下一个战略目标。