六个敏捷企业架构用例
六个敏捷 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 团队结构、速度等问题都得到了解答。
这个用例主要是在练习 TOGAF ADM 基于战略或投资组合架构的 F、G 和 H 阶段。
用例 3：使用 EA 来指导 Backlog 和 Sprint 计划
从企业架构的角度 & 托加夫， 所有实施、原型设计、试点、项目和敏捷冲刺都发生在阶段 G。最佳实践 EA 将产生一个企业架构，其中包含解决方案交付笔记本、差距、控制、架构规范和工作包。该材料需要以适合待办事项的术语进行描述：史诗、用户故事和架构跑道。
企业架构将包含一组差距、工作包，以填补这些差距和限制实施团队自由执行变更的创造力。它将包括对产品经理和客户权限之外的驱动因素、目标和优先事项的可追溯性。
在经典的敏捷中，客户驱动的史诗和用户故事填满了待办事项。客户提供优先级标准。自组织敏捷团队优先考虑工作。
此用例使用企业架构来提供非基于客户的积压工作，并指导 sprint 计划中的优先级。
在此使用差距史诗和用户故事源自差距和工作包。外部依赖限制了优先级、接受标准和退出标准。可以提供压倒一切的优先级。
这个用例主要练习 TOGAF ADM 阶段 G，实施治理：在阶段 G 中，实施团队被告知他们需要执行的工作以及对其执行工作自由的外部限制。 EA 团队的沟通方式由实施团队的组织驱动。
关键要素是使 EA 治理活动与敏捷变更模型保持一致。冲刺队的动力不能被削弱。
用例 4：使用 EA 来约束敏捷 Sprint
此用例主要练习 TOGAF ADM 阶段 G，实施治理。
下列的 最佳实践 EA 治理 基本问题是：
敏捷团队是否合理地解释了目标架构的文档化指导和约束？
-
- 如果是，他们的解释应该被接受为合规性并且通过改变架构来解决任何问题
- 如果否，请制定建议以纠正这种情况。
这是一个关键点。好的架构可以有多种实现选择，敏捷团队不需要坚持意见。如果实施选择是合理的解释，则应判断为合规。如果架构规范中遗漏了某些内容，那不是敏捷团队的问题。这是 EA 团队的问题，他们需要更改已批准的架构。
关键要素是对齐 EA 治理 具有敏捷变更模型的活动。冲刺队的动力不能被削弱。
差距、工作包策略、控制和架构规范指导和约束冲刺。它们必须以敏捷团队可以使用的方式编写和呈现。控制和架构规范通常呈现为验收标准和退出标准。
用例 5：使用 EA 解决依赖关系
在这个用例中，企业架构用于解决敏捷团队之间的依赖性和影响。
这个用例不同于用例 4，因为它改变了 EA 团队的参与方式。通常在存在依赖性的地方，它将在不同的变更方法（敏捷和瀑布）之间，并且在 sprint 中的选择可能会产生级联影响。
发展的关键作用 支持解决方案交付的架构 是在敏捷团队遇到这些依赖关系之前识别和解决这些依赖关系。
在用例 4 中，成功的衡量标准是确保势头不受影响。在这个用例中，一个团队的动力必须与其他敏捷团队、运营单位和使用其他变革方法的团队相平衡。
此用例主要练习 TOGAF ADM 阶段 G 治理和变更单活动。坦白说， 最佳实践 EA 治理 避免授予架构跨团队依赖的豁免。未确定的挑战是架构豁免中最常见的领域。
依赖性问题是 EA 团队的问题。他们将需要开展工作以最有效地将组织从这些漏洞中挖掘出来。解决这些问题需要仔细注意原则中表达的高级架构、控制和架构规范。
用例 6：使用敏捷方法开发企业架构
在这个用例中，EA 功能被配置为使用敏捷方法来开发企业架构。
Conexiam 可预测的 EA 是这个用例的一个例子。为了帮助理解架构用于支持决策制定，我们通常将有用的工作产品称为“建议粘合剂”。该活页夹针对目的和问题进行了优化。它将以几种不同的方式消费。
此用例将在很大程度上影响所有 ADM 阶段的执行以开发架构。此用例取决于初步阶段的结果以及 EA 功能的结构和执行。
从事敏捷软件开发和企业架构极端工作的从业者可能永远不会遇到彼此。他们甚至可能不认识彼此的工作成果。本质上的张力在于他们彼此之间的关系。
当您停下来考虑最佳实践 EA 和最佳实践敏捷软件开发在它们交互的基本领域的一致性时，就会变得很明显。从事企业架构或敏捷软件开发极端工作的从业者可能永远不知道对方为公司工作什么，他们可能看不到对方的工作产品。
一个致力于支持战略的 EA 从业者和一个敏捷软件团队的技术主管相距甚远。技术主管的执行窗口以几周或几个月为单位。发布计划或架构跑道是长期的思考。战略 EA 实践者可能已经在制定敏捷软件开发能力开发的路线图之前工作了多年。
加入企业架构 Kickstart
成为更好的企业架构师的 12 周免费计划