如何使用这些参与模式？
首先，查看您的 EA 用例。您期望提供什么指导？你为谁服务？然后看看能够解决您的工作挑战的敬业度模式。让他们参与你的订婚。
我们的 架构模式模板 有两个关键要素： 可预测的问题 和 方法 来解决问题。我们还收集了 硬位。当我们考虑一种模式时，我们会考虑它解决问题的效果如何，以及成功应用该模式需要多少额外的工作。
让我们看看参与模式。他们解决的问题、方法和难点。
实例：企业架构路线图上的敏捷开发
我与新聘用的系统可靠性工程师进行了一次有趣的对话。 SRE 专家很兴奋。我们终于开始了现代实践：CI/CD 和自动化测试。她问我 EA 团队正在做什么来提供帮助？
当她问我时，我不得不微笑，“EA 团队正在提供哪些帮助？“她真正的意思是，”你今天做什么来支持我？’今天，就她眼前的挑战而言，没什么。她在实施过程中。她正在考虑实施方面的问题。
她不明白这个组织是如何发展的。她并不知道 投资组合路线图。路线图有一个我们刚刚达到的过渡点。我们引入了容器、测试数据管理和弱自动化测试套件。她没有意识到老式的自上而下的计划为她的新工作创造了环境。
她考虑的是立即发展。我考虑的是整个 数字化转型。她的角色将帮助该组织度过下一次过渡期。她正在开发 关键能力。自动化测试将提供遵循架构约束的证据。我从 定义敏捷方法。我需要帮助 指导积压工作.
十座桥梁和连接道路比 500 座无处可去的半桥更有价值
第490章 建桥人会不高兴
490 位自认为正在创造价值的桥梁建设者
下载 TOGAF 标准简介，第 10 版
下载 TOGAF® 标准第 10 版简介 TOGAF 标准第 10 版使企业架构最佳实践的采用变得更加容易。它将通用概念与经过验证的最佳实践区分开来。标准强调在哪里 […]
下载 TOGAF 和 SABSA 集成
下载 TOGAF 和 SABSA 集成 将世界上最好的安全架构框架 SABSA 和行业标准企业架构框架 TOGAF 结合在一起。下载 TOGAF 和 SABSA 集成 TOGAF 和 SABSA 集成包括 SABSA 使用 [...]
企业架构和敏捷 - 定义敏捷方法
敏捷是一种选择。它有优点也有缺点。采用敏捷需要对产品、平台、服务交付策略和自上而下的过渡点进行选择。
EA 团队需要有能力支持 战略 和 文件夹 到 定义敏捷方法。
可预测的问题：什么时候使用敏捷？
产品型式
外部产品比内部产品更容易。简而言之，有市场。在内部，使用敏捷将内部系统驱动为数字产品。确定需要完成的内部系统的存在、范围、开发方法。
可预测的问题: 产品从哪里来？
方法：调整用于填补空白和工作包结果的“解决方案”的定义，以与独立产品保持一致。开发内部产品组合和内部产品的一套价值衡量标准。产品应出现在 架构路线图.
平台模式
平台可以提高开发速度和可持续性。然而，选择不当的平台将会产生相反的结果。是否使用某个平台并不是敏捷团队的选择，更不用说选择哪个平台了。我们使用平台一词来涵盖 SAP、M365、Facebook、Pega，甚至 Open Shift Containers。
可预测的问题：什么时候应该使用平台，什么时候应该不受约束地使用产品？
方法：多种方法
-
- 使用架构替代方案进行选择。主要关注点是信心、可持续性、上市时间和业务连续性
- 使用平台 参考架构 确保产品设计的完整性并评估填补所有空白
硬钻头：产品和平台的支持和可持续性问题。
服务交付策略模式
服务交付策略是指组织用来提供产品或服务的方法。您并不一定会选择当前的方法——内部、合同、人员扩充。
可预测的问题：您的组织将如何实现敏捷开发？
方法：遵循架构方法来支持策略。提出如何实现敏捷开发的问题。使用 运营模式 定义值和 组织图 定义产品的不同消费者、开发人员和运营商如何协同工作。
主要价值休息点模式
敏捷开发与任何其他方法一样知道何时停止。价值休息点是架构转变的同义词。我们使用这个术语来强调利益相关者有一个出口，可以停止投资。利益相关者使用出口匝道有以下几个原因：
可预测的问题：了解停止或改变焦点的价值休息点
方法：使用架构路线图探索替代价值交付点。创建过渡状态活动报告。
困难的部分：考虑因素包括静止时的比较价值和作为其他活动跳板的潜在价值。实施者很少理解这些对话。他们在情感上归属于一条道路或休息点。特别是当正在考虑产品的存在或下一个版本时。高层领导总是在寻找最佳的前进道路，而不是最高的潜在回报。他们想要最好的路径。
探索价值休息点是第一步。决策者需要了解选项（根据不同标准进行选择，并推迟不确定的决策）。然后确定如何才能达到不同的选定价值休息点。
-
- 考虑到不同的标准，要追求什么改变——架构路线图类型 4：场景
- 哪些工作会带来价值，以及成本和不确定性——架构路线图类型 1：热图
- 哪些决定被推迟——架构路线图类型 4：场景
- 价值何时交付——过渡状态
进一步实践最佳实践企业架构流程和方法
最佳实践 企业架构 从 Conexiam 导航
企业架构和敏捷 - Sprint 中的待办事项指南
强大的敏捷团队找到了最有效的前进道路。由于生态系统的复杂性，存在长期规划和预算。挑战在于如何弥合长期规划和敏捷创造力。连接自上而下的规划和自下而上的执行。
他们需要了解可以纳入积压管理的组织优先事项。
敏捷的存在是因为最接近解决方案的人可以找到最有效的路径。成功的组织会进行优先级排序和权衡。在时间和资源的限制下，如果没有达到理想的未来，任何工作都不应该开始。
EA 团队需要有能力支持 文件夹 并投影到 冲刺中的指导积压工作.
可预测的问题：确保预期结果、价值、级联性能预期和约束指导发布和产品开发。
硬一点：太多敏捷传播者对采用敏捷的组织仍然坚定地致力于规划和长期预算感到惊讶。我们经常必须克服人们对瀑布存在文化偏好的神话。
指导产品模式的路线图
可预测的问题：拥有全面的产品路线图，而不是功能发布周期。
方法：使用 架构路线图技术 产品或产品系列代替产品组合。确保正常的产品报告包括过渡状态的活动。
硬钻头：优秀的产品管理将提供全面的产品路线图。太多自下而上的产品所有者没有管理生命周期或跨集成产品套件集成的经验。 EA 团队需要根据产品组织的技能进行补充或回退。
太多的架构团队陷入了人工精确或想象的全知的陷阱。两者都是瀑布思维的奇特说法。经典的架构路线图会谈到过渡、差距和工作包。这对产品团队来说是不可理解的。将语言更改为产品和敏捷术语。产品负责人需要了解他们所面临的操作限制。
构建路线图需要足够的架构。唯一可扩展的方法是'刚刚够.'足够意味着执行组织优先级并避免可预见的问题。足够意味着不参与产品设计。使用跨整个产品组合交付的架构模式。足够意味着忽略潜在的协同作用。足够意味着专注于可预测的问题。避免可预测问题的价值很高。足够意味着不要害怕使用创造性破坏。使用预期生命周期的概念来推动积极的重构（全新方法和革命性方法）。
与产品负责人一起使用这些技术有助于将组织优先级和约束纳入产品路线图。
-
- 根据不同的标准，追求什么产品或关键功能 – 架构路线图类型 4：场景
- 哪些产品或功能将带来价值（利益、工作和 不确定 – 架构路线图类型 1：热图
- 何时需要改变产品和平台 – 架构路线图类型 2：生命周期
- 工作和变化的依赖性和影响是什么—— 架构路线图类型 3：影响和依赖
指导史诗模式的路线图
可预测的问题：使用史诗将自上而下的结果和约束实施到产品中。
方法：在一个 架构路线图技术 产品或产品系列代替产品组合。确保正常的产品报告包括过渡状态的活动。
困难的部分：需要紧密集成或严格约束的产品。重点领域需要放在集成或约束点上。多个产品在生态系统中共存并共享参考数据就是一个简单的例子。
陷入预先设计的陷阱是很常见的。重点应该放在软件开发人员因生态系统或外部要求而需要限制其创造力的领域。理想情况下，这应该预先完成，而不是对技术债务的反应。
当我们取得成功时，我们积极采用了像 SaFE 这样的方法语言，并在战略主题和架构跑道方面制定了路线图。
企业价值格局
可预测的问题：确保过渡和目标状态中包含的关键成功因素可以指导敏捷的待办事项整理和史诗般的规划。
方法：将自上而下的措施和目标转化为敏捷待办事项整理的可消耗标准。确保正常的产品报告包括活动选择和完成规定值。
困难的部分：自上而下的措施必须明确且易于评估。例如，不能要求敏捷团队在上市时间和弹性之间取得微妙的平衡。需要明确的术语。
自上而下措施的任何改变都会引起混乱。如果已经达到过渡状态，则尤其如此。
对于内部产品，在引入成本措施之前，我们始终确保我们有一个可靠的数字产品成本模型。如果没有成本模型，运营和平台成本将会损失，所有成本计算都将根据实施成本来证明是合理的。计划帮助内部产品经理 了解ITFM。相比之下，外部数字产品的产品经理通常对成本有很强的了解。
限制“自下而上”的产品负责人模式
可预测的问题：产品所有者通过产品及其直接用户的视角来看待整个企业。
方法：记录生态系统中的产品和角色。记录适用于产品的限制。记录评估标准。确保正常的产品报告包括过渡状态的进展以及与企业价值一致的活动。
困难的部分：内部数字产品的产品负责人往往是薄弱环节。常见的挑战包括不理解：
-
- 为什么他们的产品存在
- 产品在生态系统中的作用
- 企业约束的严重性
- 谁是决策者（资助者）
- 如何获得有关企业优先事项和价值衡量标准的指导
支持组合和项目的 EA 团队最有可能需要限制“自下而上”的产品所有者。它需要刻意的努力和人员分配。
企业架构培训和TOGAF培训
TOGAF企业架构培训课程
您想要 TOGAF 认证培训吗？通过 TOGAF 认证展示您的企业架构知识 TOGAF® 企业架构培训课程 通过 TOGAF 标准第 10 版，向成为更好的企业架构师迈出重要一步 [...]
Avolution ABACUS 培训课程
Avolution ABACUS 培训 有效的企业架构依赖于正式的建模和分析。我们提供来自实践企业架构师的 Avolution ABACUS 培训。学生在此获得创建集成企业和域架构的技能和知识[...]
企业架构师的 Kickstart
企业架构师的快速启动 我们需要保持技能与时俱进。现在比以往任何时候都更加需要。使用企业架构快速启动来提高您提供变革性企业架构的能力。这个为期 90 天的快速启动是 Conexiam Consulting 的 […]
企业架构和敏捷 - 约束冲刺
我们正在从帮助敏捷团队管理他们的背部转向进入冲刺。在这里，我们必须将架构规范纳入软件中。我们必须在不干扰敏捷团队的创造力和创新的情况下做到这一点。
每个架构规范都会消除一定程度的自由度。当我们限制他们的自由时，我们就会让敏捷团队更难找到最有效的路径。当约束驱动企业优先事项时，我们可以更轻松地找到最佳路径。
有一个基本规则：如果没有必要，切勿删除自由度
自由创新和创造是敏捷软件开发的命脉
有一个高级规则：永远不要害怕给敏捷团队提出真正困难的问题
创新和创造力将创造出您无法想象的解决方案
可预测的问题：确保对敏捷成功至关重要的冲刺决策了解并受组织优先级、偏好和约束的指导。
硬钻头：在企业需求与干预设计和所需方法自由度之间找到平衡。对于具有开发背景的建筑师来说尤其如此。主题专业知识造成了一个滑坡，超越了企业规范进入设计。这会导致糟糕的大前期架构。
支持项目和解决方案交付的企业架构师应该预料到会限制冲刺。专注于产品生态系统或平台的架构师也应该期望与这里的敏捷团队合作。
验收标准模式
可预测的问题：确保软件符合企业架构规范和标准。
方法：提供适用于史诗结束和发布之前的强制性验收标准。我们经常使用 应用程序架构模式 和 数据架构模式 创建验收标准。在所有测试报告中包括强制性验收标准。
困难的部分：知道何时执行强制性验收标准。太早会扭曲发展。太晚会导致发布例外的压力。对于没有真正可预测的发布周期的内部数字产品尤其如此。
我们将架构规范分类为：
大多数强制性验收标准需要是架构模式或标准。
永远不要忘记让开并收获创造力。
值（测量值和休息点） 模式
可预测的问题：了解什么是有价值的以及如何衡量价值。
方法：企业架构需要明确如何描述和衡量价值。价值陈述需要关键成功因素 (CSF) 和有效性衡量标准 (MoE)。确保价值衡量包含在产品、史诗和发布报告中。
困难的部分：许多 IT 专业人士对价值的理解有限。他们会使用快速的速记法来表达所交付的东西的价值。其价值在交付中是不言而喻的。
在复杂的世界中，交付的任何一件东西都会降低价值。一个简单的例子是针对非目标客户的用户的功能。或者，当一个工作单位需要以牺牲系统为代价来简化其活动的功能时。
我们强烈推荐基本的精益和六西格码实践。研究价值的定义和量化。寻找局部优化。商业模式画布的目标客户和价值主张概念非常有帮助。
绿地、进化或革命
在 TOGAF的E期，有一个很酷的步骤。查看工作包并选择适当的策略——全新策略、渐进策略或革命策略。您是否希望尽可能多地保留、彻底重构或从头开始？
这是在产品组合和生态系统规划中完成的。它是关键的指导，也是对敏捷团队的强有力的约束。您是否指示他们从头开始（格林菲尔德）？逐步改进现有系统（进化）？或者进行彻底的改变，以消除我们一直生活在其中的摩擦和麻烦（革命性的）？
可预测的问题：确保遵循实施策略。
方法：使用产品路线图和发布周期来强制方法发生根本性改变。
硬位：使自上而下的架构变化与产品路线图保持一致。当支持战略或投资组合的决策需要改变产品方法时，这是最困难的。我们不得不花费大量时间向数字产品所有者以及他们的团队保证之前的努力没有白费。
约束接口模式
当产品必须适应现有的企业环境或支持不断发展的企业环境时，界面就至关重要。接口将由数据和方法驱动。在一个复杂的世界中，即使是新兴产品也不会自由地出现某些数据结构和接口。主数据、参考数据和现有系统都会制约敏捷开发。
现有系统不会改变。投资正在投入新系统。新系统必须适应。即使是 F-22 猛禽也必须使用 20 世纪 70 年代开发的接口与遗留系统连接。即使是那么昂贵的飞机也无法对遗留系统进行改造。
可预测的问题：识别所需的接口并确保它们被使用。
方法：将自上而下的工作重点放在接口和共享数据结构上。通过史诗和发布周期提供需求。使用验收标准。我们经常使用 应用程序架构模式 和 数据架构模式 到稍微具体的接口。在所有测试报告中包括接口一致性。
硬位：接口是通常需要自上而下的前瞻性规划的点之一。努力确保有坚实的 API 基础设施、已发布的 API 以及主数据、参考数据和交易记录的数据结构。
快速发展的产品团队经常忽视跨司法管辖区的立法或不断扩大的市场业务计划。在这些情况下，EA 团队有责任向前看。一般来说，我们更喜欢彻底的重构而不是前瞻性的规划。特别是我们强制实施了模块化和接口。
企业架构与敏捷——解决依赖
敏捷团队和以数字产品为中心的开发不适合解决整个生态系统或产品组合中的问题。敏捷的基本设计是让单个团队分解问题并直接解决它们。有团队的概念，但它们很难摆脱当前时刻。
任何架构团队都需要承担解决跨产品问题的责任。敏捷开发和现代集成使这种需求服务比以往任何时候都更加重要。
解锁投资组合模式
可预测的问题：数字产品组合之间的冲突阻碍了多个产品的进展。
方法：使用企业架构技术来找到允许进展的最小更改。
困难的部分：最关键的挑战是时机。创造性的最佳实践敏捷开发团队将致力于解决这个问题。当问题出现时，它通常会成为一个关键的阻碍因素，并带来层层技术债务。
EA 团队需要关注增量过渡状态，以便在整个产品组合中取得进展。
识别真正的利益相关者模式
可预测的问题：确定真正的利益相关者，他们可以在复杂的内部产品组合中提供指导和批准。
方法：使用企业架构技术来识别利益相关者和利益相关者代理、关注点和偏好。使用企业架构技术 备择方案 和 权衡 指导利益相关者做出指导产品组合的决策。确保有效的数字投资组合治理。
困难的部分：我们可以期望数字产品团队拥有本地权威来源以及简单化的决策和决策权模型。此外，他们的沟通和评估也将是面向 IT 的和战术性的。
EA 团队必须努力确保对数字产品组合进行有效治理，并与数字产品权威结构进行互动。此外，EA 团队不具备获得利益相关者参与的特殊能力。他们确实有能力通过卓越的架构来代表利益相关者的担忧。
跨越投资组合模式
可预测的问题：本地优化的战术决策无法成为有效且可持续的数字生态系统。
方法: 保持足够即可 应用架构 和 数据架构。推动该架构中的组织优先级。应用程序架构需要关注共享服务和接口。数据架构必须关注主数据、参考数据和高安全级别的数据。需要元数据描述。使用指定生态系统方法的架构模式。
困难的部分：跨越投资组合需要调和两个相互冲突的现实。首先，敏捷方法的出现是因为观察到详细的自上而下的企业设计失败了。其次，如果没有强大的进化压力和进化时间，新兴的局部优化解决方案就无法构建高效的复杂系统。
唯一可扩展的方法是'刚刚够.'足够意味着执行组织优先级并避免可预见的问题。例如，如果您的组织优先考虑可持续性，那么您的应用程序架构必须强制实施模块化并使用 API 网关等隔离基础设施。
足够意味着不参与产品设计。相反，您需要使用跨整个产品组合交付的架构模式。
足够意味着忽略潜在的协同作用。想象复杂未来的努力常常演变成一场闹剧。协同作用是最难找到的。我们所有的架构路线图工作都证明，您总是为某些东西付出代价，您可能会受益。当存在不确定性时，协同价值很低。
足够意味着专注于可预测的问题。没有人在没有参考数据的情况下构建了分布式客户主数据。曾经。这是一个可预测的数据问题。早点解决吧避免可预测问题的价值很高。
足够意味着不害怕利用市场力量和创造性破坏。我们使用预期生命周期的概念来强调我们期望在生态系统中的哪些位置定期进行积极的重构（全新的和革命性的方法）。
发布影响模式
可预测的问题：足够的架构意味着在发布之前不会发现每一个意外情况、每一个约束、每一个冲突。
方法：在决议期间将双手插在口袋里等待叫号。除非接到电话，否则请在事件审查期间等待参与，以找出您未能识别可预测问题、低估风险或错过测试要求的地方。
困难的部分：在一种情况下，架构团队可能会遇到紧急情况。在这些罕见的情况下，影响超出了产品范围。如果最终用户正在解决该缺陷，则不会出现紧急情况。当他们制造脆弱性和责任时，你就会遇到紧急情况。
使用良好的间隙、工作包和价值休息点技术。寻找能够提供可收获价值的最小变化。在这种情况下，价值就是消除威胁和责任。
企业架构与敏捷的总结
企业架构和敏捷都遭受着长期的误用。太频繁地同时发生。调整你的方法，使你的敏捷和 企业架构 努力减少成功的不确定性。
作为企业架构师，您需要寻找可以使用增量方法来降低错误概率和成本的工具。当你降低失败的变革努力的成本时，你就消除了浪费。 100% 浪费的变革努力降低了变革的价值。
数学很简单，效益保持不变，工作量增加。净值较小。
简单的答案是发挥你的力量。并期望敏捷团队发挥他们的优势。
企业架构和敏捷有四种顶级参与模式：
模式的选择取决于您的 企业架构用例 这 您的 EA 团队的设计.
进一步提升企业架构和敏捷性
更进一步 敏捷 与敏捷软件开发不同。企业架构和敏捷在三个领域结合在一起：
- 构建敏捷企业
- 开发最佳实践企业架构的敏捷工作实践
- 敏捷软件开发和企业架构
