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