六个敏捷企业架构用例
六个敏捷 EA 用例明确了如何针对不同情况设计 EA 团队。包括适用于 EA 的敏捷方法、支持敏捷开发的 EA 以及敏捷企业。.
这些是标准的子集 企业架构用例. 。标准用例涉及从战略变革到风险缓解和收购到敏捷开发的所有方面。.
敏捷性、企业架构和敏捷软件开发相辅相成。.敏捷与企业架构 完美地结合在一起。两者都解决了问题的不同部分。.
敏捷软件开发擅长构建我们从未有过且不知如何构建的东西。企业架构在你不知所措时，能够提前做出决策。.
放 敏捷软件开发和企业架构 共同优化变革。.
大多数架构师一上来就会想到企业级开发和敏捷开发之间的联系。我们见过很多人试图将两个截然不同的世界融合在一起，却通常没有停下来去理解其中任何一个。.
我们通过结合企业架构和敏捷开发的优势来优化它们。简而言之，企业架构在您尚不明晰时，在决策之前就表现出色。敏捷软件开发则擅长构建我们从未有过的东西。.
这两种方法都长期存在误用问题。尽管 TOGAF 本身就强调迭代的概念，但太多架构师还是抓住了 ADM 麦田怪圈图不放，只看流程。在 ADM 图中很容易看到瀑布图。虽然错了，但很容易理解。此外，敏捷开发中，为了掩盖其混乱的本质，在探索之旅中也采取了混乱的跳跃方式。.
现实世界纷繁复杂。除非我们谈论的是一招鲜的简单绿地，否则软件产品必须融入复杂的生态系统。现有的流程、组织、合作伙伴和基础设施使企业能够为客户提供服务。新产品必须在融入生态系统的同时，增强生态系统的适应性。.
高效的敏捷开发和企业架构在现实世界的复杂性中大放异彩。充分发挥它们的优势。我们强大的敏捷软件开发实践建立在解决根本矛盾的基础之上。.
敏捷张力
你知道你要去哪里，但你不知道如何到达那里
企业架构师指南
下载 企业架构师指南 关于开发有用的企业架构的 TOGAF 系列指南。.
敏捷 EA 用例示例
用例 1：构建敏捷企业
在这种用例中，EA 目的受到限制，要求可接受的目标架构优先考虑敏捷性。.
坦白说，这与任何敏捷方法都无关。我们合作过的许多敏捷组织并不使用敏捷变革方法。.
我们大量借鉴供应链和灾难响应的经验，将其作为高敏捷性的试金石。我们采用5个属性来衡量敏捷性（这些属性源自体育和军事研究）：
- 警觉
- 无障碍设施
- 果断
- 迅捷
- 灵活性
此用例练习 Conexiam 的 Navigate Agile Enterprise Atlas. 。它通过专门的视点库、利益相关者的参与和关注来优化架构开发的敏捷性。.
坦率地说，如果这种用例与组织强大利益相关者的真实偏好不一致，那么它是危险的。.
按照 TOGAF, ，这个用例主要关注的是 TOGAF ADM G 阶段和 H 阶段价值实现活动，其中变革必须与创建和维持敏捷企业保持一致。.
用例 2：使用 EA 定义敏捷变革方法
在此用例中，企业架构用于构建企业如何执行变更。产品、Sprint团队结构、速度以及与所有变更方法的协调都得到了执行。.
需要解决的问题是：哪些变化、哪些开发应该遵循哪种方法。在敏捷方法中，产品、Sprint 团队结构、开发速度等问题都得到了解答。.
这个用例主要锻炼了 TOGAF ADM F、G 和 H 阶段基于战略或投资组合架构。.
用例 3：使用 EA 指导 Backlog 和 Sprint 计划
从企业架构的角度来看 TOGAF，, 所有实施、原型设计、试点、项目和敏捷冲刺都发生在阶段 G。最佳实践的企业架构 (EA) 将生成一个包含解决方案交付笔记、差距、控制、架构规范和工作包的企业架构。这些材料需要使用适合待办事项的术语进行描述：史诗、用户故事和架构跑道。.
企业架构将包含一系列差距、用于填补这些差距的工作包以及对实施团队执行变更的创造力的限制。它将包括对产品经理和客户职责范围之外的驱动因素、目标和优先级的可追溯性。.
在经典敏捷中，客户驱动的史诗和用户故事填充了待办事项列表。客户提供优先级标准。自组织的敏捷团队负责确定工作的优先级。.
该用例使用企业架构来提供非基于客户的积压工作并指导冲刺计划中的优先级排序。.
在此使用差距史诗和源自差距和工作包的用户故事。外部依赖关系约束优先级排序、验收标准和退出标准。可提供优先优先级。.
这个用例主要练习 TOGAF ADM G阶段，实施治理：在G阶段，以通俗易懂的语言告知实施团队他们需要执行的工作以及对其执行工作自由的外部约束。EA团队的沟通方式由实施团队的组织结构决定。.
关键在于将 EA 治理活动与敏捷变革模型相结合。切勿损害冲刺团队的势头。.
用例 4：使用 EA 约束敏捷冲刺
该用例主要实践了 TOGAF ADM 阶段 G，即实施治理。.
下列的 企业架构治理最佳实践 关键问题是：
敏捷团队是否合理地解释了目标架构的记录指导和约束？
-
- 如果是，他们的解释应该被接受为合规，并且任何问题都可以通过改变架构来解决
- 如果没有，请提出建议来纠正这种情况。.
这是关键点。好的架构可以有多种实现选择，敏捷团队无需固守意见。如果实现选择是合理的解释，则应判断其合规。如果架构规范中遗漏了某些内容，那不是敏捷团队的问题，而是 EA 团队的问题，他们需要对已批准的架构进行更改。.
关键要素是协调 企业架构治理 敏捷变革模型的活动。冲刺团队的势头一定不能受到损害。.
差距、工作包策略、控制措施和架构规范指导并约束冲刺。它们必须以敏捷团队能够理解的方式编写和呈现。控制措施和架构规范通常被呈现为验收标准和退出标准。.
用例5：使用EA解决依赖关系
在此用例中，企业架构用于解决敏捷团队之间的依赖性和影响。.
此用例与用例 4 不同，因为它改变了 EA 团队的参与方式。通常，依赖关系存在于不同的变更方法（敏捷和瀑布式）之间，并且冲刺中的选择可能会产生连锁影响。.
发展中国家的关键作用 支持解决方案交付的架构 是在敏捷团队遇到这些依赖关系之前识别并解决它们。.
在用例 4 中，衡量成功的标准是确保势头不被削弱。在这个用例中，一个团队的势头必须与其他敏捷团队、运营部门以及使用其他变革方法的团队保持平衡。.
此用例主要演练了 TOGAF ADM 阶段 G 的治理和变更单活动。坦白说，, 企业架构治理最佳实践 避免授予架构跨团队依赖关系豁免。未识别的挑战是架构豁免最常见的领域。.
依赖问题是 EA 团队面临的问题。他们需要采取有效措施，帮助组织最有效地摆脱这些困境。解决这些问题需要认真关注“原则”中阐述的卓越架构、控制措施和架构规范。.
用例 6：使用敏捷方法开发企业架构
在此用例中，EA 功能配置为使用敏捷方法来开发企业架构。.
Conexiam可预测EA 是此用例的一个示例。为了帮助理解架构如何用于支持决策，我们通常将有用的工作产品称为“建议活页夹”。此活页夹针对目的和问题进行了优化。它将以多种不同的方式被使用。.
此用例将极大地影响架构开发过程中所有 ADM 阶段的执行。此用例取决于初步阶段的结果以及 EA 功能的架构和执行情况。.
在敏捷软件开发和企业架构的极端领域工作的从业者可能永远不会相遇。他们甚至可能不认识彼此的工作成果。真正的紧张在于他们之间的关系。.
当你停下来思考，在企业架构最佳实践和敏捷软件开发最佳实践之间相互作用的基本领域，两者之间的一致性就变得显而易见了。在企业架构或敏捷软件开发两端工作的从业者可能永远不知道对方在公司做什么，他们可能看不到彼此的工作成果。.
负责支持战略的 EA 从业者与敏捷软件团队的技术主管工作地点相距甚远。技术主管的执行窗口期以周或月为单位。发布计划或架构跑道则需要长期思考。战略 EA 从业者可能早在多年前就已着手制定敏捷软件开发能力发展的路线图。.
加入企业架构启动
免费的 12 周课程，助您成为更优秀的企业架构师
