EA——或者我应该说“商业技术战略”——不是战略的表亲，而是后代。只有当EA来自连贯的业务战略时，EA才有意义。对于技术公司，即销售基于技术的产品和服务的公司——EA的作用更容易定义。谁不想帮助技术（又名“工程”）——那些构建产品和服务的人——使用正确的基础设施上的正确数据构建正确的应用程序？

EA的官方步骤包括开发四个“架构”：

“业务架构——定义业务战略和组织、关键业务流程以及治理和标准。

应用程序系统架构——为部署单个系统提供了蓝图，包括应用程序系统之间的交互及其与基本业务流程的关系。

数据架构——记录逻辑和物理数据资产的结构以及任何相关的数据管理资源。

技术架构——描述了支持部署关键任务应用程序所需的硬件、软件和网络基础设施。”

让我们翻译所有这些：

“业务架构——定义业务战略和组织、关键业务流程以及治理和标准：

公司如何赚钱的描述。赚钱的流程、产品和服务的描述。描述公司今天如何赚钱，以及它预计在未来3-5年如何赚钱。公司赚钱的竞争市场描述。（有工具可以帮助做到这一点。）

应用程序系统架构——为部署单个系统提供了蓝图，包括应用程序系统之间的交互及其与基本业务流程的关系：

实现赚钱的流程、产品和服务的软件应用程序。使公司在未来3-5年内赚钱的软件应用程序。（也有这方面的工具。）

数据架构——记录逻辑和物理数据资产的结构以及所有相关的数据管理资源：

公司需要的数据类型来为软件应用程序提供燃料，从而实现赚钱的流程、产品和服务。使公司在未来3-5年内赚钱的数据。（有这方面的工具。）

技术架构——描述支持部署关键任务应用程序所需的硬件、软件和网络基础设施：

使用公司所需的数据的技术基础设施和技术交付，为软件应用程序提供动力，从而实现和优化赚钱的流程、产品和服务。使公司今天和未来3-5年能够赚钱的基础设施。（有这方面的工具。）

一个测试是，这一切对非技术高管来说有多容易理解。我们可以选择“业务架构”、“应用程序系统架构”、“数据架构”和“技术架构”，也可以简单地选择策略、应用程序、数据和交付。（我经常对IT坚持要求每个人都学习自己的语言感到困惑，即使IT服务于业务。）

当然，这一切都有“框架”。（总是有框架。）很多很多框架都有奇怪的名称，比如TOGAF、Zachman和FEAF。我从未见过任何成功实施任何框架的人。当然，有些人到处实施了部分，但实际上没有一个部件始终将TOGAF、Zachman或FEAF的使用制度化。

治理呢？BTS必须自上而下，而不是自下而上。商业技术策略师应该与执行团队和商业策略师合作，而不是与技术人员合作，至少在最初不应该。他们的第一份工作是转换；他们的第二份工作是桥梁和翻译。如果我们在RACI制定这个图表，BTS有责任，高管有责任。最初，会咨询技术人员。如果这种治理有任何变化，BTS将失败。为什么？因为技术“恶作剧”无处不在。技术人员总是认为他们最了解情况——有时当他们的架构与BTS完全一致时，他们会知道——但通常他们不知道。技术与业务之间的脱节大于业务与技术之间的脱节。

如果BTS沦为具体的商业价值，它绝对值得。几十年来，我们一直有一个统一的目标。它还在这里。它将永远在这里。BTS只是公正的，都是关于对齐统一的。多年来，EA方法、工具和框架得到了开发，并强加给几乎不了解它们的公司、战略家和技术人员。现在是时候将EA剥离到其最基本的特性了——业务战略与运营和战略技术保持一致。我们可以继续使这一切复杂化，或者只是承认我们正在通过开发动态业务技术战略来寻求业务技术一致性。EA是个好主意，但它不是一个切实可行的解决方案。BTS将产生更好的结果。