在 Vault Health，首席技术官 Steve Shi 开始企业架构 (EA) 工作，他对整个 IT、应用程序、系统和数据基础架构进行了现场调查，但将其限制在两周内，并针对每个功能进行一小时的采访。

Shi 说，客户，无论是员工还是为产品或服务付费的人，都必须“喜欢”这种最低可行的 EA 方法的结果。“如果你没有得到客户的认可，你就会失去动力，如果你失去动力，在最小可行的发布之后继续迭代就更难了，”他说。

像许多 IT 领导者一样，施正试图在未使用的复杂架构研究和缺乏足够范围和深度以提供持久价值的简陋 EA 报告之间取得平衡。找到这种平衡需要紧贴业务需求，削减繁重的工作，适当地确定项目范围，并设置和执行正确的架构标准和原则。以下是熟悉该流程的 CIO 推荐的五个步骤。

贴近业务

与业务利益相关者保持密切沟通是了解最小可行企业架构在哪里可以最好地帮助业务并随着业务需求的变化为持续的 EA 评估提供资金的唯一途径。

在 Carrier Global Corp.，CIO Joe Schulz 通过业务指标来衡量 EA 的成功，例如员工生产力如何受到应用程序质量或服务中断的影响。

Schulz 说：“我们不会将企业架构视为一群看门人，他们在本质上对某件事情应该如何工作有更多的理论性。”他使用 EA 工具 LeanIX 生成的报告和见解来描述生态系统的互连性以及整个产品组合的系统功能，以识别冗余或差距。这使得智能建筑和冷链解决方案的全球供应商能够“使许多决策民主化……（以）在我们的组织中发挥所有最佳思维和投资能力。”

破产技术和服务公司 Stretto 的首席技术官 George Tsounis 建议使用 EA 来“建立信任和透明度”，方法是告知业务领导者当前的 IT 支出以及平台与业务战略不一致的领域。他说，这使得未来与 EA 相关的对话“比企业架构师在孤岛中工作并且没有这种关系要容易得多”。

修剪繁文缛节

冗长的问卷调查和模板驱动的访谈是 EA 工作中常见但通常不受欢迎的一部分。最低可行的 EA 从业者建议消除任何不能提供基本信息并允许用户反馈的问题。

云超大规模企业 Amazon Web Services 的企业战略总监 Gregor Hohpe 建议从“重量级、主要是单向”的 EA 流程转变为与业务用户进行更简单、更快和迭代的对话。

在金融服务公司 State Street，全球首席架构师 Aman Thind 试图通过只提出精确且相关的问题而不是 EA 模板中的所有问题来简化 EA 流程。他说，专注于最重要的问题可以将架构审查和提交所需的时间减少至少一半，并使流程更加有效。例如，SaaS 应用程序用来提供用户界面的框架不如确定用户如何与其交互的身份和访问管理程序重要。

除了使用自动合规检查和自助服务平台外，Hohpe 还建议消除“大量被忽略的标准列表”，召开审查会议，所有文件都根据各自团队的首选结果进行逆向工程，“调整”会议增值主题，以及“从从未用于决策的重量级 EA 工具生成巨大的挂毯”。

在数字医疗保健公司 Vault，Shi 发现应用程序可观察性工具 New Relic 通过提供对整个架构的即时可见性，在加速 EA 工作方面很有价值。

他还使用新的术语和流程来避免常见的减速，并让人们意识到他的新颖方法。一个例子是“网站报告”，它要求用户设想最终的 EA 产品。这有助于定义关键要求，例如应用程序必须支持的事务数量和流程类型，“来自客户端并向后工作”。Shi 没有使用要求用户预先就关键技术决策达成一致的“一次性完成”流程，而是要求他们确认或修改“开发假设”，例如系统每天必须支持的数据库调用数量。他说，这种方法可以加快就数据库等组件的选择达成一致。

