六个敏捷EA用例

六个敏捷EA用例确定了如何在不同条件下设计EA团队。 EA的敏捷方法,支持敏捷开发的EA和一家敏捷企业。

我们寻找简单的框架模型来阐明我们的想法。框架模型是为了帮助我们明确隔离需要进行配置选择的条件。

敏捷EA的六个用例敏捷性,企业体系结构和敏捷软件开发结合在一起。

  1. 企业敏捷度
  2. 敏捷软件开发与企业架构
  3. 企业架构 使用敏捷方法

隔离条件使您可以放心地设计EA团队。我们的 EA能力服务 使用 导航 EA功能参考架构。高功能的EA团队的配置得到了优化。

敏捷与企业架构 完美地融合在一起。两者都解决了问题的不同部分。

敏捷软件开发擅长构建我们从未有过的,不知道如何做的东西。当您不知道该怎么做时,企业架构会在做出决定之前表现出众。

敏捷软件开发与企业架构 一起优化变化。

大多数架构师跳到企业与敏捷开发之间的关系。我们已经看到许多人试图将两个大不相同的世界融合在一起,通常是在不停地了解其中一个的情况下。

我们通过使企业架构与自身优势保持一致来优化企业架构和敏捷开发。我们使用的速记方式是,当您不了解该怎么做时,企业架构会在做出决定之前胜于决定。敏捷软件开发擅长构建我们从未有过的东西。

两种方法都遭受长期误用的困扰。尽管TOGAF具有内在的迭代概念,但仍有太多的建筑师使用ADM作物圆图来查看过程。在ADM图中很容易看到瀑布。错,但是容易。同样,在敏捷开发中,无组织的飞跃跨越了发现的旅程,以掩盖其无组织。

现实世界是混乱的。除非我们谈论的是一个简单的“小技巧”绿地,否则软件产品必须适合复杂的生态系统。现有的流程,组织,合作伙伴和基础架构使企业可以为客户提供服务。新产品必须在安装时增强生态系统。

在现实世界的复杂性中,有效的敏捷开发和企业体系结构发光。发挥自己的优势。我们将强大的敏捷软件开发实践建立在解决基本矛盾的基础上。

敏捷张力
你知道你要去哪里。你不知道怎么去那里

企业架构师指南

下载 企业架构师指南 关于开发有用的企业架构的 TOGAF 系列指南。测试

敏捷 EA 用例示例

用例1:架构敏捷企业

在此用例中,EA目的受到限制,要求使用可接受的目标架构来优先考虑敏捷性。

坦白说,它与任何敏捷方法都没有关系。我们与之合作的许多敏捷组织都不使用敏捷变更方法。

我们从供应链和灾难响应中大量汲取了高敏捷性的试金石。我们使用5个属性来表示敏捷性(从体育和军事研究得出):

  • 警觉
  • 辅助功能
  • 决定性
  • 迅捷
  • 灵活性

此用例练习 Conexiam的导航敏捷企业地图集。它通过专门的观点库,利益相关者的参与和关注来优化体系结构开发以实现敏捷性。

坦率地说,如果这种用例不符合组织强大的利益相关者的真实偏好,那将很危险。

按照 托加夫,此用例最着重于 TOGAF ADM G阶段和H阶段的价值实现活动,其中的变更必须与创建和维持敏捷企业保持一致。

用例2:使用EA定义敏捷的变更方法

敏捷和企业架构工作产品在此用例中,企业体系结构用于构造企业执行变更的方式。产品,Sprint团队的结构,速度,与所有变更方法的一致性均得以执行。

要解决的问题是什么变化,应该采用哪种方法进行什么发展。对于敏捷方法,将回答诸如产品,Sprint团队结构,速度之类的问题。

该用例主要是在行使 TOGAF ADM F,G和H阶段基于战略或项目组合架构。

用例3:使用EA指导积压和冲刺计划

从企业架构的角度来看 TOGAF, 所有实施,原型设计,试验,项目和敏捷性冲刺都在G阶段进行。最佳实践EA将产生一个企业体系结构,其中将包含解决方案交付笔记本,差距,控制,体系结构规范和工作包。需要使用适合待办事项的术语来描述此材料:Epic,用户案例和体系结构跑道。

企业体系结构将包含一组差距,填补这些差距的工作包以及对实施团队执行变更的自由度的创造力的限制。它将包括对产品经理和客户权限范围之外的驱动因素,目标和优先级的可追溯性。

