企业架构（EA）有很多定义，但最简单的定义也许是在Gregor Hohpe的《软件架构师电梯》一书中，它将企业架构描述为 "业务和IT架构之间的粘合剂"。
在此基础上，我们与一位CS客户一起制定了以下价值主张。
EA是：
战略领导层和工程团队之间的桥梁。
它的作用是将业务战略转化为清晰的工程愿景，促进高质量的系统设计，确保所有的非功能需求得到解决，并保持信息在各个方向的流动。
它也是风险和合规团队的技术桥梁，确保正确的架构和成功的合规评估。
新的工作和合作方式
这些对EA功能的定义已经存在了很长时间，但随着公司对敏捷和其他相关工作实践的接受，工作方式也发生了变化。
在传统的组织中，所有的决定都是自上而下的--从战略规划师到建筑师，他们负责创造详尽的设计，准备交给工程团队执行。在这样的环境中，EA和其他各种架构和分析功能负责所有的架构选择。在这种情况下，所有的决定都必须在实际工程工作开始之前做出。这一点在下文中得到了体现，（基于《企业架构的实践》中的插图。 Svyatoslav Kotusev所著的《企业架构的实践：业务和IT整合的现代方法》中的插图）
这种模式在敏捷环境中并不成立，在敏捷环境中，信息自上而下、自下而上地流动，并且通过使用部落和实践社区（COP），从侧面流动。在这种情况下，EA团队会做一些翻译工作，但也会扮演向导和讲故事的角色。
在这种情况下，EA团队：
- 帮助将业务战略转化为技术战略，在领导层和相关工程团队之间形成一座重要的桥梁。
- 促进开发团队的软件设计过程，确保来自安全、合规和风险等团体的非功能需求得到满足。
- 为开发团队提供架构选择方面的咨询，包括扩展性、安全性、合规性、工具和语言。
- 策划并促进信息交流。
下图反映了现代企业的情况：
左边的业务战略通过组织，被转化为技术战略，最终交付业务成果。然而，有清晰的反馈回路和空间让各小组通过使用持续集成不断改进其系统的设计。
但是，这个模型没有显示EA团队是如何随着时间的推移而发展的，特别是当公司转移到云端时需要发生的变化。
在早期阶段，EA团队是一个合作伙伴和合作者，帮助Dev团队做出正确的选择和绘制世界。这里有一些典型的困难需要克服，比如理解云计算的应用必须以不同的方式进行架构。随着企业云计算能力的成熟和设计的一致性和可重复性，EA团队被期望采取更多的指导性立场，更严格地执行架构原则。这种变化可能是相当微妙的，一个常见的错误是认为EA团队可以采取 "一刀切 "的方法。
下一个任务 - 绘制世界地图
在变得更加敏捷时，最大的挑战之一是在不牺牲安全和可靠性的情况下实现规模化的速度。云原生告诉我们，你不一定非要用这些东西来交换。相反，你可以通过速度实现可靠性，以完全自动化的方式回滚变化或向前滚动修复。然而，这并不是 "开箱即用"。相反，有三个关键和相关的构建块：
- 轻松获取信息。如果你不能建立在过去的经验教训上，就不可能向前迈进。当你成为云原生，你会从失败和成功中学习，然后记录下来。如果你想快速行动并进行大规模的创新，方便地获取这些经验是至关重要的。
- 随处可见的自助服务。 这里的一般规则是，永远不要派人去做机器的工作。文件是必要的，但自动化甚至更好。自助服务门户不仅有助于劳动密集型的工作，还能让我们以可重复和安全的方式做事，使我们在整个组织内实现标准化。重要的是，在许多情况下，它们可以将交接工作减少到零。
- 轻触式流程。 流程是至关重要的，但它们必须有适当的规模，既不能太大，也不能不足。通过这种方式，你可以快速行动，但要有保护你的护栏。它们还可以减少官僚主义，在云原生的规模中，让各个团队自主行动。
那么，你的第一步是什么？
没有地图，云迁移将很难导航，因此，EA团队的第一个主要任务是创建可靠和广泛的现有和未来景观的地图。
转变必须是整体的，涵盖所有相关维度。
改变从核心开始，有一个强大的战略和愿景，在那里你设计你想要创建的未来。
因为所有的维度都是相互影响的，所以必须对它们进行相互监测。
为此，EA团队确定了变化的维度，并应明确定义每个维度的里程碑，以确保利益相关者和领导层对迁移的现状有清晰的了解。
基于这些变化的维度，EA团队可以创建未来云世界的部分视图，并通过与各领导层和工程团队的持续接触，继续在所有维度上扩展地图
。EA团队如何工作
EA团队应作为SDLC流程的核心部分被嵌入。它应该在确保任何监管者都满意的情况下，采取尽可能轻的接触。除了架构和设计审查外，为了减少不必要的官僚主义负担，这个过程应该协调安全和其他非功能团队的额外深入审查。
每个新产品、项目、倡议和技术政策都应该通过EA审查过程。这个过程需要被设计成帮助团队澄清他们的想法，并有机会考虑每个解决方案的未来影响。这个过程需要促成而不是阻碍。一个典型的EA审查过程可能由五个步骤组成：
1.启动会议（对于重大举措，由开发或EA团队要求）。2.2. 填写设计审查模板（由开发团队填写）。
3.3.在线、异步审查过程（开发团队、EA、安全、风险、平台/运营）。
4.4. 签收（EA、安全、风险、平台/运营）。
5.5.记录结果（EA的ADR）。
下面，你可以看到我们记录了如何与EA接触：
从左边，你可以看到各种主要步骤。所有的开发活动都需要得到批准的设计文件的支持，所有与批准的设计的重大偏离都可能引发额外的增量设计审查。这个过程以自我服务的方式进行，它让人们以异步的方式做出贡献，这对规模化来说是至关重要的。