在应用程序推出期间，Shi 避免使用通用项目计划，而是采用他所谓的“特定宏排序计划”，即围绕里程碑（如 alpha 和 beta 测试及其相关的验证里程碑）构建的步骤。这为部署的每个阶段定义了业务方面的成功，例如收入或用户采用率以及从降低持续支持成本的支持流程中吸取的经验教训。他说，这也提醒每个人，“在我们知道架构已经交付了可衡量的客户价值之前，项目不会结束。”

范围正确

在一个最小可行的 EA 项目中承担太多，在完成之前它就会过时，交付结果太晚，无法满足并从商业领袖那里获得未来的资金。将其缩小太多，将无法提供充分利用 IT 投资所需的技术和业务的全面视图。达到适当的平衡通常需要专注于业务中的一个应用程序或痛点，或者由于新的业务或监管需求而导致需求快速变化的领域。

Gartner Inc. 副首席分析师 Nolan Hart 将适当的 EA 范围称为“最少数量的可交付成果，例如观点、参考模型和设计模式，有助于确保及时、合规地交付产品和解决方案。”他建议，与其花太多时间了解当前架构，不如“首先了解你想要的结果”。他说，“永远、永远、永远地迷失记录你当前功能失调的架构”是没有价值的。

Shi 建议最小可行的 EA 考虑“从用户界面到将系统链接到数据架构的 API 的所有内容，而不是单个孤立的组件或服务。”他说，提议的架构还必须能够在生产规模上进行测试，并且能够处理与它所取代的系统相同的峰值需求。

适当的范围也适用于 EA 组织。Carrier 不是专门的 EA 团队，而是为 CRM、现场服务、ERP、分析和数字工厂功能等关键需求创建了卓越中心。Schulz 说，这些中心提供了核心组件的简化基础，使其能够快速创新，而无需进行 EA 练习来评估每个业务部门的单独平台。

如果企业中的一个小组对最小可行的 EA 项目不感兴趣，“还有很多其他人会花时间，”Hart 说。将该需求与 EA 团队的技能相匹配，以确定“您可以提供的三到五种服务，以用最小可行的方法交付这些业务成果”。

制定和执行标准

Tsounis 说，实施设计原则以及关注业务需求有助于缩短“关于哪种解决方案最佳的哲学争论”。他鼓励的原则包括“始终尝试创建尽可能简单的解决方案，不要过度设计，允许在整个组织中最大限度地重用，在构建新东西之前利用已建立的架构设计模式以及基于云的服务。”

Thind 说，网络安全、数据治理、生产管理和部署最佳实践等领域的参考架构和标准提供了“现成的剧本”，可以有效地构建健壮、合规和弹性的可组合应用程序。此类架构由“定义非常明确……在 API、可扩展性和互操作方式方面”的微服务构建，允许企业在不影响任何其他微服务的情况下替换任何微服务，从而创建面向未来的设计。

Hohpe 说，一些标准扼杀了创新，而另一些则促进了创新。例如，统一接口对于创建易于适应的架构至关重要。然而，过于严格的标准会导致糟糕的技术选择。他记得有一个应用程序团队选择 XML 作为组件接口而不是更快的通信协议。当被问及原因时，该团队回答说架构团队需要它，显然没有考虑 XML 解析对应用程序性能的不利影响。

从某个地方开始

如果不出意外，Thind 说，任命一名“......首席架构师，一名高管评估整体标准、整体治理、整体平台和应用程序设计的整体纪律。仅仅担任这个职位就表明了架构对整个公司的重要性，并灌输了我们创建高效和创新 IT 组织所需的正确行为。”

开始一个最小可行的企业架构可以从简单地“盘点”开始，Thind 说，识别超支，例如“为什么我们有六个不同的应用程序用于相同的流程，五个不同的合同（用于）相同的 BI 工具，多个市场数据合同范围相同，24×7 Hadoop 集群用于月度报告，等等。”但即使是这种最低限度的可行努力也能带来巨大的好处。“只要确保将正确的工具用于正确的工作，并且围绕它们的使用进行标准化和最佳实践，就可以对底线产生相当大的影响，并减少技术债务，减少支持需求，并允许更快的创新，”他说。