在经典敏捷中,客户驱动的史诗和用户故事充斥着积压的待办事项。客户提供优先级标准。自组织敏捷团队优先处理工作。

此用例使用企业体系结构来提供非基于客户的积压,并指导sprint规划中的优先级。

在这种用法中,由差距和工作包衍生而来的差距史诗和用户故事。外部依赖性限制了优先级,接受标准和退出标准。可以提供优先级。

该用例主要练习 TOGAF ADM G阶段,实施治理:在G阶段,以通俗易懂的语言向实施团队通报了他们需要执行的工作以及实施工作自由度的外部限制。 EA团队的沟通方式由实施团队的组织来驱动。

关键要素是使EA治理活动与敏捷变更模型保持一致。冲刺队的势头一定不能受到损害。

用例4:使用EA约束敏捷Sprint

该用例在很大程度上锻炼了 TOGAF ADM G阶段,实施治理。

下列的 EA治理最佳实践 基本问题是:

敏捷团队是否合理地解释了目标架构的文档指导和约束?

    • 如果是,则应接受其解释为合规性,并且通过更改体系结构解决任何问题
    • 如果否,请提出建议以纠正这种情况。

这是关键。好的架构可以有多种实现选择,并且敏捷团队不需要坚持意见。如果实施选择是合理的解释,则应判断其符合要求。如果在架构规范中遗漏了一些东西,那不是敏捷团队的问题。这是EA团队的问题,他们需要更改已批准的体系结构。

关键要素是对齐 EA治理 敏捷变更模型进行活动。冲刺队的势头一定不能受到损害。

差距,工作包策略,控件和体系结构规范指南并限制冲刺。必须以敏捷团队可以使用的方式来编写和呈现它们。控件和体系结构规范通常呈现为验收标准和退出标准。

用例5:使用EA解决依赖性

在此用例中,企业体系结构用于解决敏捷团队之间的依赖性和影响。

该用例不同于用例4,因为它改变了EA团队的参与方式。通常存在依赖关系的地方是在不同的更改方法(敏捷和瀑布式)之间,并且冲刺中的选择可能会产生级联影响。

发展的关键作用 支持解决方案交付的体系结构 是在敏捷团队对它们的依赖之前识别并解决这些依赖。

在用例4中,成功的措施是确保不削弱动量。在这种用例中,一个团队的动力必须与其他敏捷团队,业务部门和使用其他变更方法的团队保持平衡。

该用例主要用于TOGAF ADM阶段G治理和变更单活动。坦白说,  EA治理最佳实践 避免对架构的跨团队依赖性挑战授予豁免,这些挑战尚未确定是架构豁免的最常见领域。

依赖性问题是EA团队的问题,他们将需要执行工作以最有效地从这些漏洞中挖掘组织。解决这些问题需要仔细关注Principles所表达的高级体系结构,控件和体系结构规范。

用例6:使用敏捷方法开发企业体系结构

在此用例中,将EA功能配置为使用敏捷方法来开发企业体系结构。

Conexiam可预测的EA 是该用例的一个示例。为了帮助理解使用架构来支持决策,我们通常将有用的工作产品称为“ Advice Binder”。该粘合剂针对目的和问题进行了优化。它会以几种不同的方式消耗。

该用例将在很大程度上影响所有ADM阶段的执行以开发体系结构。该用例取决于初步阶段的结果以及EA功能的结构和执行。

在敏捷软件开发和企业体系结构的极限下工作的从业者可能永远不会遇到彼此。他们甚至可能都不认识彼此的工作成果。本质上的张力在于它们之间的关系。

当您停下来考虑最佳实践EA和最佳实践敏捷软件开发在它们相互作用的基本区域时的配合变得很明显。从事企业体系结构或敏捷软件开发极限工作的从业人员可能永远不会知道其他人为公司工作的内容,而他们可能看不到彼此的工作产品。

负责支持战略的EA从业人员和敏捷软件团队的技术负责人相距甚远。技术负责人的执行窗口数周或数月。发布计划或架构运行是长期思考。 EA的战略从业者可能已经在制定敏捷软件开发能力发展的路线图上进行了多年的工作。

企业架构师指南

下载 企业架构师指南 关于开发有用的企业架构的 TOGAF 系列指南。测试

https://conexiam.com/togaf-9-2-body-of-knowledge/

使您的企业体系结构团队适应不同的敏捷用例,可帮助确定最适用的应用程序 企业架构用例.

加入个人企业架构启动

免费12周计划,成为一名更好的企业架构师

滚动到顶部