信息安全架构框架的结构与内容

企业信息安全架构（EISA）是信息安全计划的关键组成部分。EISA的主要功能是以一致的方式记录和通信安全程序的工件。因此，EISA的主要可交付成果是一组将业务驱动因素与技术实现指导联系起来的文档。这些文档是通过多层抽象迭代开发的。

信息安全应在架构框架中定义三个维度或视角：

• ·表示信息安全组织和流程维度的“业务”视图。这种观点反映了“安全业务”，即它代表了信息安全在组织中的实施方式，以及“安全业务”如何通过流程、角色、职责和组织结构与企业的其他部分相互关联。
• ·表示运行信息安全功能所需信息的“信息”视图。它表示安全团队使用的信息模型，以及用于捕获企业信息的安全需求的模型。
• ·代表安全基础架构的“技术”观点。它捕获用于将不同的安全需求抽象为所需硬件和软件配置指南的模型。

安全架构应该描述如何将安全性编织到业务结构中。因此，EISA应该与组织的EA集成。EISA过程必须允许来自其他规划规程的设计组件的输入和接口点（图1）。许多这些输入可以从EA获得。然后，随着架构和安全过程的成熟，EISA和EA之间的关系应该变得越来越共生和集成。

图1

EISA(企业信息安全架构)内容

EISA由三层文件组成：

• 1] 需求：定义架构要实现的目标的文档。在概念层，这可以表示业务需求，例如战略产品计划或法规要求。在实现层，它可以表示技术产品规范。
• 2] 原则：包含在架构（architecture）过程中指导决策的语句的文档。
• 3] 模型：替代模式或当前和未来状态的表示。基于模式的模型表示业务流程和应用程序中重复出现的特性，并用作决策工具。当前和未来状态模型用于提高利益相关者之间的共同理解，并用于项目规划和优先顺序的差距分析。

用于实现安全架构的不同方法

术语“安全架构”可替换地用于描述一个过程、一组可交付成果，有时也用于描述作为该过程的结果而实现的解决方案。企业信息安全架构（EISA）是为支持信息安全计划而交付规划、设计和实现文档（工件）的过程。

EISA过程是一组动态的规划和设计活动。这些活动的确切性质取决于组织对安全架构采取的方法。有三种不同的战略方法：

• 战略更新方法，其中架构的主要功能是指导企业安全环境的全面更新。
• 机会主义方法，其中架构仅用于开发特定项目和计划的安全需求。
• 混合方法，其中架构主要以机会主义的方式使用，但也有选择地用于更具战略性的规划目的。

定义有效信息安全计划的结构和范围

有效的信息安全需要一种集成的方法，在这种方法中，安全是业务流程核心结构的一部分，是组织文化的一个关键组成部分。这意味着安全团队必须努力将安全性的关键组件（策略、流程、行为和技术）注入IT的所有维度：业务流程、应用程序、技术基础设施，最重要的是人员。挑战的范围要求在更大的组织内建立战略安全计划。

一个有效的安全计划始于建立一个资源和原则框架。使用这个框架，可以管理项目的优先顺序列表。信息安全计划的主要目标是建立一个连续的、迭代的方案来规划、构建和运行从业务需求派生的安全解决方案。为了确保这种解决方案的可伸缩性和可重复性，安全团队必须定义和实现战略安全流程。该计划应考虑到这样一个事实，即有效的安全态势是建立在适当的政策基础上的，而这些政策是由操作过程、文化行为和技术的有效组合所实施的。下面是一个显示安全模型组件的图表。

原文：https://sites.google.com/site/aniketsaoblog/home/security-architecture/information-security-architecture

本文：http://jiagoushi.pro/node/1064

讨论：请加入知识星球【首席架构师圈】或者小编小号【jiagoushi_pro】

安全需求愿景

在开始任何安全架构工作之前，定义安全需求是很重要的。这些需求应该受到业务上下文和通用需求远景文档的影响。下面是一个图表，它显示安全需求是企业信息安全体系结构中业务上下文的一部分。

图1

安全需求远景（SRV）有助于将安全解决方案与定义的业务需求联系起来。它支持业务策略和安全决策之间的可跟踪性。

SRV的内容通常包括

• 将影响企业信息安全体系结构（EISA）的相关环境趋势和业务策略列表
• 影响安全解决方案设计的相关安全技术趋势（STT）和最佳实践列表
• 从环境趋势、业务战略、技术趋势和最佳实践中获得的环境影响评估的明确变更、技术和信息需求说明列表
• 由变更、信息和技术需求声明派生的安全解决方案需求（SSR）
• 映射业务策略和环境趋势之间以及业务策略和变更、信息、技术和解决方案需求之间相互关系的矩阵

战略安全架构原则

战略安全体系结构原则指导在体系结构开发、设计和实现阶段做出的决策。这些原则指导了一种安全体系结构策略，该策略通过以下方式从各种断开连接的安全活动移动到一致的未来状态：

• 与业务目标和风险保持一致。
• 使用一组通用控件满足多个需求。
• 为单一版本的真相（即商定的控制、政策、过程和技术）提供通用的报告基础设施。
• 尽可能无创，尽可能使用自动化控制，而不是手动测试和测量。
• 明确角色、责任和责任。

安全治理、安全管理和安全操作

安全治理、管理和操作具有非常不同的功能。

• 安全治理的存在是为了确保定义了业务的战略需求，并确保安全计划充分满足这些需求。这可能包括在复杂情况下讨论和判断业务需求
• 安全管理构建并运行安全程序以满足这些战略业务需求。这包括组成安全程序的各种安全功能、过程和策略。
• 安全操作日常执行与当前基础设施相关的安全相关流程。

这是三者之间的关系

图2

获取正确的安全流程

首席信息安全干事（CISO）不断面临压力，要在复杂的环境中提供一致、可证明和经济高效的安全。流程目录中定义和优先排序的一组关键安全流程将使CISO能够满足客户、合作伙伴、供应商、审计师和监管机构的需求。它也为安全服务目录在正式服务模型下提供可收费的安全服务奠定了基础，从而为组织的IT交付的新方法的发展做准备。

某些流程对于有效地管理安全性至关重要，它们应该在流程目录中定义。尽管这些过程通常是为了定义的目的而单独定义的，但它们在实践中不太可能孤立地运行。在大多数情况下，这些过程之间会有相互依赖的关系。

在战略安全计划方面有一定进展的组织，将需要一个更全面的投资组合（见图）。这样一个组合可以描述两类流程——战略流程（那些支持安全团队和业务之间关系的流程）和保护流程（更多直接旨在保持企业安全的操作流程）。

图3

安全过程的形式化

对于给定的流程，第一步是分配（或验证）流程所有权，然后开始记录单个流程。在顶层，正式流程定义应包括以下组件：

•  过程描述-过程目标和范围的概要。它可以包括对过程中包括的子过程和活动的简要标识。
• 流程图-构成流程的子流程和活动之间的流程的可视化表示。
•  集成矩阵-表示集成点以及与其他安全、操作和服务管理流程的相互关系的表。除了流程之间的集成点之外，它还应指明构成此流程一部分的其他流程。
• 技能和人员配置需求-表明流程所需直接和间接人力资源的数量和性质。
• 角色和职责定义-确定有助于流程的特定组织职能以及这些职能各自的职责。这通常是通过一个负责、负责、咨询和告知（RACI）矩阵来实现的。
• 自动化机会-识别可通过技术实现自动化的过程组件。在流程定义的这个层次上，其目的不是为了特定于产品或技术，而是仅仅为了指示流程中可能有助于自动化的组件。

原文：https://sites.google.com/site/aniketsaoblog/home/security-architecture/model-security-architecture

本文：http://jiagoushi.pro/node/1063

讨论：请加入知识星球【首席架构师圈】或者微信小号【jiagoushi_pro】

安全架构师团队由以下主要角色组成

• 1] 安全架构师
• 2] 信息安全架构师
• 3] 首席信息安全官
• 4] 信息安全分析员

1] 安全架构师角色

业务要求安全架构师（SA）提供安全的解决方案和服务，这些解决方案和服务可以安全地支持诸如增加利润和生产力、改进客户服务、创新以及更快地将新产品和服务推向市场等活动。

以下是根据Forrester定义的解决方案架构师

“负责确保业务解决方案设计满足安全和法规遵从性要求的技术角色。SA与整个组织的利益相关者合作，以安全地实现业务计划的功能需求。SA是组织内信息安全体系结构的技术权威。”

安全架构师的业务和技术技能

1] 风险管理

• 识别和沟通风险教育管理与特定业务解决方案相关的风险影响是SA的核心能力。
• 降低风险-一旦业务领导人就建议的解决方案或行动方案作出决定，SA有责任设计一个安全的解决方案，使其平衡功能需求与安全和合规要求。

2] 架构和威胁建模

• “扩展企业”的架构能力——由于移动业务的爆炸和云服务的兴起，扩展企业的业务流程很少（如果有的话）独立于公司的四壁之内。在当今的扩展企业中，成功的SAs必须具备核心安全知识，以及API驱动的应用程序环境和联邦身份的内部和外部知识。
• 像攻击者-威胁建模一样思考的能力是识别系统中的威胁和漏洞并寻找利用它们的方法的过程。

安全架构师的非技术技能

• 有很强的写作和表达能力-SAs必须能够与组织的所有级别进行沟通
• 谈判、说服和影响技能——这在没有要求特定行动方案的合规授权的组织中尤其适用。在这种情况下，影响决策的难度要大得多，而且需要更多的技巧

组织结构

安全体系结构和企业体系结构（EA）之间的关系非常重要。EA集团帮助创建一个以业务为中心的企业架构，将战略与技术联系起来。安全必须是EA的一部分。无论组织结构是什么，安全架构师都应该与企业架构师和首席信息安全办公室密切合作。更多细节请参见图。

图1

2] 信息安全架构师

信息安全架构师的角色要求业务洞察力、技术敏锐性以及在不同抽象层次上思考、交流和写作的能力。

角色和责任

• 与企业架构师、其他功能区架构师和安全专家密切合作，确保在所有IT系统和平台上都有足够的安全解决方案，以充分降低已识别的风险，并满足业务目标和法规要求。
• 开发构成企业信息安全体系结构和解决方案的业务、信息和技术构件。
• 担任应用程序开发、数据库设计、网络和/或平台（操作系统）工作方面的安全专家，帮助项目团队遵守企业和IT安全政策、行业法规和最佳实践。
• 有助于安全治理与EA治理、项目和项目组合管理（PPM）的协调。
• 研究、设计和倡导新技术、体系结构和安全产品，以支持企业及其客户、业务合作伙伴和供应商的安全需求。
• 有助于制定和维护信息安全战略。
• 根据批准的安全体系结构评估和开发安全解决方案。根据新出现的安全威胁、漏洞和风险，分析业务影响和风险。
• 向业务合作伙伴和IT人员传达安全风险和解决方案。

3] 首席信息安全官

CISO负责建立和维护公司范围的信息安全管理计划，以确保信息资产得到充分保护。该职位负责以符合合规和监管要求的方式识别、评估和报告信息安全风险，并符合和支持企业的风险态势。CISO职位需要一位有远见的领导者，具备良好的业务管理知识和信息安全技术的工作知识。CISO将主动与业务部门合作，实施符合信息安全规定政策和标准的实践。

责任

• 制定、实施和监控战略性的、全面的企业信息安全和IT风险管理计划，以确保信息的完整性、机密性和可用性由组织拥有、控制或处理。
• 管理企业的信息安全组织，包括直接报告和间接报告（如业务连续性和IT运营中的个人）。这包括招聘、培训、员工发展、绩效管理和年度绩效评估。
• 通过实施分级治理计划，包括成立信息安全指导委员会或咨询委员会，促进信息安全治理。
• 制定、维护和发布最新的信息安全政策、标准和指南。监督安全政策和实践的批准、培训和传播。
• 创建、沟通和实施基于风险的供应商风险管理流程，包括对合作伙伴、顾问和其他服务提供商可能产生的风险进行评估和处理。
• 制定和管理信息安全预算，并监控其差异。
• 为所有员工、承包商和经批准的系统用户创建和管理信息安全和风险管理意识培训计划。
• 直接与业务部门合作，促进IT风险评估和风险管理流程，并与整个企业的利益相关者合作，确定可接受的剩余风险水平。
• 作为企业风险管理战略计划的一部分，定期向企业风险团队、高级业务领导和董事会报告信息安全计划的现状。
• 为信息所有权、分类、责任制和保护方面的角色和责任建立一个框架。
• 开发并增强基于以下内容的信息安全管理框架：如果存在或标识了某个框架，则插入该框架。
• 为IT项目提供战略风险指导，包括技术控制的评估和建议。
• 与企业架构团队联系，确保安全架构和企业架构之间的一致性，从而协调这些架构中隐含的战略规划。
• 与IT组织和业务部门团队的资源协调信息安全和风险管理项目。
• 创建和管理一个统一、灵活的控制框架，以整合和规范全球法律、标准和法规产生的各种不断变化的要求。
• 确保安全计划符合相关法律、法规和政策，以尽量减少或消除风险和审计结果。
• 根据需要与信息安全团队和公司合规、审计、法律和人力资源管理团队保持联络。
• 定义并促进信息安全风险评估过程，包括报告和监督处理负面结果的工作。
• 管理安全事件和事件以保护公司IT资产，包括知识产权、受监管数据和公司声誉。
• 监控外部威胁环境中出现的威胁，并就适当的行动方案向相关利益相关者提供建议。
• 与外部机构联络，如执法机构和其他必要的咨询机构，以确保本组织保持强有力的安全态势。
• 协调信息安全计划中涉及的外部资源的使用，包括但不限于面试、谈判合同和费用，以及管理外部资源。

4] 信息安全分析员

信息安全分析员是信息安全团队的高级成员，与团队其他成员密切合作，制定并实施全面的信息安全计划。这包括定义安全策略、过程和标准。安全分析师与IT部门合作，选择和部署技术控制以满足特定的安全需求，并定义流程和标准以确保维护安全配置。

• 与业务部门和其他风险职能部门合作，使用可能包括风险和业务影响评估的方法确定安全需求。该活动的组成部分包括但不限于：
• ¨业务系统分析。
• ¨沟通、促进和建立共识。
• 协助协调和完成信息安全操作文档。
• 与信息安全领导层合作，制定战略和计划，以执行安全要求并解决已识别的风险。
• 向管理层报告剩余风险、漏洞和其他安全风险，包括滥用信息资产和违规行为。
• 在应用程序开发或获取项目中扮演顾问角色，以评估安全需求和控制，并确保安全控制按计划实施。
• 在关键IT项目上进行协作，以确保在整个项目生命周期内解决安全问题。
• 与IT部门和信息安全团队成员合作，识别、选择和实施技术控制。
• 开发安全流程和过程，并支持服务级别协议（sla），以确保安全控制得到管理和维护。
• 就安全授权请求的正常和基于异常的处理向安全管理员提供建议。
• 研究、评估和推荐与信息安全相关的硬件和软件，包括开发安全投资的商业案例。

原文：https://sites.google.com/site/aniketsaoblog/home/security-architecture/model-security-architecture/security-architecture-team

本文：http://jiagoushi.pro/node/1065

讨论：请加入知识星球【首席架构师圈】或者小编小号【jiagoushi_pro】

分享知识和良好实践是BiZZdesign的核心价值观之一。我们定期组织和参与在线和离线研讨会，会议和圆桌会议。在一次题为“安全不是IT问题”的演示之后，我们组织了一个世界咖啡馆，讨论安全架构，安全控制和安全系统等相关主题。请通过回复此博客分享您的好的和最坏的做法。

安全性仍然不是业务设计的一个组成部分

在许多组织中，安全似乎是一个完全独立的知识领域。将安全的所有方面集成到业务设计工作中往往是一个巨大的挑战，这是由决策者，架构师和设计师完成的。与EA领域的领导者所做的预测相矛盾的是，安全架构师在设计和控制网络安全，隐私和连续性方面仍然是一个独立但重要的角色。但是，如果我们努力使这个单独的角色变得多余，那么正确的做法是什么？

七个良好实践：从安全架构到安全架构

1. 明确定义的任务，角色，CISO和企业架构师的职责
2. 通过引入“设计安全”来改变组织的DNA
3. 建立持续的安全意识计划
4. 建立一个内部“犯罪智囊团”
5. 将安全性集成到企业架构方法中
6. 深入了解架构的所有层
7. 基于原则的工作

明确定义的任务，角色，CISO和企业架构师的职责

在出席会议的许多组织中，CISO和架构团队正在努力合作。他们似乎捍卫自己的领土，花时间和精力证明对方是错的。安全架构师花费了大量时间来维护和平并管理这两个群体之间的关系。一些与会者建议更加明确两个团队的角色，这确实是一个很好的做法。

通过引入“设计安全”来改变组织的DNA

我并不是说这是一个简单的壮举，但通过在DNA中添加安全意识来操纵组织的DNA是实现安全架构的重要实践。许多与会者声称信息安全通常不是组织DNA的一部分。

建立持续的安全意识计划

缺乏信息安全意识是安全架构师存在的一个原因。它本身并不是安全设计的。拥有结构化和强化的意识计划被认为有助于提高组织内部存在的风险意识（改变x影响）。

建立一个内部“犯罪智囊团”

一些与会者建议其他人“像罪犯一样思考”。这很有趣，但也很有用。也许一些安全架构师实际上是善良的罪犯。如果所有管理人员和设计人员都会从威胁组织的角度考虑他们的数据资产，那将有助于他们获得理解和认识，并考虑相关措施。

将安全性集成到企业架构方法中

安全性通常是EA方法的一个方面。例如，在TOGAF中，安全性被认为是ADM中所有阶段的一个方面。但是，安全性仍然有自己独特的方法，如SABSA或OpenSecurityArchitecture。尽管有各种可用的方法，但您组织面临的真正挑战在于将这些专用框架的强大功能真正集成到您的EA方法中。优选地，这将与选择正确的标准（ISO或NIST）结合进行。这有助于创建集成的安全体系结构，而不是开发单独的安全体系结构。

深入了解架构的所有层

为了理解风险和必要的措施，人们认为跨越架构层可视化安全方面的任务至关重要。这不仅涉及测试所产生的技术影响，还涉及认证风险对业务的影响。 ArchiMate®可以在完成所有这些工作中发挥至关重要的作用。

基于原则的工作

最后，基于原则的设计而非基于规则的设计的概念有助于在业务中的所有设计学科中实现安全性方面的集成。风险经理和架构师应共同努力，确定一套指导组织设计的原则，而不是详细说明所有要求。

使用这些最佳实践可以帮助您从安全架构转变为真正安全的架构！你从哪里开始的？请随时查看本系列的下一篇文章：信息安全：生命的必需品。

原文：https://bizzdesign.com/blog/from-security-architecture-to-a-secure-architecture/

本文：http://pub.intelligentx.net/enterprise-security-architecture-security-architecture-secure-architecture

讨论：请加入知识星球【首席架构师圈】

在这篇博客文章中，我们讨论了使用企业架构作为支柱，在企业中管理风险，合规性和安全性的集成方法的价值。

对风险的战略洞察力

为了控制您所面临的风险，您首先需要从风险管理的角度对您的组织进行战略洞察。这需要对您当前的产品，流程，应用程序和基础架构以及所有相关的风险和安全方面进行一致和最新的概述。在不知道主要风险相关问题是什么的情况下，C级管理层无法履行其职责。

了解这些关系也有助于您评估业务决策的影响。这为企业提供了清晰的洞察企业风险，例如，引入新产品和计划，外包业务流程或IT系统，或在合并后吸收其他组织。因此，他们可以权衡企业对潜在后果的风险倾向。

此外，整个企业的风险传播是高管和运营管理层非常关注的问题。一个领域的风险可能会带来另一个领域的风险。例如，关键业务流程，服务，客户，合作伙伴，市场的系统故障，闯入，停电，欺诈或其他事故可能产生的连锁反应是什么？企业架构可帮助您深入了解这些关系和依赖关系，从而避免或减轻潜在的灾难。

业务驱动的安全和风险管理

EA提供切实业务价值的相关领域是使安全和风险管理与业务目标和目标保持一致。许多组织发现很难确定适当级别的安全措施，业务经理经常将此视为技术问题留给IT人员。反过来，他们不想承担任何风险并创建非常安全的镀金解决方案，但也非常昂贵（并且通常对用户不友好）。

业务目标，架构决策和技术实施之间更好的一致性有助于组织明智地花费其安全预算，专注于与业务相关的风险。这可能会带来成本节约和降低风险，因为您不会为不重要的事情投入过于强大的安全措施，留下更多预算来保护您的企业真正关心的事物。

此外，安全性不是事后可以“加强”的。本质上不安全的架构和系统很难在以后修复。相反，应该从一开始就设计安全和风险管理，使用企业的业务目标来决定适当的措施。

法规遵从和审计

成熟的EA实践的另一个常见原因是监管合规，特别是在银行和保险等受到严格监管的行业。中央银行和其他监管机构要求或至少强烈建议金融机构拥有完善的EA实践，以确保它们能够控制其运营。他们甚至可以审核这些体系结构，或以其他方式使用它们来评估组织运行的风险。当然，内部审计师，CISO和风险经理也可以从使用EA工件中受益。对这些提供的企业级关系和依赖关系的见解是其任务的重要输入。

实施SEPA，Solvency II，Basel III等标准和政策需要企业范围内的协调，可见性和可追溯性，例如董事会层面的决策。组织的风险偏好，直至业务流程和IT系统中的措施和控制的实施。企业架构作为一种实践，以及捕捉这些关系的企业架构模型，对于管理此类开发的广泛影响是不可或缺的。

下一步

为了在安全性，合规性和风险管理的背景下充分受益于企业架构的使用，我们建议您关注以下内容：

1. 使安全和风险管理与业务战略保持一致。始终从他们添加的业务价值角度查看安全和风险衡量指标。 Enterprise Studio的战略支持将为您提供帮助。
2. 捕获并可视化组织的风险和安全方面。可视化与整体架构和业务战略相关的危险，风险和缓解措施。使用我们的EA功能创建风险和措施的集成模型。
3. 衡量并可视化风险的影响，并使用我们的风险分析功能将这些见解用于决策。使用热图来告知决策者必要的措施。
4. 优先考虑安全项目。计算安全项目的业务价值和影响，并使用它来确定IT措施的优先级。使用我们的企业投资组合管理来确定最有效地使用预算的位置。

原文：https://bizzdesign.com/blog/the-value-of-enterprise-architecture-in-managing-risk-compliance-and-security/

本文：http://pub.intelligentx.net/enterprise-security-architecture-value-enterprise-architecture-managing-risk-compliance-and

讨论:加入知识星球【首席架构师圈】

在我之前的博客文章中，我描述了将于2018年5月生效的新的欧盟通用数据保护法规（GDPR），并概述了其对组织的深远影响，不仅在欧洲，而且在全球范围内。该法规以及相关的欧盟指令（如ePrivacy Directive和网络与信息系统安全（NIS）指令）迫使组织重新考虑如何处理个人隐私敏感数据。在本博客中，我想解决您作为架构师可以采取的步骤，以帮助您的组织遵守这些法规。

为什么架构是关键

为了确保您的组织符合要求，您需要广泛了解个人数据的使用方式，收集方式，处理方式，访问权限，存储位置，涉及的第三方，内部和外部威胁等等。企业架构师对其组织具有独特的广泛和集成的视图，并拥有可用于评估，改进和确保数据保护的模型和工具。

此外，GDPR不仅要求合规性，还要求您证明合规性。架构和架构模型是此信息的主要来源，特别是当您需要与个人数据相关的所有内容的连贯和连接视图时。

查看我们录制的网络研讨会“不要让GDPR成为一个松散的大炮”，并了解企业架构师如何在风险和安全分析中利用架构模型以及Enterprise Studio如何为您提供帮助。

采取的步骤

1.在大多数组织中，企业架构师对确保合规性没有最终责任。

您的责任可能在于您的法律部门，首席风险官，首席合规官，首席信息安全官或GDPR新要求的数据保护官。与这些官员合作并让他们意识到建筑的潜在贡献是第一步。

2.确保合规性的任何工作都依赖于对所涉及的个人数据的良好概述。

创建“隐私库存”至关重要：

1. 。根据GDPR确定所有被视为“个人”的数据。
2. 根据其隐私敏感度对此数据进行分类。将此作为常规安全流程的一部分，您可以在其中为数据分配其他信息安全属性，例如熟悉的“CIA”（机密性，完整性，可用性）。
3. 描述收集这些数据的目的，并确保您拥有（或获得）数据主体的同意以这种方式使用它。
4. 特别注意特殊类别的个人数据，例如与健康，生物识别，政治，宗教，种族或工会会员有关的数据。除非有特殊情况，否则GDPR明确禁止使用该数据。

• 3.分析个人数据的使用，如果可能，利用您现有的架构模型为您的分析提供支柱：

1.  从高风险区域和最敏感的数据类型开始。 它在哪里存储和使用？
2. 模型数据流：哪些应用程序，进程，人员和各方在哪些位置使用此数据？

• 4.评估敏感数据的风险，特别是有关数据主体的权利和自由的风险：

1.  在您的业务和IT环境中，您是否看到了漏洞？
2. 可以利用这些漏洞的常见威胁是什么？
3. 有什么潜在的后果？

您可以使用BiZZdesign Enterprise Studio的企业风险和安全管理功能进行风险的高级分析，该分析基于The Open Group的ArchiMate和Open FAIR标准。 下面的热图是这个可以创建的输出类型的一个例子。 BiZZdesign为客户提供包含常见信息安全和业务连续性威胁的预先填充内容，以及ISO / IEC 27001标准规定的控制。 这为您提供了一个有用的起点，因此您无需重新发明轮子。

5.定义控制措施和缓解措施。

使用ISO / IEC 27001等通用标准作为识别有用控制的基础。重要的是，您希望尽早在设计或更改轨迹中执行此操作，以促进数据保护设计方法（GDPR明确提及！）并避免在后期采取措施，所有相关的返工，成本和风险。

6.确定风险优先级，分配预算并规划必要的变更和改进：

• 评估针对风险的措施成本（预期损失），以将预算集中在真正重要的位置。
• 将此决策与您的整体投资组合管理和路线图集成在一起。例如，您可以避免在修复即将淘汰的应用程序上花费太多，并且可以将与安全相关的改进与其他更改相结合。

Enterprise Studio的项目组合管理功能在此阶段非常有用。清晰的仪表板有助于管理层决定优先级和投资，考虑所有角度，并允许您过滤并专注于基本要素（见下文）。

7.实施

实施您在组织，流程和系统中定义的控制和措施，并测试其安全性。这当然是最重要的！

8.证明

证明符合监管机构的要求，说明您如何处理个人数据，如何处理风险以及您实施的缓解措施。

当然，这不是一次性的方法;您应该定期重新审视上述步骤，以确保您保持合规并将其嵌入您的治理框架中。当您执行数据保护影响评估（DPIA）时，这些步骤也特别相关，这是GDPR对任何使用个人数据的新系统的实施所要求的。

BiZZdesign解决方案可帮助您利用现有架构和产品组合模型和数据，为您提供快速启动，以提高数据安全性并确保合规性。我们的集成方法可帮助您在重要的环境中投资安全性，并避免违规或更严重的数据泄露的处罚和声誉风险。 2018年5月比您想象的更近，可能需要做很多工作，所以不要犹豫，立即开始吧！

原文： https://bizzdesign.com/blog/8-steps-enterprise-architects-can-take-to-deal-with-gdpr/

本文:http://pub.intelligentx.net/enterprise-security-architecture-8-steps-enterprise-architects-can-take-deal-gdpr

讨论:加入知识星球【首席架构师圈】

在之前的博客文章中，Marc Lankhorst讨论了EA在管理企业风险，合规性和安全性方面的价值。他建议采取下一步措施;本博客中将详细讨论其中两个步骤：

1. 捕获并可视化组织的风险和安全方面。可视化与整体架构和业务战略相关的危险，风险和缓解措施。
2. 衡量并可视化风险的影响，并将这些见解用于决策。可视化来自例如的数据渗透测试并使用它来在业务层面决定必要的IT措施。

企业风险管理方法概述

上面的两个步骤被纳入企业风险管理方法，如图1所示。这种方法有助于理解风险和安全政策的后果，因为战略层面的风险和控制措施的定义是逐步详细的步骤逐步纳入运营控制措施。

这是一种模型驱动和循环方法，可以在周期中的多个点上启动，具体取决于您使用的是更自上而下的方法还是更自下而上的方法。下面将简要介绍每个阶段：

1. 评估风险：在此步骤中，识别并记录企业必须应对的风险。这涵盖了多种风险类型：这些类型可能与IT相关（如网络攻击）风险，但也可能与业务相关的风险。此外，风险可以基于已识别的威胁（参见步骤6）。
2. 指定所需的控制措施：确定每个已识别风险所需的控制措施。一些风险可能需要广泛的控制措施（由于风险的高影响），而其他风险可能需要较少的控制措施。风险和控制措施的组合可以使用ArchiMate动机扩展（评估，目标和要求）的要素进行建模，这使得这些方面之间的关系变得清晰。此外，它可以通过将风险和控制措施与ArchiMate核心元素相关联，将其纳入您现有的EA模型中。
3. 实施控制措施：需要实施所需的控制措施。这是从设计转向实施的步骤。控制措施可以通过多种方式实施：一些可能是IT控制措施，如防火墙或认证机制。其他人可以采取以商业为中心的控制措施，如四眼原则。
4. 执行和监控：需要执行已实施的控制措施。此外，有必要对业务层面进行监测，以获得所实施控制措施的绩效和有效性的统计数据。一个例子是在技术基础设施上使用pentesting。通过pentesting，您可以通过系统化和自动化的方法寻找基础设施中的薄弱环节。测试结果用于分析基础设施中的漏洞并定义新的控制措施。
5. 分析漏洞：从执行和监控中，您获得了有关已实施控制的性能和有效性的必要见解，例如通过pentesting）。在此步骤中，将分析此数据以确定存在哪些漏洞以及这些漏洞存在多大危险。通过使用现有的EA模型，在第2步中的漏洞和已识别的风险之间建立链接。这可以深入了解风险的管理情况或需要采取新的或改进的控制措施。
6. 识别威胁。在此步骤中，识别来自外部或内部环境的威胁。内部环境的威胁可以基于上一步的结果（分析漏洞）。识别新威胁可以在步骤1中导致新的或变更的风险评估。

自上而下与自下而上

上述方法可以自上而下或自下而上应用。自上而下的方法将首先确定威胁和评估风险，作为控制措施的设计和实施的基础。自下而上的方法通常从监视和执行步骤开始：使用pentests或其他机制调查当前实现，并使用此信息来确定当前环境中的漏洞。
哪种方法最适合您的组织，取决于许多方面。通常，具有更成熟的EA方法的组织可以更容易地遵循自上而下的方法。

这种方法的好处

这种方法包括以下好处：

• 系统分析威胁和漏洞
• 控制措施的综合设计
• EA模型支持技术风险/漏洞的业务影响分析
• 将业务风险和安全决策转化为有效的企业变更。这需要业务和IT之间的强大合作。

这些优势有助于将安全性更多地嵌入到组织的业务层中，并有助于根据操作风险影响和成本做出明智的决策。

原文：https://bizzdesign.com/blog/enterprise-risk-management-approach/

本文:https://medium.com/capital-one-tech/microservices-when-to-react-vs-orchestrate-c6b18308a14c

讨论: 请加入知识星球【首席架构师圈】

在最近关于“安全不是一个IT问题”的演讲之后，我们决定建立一个世界咖啡馆，以进一步讨论周围的主题，该调查研究了许多组织内政策和措施之间缺乏关系。我们将讨论分为四个主题，并对每个主题进行了辩论。在我之前在本系列的博客中，我写了关于信息安全中的7个最差实践。在本博客中，我将介绍董事会中有关信息安全的讨论结果。请在下面的评论部分与我们分享您的想法。

提出解决方案，而不只是问题

安全问题，威胁和挑战是一个有趣的讨论话题，非常重要。但是，董事会成员需要做出决策，他们需要快速做出决定。因此，提出您的组织目前面临的风险非常重要，但也要提出在威胁未得到解决时可能出现的潜在情景，并就如何向前发展提出建议。大多数与会者声称董事会不愿意就可能的威胁进行长期的，知识性的讨论，但他们希望得到明确的信息和准备充分的决策。

董事会不是一个人......这是一个个人的集合，每个人都有自己的议程。作为负责组织安全的人，您需要了解他们面临的挑战，并就他们应采取的措施向他们提出建议。如果您不成功，很可能您的“技术”消息无法在董事会中找到牵引力。

与组织目标保持一致

业务目标通常比董事会成员的个人目标和抱负更好地记录。我们研讨会上的一些安全架构师确实从目标，原则，安全架构中的元素到安全措施，制定了推理方法。其他人只是梦想有这样一个有条理的正式道路，但相信这会帮助他们完成自己的工作。

用例

董事会成员的政策和措施似乎是抽象的。创建一个真实的案例，说明当黑客敲开您的数字门时发生的事情，或者当雇用新员工时会发生什么事情将使董事会的事情变得活跃起来。您可以通过模拟来说明这一点。其中一位与会者表示，实时黑客攻击董事会成员的iPhone和平板电脑会留下令人难忘的印象！

来自监管机构的压力

据一些与会者称，合规性问题，规则和法规正在分散公司对帮助客户改善业务的注意力。一些安全架构师表示，监管机构的压力有助于他们将安全和隐私问题列入董事会议程。帮助组织变得合规被视为安全专家可以为组织带来的真正商业价值。

理解背景
 

信息风险和安全性只是运营组织的一个方面。如果您不理解安全性只是董事会议程中的众多方面之一，那么您将无法成功地影响它们。或者你会立刻感到沮丧。通过在业务目标的上下文中提供安全性，您表明您了解生命不仅仅是安全性，风险，隐私和信任。还有销售，易用性和上市时间。这将为未来的合作奠定良好的基础。

信息安全不仅仅与技术有关，而且也是一个需要董事会理解和认可的业务问题。参加我们研讨会的专业人士提示可能会帮助您解决您所面临的挑战。

我们希望您喜欢我们关于信息安全的博客系列，我们很乐意听到您的评论如下。信息安全的主要挑战是什么？

原文：https://bizzdesign.com/blog/information-security-in-the-boardroom/

本文：http://pub.intelligentx.net/enterprise-security-architecture-information-security-boardroom

讨论:加入知识星球【首席架构师圈】

在之前的两篇博客中，我讨论了新的欧盟通用数据保护法规的影响，以及建筑师可以做的8件事情，以帮助他们的组织遵守这一影响深远的法规。我们还提供了“您对GDPR的准备程度如何？”测试，该测试确定您的组织是否做了足够的准备来制定重要的法规。如果你还没有这样做，你仍然可以在这里参加考试。到目前为止的结果（基于近200名参与者）为我们提供了一些有趣的见解，让我们了解受访者对GDPR的认识以及组织之间的准备情况。

只有一半的受访者了解GDPR并计划开展合规工作

首先，约95％的受访者表示他们的组织与欧盟公司或居民开展业务。所有这些组织都必须遵守GDPR，即使它们位于欧盟以外。

尽管如此，只有一半的受访者了解这一问题，并且正在积极规划或致力于合规性。考虑到GDPR的严格要求，不合规的财务和声誉后果，以及GDPR执行前的剩余时间（2018年5月），这是一个有关的统计数据！

如果我们查看受访者的职称，我们会看到一些有趣的差异。 IT和风险经理更加了解GDPR并声称有一个连贯的行动计划，但建筑师似乎没那么准备。 这是否意味着建筑师不了解其IT和风险经理的举措？ 如果是这种情况，则错失良机，因为架构可以为组织GDPR做好准备。

在业务经理和架构师之间，许多人都知道，但不知道下一步该做什么。 对于那些受访者，我在上一篇博客中概述的步骤提供了他们可以采取的第一个行动的想法。

不到三分之一符合“知情同意”标准

另一个问题涉及所谓的“知情同意”。 从本质上讲，在您不知情和事先同意的情况下，您不得对您收集的有关欧盟居民的数据做任何事情（选择加入，不选择退出！）。 同意必须明确; 您不得将此埋藏在许可协议或使用条款的深处。 在我们的调查中，只有不到三分之一的受访者表示完全遵守这一规定。

尽管GDPR是欧盟法规，但它适用于存储或处理欧盟居民个人数据的任何组织，无论组织本身位于何处。 这包括美国和其他地方的许多组织。 欧盟及其外部的大量组织不知道他们使用的个人数据是相当令人担忧的。
有趣的是，似乎北美受访者在保护个人数据方面比欧盟的成熟者略微成熟，如下所示（尽管也有更多的落后者）。

然而，北美对GDPR影响的认识平均要低很多。 欧盟以外的许多公司可能会认为它不适用于它们，但那将是一个错误。 任何存储或使用欧盟居民数据的组织都会受到影响。 即使在某人的设备上放置跟踪cookie也可能使您承担责任。

22％的组织不知道他们存储了哪些个人数据

也许最令人震惊的结果是那些不知道他们存储的个人数据的组织比例：22％的受访者。

这个群体也很大一部分与25％的人回答，当被问及他们的系统架构和设计的哪些阶段他们解决隐私和安全问题时，他们手动测试安全问题并在之后采取一些措施，而不是将此考虑为完整设计和实现过程中的关键问题。如果您是其中一个组织的客户，您应该非常担心。此外，如果负责当局调查这些组织，比如说在数据泄露之后，他们可能会受到严厉的处罚。

下面的散点图显示了受访者估计的最高罚款与基于年营业额的实际最高罚款。实际最高金额为年营业额的4％或2000万欧元，以较高者为准。但是，正如您所看到的，大多数组织的估计都太低了。

如果您尚未启动计划以确保符合GDPR，那么现在是时候了。 正如我在之前的博客文章中所解释的那样，建筑师可以在这方面发挥关键作用。 BiZZdesign Enterprise Studio可帮助您利用现有模型和数据，分析安全和隐私问题，并定义正确的度量和控制。 这为您提供了改善数据安全性和确保合规性的良好开端。 缺乏隐私保护的日子肯定已经结束，所以今天就开始吧！

原文：https://bizzdesign.com/blog/are-you-ready-for-the-gdpr-the-test-results/

本文：http://pub.intelligentx.net/node/389

讨论:加入知识星球【首席架构师圈】

直到最近，IT安全才是安全专家的领域。但是，在过去几年中，组织已经开始意识到IT相关风险不能孤立地看待，应该被视为企业风险和安全管理（ERSM）的一个组成部分。 ERSM包括组织用于管理与其目标成就相关的所有类型风险的方法和技术。

将ERSM置于企业架构（EA）的环境中是很自然的，它提供了关于组织结构和设计的整体视图。因此，诸如TOGAF之类的EA方法包括风险和安全性章节也就不足为奇了（尽管这些主题在整体方法中的整合仍有待改进），而SABSA等安全框架与Zachman显着相似EA的框架。作为必然结果，使用ArchiMate语言对风险和安全方面进行建模也是非常有意义的。

本系列之前的博客文章概述了使用ArchiMate进行基于EA的ERSM的方法。本文提出了风险和安全概念到ArchiMate概念的初始映射，并说明了如何将这些概念用作执行组织范围风险评估的基础。

ArchiMate风险概念的映射

ERSM标准和框架中使用的大多数概念都可以轻松映射到现有的ArchiMate概念。由于ERSM关注的是与实现业务目标相关的风险，因此这些主要是来自动机扩展的概念。

1. 体系结构中表示的任何核心元素都可以是一种资产，即一种容易受到组织想要保护的损失的价值。这些资产可能存在漏洞，可能使其成为攻击或意外丢失的目标。
2. 威胁可能导致威胁事件，针对资产的漏洞，并且可能具有相关联的威胁代理，即（有意或无意）引起威胁的参与者或组件。根据威胁能力和漏洞，威胁事件的发生可能会也可能不会导致丢失事件。
3. 风险是对可能损失的（定性或定量）评估，就损失事件频率和可能的损失程度而言（非正式地，“可能性时间影响”）。
4. 根据风险评估的结果，我们可能决定接受风险，或设定控制目标（即高级别安全要求）以降低风险，从而导致对控制措施的要求。控制措施的选择可以由预定义的安全原则指导。这些控制措施由任何一组核心元素实现，例如业务流程（例如风险管理流程），应用服务（例如认证服务）或节点（例如防火墙）。

ArchiMate mapping of risk concepts

使用ArchiMate标准中描述的扩展机制之一，可以将风险相关属性分配给这些概念。 The Open Group采用的信息风险因子分析（FAIR）分类法为此提供了一个很好的起点。

定性风险评估

如果可以获得足够准确的输入值估算，定量风险分析可为基于风险的决策提供最可靠的依据。然而，实际上，这些估计通常很难获得。因此，FAIR提出了基于定性（有序）措施的风险评估，例如：威胁能力从“非常低”到“非常高”，风险从“低”到“关键”。下图显示了如何将这些值链接到ArchiMate模型中的元素，以及如何在“热图”中显示它们：

1. 漏洞级别（Vuln）取决于威胁能力（TCap）和控制强度（CS）。应用具有高控制强度的控制措施可降低漏洞级别。
2. 丢失事件频率（LEF）取决于威胁事件频率（TEF）和漏洞级别。较高的漏洞会增加威胁事件触发丢失事件的可能性。
3. 风险等级由损失事件频率和可能的损失幅度（PLM）确定。

以下示例显示了此类评估的简单应用。保险公司的支付系统的漏洞扫描表明，所传输的支付数据的加密级别很低（例如，由于所使用的加密协议的过期版本）。这实现了中间人攻击，其中攻击者可以修改数据以进行未经授权的支付，例如，通过更改收款银行帐户。对于具有中等技能（中等威胁能力）并且没有其他控制措施的黑客，这会导致非常高的漏洞（根据上面的漏洞矩阵）。假设低威胁事件频率（例如，平均每月一次尝试攻击），根据丢失事件频率矩阵，预期丢失事件频率也低。最后，假设损失程度很高，所产生的风险水平很高。作为预防措施，可以应用更强的加密协议。通过修改参数，可以显示将控制强度增加到“高”或“非常高”，剩余风险可以降低到中等。进一步降低这种风险需要采取其他措施，例如：限制可能的损失幅度的措施。

通过将风险相关属性与ArchiMate概念相关联，可以在建模工具的帮助下自动进行风险分析。 通过这种方式，可以轻松分析整个组织中这些值变化的影响，以及潜在控制措施对降低风险的影响。 例如，IT系统或基础架构中的漏洞导致的风险对业务的影响可以通过最佳地支持管理者做出的安全决策的方式进行可视化。

原文:https://bizzdesign.com/blog/enterprise-architecture-based-risk-assessment-with-archimate/

本文：http://pub.intelligentx.net/node/404

讨论：请加入知识星球【首席架构师圈】

在之前关于网络安全的博客中，我写了关于在日益危险的数字环境中保持组织安全的基本步骤：

1. 确保企业范围内的意识
2. 使安全和风险管理与业务战略保持一致
3. 分析您的漏洞和风险
4. 采用安全设计方法
5. 假设你受到了损害

在这篇博客中，我想放大哪些工具来帮助您实现网络安全 - 特别是第3步和第4步。

网络安全模型

我们提倡采用基于模型的方法来分析和减轻网络风险，这并不会让您感到惊讶。对企业的清晰，正式的描述将帮助您获得提供最佳安全解决方案所需的理解。当然，无法实现绝对安全;相反，您应该从以下角度关注您需要投资的地方：1）您要保护的资产的价值以及2）与这些资产相关的漏洞。

我们的企业风险和安全管理方法基于几个开放标准，最着名的是ArchiMate企业架构建模标准，以及信息风险管理的开放式FAIR标准。 The Open Group关于建模企业风险管理和安全的白皮书中描述了更多细节。

上图显示了我们的方法的主要步骤，这些步骤内置于BiZZdesign Enterprise Studio的治理，风险和合规性功能中。在此图的底部，您将看到要保护的资产免受网络风险的影响，而在顶部，我们会看到指导组织的政策，原则和目标。中间是连接这些的步骤;在左侧（红色），您将看到组织中的网络风险分析，在右侧（绿色），您将看到控制的实施，以提高您的安全性。这些是风险和安全管理的步骤：

• 审核资产。对您的企业至关重要的最重要资产是什么？适用法规对这些资产的说法是什么？例如，您的客户的个人数据可能是一个这样的资产。您作为值得信赖的组织的声誉可能是另一个。你能为这些元素赋值吗？这将有助于您在决定什么是最重要的保护时。
• 分析漏洞。您的企业资产在哪些方面容易受到攻击？在网络安全中，除了攻击者之外，任何人都不知道的“零日漏洞”当然是最危险的，并且自然不会出现在此列表中。但是，您应该识别的其他漏洞应该被调查并链接到它们公开的资产。您可以重用业务和IT体系结构的模型，可能会通过相关的安全性方面对其进行扩充。
• 评估威胁。在评估特定于资产的漏洞后，您需要评估这些漏洞是否真的可被所谓的“威胁事件”和“威胁代理”利用。这些漏洞可能包括恶意黑客，敌对政府以及您自己的员工。 ，技术故障，自然灾害和其他事故。我们收集了数百个常见漏洞，威胁代理和威胁事件的广泛模型，可以作为您在此步骤和上一步中进行分析的起点。
• 计算风险。根据潜在威胁和资产价值，您可以评估企业实际面临的风险。在一个简单的公式中，风险=价值x概率，风险越高，您希望投资减少风险越大。下图显示了在前四个步骤中逐步建立的此类分析的示例。

模型的较低的黄色部分显示业务流程和要保护的资产（“客户信息”）。上半部分从左到右显示：

1. 漏洞（'弱认证'）
2. 威胁代理（黑客）
3. 威胁事件
4. 这些威胁造成的潜在损失事件
5. 由此带来的风险

交通信号灯显示各种参数，例如资产价值，漏洞等级和由此产生的风险等级。所有这些都是相互关联的，我们的风险分析算法计算结果，例如如果增加资产价值或威胁能力，则增加风险等级。

• 5.制定政策。要主动处理潜在的网络风险，您应该定义符合业务战略的适当安全策略和原则，并遵守适用的法规。例如，这可能包括诸如设计安全性，职责分离，个人数据访问受限以及其他共同政策等原则。像GDPR这样的监管框架需要可靠的数据保护政策，对违规行为负有高额罚款，甚至对负责任的管理层承担个人责任。反过来，这会影响您要保护的资产的价值。这不仅仅是他们的内在价值;还应考虑罚款，声誉损害和其他副作用。
• 6.定义控制目标。根据您在上一步中创建的策略，您现在应该定义适当的控制目标。例如，一种标准方法是根据您的常见用例对数据的机密性，完整性，可用性，隐私敏感性和其他属性进行分类。例如，您网站上的数据需要较低的机密性但高可用性，而客户数据将具有更高的隐私和机密性要求，而可用性可能不那么令人担忧。
• 7.制定控制措施。然后将这些控制目标转化为适用的控制措施，告诉您如何实现这些目标。相关标准，例如ISO / IEC 27001，NIST 800-53，CSA和其他标准可以通过提供预定义且组织良好的一组控制措施来提供帮助。下面，您将看到ISO / IEC 27001标准模型的一小段摘录，显示了一个特定的控制目标和一些相关的控制措施，用ArchiMate的风险和安全覆盖表示，在上面提到的Open Group白皮书中定义。

这些控制措施的强度也可以用作上图所示风险计算的输入。 您的控制力越强，漏洞越低，因此您运行的风险就越低。

• 8.实施。 最后一步是将这些控制措施的实现设计为您自己的体系结构，流程和系统的一部分。 例如，您需要弄清楚如何执行用户注册（上图中的第一个度量）。 实施这些措施的成本可以与您运行的风险进行比较。 它们真的值得，还是用过于昂贵的控制来保护低价值资产？

当然，上面显示的分析是建模和风险评估专家要做的事情，对于没有经验的人来说可能看起来很复杂。 但是，结果可以在用户友好的热图中呈现，如下所示。

上面的热图显示了威胁的高能力（例如智能黑客）与低强度控制相结合导致了非常高的漏洞级别。此热图中的另外两个漏洞可能不那么紧急。

此分析有助于管理层优先考虑改进安全性的投资，例如，在密码长度上实施规则或实施多因素身份验证。因此，您的组织在其预算中有足够的空间进行投资。

安全架构是一个持续的问题

风险管理是一个连续的，迭代的过程。应定期运行上述流程，以评估新的漏洞和威胁，并根据组织的战略和适用的法规要求更新您的政策，原则和控制措施。此外，您有这样的风险管理流程这一事实本身就是各种监管框架所要求的。

将其嵌入到您的常规架构和设计流程中，可以为您提供逐个安全的方法 - 一种更有效的方法来提高组织的弹性，而不仅仅是在网络安全事件发生后简单地处理一些安全措施。

无法保证什么都不会出错。尽管如此，拥有这种基于模型的风险分析和缓解方法将证明是对您的组织的网络安全，业务连续性和弹性的重大投资。

有兴趣了解更多？联系我们的专家进行演示！

原文：https://bizzdesign.com/blog/protect-your-enterprise-analyze-your-security-with-architecture-models/

本文:

讨论：请加入知识星球【首席架构师圈】

本月早些时候，我在一系列基于世界咖啡馆讨论的系列文章中撰写了第一篇博客文章，该讨论围绕着许多组织中政策和措施之间缺乏关系。讨论以4轮辩论的形式进行。在之前的博文中，我将信息安全作为生活的必需品。毫无疑问，对于大多数组织而言，信息安全是一个非常重要的主题，但在辩论期间，许多参与者不确定是否以及如何与公司其他人沟通。在这篇博文中，我将介绍本次讨论的结论。

沟通问题和解决方案

讨论建筑风险和安全的沟通时，我的第一个问题是：你需要沟通吗？如果答案是肯定的：对谁？什么？这引起了参与者之间的争论。总的结论是，沟通实际上是不可或缺的，决策者是我们的目标受众，因为企业需要充分了解如何做出正确的决策权利。回答第二个问题：我们沟通什么？因为商业决策者之间的差异是巨大的，所以要困难得多。个人兴趣，背景，教育水平和专业领域往往各不相同。尽管如此，我们还是能够提出一系列良好做法。

7个最佳实践：沟通企业风险和信息安全

1. 风险不是受到伤害。影响！
2. 使用隐喻
3. 显示具体的例子
4. 测试安全性
5. 利益相关者的具体沟通
6. 不要使用行话，如果你真的需要，请使用商业行话
7. 让它变得个性化

对于每个最佳实践，我们将尝试解释您可以做什么，以及它如何有助于理解信息安全风险和措施。

1.风险不是受到伤害。影响呢！

通常，风险经理和安全架构师试图以两种不同的方式获得管理者的关注。一种流行的方法是针对恐惧和痛苦。他们传达风险对业务的潜在影响。或者，一些与会者建议介绍在安全方面取得成功的潜在好处，例如：更多来自客户的信任。大多数与会者最为成功的销售恐惧，而不是出售安全的收益。

2.使用隐喻

隐喻在向业务管理团队传达更复杂的概念方面非常有效。例如，您可以通过将信息安全性与保险进行比较来简化讨论。每个人都有某种形式的保险。许多人拥有比他们真正需要的更多的保险。大多数人希望他们永远不会需要它，但无论如何他们都有它们，以防万一。其他与会者提到了交通的比喻。也许有些经理喜欢高速驾驶。他们可能知道事情可能会出错，他们最终会受到某种形式的惩罚，但他们往往愿意接受这种风险。一些管理人员可能永远不会超过限制超过50公里，因为他们知道他们可能会失去他们的执照。其他人可能会使用应用程序来确定警察的检查点。当您使用隐喻时，风险比大多数抽象的网络安全术语更容易理解。这有助于倡导风险管理的重要性。

3.展示具体的例子

Raymond Slot表示，只有6％的黑客被公之于众。然而，他们确实有助于了解可能是违规行为造成的损失。使用这些！最好来自您自己的行业和/或国家，以使其尽可能接近您的业务。

4.测试安全性

在另一个消防演习之后，我们每隔一个月就站在大楼前。不方便和讨厌，但我们都明白它有某种目的。例如，通过渗透测试完成计算机问题的实际测试。但是，业务本身和管理团队几乎不受这些测试的影响。我们讨论中的一些与会者在实际测试安全泄漏，攻击和停机测试方面拥有良好的经验。这不仅为您提供相关信息，还有助于为您的利益相关者提供正确的紧迫感。

5.利益相关者特定的沟通

“生意”不是一个人。这是一个庞大的受众，从现场员工，团队领导，非技术，半技术和技术观众到董事会成员，甚至可能是采购合作伙伴。这些群体有不同的信息需求，需要不同的沟通方式。观众中的一些人创建了沟通策略，通过正确的渠道向正确的内部受众定期提供正确的安全信息。

有些人在与管理层进行“miffy式”沟通方面有很好的经验，其他人建议不要通过向孩子提供信息来冒犯管理人员。

6.不要使用行话，如果你真的需要，请使用商业行话

架构师理解概念模型，逻辑模型和物理模型之间的区别，并考虑需要应用的方法。但经理不在乎......一点都没有！他们流利的唯一行话是你的事业的行话。金钱，速度和风险是会议室使用的行话。我们研讨会的一些与会者建立了他们的案例，以实施有关金融风险可能造成的损失的措施。这似乎真的有助于他们让董事会成员参与信息安全主题。

7.使其个性化

在信息安全意识会议之后应该在业务经理心中根深蒂固的关键信息应该是：“这是一个严重的问题”。或者更具体地说：“这影响了我/我的位置/我的员工/我的客户/我的职业生涯”。仅在大型会议上讨论这些主题并不能真正帮助您获得反馈并了解您的消息是否已落实。不要在您希望拥有信息安全列车的经理谈话，而是与他们交谈！

您在企业风险与安全方面面临的主要挑战是什么？请在评论中分享您的想法，经验和想法，或使用此页面上的社交按钮。

当然，请继续关注本系列的下一篇博文，其中将讨论：构建信息安全意识真正起作用的是什么？

原文：https://bizzdesign.com/blog/information-security-7-communication-tips-to-involve-your-business/

本文：

讨论：请加入知识星球【首席架构师圈】

BiZZdesign的核心价值之一是分享知识和最佳实践。这就是我们定期组织和参与在线和离线研讨会，会议和圆桌会议的原因。在题为“安全不是IT问题”的演示文稿中，说明了组织内政策和措施之间经常缺乏联系，我们决定设立一个世界咖啡馆，讨论围绕此问题的一些主题。该系列的最后一篇博客文章解决了如何沟通信息安全的问题。在这篇博文中，我将介绍关于真正有效建立信息安全意识的辩论结果？欢迎在下面的评论部分分享您的想法。

它对我来说有什么用？
组织中的大多数员工都理解整个组织对信息安全的兴趣，但个人利益似乎更重要，或者至少对许多人来说更为紧迫。你需要告诉人们他们必须失去什么。声誉，信任，业务连续性，资金，数据，时间和焦点只是提到的一些难点。

如果这是你的公司怎么办？
询问某人如果他们的公司面临信息安全问题他们会做什么是获得诚实回应的好方法。这是一个个人问题，它可以帮助人们看到更大的挑战，而不是专注于自己手头的任务。

本月的安全英雄
没有人真正拥有“月度安全员工奖”（获胜者是......密码最复杂的人？），但奖励良好行为是一种简单而有效的机制。通过一些简单的奖励和管理层的称赞来赞扬那些表现良好的人可以真正发挥巨大的作用。

短暂而频繁的消息，而不是一年一度的大型活动
人们的议程很繁忙，当我们发布新版本的安全架构时，我们会有很多东西要呈现，所以我们只是简单地进行沟通......这听起来很熟悉吗？嗯，这是一个不好的做法。路演，提高认识和互联网活动可能看起来很棒，但如果你每年做一次，那就很难奏效。经常分享短信，而不是很少长信息，可以更好地保持安全在人们的头脑中。不断重复您的愿景并重复您期望人们做的事情。

使它成为现实
当我们被黑客攻击时会发生什么？黑客演示可以揭示这个问题。本身没有必要展示技术部分，而是展示损坏的部分。通过这种方式，人们真正看到获取信息的难易程度，以及了解采取安全措施的重要性。

创建意识确实是一项挑战，但是通过我们的圆桌会议中提到的最佳实践，事情可能变得更容易一些。

请继续关注本系列的下一篇文章，该文章将讨论信息安全中的7个最差实践。

原文：https://bizzdesign.com/blog/information-security-what-really-works-to-build-awareness/

本文：http://pub.intelligentx.net/enterprise-security-architecture-information-security-what-really-works-build-awareness

讨论：请加入知识星球【首席架构师圈】

BiZZdesign的核心价值之一是分享知识和最佳实践。我们定期组织和参与在线和离线研讨会，会议和圆桌会议。在最近一次题为“安全不是IT问题”的演讲之后，我们决定建立一个世界咖啡馆，这个演讲说明了组织内政策和措施之间经常缺乏联系。在这篇博文中，我将根据信息安全的重要性，介绍我们之一的辩论结果。请随时查看我在本系列中的最后一篇文章：从安全架构到安全架构。

信息安全很重要，但这是生活的必需品......？

对于公共和私营部门的许多组织而言，连续性是一个重要目标。不知道风险和无法准备和应对这些风险的结果会严重破坏这种连续性。从业务经理的角度来看，信息安全只是需要考虑的一个方面。可用性，速度，性能和价格也是需要考虑的重点。所有与会者都认为安全架构很重要。这并不奇怪，因为他们靠这个工作领域谋生......但是对于它的重要性给出了一些细微差别：

安全的重要性取决于您的行业

重要性（以及随后该领域的FTE数量）取决于您所在的行业。在银行业，黑客的潜在经济利益很高，而信任是银行业务模式的本质！在一家修鞋店，情况并非如此。

风险被低估了

管理层往往低估了风险。通常需要大量的信息安全事件才能真正将企业风险和安全管理置于聚光灯下。但只有你能幸免于此事件。事故让风险变得活跃起来！

物理安全和数字安全

物理安全（例如机场周围）通常被接受并被认为对安全旅行至关重要。随着物联网和与此趋势相关的大数据的巨大潜力，信息安全变得越来越重要。如果您的业务依赖于此数据供应链，安全是生活的必需品！将您的政策，架构和具体措施与该供应链联系起来。物理信息安全正在采用物理措施来保护信息。

合规性推动了安全性

法律法规推动了金融部门的合规浪潮。这促进了信息安全计划，但他们确实需要提供。只填写一个复选框最终将无法证明您在组织中的职位。讨论的结论是，鉴于我们周围存在的所有其他风险，信息安全是某些部门生活的必需品，但不能保证长寿和繁荣的生活。

因此，信息安全很重要......但我们如何说服并参与其他业务？请继续关注本系列的下一篇博客，该博客将提供7个参与业务的沟通技巧。

原文：https://bizzdesign.com/blog/information-security-a-necessity-of-life/

本文：http://pub.intelligentx.net/enterprise-security-architecture-information-security-necessity-life

讨论：请加入知识星球【首席架构师圈】

强大的分析技术

在本博客系列的最后一部分中，我想谈谈风险，安全性和合规性领域，这是建筑师，流程设计师和其他人日益重要的领域。 例如，在之前的一些博客中，我已经概述了新的欧盟通用数据保护法规（GDPR）及其影响。 在我的一篇文章中，我使用了一个简单的数据分类示例，以及如何使用它来评估您的应用程序环境。 但是我在那里展示的并没有实际证明我们在Enterprise Studio中实现的分析技术的全部功能。 从如下图所示的数据分类开始，这种分类可以在整个架构模型中传播，其中各种元素和关系的含义被认为是一种合理有用的结果。

快速评估隐私和安全的影响

如果应用程序可以访问多个数据对象，则基础分析算法将这些对象的最高级别分类作为该应用程序的标准。 因此，如果它同时使用高保密和中保密数据，则会获得最高分类。 如果在业务流程中使用此应用程序和其他应用程序，则该流程将再次获得最高分类; 如果某个业务角色执行此过程和其他过程，并且如果某个角色执行多个角色，则最高级别将再次计算。 这甚至适用于ArchiMate 3.0中新的关系 - 关系功能，例如，您可以在其中模拟与两个应用程序之间的流相关联的数据：如果这两个应用程序交换高度敏感的数据，则需要至少具有 相同的安全分类。

使用此分析为您提供快速方法，以初步评估隐私，安全性和类似问题的影响。它有助于首席信息安全官，首席风险官，数据保护官员和其他人放大高风险领域，优先考虑在最需要的地方加强安全性，并解决设计安全性，数据隐私影响评估和其他法规要求。 GDPR。

尝试不同的方案来分析您的漏洞

另一个甚至更高级的例子是我们作为企业风险和安全管理功能的一部分实施的风险评估方法。这是基于ArchiMate，Open FAIR和SABSA等标准的组合，并在The Open Group和之前的一些博客（1,2）的白皮书中进行了描述。使用此方法，您可以使用体系结构模型来分析您的漏洞是什么，内部和外部威胁可能产生的影响，以及如何减轻这些威胁。下图显示了此类分析的示例。

此图中的所有“交通信号灯”都是互连的：例如，如果您增加了可以缓解漏洞的措施的控制强度（CS），您的漏洞级别（Vuln）会下降，丢失事件频率（LEF）也会降低 减少，因此你的风险下降。 这些结果也可以通过下面的热像图以更加“管理友好”的方式呈现。

有关您在此处看到的内容或本博客系列中所示的任何先前分析的完整说明，请预订此功能的演示！

原文：

https://bizzdesign.com/blog/powerful-analysis-techniques-7-risk-security-compliance-analyses/

本文：

讨论: 加入知识星球【首席架构师圈】

通用数据保护法规（GDPR）是一项严格的欧盟隐私保护法规，将于2018年5月生效。企业架构师可以在帮助其组织符合GDPR标准方面发挥重要作用。您是否了解GDPR对您的组织的影响？

以下是您应该了解的有关GDPR的7件事：

1. GDPR适用于处理欧盟居民数据的所有公司

即使您的公司不在欧盟国家，GDPR也可能适用于您。正如该条例所述（第3条），它“适用于由未在联盟内设立的控制人或处理者处理国际电联数据主体的个人数据”。这意味着任何处理欧盟居民数据的美国和其他外国公司也应根据GDPR承担责任。

2. GDPR是关于证明合规性的

除了符合要求外，您还必须证明合规性。正如第5条规定：“控制人应负责并能够证明符合第1款（”问责制“）。”企业架构师的独特定位是帮助其组织证明其遵守。利用其架构模型进行安全性和隐私分析，架构师可以跨企业，流程，人员和IT系统提供跨数据的使用和保护分析。

了解您的组织是否为通用数据保护法规做好了充分准备。自己测试并了解要采取的措施。

3. GDPR希望您记录收集个人数据的目的

您必须记录您对个人数据的处理以及用于何种目的（第30条）。这包括以下内容：在哪些位置存储个人数据，哪些应用程序使用它，谁有权访问这些应用程序，与之交换的第三方，这些位于何处等等。现有的合规程序通常尝试使用电子表格来捕获这些和其他Office文档，但这很快变得无法管理。架构师在这方面发挥了重要作用，因为他们的架构模型通常包含了获得数据使用的集成概述所需的大部分内容。

4. GDPR要求采用综合的方法来设计安全性

您必须“实施适当的技术和组织措施，以确保适合风险的安全级别”，其中包括“定期测试，评估和评估这些措施的有效性”的流程（第32条）。只需采取一些安全措施，就不会削减它。这需要采用集成的安全设计方法，而不仅仅是关注IT部分，而是包含组织的所有方面。企业架构师是处理这个问题的最佳场所，因为他们拥有所需的概述和洞察力。

5. GDPR需要数据保护影响评估

每次实施处理个人数据的系统时，您都必须执行数据保护影响评估，其中包括处理的系统描述，风险评估，解决这些风险的措施以及您将如何证明合规性。这种对大型复杂业务和IT环境的分析需要智能软件解决方案。 BiZZdesign Enterprise Studio的企业风险和安全管理功能非常适合此类安全和隐私分析和设计。利用现有的架构模型，您将获得快速发展！

6. GDPR强制您在72小时内报告数据泄露事件

您必须在72小时内向当局和相关的“数据主体”（第33和34条）报告数据泄露事件。这可能会导致严重的声誉风险，正如之前的事件所表明的那样。试图隐藏违规行为不再是一种选择。

7.不遵守GDPR会导致严重的处罚

对违规行为的处罚包括“高达2 000 000欧元的罚款，或者在承诺的情况下，高达全球年度总营业额的4％”（第83条），紧接数据可能要求的个人损害主题（也是集体诉讼），以及董事和高级管理人员的个人责任。对于您的组织来说，避免这些风险有什么价值？

是时候证明架构的重要性了

网络安全和相关的声誉风险已成为高级管理层的首要战略问题，而GDPR对此问题施加的压力更大。作为企业架构师，您可以在此领域发挥关键作用。揭示您的架构知识，模型和分析的隐藏价值。帮助您的组织提高其网络弹性，确保合规性，并降低运营，声誉和财务风险。展示建筑在董事会中的重要性！

原文:https://bizzdesign.com/blog/7-things-every-enterprise-architect-needs-to-know-about-the-gdpr/

本文:

讨论：请加入知识星球【首席架构师圈】

网络安全威胁不断增加。有时候会说有两种组织：那些知道自己被违反的组织，以及那些还不知道的组织。为了降低与网络安全相关的风险和损害，重要的是要知道如何评估这些风险并通过设计安全性来改善您的防御。如果事情确实横向发生，那么计划做什么也很重要。

确保企业范围内的意识

在大多数组织中，由于过去几年中发生过许多引人注目的事件，上层管理层对网络威胁的认识有所提高。与勒索软件，数据泄露和其他问题相关的成本很容易达到数亿。

但有时，网络安全仍被视为技术问题，由IT主管和他或她的下属处理。唤醒董事会对网络安全意识的一个可靠方法是遵守法规。在这些情况下，管理层可以对违规行为负个人责任，因此有强烈的动机采取行动。关于数据隐私的新规定，例如欧盟GDPR，只是安全和隐私问题已经进入董事会的一个例子。特定行业和地区法规，例如美国HIPAA医疗保健行业隐私规则或NYDFS纽约金融服务部门网络安全法规，是其他例子。

但通常情况下，当涉及到网络威胁时，管理层会感觉像头灯中的鹿。他们看到了危险，但不知道面对这些威胁该怎么做。这些问题的广度和深度可能看起来确实难以理解和无法解决。为了帮助管理层克服这种瘫痪，您必须提出解决方案，而不仅仅是问题。企业架构师的独特定位是为这些解决方案做出贡献。

当企业架构师试图建立网络安全流程和标准时，您需要不仅涉及管理层，而且还要通知组织的其他部门。我们撰写了一系列关于信息安全的沟通，讨论了董事会中的信息安全问题，提供了涉及业务的技巧以及解决真正有效建立安全意识的方法。有关如何正确缓解网络和信息风险的更多信息，请查看它们。

使安全和风险管理与业务战略保持一致

为了明智地花钱，你需要在真正重要的地方投资安全 - 也就是说，它在战略上具有重要意义。因此，您应该从策略的角度对您的资产进行分类，同时考虑到法规遵从性和其他准则。这些资产的价值是什么，不仅仅是在财务方面，而是在更广泛的意义上？例如，保护宝贵的知识产权或隐私敏感数据可能对您的业务连续性至关重要，或者从监管合规的角度来看是必不可少的。这种分类有助于您确定投资优先级，并避免在相对不重要或一揽子措施上花费太多。

不幸的是，许多组织在其战略和资产之间没有明确的联系。与战略方向和动机相关的稳固的企业架构，以及在组织内部的实施，提供了您所需的“结缔组织”。 BiZZdesign Enterprise Studio提供集成支持，用于描述创建此类视线所需的策略，体系结构，流程，系统和数据。

分析您的漏洞和风险

使用数字，物理和社会工程技术的组合，网络攻击变得越来越复杂。一个常见的例子是所谓的“公路苹果攻击”。一名潜在的入侵者“意外地”将USB闪存盘留在公共场所，例如公司停车场。一名员工捡起来，很有可能他无法抑制好奇心并将其插入电脑。惊喜：驱动器感染了感染PC的恶意软件，并向入侵者发送敏感信息。

您必须采取整体方法来抵御此类攻击，包括企业的所有方面，包括人员教育，流程和程序，以及防火墙和防病毒软件等技术措施。此外，您应该从业务目标和战略的角度来看待这一点，如前所述。

使用Enterprise Studio，您可以捕获并可视化组织的各种风险和安全方面。它可以帮助您可视化与整体架构，业务战略和资产相关的危险，风险和缓解措施，以便您可以执行真正的基于策略和价值的风险和合规性评估。您可以衡量和可视化这些风险的潜在影响，并使用这些见解优先考虑减少措施的投资，作为下一步的一部分。如果您在该领域寻求更多指导，我们过去也会撰写关于安全性和合规性分析的文章。

采用安全设计方法

事实之后不应该修复漏洞，特别是不要仅仅使用额外的防火墙等临时安全措施。您不应该定义单独的安全体系结构，而应该开发一个安全的体系结构，并在企业的各个层面（从人员和职责到流程和技术）主动地解决架构和设计中的风险。

您还需要考虑您的组织在更广泛的生态系统中的位置。按顺序拥有自己的房子可能还不够。例如，如果您广泛依赖某些外部合作伙伴，那么他们的安全性可能对您自己的运营至关重要。有些组织试图依靠合同和协议来处理这个问题，但这可能是不够的。从法律上讲，您可能要对外包合作伙伴的违规行为负责。诸如GDPR之类的监管明确规定，即使您雇用其他人为您执行此操作，您的组织仍对处理隐私敏感数据负责。在某些情况下，您甚至可能需要审核您的业务合作伙伴以保持合规性。

在按设计安全的方法中，您可以根据资产价值和先前步骤中确定的漏洞确定安全投资的优先级。您可以计算安全项目的业务价值和影响，并使用它来确定IT度量的优先级。使用我们的企业投资组合管理来确定最有效地使用预算的位置。

假设你受到了损害

没有多少安全措施可以让您100％安全，所以当事情横行时，您最好做好准备采取行动。许多组织争先恐后地发现在受到攻击时该怎么做，因为他们不知道组织的哪些部分或其系统可能受到影响。

根据对企业结构和运营的明确见解制定应急计划至关重要。最新的架构，流程，系统和数据模型可以帮助您评估问题可以传播的范围，以及您应该在哪些方面快速采取行动来限制安全漏洞的影响。

但请记住艾森豪威尔的格言：“计划一无所获;规划就是一切。“没有什么能完全按照计划进行，但这些计划的发展本身将清楚地说明你需要知道什么，未知的是什么，以及你必须更新你对企业化妆的知识。将Enterprise Studio与CMDB等管理和监控操作实际的系统相连接，有助于确保您使用最佳和最及时的数据。

最后，您的组织的“第一响应者”需要随时可以访问所有这些信息.BiZZdesign的HoriZZon门户网站为此提供了一个很好的解决方案，为各种类型的用户提供易于使用的视图和仪表板，从业务决策者到运营管理层和人们在众所周知的车间。

有兴趣了解更多？加入我们的网络研讨会或预订演示！

原文:https://bizzdesign.com/blog/cyber-security-5-steps-to-stay-safe-in-a-dangerous-world/

本文:http://pub.intelligentx.net/enterprise-security-architecture-cyber-security-5-steps-stay-safe-dangerous-world

讨论:请假知识星球【首席架构师圈】

未经适当授权，任何人不得进入大楼; 所有传入的电子邮件都被过滤掉; 用于存储敏感数据的个人计算机没有直接连接到Internet，因此无法远程访问。 有了这些企业安全规则，我们确保我们的私人信息是安全的，对吧？ 错误！

使用数字，物理和社交工程技术的组合，网络攻击变得越来越复杂。 典型的例子是所谓的“公路苹果攻击”。 一名潜在的入侵者“意外地”在一个公共场所（如公司停车场）留下一个带有公司徽标的USB闪存盘。 一名员工捡起来，很有可能他无法抑制好奇心并将其插入电脑。 惊喜：驱动器感染了恶意软件，除非采取适当的措施，否则会感染PC并将敏感信息发送给入侵者。

当然，有几种方法可以防止这种情况发生。系统管理员可能决定完全禁用USB驱动器的使用，但这可能限制太多，导致员工想方设法绕过这一点。或者，如果人们有足够的纪律来遵守它，那么反对使用未经验证的存储设备的政策就足够了......没有简单的方法来确定安全性是多少，以及安全性是多少。换句话说，我们如何找到安全性，可用性和成本之间权衡的最佳位置？

目前大多数安全和风险管理方法都基于清单，启发式和最佳实践。安全措施以自下而上的方式应用，往往忽略了社会方面。这可能导致预防性安全措施的过度杀伤，同样在更便宜（且侵扰性较小）的治疗措施可能就足够的情况下也是如此。另一方面，组织中不那么明显的威胁或漏洞可能很容易被忽视。

企业安全管理，Archimate核心

为了避免这种情况，我们提倡基于模型的企业安全管理方法，其中安全方面完全集成在设计链中：从战略和业务模型到企业架构，再到组织和IT支持的设计和实现。为此，与风险相关的概念包含在现有的体系结构和设计语言中。在企业架构层面，ArchiMate作为一个广泛接受的开放标准（具有可用的工具支持），适合以集成的方式描述业务和IT方面，是一个显而易见的选择。 ArchiMate中描述的体系结构可以链接到目标，原则和要求，以及用BPMN或UML等语言表达的详细设计模型。由此产生的模型为风险和漏洞分析提供输入，突出显示架构中最容易受到攻击的区域。此外，他们还将指导设计有效和高效的安全措施。

通过这种方法，BiZZdesign可以帮助您设计一个安全的组织 - 不会过度限制您的员工在日常工作中。

原文：https://bizzdesign.com/blog/designing-secure-organizations-risk-management-enterprise-security-management-and-archimate/

本文:

讨论:请加入知识星球【首席架构师圈】

大约95%的组织使用至少一个框架来管理其IT治理。公司将始终受益于在其业务和IT流程中增加结构并保护其资产。这就是为什么许多框架都有蓝图，以便组织能够实现其关键目标，如治理、法规遵从性和安全性。两种流行的模式是COBIT和TOGAF，这两种模式都被企业广泛用于网络安全和数字恢复。在这篇关于COBIT与TOGAF的文章中，让我们探讨一下这些流行的IT治理框架在网络安全方面是如何不同的。

COBIT：概述

COBIT是ISACA开发的应用最广泛的IT管理框架之一，于1996年首次发布。当涉及到管理信息和it治理以实现网络安全时，公司会帮助他们制定、组织和实施最适合公司的战略。

COBIT5由ISACA发布，包括许多组织和公司的风险管理实践以及管理治理。COBIT 2019更新旨在与时俱进，为公司提供更频繁的更新。所制定的战略更加灵活，更适合个别公司的需要。这些战略对不断变化的新技术采取了更具协作性的方法。

TOGAF：概述

创建开放组体系结构框架（TOGAF）是为了帮助公司创建组织其开发过程的系统方法。TOGAF帮助组织减少错误，维持所有截止日期，同时遵守预算，以提供高质量的结果。据发现，2016年，全球50家公司中有近80%使用TOGAF作为网络安全框架。当涉及到内部使用框架时，TOGAF对组织来说是免费的，但当涉及到商业使用时就不是了。

TOGAF还帮助公司协调业务和IT目标。它还帮助组织跨所有部门管理其It工作。在TOGAF的帮助下，公司可以在任何项目开始之前轻松地组织所有需求。这有助于为任何项目创建一种更安全的方法，因为在项目开始之前，所有的威胁和风险因素都已被理解和管理，从而使流程快速推进，几乎没有错误。

创建TOGAF是为了让公司中的每个人都能“说相同的语言”，节省资源，并更有效地使用它们。它有助于标准化创建企业架构的开放方式。这导致了软件技术实现的更结构化和更有组织的方式。TOGAF更注重治理，包括网络安全和实现业务目标。TOGAF还帮助解决IT部门内部或外部的任何问题，使所有利益相关者保持一致。

COBIT的组成部分

COBIT 2019可以与ITIL、TOGAF和CMMI一起工作。这使得COBIT 2019成为创建伞式框架的最佳选择，这样所有公司流程都可以得到统一。它解决了技术和安全需求的所有新趋势。总而言之，COBIT 2019的设计使企业在定制其it治理战略以满足其需求时具有更大的灵活性。

COBIT还有助于协调业务目标和IT目标，就像TOGAF一样。它在It部门和企业其他部门之间建立了各种联系，以弥合差距。COBIT的与众不同之处在于，它比其他框架更注重网络安全，并将信息安全、风险管理和治理列为其主要优先事项。COBIT不仅仅是一个组织所有业务流程和管理TOGAF等技术的工具，即使它确实集成了这些流程和技术。COBIT被明确设计用于管理可能影响整个组织的IT风险，以便所有业务流程都能顺利进行。

COBIT 2019框架附带一个指南，介绍COBIT的所有主要原则和总体结构。它还包括COBIT帮助公司实现的所有40个治理和管理目标。COBIT 2019还提供了一个设计指南，使组织能够深入了解如何开发一个专门针对其需求的IT治理系统，并提供了一个在开发战略后实施战略的指南。

TOGAF的组成部分

创建TOGAF是为了为组织的IT架构和总体业务运营提供四个主要领域。它为组织提供了有关如何创建更好的业务战略的信息，特别是在涉及治理和如何实现所有现有流程时。TOGAF还有一个架构和部署各种系统的蓝图，以符合组织的业务目标。TOGAF为公司提供了一种定义整个组织的数据存储并对其进行管理和维护的方法。

TOGAF框架有一个内容元模型，用于指导公司创建和管理组织中的所有企业体系结构。它创建了一种更精简的基础架构管理方法。TOGAF9中的分区组件在分离公司中的特定体系结构时提供指导。TOGAF还拥有一个体系结构存储库，其中包含与所有相关项目的企业范围体系结构相关的不同细节，包括各种想法、设计、流程和框架，以帮助项目更顺利地完成。TOGAF9还提供了各种指导原则和技术，以帮助在组织内应用框架并管理一些安全问题。

COBIT和TOGAF认证

这两种认证都属于IT安全和治理类别，任何组织的员工都可以使用它们来帮助以更有效的方式实现框架。

COBIT 5和COBIT 2019认证相互补充，如果组织实施COBIT 2019，COBIT 5认证将派上用场。COBIT 2019认证包括一个COBIT桥梁研讨会，这是一个为期一天的课程，涵盖各种概念和模型，重点关注COBIT 5和COBIT 2019之间的差异。有一个为期两天的基础课程与考试，也是一个设计和实施认证。

TOGAF认证有两个级别。第1级涵盖了ToAF的基础方面，第2级涵盖了员工可能需要成功实现框架的所有工作知识。

COBIT vs TOGAF：最后的想法

COBIT是一个更加关注于创建企业范围的IT治理系统的框架，该系统实现了各种安全控制。相比之下，TOGAF用于为公司创建一个信息体系结构，以简化的方式整合业务和IT目标。它们也可以作为混合模型一起使用，以创建一个强大的治理框架。

个人和企业团队可以参加的一些流行的IT安全和治理认证课程包括：

• COBIT 5基金会认证培训
• COBIT 5实施认证培训
• COBIT 5评估员认证培训
• CGEIT认证培训
• CRISC认证培训

原文：https://www.invensislearning.com/blog/cobit-vs-togaf-which-is-better-fo…

本文：http://jiagoushi.pro/node/1522

讨论：请加入知识星球【首席架构师圈】或者小号【cea_csa_cto】

网络安全是商业界必须处理的关键问题之一，其重要性只会上升。随着技术稳步发展以接管越来越多的业务（和个人）生活方面，雅虎和Experian的违规行为或WannaCry勒索软件攻击等事件迫切需要安全性。每年都有大量公司被黑客入侵。以下是一些最有名的案例，可以给你一个想法。结果？全世界无数人受到影响，网络安全状况不佳的成本很容易在数百万人中流失。

一切都在安全？

当你考虑所有这些时，那么只有一个组织抛出他们在这个问题上得到的一切才有意义。对？好吧，虽然这可能听起来不直观，但答案是否定的。事实上，公司的最终目标不是成为一个难以穿越的数字堡垒，而是为了（为客户创造价值）保持业务。

由于现在公平竞争的变化有多快 - 考虑技术进步，不断变化的监管等等，因此保持业务需求实际上比以往任何时候都难以实现。因此，仅关注业务的一个方面是无关紧要的必然结果。创新，服务交付水平，客户满意度，合规性，企业公民 - 这些只是组织为了获得成功而需要注意的其他事项。

因此，我们认为对于认真对待其网络安全战略的公司来说，最好的办法是以高精度，高影响力的方式运营。这意味着承认一揽子措施通过机会成本，用户不便和彻头彻尾的浪费来做同样多的损害。期望一切都是100％安全是不现实的。在游戏中有一个收益递减规律，确保你无法到达那里，即使你拥有世界上所有的时间和资源，也无论如何你都不会。因此，专门针对关键弱点的刻意行动是最合理的路径 - 这就是为什么高精度，高影响力的思维方式是关键。

准确定位安全漏洞

理解背景

为了能够“手术”操作，您首先需要清楚地了解当前的功能。我们的协作业务设计平台HoriZZon及其建模环境Enterprise Studio完美地配备了这一平台。使用我们的套件，用户可以构建其业务和技术环境的准确数字模型，他们可以实施基于功能的规划，并将各种功能链接到应用程序，基础架构或流程，以便对其组织有广泛的了解。可以想象，这可以实现逐个安全的方法，因为它允许将企业风险和安全管理过程嵌入到企业的实际架构和设计过程中。

除了可以让您探索企业所有方面的数字建模功能外，该平台还有助于培养最佳实践遵从性和安全合规性。 HoriZZon支持广泛的安全标准和框架，并提供可靠的内容治理功能。主流标准，如ISO / IEC 27001，NIST 800-53，CSA，Open FAIR，SABSA等，为希望建立稳固的安全和风险管理实践的用户提供结构，指导和适当的指标。实际上，它们为识别，评估和确定安全目标和操作的优先级提供了完美的方法。通过最佳实践和企业（及其生态系统）的清晰的全局视图，您可以最佳地开始安全风险评估。

运行安全评估

因为完美的安全是一个无法实现的目标，所以在这一点上的重点应该放在支付安全资金的最有效方式上。在分析风险，威胁，机会或绩效目标时，基于风险的方法提供了持续连接和解决重叠问题所需的结构。在组织内部开发风险意识文化是成功的企业风险管理计划的重要组成部分。

在BiZZdesign，我们的风险和安全管理方法结合了几个开放标准。如果您想了解更多信息，可以下载我们的如何使用EA白皮书改进网络安全，但现在只需说明评估阶段的主要步骤是：分析漏洞，评估威胁和计算风险。

我们的平台使安全专业人员能够有效地规划，实施和成熟企业内的企业风险管理实践。我们甚至编制了一份在分析阶段证明有用的漏洞和威胁的综合列表。运行风险评估的直接方法是使用公式Risk = Value x Probability，其中较高的风险将需要更多的努力来减轻风险。在此阶段结束时，您应该充分了解企业面临的风险状况。以下是我们如何使用HoriZZon的建模环境Enterprise Studio进行此类分析的示例。

模型的下半部分显示了您要保护的基础架构和资产（“加密支付记录”）。上半部分显示：

• 两个漏洞（“不安全的传输通道”和“支付数据的弱加密”）
• 威胁代理人（'网络犯罪'）
• 威胁事件（'中间人攻击'）
• 此威胁造成的潜在损失事件（“未经授权的付款”）
• 由此产生的风险（“财务损失”）

交通信号灯显示各种参数，例如资产价值，漏洞等级和由此产生的风险等级。所有这些都是相互关联的，我们的风险分析算法会计算结果，即如果您增加资产价值或威胁能力，则会增加风险等级。

制定并实施减轻风险的措施

在上面的评估阶段大纲之后，下一步是提出控制措施并进行部署。通过不受阻碍地了解弱点的位置以及违规的后果，目标是制定有效的措施。我们建议的结构是首先考虑策略，然后定义控制目标，然后创建控制措施，最后实现它们。利用企业架构和/或项目组合管理输出将在此处再次派上用场，因为安全建议可以与基础架构层中的实际易受攻击元素（例如，或重要业务功能）相关联。

作为此阶段的一部分，您应计算安全措施的成本，并将其与其降低的风险进行比较。那钱花得好吗？如果报告明确表明它将带来的好处，管理层必然会更严肃地对待报告。最后一项建议是在个人层面上与决策数据联系起来。例如，您可以指出，如果发生违规或不合规的业务惯例，负责任的管理层将面临个人责任的趋势。欧盟的通用数据保护法规就是一个这样的监管框架，它不仅推动了数据处理器的边界和压力，而且还压制了以前不承担任何责任的数据控制者。通过避免昂贵的一揽子措施并精确地攻击最紧迫的安全问题，一个组织有更好的机会来防范威胁，但从长远来看也是繁荣的。

结论

随着公司发现自己拥有越来越多的客户数据，恶意行为者加倍努力，网络安全比以往任何时候都更加重要。鉴于这些情况，公司很容易采取全面的防御姿态，并在创新上“拉开桥梁”以及有助于持久成功的其他因素。然而，这将是一个战略性的失误。

这是因为通过加强控制和谨慎，您还可以降低灵活性和灵活性，从而降低企业在一个奖励快速适应能力的时代的整体竞争力。我们认为，解决方案是明确了解企业的​​风险状况，然后在风险最大的领域开发和部署缓解控制措施。能够以数字方式实现企业，然后在实时模型之上运行风险评估，提供了很大的改进机会。

要了解有关网络安全以及企业架构如何在制定可靠的网络安全战略中发挥作用的更多信息，请下载我们的如何使用EA白皮书改进网络安全。

讨论: 加入知识星球【首席架构师圈】

作为中台倡导者，百度如何利用“搜索中台”实现月级别孵化新产品

https://www.infoq.cn/article/tlB*k1aXYfXMpMhJEpIA

白话中台战略（一）：中台是个什么鬼？

https://www.infoq.cn/article/cG-DHodbHjRcv92W6tYh

白话中台战略（二）：中台到底长啥样？

https://www.infoq.cn/article/I_QyoXJO0KFBWoKmNXuK

白话中台战略（三）：中台的定义

https://www.infoq.cn/article/Mh_Qmji7w0R4lB9ETFAA

白话中台战略（四）：从互联网巨头变阵看中台战略

https://www.infoq.cn/article/Izi6-VLssZlkrj4b3uLh

中台之上（一）：重视业务架构，不要让“业务的归业务、技术的归技术”

https://www.infoq.cn/article/Cs*cvPvLbhpuEBzUhqaY

中台之上（二）：为什么业务架构存在 20 多年，技术人员还觉得它有点虚？

https://www.infoq.cn/article/th-QkbHEr82MaxS9BMof

这些流行和新兴的 EA 工具为企业提供了支持企业架构和数字化转型所需的一切。

企业架构系统并不总是必不可少的。 据推测，在 1940 年代，国际商业机器公司的一位领导人小托马斯·沃森 (Thomas Watson Jr.) 曾说过：“我认为大约有 5 台计算机的全球市场。” 没有人需要定制软件来跟踪这么短的列表。

然而，现代企业则大不相同。 一些员工仅在他们的办公桌上就有超过五台计算机。 即使是小型组织也可能拥有数千台机器； 有些人可以轻松拥有超过一百万。 那是在考虑构成物联网的传感器和智能设备之前。 企业架构 (EA) 系统跟踪所有这些机器和在其上运行的软件——更不用说这些软件层如何交互了。 因此，EA 工具是管理这些新兴虚拟世界的唯一真实来源。

EA 工具市场状况

EA 市场很强大，有几十个严肃的竞争对手。有些专门研究特定平台或云。其他提供与商业智能和业务流程管理软件的更深层次的集成。有些开始时是通用建模软件；其他的则是专门为企业架构而构建的。所有这些都编译一长串机器，并提供各种表格和图形仪表板来跟踪它们。

EA 系统以多种方式收集设备和软件信息。最手动的过程涉及要求利益相关者和开发人员填写表格，详细说明谁拥有什么机器。最自动化的工具直接登录到公司的云端，计算机器本身。大多数使用这些方法的混合。有些提供拖放小部件，以便开发人员、架构师和管理人员可以创建所有机器、这些机器运行的软件以及数据如何从一台机器流向另一台机器的模型。

从 CIO 到快速响应团队的每个人都可以使用 EA 仪表板中的图表来查找流程并跟踪数据流。有些人想注意坏机器或过载的管道。他们可以通过跟踪一连串的故障来修复问题。其他人则希望通过寻找瓶颈或捷径来规划未来。所有人都依赖系统中的数据作为快速决策的跳板。

许多工具使用 ArchiMate，这是一种开放式建模标准，旨在捕捉企业架构的大部分复杂性。它旨在与 TOGAF 开放框架密切合作。视图和可视化的创建方式类似于 UML（统一建模语言），这是另一种可视化设计的通用方法。

一个重要的考虑因素是与本地堆栈中软件类型的集成级别。所有 EA 工具都支持可以从特定云或操作系统收集数据的大量模块，但有些工具比其他工具更好地支持各种云和操作系统。有些人专注于计算世界的特定角落。

为您的办公室选择最佳解决方案意味着查看与您的特定堆栈的集成量，然后权衡软件生成的图表和表格的有用性。以下按字母顺序概述了当今可用的顶级企业架构平台。

18 大企业架构工具

• Ardoq
• Atoll Group SAMU
• Avolution Abacus
• BOC Group ADOIT
• BiZZdesign HoriZZon
• Capsifi
• Clausmark Bee360
• EAS
• LeanIX Enterprise Architecture Suite
• Mega Hopex
• Orbus Software iServer
• Planview Enterprise One
• QualiWare Enterprise Architecture
• Quest Erwin Evolve
• Software AG Alfabet
• Sparx
• Unicom System Architect
• ValueBlue Blue Dolphin

Ardoq

Ardoq 旨在通过一系列简化表格从整个企业的各种用户、开发人员和利益相关者那里收集信息。目标是让了解各种系统角色的人参与进来。这些数据为每个人创造了一个更加“民主”的机会，可以使用网络和数据流的可视化来支持和现代化支持其角色的系统。该工具提供与主要云的集成以及可通过所有主要语言（Python、C#、Java 等）进行定制的 API。

Atoll Group SAMU

Atoll Group 创建了 SAMU，通过与云层和业务流程管理工具的深度连接来跟踪企业架构。它提供与监控工具（Tivoli、ServiceNow 等）、云虚拟化管理器（VMware、AWS 等）、配置管理数据库（CA、BMC）以及服务组织工具（BMC、HP）的集成。这些集成提供了一个集中的数据模型，该模型增加了利益相关者的输入。

Avolution Abacus

Avolution 的主要工具 Abacus 提供了一组数据收集集成例程，用于构建图表驱动的仪表板。与 SharePoint、Excel、Visio、Google Sheets、Technopedia 和 ServiceNow 等办公工具的核心集成简化了使用它们的工作流的使用。该工具最近开始添加机器学习层，现在用户可以尝试训练一个模型，该模型可以帮助回答诸如哪个工作人员负责特定系统等问题。

BOC Group ADOIT

BOC Group 的 ADOIT 是一个广泛开放的工具，可将每个系统或软件包映射到一个对象。系统之间的数据流使用可定制的元模型转换为对象捕获的关系。业务流程也由集成良好的配套产品 ADONIS 进行类似建模。基于 Web 的工具还与 Atlassian 的 Confluence 等工具集成，以加快数据捕获和演化。

BiZZdesign HoriZZon

BiZZdesign 的主要工具称为 HoriZZon，它提供了一个基于图形的模型，用于从所有利益相关者那里收集数据，因此其分析引擎可以生成说明系统当前状态的图表。管理变更和规划未来是 BiZZdesign 的重点，HoriZZon 旨在帮助管理重新设计的风险。该工具集支持 ArchiMate、TOGAF 和 BPMN 等主要标准。

Capsifi

Capsifi 的 Jalapeno 在其基于云的平台中创建商业模式。目标不仅仅是在模型中捕捉工作流，而是让领导层能够充分理解以通过创新推动转型。该软件允许用户将“客户旅程”或“价值流”等建模概念结合在一起，并将其与从 Jira 等工具收集的数据集成。这些数据可以生成通过一组图表和仪表报告的指标，这些图表和仪表旨在衡量进度或“燃尽”。

Clausmark Bee360

Clausmark 的旗舰产品 Bee360（以前称为 Bee4IT）旨在提供有关企业工作流程的简单事实来源，以便许多角色可以做出更明智的决策。该系统还提供了使用 Bee360 FM（财务管理）跟踪和分配成本的能力。

EAS

Enterprise Architecture Solutions 的 Essential 包最初是一个开源项目，后来演变成一个商业可用的云解决方案。它创建了一个描述系统和业务流程之间交互的元模型。商业版本包括用于跟踪一些常见业务工作流程的软件包，例如数据管理或 GDPR 合规性。

LeanIX Enterprise Architecture Suite

LeanIX 工具集包括企业架构套件以及其他几个工具，例如用于跟踪云部署和在其上运行的服务的云智能和服务智能。它们一起收集有关您的 IT 基础架构的数据，并将其呈现在其 Fact Sheet 模型中，这是一种用于基本信息的直接交付机制。该工具与几个主要的云工作流工具紧密集成，包括 Confluence、Jira、Signavio 和 Lucidchart，这对于已经使用这些工具来规划和执行开发策略的团队来说是一个优势。

Mega Hopex

Mega 构建了 Hopex 平台以支持对企业应用程序进行建模，同时了解它们支持的业务工作流程。数据治理和风险管理是等式的重要组成部分。该工具建立在 Azure 之上，并依赖于一系列开放标准，包括 GraphQL 和 REST 查询，以从组件系统中收集信息。报告与 Microsoft 的 Office 工具以及 Tableau 和 Qllk 等图形解决方案集成。

Orbus Software iServer

Orbus 在 Microsoft 堆栈上构建了它的 iServer 工具，它的产品对于任何与 Microsoft 工具紧密结合的团队来说都是熟悉和可用的。报告出现在 Microsoft Word 中。数据被格式化为 Excel。一切都在 Azure 上运行良好。这些工具不仅限于 Microsoft 环境，因为它的模块集合支持主要的、开放的集成标准来收集数据。

Planview Enterprise One

Planview 提供了一系列用于跟踪团队合作、流程和企业架构的产品。其 Enterprise One 创建机器和软件层组合，为经理和团队成员提供基于角色的视图。该工具与常见的工单跟踪系统（如 Jira）集成，用于创建工作流分析和报告。 Planview 还提供了类似的工具，例如 Daptiv、Barometer 和 Projectplace，用于跟踪业务工作流程和流程的发展。

QualiWare Enterprise Architecture

QualiWare 的企业架构工具是一系列旨在捕获所有业务流程的建模工具的一部分。它为构建可以记录客户旅程进展情况的数字双胞胎提供了一个全新的条件。该公司正在整合各种人工智能算法，以增强文档和流程发现。

Quest Erwin Evolve

Quest 的 Erwin Evolve 工具最初是一个数据建模系统，后来发展为提供企业架构和业务流程建模。团队可以使用定制的数据结构来捕捉现代、联锁软件系统和他们管理的业务工作流的复杂性。基于 Web 的工具创建模型，生成基于角色的图表和其他可视化，为所有团队成员形成仪表板。这些也可以转换为定期报告以进行分发。

Software AG Alfabet

Alfabet 是用于管理 API、云计算和支持物联网设备的应用程序的大量产品之一。该系统从各种界面收集信息，并生成数百甚至数千个充满生命周期地图、图表、排名和地理坐标的潜在报告。传统上，Software AG 提供与 IBM 产品紧密结合的 ADABAS 等工具，而 Alfabet 提供与所有主要平台的紧密集成，包括 Microsoft Teams 等协作空间。其最新版本将包括一个声音选项 Alfabot，它提供“对话式用户界面 (CUI)”。

Sparx

Sparx 创建了四个级别的工具，以便各种规模的团队可以处理各种规模和复杂性的项目。所有这些都提供基于 UML 的建模，以跟踪日益复杂的系统的各个部分。模拟引擎可以进行兵棋推演，并了解故障如何传播和级联，这是灾难规划的重要组成部分。 Sparx 认识到可以出于各种原因构建模型，包括纯粹的分析、软件开发或战略规划，并且他们提供了数百种潜在的预构建设计模式来指导建模。

Unicom System Architect

联通 TeamBlue 的最新产品之一是 System Architect，这是一种使用元模型自动收集有关运行系统的尽可能多数据的工具，有时通过对数据流进行逆向工程。这个系统范围的数据模型可以在用户可定制的仪表板中呈现给所有角色的团队成员。有远见的管理者也可以开始模拟以帮助优化资源分配。

ValueBlue Blue Dolphin

ValueBlue 的 BlueDolphin 以三种方式收集数据。 首先，它依赖于标准驱动的自动化（ITSM、SAM）来导入基础数据。 其次，它以 ArchiMate 或 BPMN 等文件格式与架构师和系统设计师合作。 最后，它使用由可定制模板驱动的问卷调查其他利益相关者。 所有这些都是在一个跟踪系统历史演变的视觉环境中提供的。

有关推进企业架构的更多信息：

• https://jiagoushi.pro/enterprise_architecture

原文：https://www.cio.com/article/196069/top-enterprise-architecture-tools.ht…

本文:https://jiagoushi.pro/node/2105

企业正在使用企业架构来改善产品交付、风险管理，甚至员工保留，以及其他关键业务用途。

企业架构 (EA) 学科经常被批评为迫使业务用户选择技术或产生无人使用的软件分析。

但是今天 EA 的实践正在蓬勃发展，任何描述的架构师都很难找到并且“非常昂贵”，Gartner 研究副总裁 Marcus Blosch 说。

Forrester Research 已确定其客户使用的 20 多种企业架构角色。他们的范围从定义业务和运营模型的组织架构师到项目、平台和数字架构师。 Forrester 的首席分析师 Gordon Barnett 说：“这份名单越来越多，从只关注应用程序和基础设施的 EA 转变为真正的企业。您需要一个由主题专家组成的生态系统。你可能不会称他们为建筑师，但他们仍然扮演着建筑师的角色。”

以下是精明的 EA 从业者如何帮助企业应对当今最紧迫的三个业务挑战。

弹性和适应性

随着从 COVID 关闭到经济制裁破坏运营和供应链的一切，企业正在转向 EA 的洞察力，以更快、更有效地预测和响应问题。

Barnett 表示，虽然弹性一直是 EA 的重点，但“现在的重点是主动弹性”以更好地预测未来风险。他建议扩展 EA，不仅要映射企业的技术资产，还要映射其依赖供应商的所有流程，以及可能因流行病、制裁、自然灾害或其他中断而无法使用的兼职和合同工。

Barnett 说，企业还希望使用 EA 来预测问题并规划工作负载平衡或按需计算等功能，以应对需求激增或系统中断。这需要企业架构师与风险管理和安全人员更紧密地合作，以了解架构中组件之间的依赖关系，从而更好地了解中断的可能性和严重性，并制定应对计划。

他说，例如，EA 可以帮助描述哪些云提供商共享相同的网络连接，或者哪些托运人依赖相同的端口，以确保“备用”提供商不会遭受与主要提供商相同的中断。

规划供应链中断

Mike Small 是工程和数字解决方案公司 AKKA & Modis（即将成为 Akkodis）北美地区的负责人，他表示 EA 正在帮助汽车制造商等企业了解他们是否以及如何在没有完整的难以交付的产品的情况下交付产品。 - 寻找半导体等组件。

他的一些客户将企业架构师与产品、分析和供应链专家聚集在一起，询问“我是否仍然可以在没有 100% 的物料清单的情况下安全地销售该产品？如果答案是肯定的，那么当我的系统设计为与产品规格零偏差时，我该怎么做呢？”他说。他说，这可能需要对 ERP 系统进行分析，以了解引用物料清单的所有依赖项和功能。

Radicle Science 提供在线服务来衡量健康和保健产品的有效性，它使用 EA 来跟踪其数据供应商使用的 API 和数据格式，因此变化不会破坏业务，首席技术官 Sheldon Borkin 说。 “我们对第三方物流供应商的建模越深入”，Radicle 就越意识到不仅需要映射每个供应商使用的 API，还需要映射他们存储提供给 Radicle 的数据的格式。 “我们需要为每个 API 编写一个适配器，并在 EA 中构建对此类适配器的需求以及跟踪它们的能力，”他说。

员工招聘和保留

随着员工短缺使全球各行各业步履蹒跚，改善员工体验以留住重要人才已成为一项战略当务之急。企业使用 EA 不仅可以提供更好的应用程序和服务，还可以提供能够吸引和留住员工的工作体验。

在过去几年中，AKKA & Modis 对从其网络到身份验证工具的所有内容进行了改造，“以在实体办公室或远程位置提供相同的体验，”Small 说。 “远程工作促使我们的客户重新配置他们的企业架构计划和战略。 EA 对于确保这些远程工作和协作工具具有可扩展性和安全性至关重要，”他说。 “这是我们在招聘和留住人才方面看到的关键差异化因素。”

Small 说，EA 还通过了解新员工在第一天需要哪些应用程序和服务并确保他们拥有访问权限，“在确保新员工能够尽快、轻松地入职”方面发挥着关键作用。他说，让新员工快速感受到工作效率对于留住他们至关重要。

Barnett 说“人员架构”是一种不断发展的 EA 形式，旨在了解外包、裁员和自动化等变化如何影响员工以及如何帮助他们适应。例如，近年来，网络工程师完成的大部分工作已经自动化。他说，了解这些变化如何影响他们，以及如何在新领域使用他们的技能，对于留住员工和最大限度地提高他们的生产力至关重要。

改进的产品和服务交付

跨行业，灵活的公司需要将其 IT 工作集中在客户最需要的产品和服务上，而不是为了自身的利益而实施技术。

Small 看到了将以前在独立团队中从事云或数据分析等技术工作的员工重新部署到“基于项目的 pod 以解决紧急需求”的趋势。企业架构是将这些单元粘合在一起的粘合剂，着眼于整体业务需求”并确保他们开发的产品或服务运行良好，他说。

在 Wells Fargo，EA 提供云参考架构，支持这家金融服务巨头迁移到云、敏捷软件开发，并提供更多新“产品”，例如指导首次求职者创建银行账户并获得他们的银行账户的应用程序。第一张信用卡，首席企业架构师 Manish Vipani 说。

EA 还帮助 Wells Fargo 集成面向客户的和后台应用程序，以跨渠道（如面对面、Web、电话和移动应用程序）创建更一致的体验。 Vipani 说，它的 EA 实践正在帮助它从点对点连接的“意大利面条式”架构转变为更多通过 API 连接的具有明确定义层的“千层面”类型架构。

例如，其数百个 EA 的工作帮助富国银行使用此类数据集成，通过将一些数据预填充到客户的应用程序中来实现房屋抵押在线申请流程的现代化。他说，类似的方法有助于将信用卡申请流程从平均 25 分钟缩短到 4 分钟。如果改进后的集成可以告诉信用卡应用程序客户在银行有直接存款，它可以对他们进行信用卡资格预审，并通过单击鼠标处理应用程序。

“我们通常希望快速推出产品，如果成功，就更大规模地推出，”他说。 “这需要了解所有通过 API 公开的系统，无论是核心银行平台还是财富管理。”

跟踪数据和 API

随着 Radicle 致力于更快地完成更多健康产品的虚拟试验并向客户证明其结果，“我们的软件平台需要对人员、参与者和用品进行编排，以使其具有可扩展性，”Borkin 说。

为了实现这一目标，它正在重新定义其衡量的 EA 组件，以了解例如哪些数据必须以何种格式存储，以便随着时间的推移对其进行研究。 “重要的是技术团队和进行试验的研究团队之间的沟通，”他说。 “作为一家公司，我们同意我们收集的关键数据及其组织方式。”

Radicle 还使用 EA 洞察力来确定要维护的数据库的数量和类型，以及何时应该通过点对点 API 交换数据，通常是在内部开发的服务或一次性集成之间，而不是通过公共服务层旨在随着时间的推移而扩展。

“由于我们正在建立一个多年的研究数据存储库，仅仅说‘我们有 API’是不够的，”他说。 “您可能不知道连接到新数据源或服务所需的所有 API，例如需要与研究存储库交互的数据规范化。” Radicle 使用 EA 来“确保构建此关键数据资产以扩展广度和深度，同时保持易于访问以发现新的健康见解。”

本文：https://jiagoushi.pro/five-areas-where-ea-matters-more-ever

今天的内容构成了名为“谁仍然对企业架构感兴趣？”系列的六个部分中的第六部分，也是最后一部分。在本系列中，我将就当今企业架构的足迹、企业架构师角色的潜在死亡、大型参与者（例如 The Open Group、AWS 或 Azure 的 TOGAF）以及EA 工具提供商的角色以及其他相关证书和市场上的发展。

在今天的第六部分中，我们从前面的部分中得出结论，并预测这对未来意味着什么。

无论您是在阅读本文还是在收听播客版本，请务必同时查看本系列的前五个部分！

谁仍然对企业架构感兴趣？ — 第 6 部分，共 6 部分

1.企业架构活动由不同的角色承担

EA 不再总是被称为 EA，但这种做法仍然高度相关。当今大多数为现代 EA 提供最佳实践的行业和思想领袖不再称自己为企业架构师。这就是为什么这种做法在今天被认为不那么重要的原因。

但是，有一些新的头衔和角色涵盖了企业架构方面，它们过去并没有成为传统企业架构模型的一部分。此外，企业架构活动通常由 IT 架构师负责，他们同时承担一些 IT 和一些企业职责。结果是企业架构和 IT 架构变得更加一致，有时由同一个角色来处理。

2. 新的企业架构管理框架

由于框架和方法的相关性和紧迫性增加，新的参与者进入了企业架构领域。

传统的、著名的企业架构组织的结构似乎太慢了，无法对数字化转型引发的破坏做出反应。

因此，新工具和技术的供应商，尤其是来自云领域的供应商，开发了他们自己的框架和方法来应对他们组织的多重新挑战。

3. 企业架构框架是推动成功数字化转型所必需的

数字化发展仍会引发定期中断和强劲增长（例如，新的云服务提供商和支持技术）。

因此，有许多新兴市场参与者提供了新的和多样化的解决方案，导致企业架构最佳实践分散。

因此，EA 针对不同的实践和部门以及不同的参与者，例如工具提供商、大型云提供商、敏捷框架、组织和社区。

企业架构的未来

虽然在许多领域，多样化的解决方案和竞争是有益的，但对于旨在提供标准和可比性的企业架构而言，情况并非如此。此外，多样化的市场解决方案可能会使 IT 和企业架构师的工作在未来更具挑战性，因为他们需要保持概览并完全一致。

因此，近年来发展起来的多样化格局可能会在涵盖企业架构的关键活动和目标的新（甚至旧）总称下巩固和协调。

这是“谁仍然对企业架构感兴趣”系列的结尾。如果您喜欢它或它对您有帮助，请喜欢，分享，并在下面的评论部分告诉我您的反馈！

原文：https://digitalroadmap-management.medium.com/why-enterprise-architectur…

本文：https://jiagoushi.pro/why-enterprise-architecture-activities-are-more-i…

你在开玩笑吗？

当涉及到想象力时，生活总是胜过小说。最近，一家大公司要求我展示再次实施 EA 功能的 ROI 证明。

这家公司过去曾聘请过架构师，但在他们选择大型企业资源规划 (ERP) 解决方案作为公司的运营信息系统 (IS) 主干时，他们就被淘汰了。这在某种程度上是有道理的：IS 是围绕所有 ERP 功能组织的。那么在这种情况下，企业架构师的需求是什么？此外，我们可能认为公司的 EA 架构师实际上是 ERP 编辑的。

没有企业架构师的公司会获得默认的企业架构。因此，在这种情况下，此默认 EA 由 ERP 编辑器的策略驱动。只要公司的战略以卓越的商品服务实施为基础，它就可以奏效，而且在这种情况下也奏效了。这意味着公司的竞争优势基于成本削减和运营生产力。再加上最终在 ERP 之外的孤立的 IS 中管理的一两个业务创新。

这家公司最近完成了一项业务和 IT 审查，发现 ERP 是部署新业务线和所需 IT 推动力的瓶颈。因此，他们决定在许多 IS 战略领域推翻 ERP。但是他们现在缺少企业架构师。项目和项目负责人现在有一个长期的习惯，主要是为了他们自己的需求而做架构，并且不想改变这种做法。因此，EA ROI 证明的问题是为了有机会获得一些高水平的赞助，以应对变革的运营阻力。

我的回答不是“你在开玩笑吗？”但听起来很像。我失去了这笔交易。

危险

想大点。快速失败。我尝试了几个不成功的想法。

• 第一个是：如今，信息系统是每个业务战略运营实施的核心。如果没有人来推动 IS 架构，你怎么能想象取得成功的战略成果？答案是：“到目前为止，我们已经没有架构师了，一切都很好。这个论点并不能证明 EA 的价值”。客观地，由于情况会改变，答案并不真正适用……但它是客户，我不能这么说。
• 第二个论点是关于迄今为止从 ERP 编辑器自己的 EA 中受益。既然 ERP 的使用打算减少为非战略性商品服务，那么 ERP 架构师将不得不被公司的架构师取代。相同的答案：项目负责人不会让架构师对他们的业务嗤之以鼻。
• 第三个论点：让我和 C 级的人谈谈，我相信他们知道 EA 的价值，并且会支持再次将其引入内部。没有反应。也许我的对话者尝试过但没有被倾听。或者很可能他们不敢尝试没有数字。

然后光来了。危险。 EA 的答案是什么？为什么又要 EA 回来？当你想到它时，这不是一个笑话：你确实想要 EA，为什么？

EA成本太高的想法是怎么来的？

越抽象的事物，就越难以将独家收益与它联系起来。所以 EA 投资回报率的回报部分肯定是难以阐述的。我们大概可以粗略计算出公司新业务战略部署的预期投资回报率。但是很难（委婉地说）隔离它的一部分，这要归功于企业级别的良好架构方法。即使使用不好的或默认的 EA 方法，我们仍然可以获得一些收益。并且，如果管理良好的 EA 实施，收益会更大，这一事实可能（委婉说法）永远不会被评估。

计算成本很容易（似乎是这样，但让我们从简单的角度来看）。企业架构的成本是多少？主要是花费时间的劳动力成本：架构工作、架构组合学、架构治理、架构支持和传播。最终还与架构工具相关的成本。此外，延迟上市时间的间接成本也可能被视为收入延迟过多（我们可以说安全工作流也是如此）。

即使使用默认 EA，也会发生这些成本！如果不做出架构决策，任何人都无法构建信息系统。问题是：我们是否想以一种有管理的方式组织这些决策？还是我们想让个人在每个决策点做出决定？考虑或不考虑其他地方做出的架构决策？在这种“默认”方式中，不会编译 EA 成本，因此我们看不到它们。

对 EA 的误解

EA 最大的错误当然是认为架构师必须做所有的架构工作。架构师是唯一能够使用架构材料来讲述“真相”的人，因为架构很复杂。

这种情况被称为象牙塔综合症。在这种情况下，架构师一起工作并生成仅供架构师使用和使用的架构文档。最终他们产生了一些转型影响分析：通常生产成本为 80% 的 20% 的部分。这些架构工件需要经常与“现实世界”保持一致。使用昂贵的工具。

总成本的 20% 的 80% 部分，对于其他任何人来说都足够了，要么由架构师或其他人生产，要么甚至不生产或部分生产。这一切都取决于利益相关者对架构问题的看法。碰巧的是，核心架构描述是在没有架构师负责的情况下做出的，并做出了相关的决定！

我们不想再去那里了。可以理解。这种没有重大影响的“无底井”成本来源是对 EA 不信任的主要原因。

如何让 EA 再次伟大？

让我们尝试以仅 20% 的 EA“大图”成本获得 80% 的 EA 收益。

这个想法是在战略/组织级别上重新控制架构决策。并避免让这些决策在本地子级别或全局元级别做出。

让我们来说明这个想法。
在进行任何重大战略转型之前，最好先解释一下我们想要做什么、为什么、如何等。企业架构如何在构想中发生？
让我们用 5W2H 方法来说明这一点：

• 什么？ ：我们将改变什么到IS组织（架构）？
• 为什么？ : 我们怎么会改变 IS 架构？
• 在哪里？ ：IS的哪一部分会受到关注？
• 什么时候？ : 有没有设想的路线图？
• 谁？ ： 什么构建组织将操作更改？ （以及如何在构建组织和 IS 构建块之间获得精益映射）
• 如何？ ：是否有任何 IT 推动者可以实现更轻松的更改？
• 多少？ ：与减少建筑债务相关的成本是多少？设置新的 IT 功能？

是的，这与 TOGAF 架构开发方法中的阶段 A：架构愿景非常相似。相似但不一样。在这里，我们不关注架构的架构，但我们希望将架构作为整体的一部分来关注。架构与任何其他考虑因素一样参与转换。

这里的想法是：让我们与大家分享架构愿景。就像我们对业务愿景、产品愿景、组织愿景所做的那样……

企业架构是业务需求、运营业务的 SI 产品以及人员和其他资源的组织之间的粘合剂，以帮助公司实现其下一个战略目标。

原文：https://medium.com/@vhanniet/the-return-on-investment-roi-of-enterprise…

本文：https://jiagoushi.pro/node/2177

有几个角色与企业架构以及团队/项目级别的架构相关。请记住，这些是角色，而不是职位。小型组织可能有一个人担任这些角色中的每一个，而大型组织可能有几十个细粒度的职位。请记住，上下文很重要。我们为 Disciplined Agile® (DA™) 企业架构定义了以下角色：

• 企业架构师 (EA)。企业架构师负责构想、沟通和发展组织的企业架构。企业架构解决了关键的企业方面——包括组织结构、业务流程和战略、价值流、数据和信息以及支持技术——以及它们如何组合在一起并随着时间的推移而发展。
• 首席企业架构师。首席企业架构师或首席 EA 领导组织内的企业架构团队。此人通常是具有额外领导职责的企业架构师。
• 架构所有者 (AO)。 AO 在架构/解决方案决策中指导团队，特别是解决方案交付团队。 AO 将与企业架构师密切合作，甚至可能同时担任这两个角色。 AO 是一个团队级别的角色，有时被称为敏捷解决方案架构师或简称为敏捷架构师。
• 首席架构师 (CAO)。 CAO 是项目级别的角色，领导整个项目的架构工作。 CAO 通常是具有领导职责的高级 AO。 CAO 与 EA 密切合作，也可能是 EA。
• 专业架构师。对于专注于企业架构特定方面的架构师来说，这是一个“元角色”。表 1 列出了您组织中可能存在的潜在专业架构师。

表 1. 专业架构师的类型。

原文：https://www.pmi.org/disciplined-agile/process/enterprise-architecture/e…

本文：

今天的内容构成了名为“2021 年谁仍然对企业架构感兴趣？”系列的六个部分中的第一个部分。在这个系列中，我提供了我的观点

• - 当今企业架构的足迹，
• - 企业架构师角色的潜在死亡，
• - 大玩家，例如 The Open Group、AWS 或 Azure 的 TOGAF，
• - 以及 EA 工具提供商的角色和
• - 市场上的其他相关证书和发展。

在今天的第一部分中，我分析了 Google Trends 上常见企业架构术语的搜索词 attention。我将重点介绍当今最重要的 EA 框架 TOGAF 和 Zachman 的起源，并分享我的求职结果。我推断企业架构可能是一种死法。

无论您是在阅读本文还是在收听播客版本，请务必尽快查看该系列的其他部分！

2021 年谁还对企业架构感兴趣？

– 第 1 部分，共 6 部分
似乎，尤其是在现代科技公司中，企业架构 (EA) 实践的重要性正在下降。一些组织甚至可能认为这是一种无关紧要的做法。在下文中，我们分析了这些意见的来源。在本系列的后面部分，我们将提供反对这种推理的论据并提供分析，这表明这并不是企业架构作为一种实践的终结。然而，企业架构将经历转变为一组经过调整的活动、新的优先事项和新的所需技能。

传统的企业架构术语、角色和框架变得无关紧要

对 EA 的关注度似乎在稳步下降：根据谷歌趋势摘录的图 1，主题集群“企业架构”的搜索请求数量自 2016 年以来下降了 50% 以上，自 2004 年以来下降了 75% 。此外，图 1 显示了 2004 年至 2021 年期间对“业务架构”、“应用程序生命周期管理”、“数据管理”和“技术管理”等相关 EA 术语的搜索请求的相对数量。所有随着时间的推移，他们的注意力逐渐减少。

图1

此外，与几十年前相比，EA 博客和网站也少了很多。由于缺乏更新，很多关于最佳实践的过时 EA 内容在搜索引擎中的排名仍然较高。

TOGAF 和 Zachman 已过时

进一步的证据来自最重要的行业标准框架，例如 TOGAF 和 Zachman。 TOGAF 于 1995 年首次发布。它由 The Open Group 的几家成员公司开发，包括 IBM 或 Oracle 等主要参与者。 TOGAF 标准每隔几年更新一次，最新版本是 2018 年 4 月的 9.2 版。虽然最新版本旨在更好地针对数字化转型这一主题，但整体内容并没有太大变化。此外，经过认证的从业者不需要在次要版本之间更新他们的认证，当前的主要版本于 2011 年上线。在持续数字中断的时代，十年前的内容不再完全相关。

第二个最重要的框架是 Zachman 框架。随着 1987 年的初始版本和 2011 年的最新主要版本，它与 TOGAF 具有相同的年龄。因此，我们可以说，最重要的企业架构框架在过去十年中没有收到任何重大更新，因此——至少部分地——已经过时了。

许多大型科技公司不寻找企业架构师

除了上述论点之外，还有一个额外的观察结果，这在许多不同的组织中都很常见：组织拥有的旧世界/遗留 IT 越多，组织中的企业架构师就越重要。同样，在拥有旧世界和新世界 IT 的组​​织中，企业架构师负责管理旧世界的架构。但是，它们对新世界IT的发展影响甚微；数字区。如果他们干涉（例如，试图调整事情），他们通常被视为减慢进程，并成为项目成功的障碍或威胁。尽管这肯定有例外，但有一个明确的模式是，很少或没有遗留 IT 的公司没有企业架构师的角色，也不为他们的组织寻找这样的职位。在 Netflix 或亚马逊寻找“企业架构师”的工作似乎证实了这一趋势。

这是否意味着企业架构已死？ 2021 年的企业架构是否还有相关性？它在当今的数字时代扮演什么角色？在本系列的下一部分中，我们将回答这些问题。

您喜欢“企业架构的相关性”系列的这一部分吗？你能确认观察和分析，还是你不同意？很高兴听到你的想法！

原文：https://digitalroadmap-management.medium.com/what-is-today-s-relevance-…

本文：https://jiagoushi.pro/what-todays-relevance-enterprise-architecture-pra…

EA 软件可以为您企业庞大的技术运营的内部运作带来秩序。 这是制图和编目的好处——以及关于真正魔力所在的一些注意事项。

企业架构旨在为企业 IT 的广阔领域及其蓬勃发展的机器和软件集合带来秩序，这是几十年前无法想象的聚宝盆。台式机、平板电脑、手机——一目了然的屏幕。这还不包括无屏幕设备，如传感器、响应“Alexa”的音频设备，以及所谓的物联网中的所有其他东西。

唉，数字丰富并不总是一份礼物。毕竟，这一切都伴随着责任。机器、算法、软件升级和科罗拉多农场似乎成倍增加，需要有人看管和照顾它们。

在其核心，企业架构 (EA) 工具以数据库表的形式维护资产的主列表，该数据库表对设备进行编目。然后它添加了一系列功能，以易于使用的方式显示此信息。魔力来自部署软件、用数据填充软件、然后使用它做出更明智决策的团队。

所有这些制表、策划和跟踪都值得吗？大惊小怪值得麻烦吗？以下是您的组织值得投资企业架构解决方案的六个原因——以及在依赖 EA 工具时需要牢记的一些问题。

秩序很好

任何事情都比运行未知软件的庞大计算机网络要好，这些计算机运行由可能不再为公司工作或不再为公司工作的未跟踪工人编写的未知软件。写在纸上的清单将是一个开始。电子表格会更好。企业架构工具远远超出列表。它们为世界增添了秩序，提供了大量关于通过您企业无穷无尽的硬件收集的大量比特的信息。

然而，重要的是要记住，工具不提供秩序。人们这样做。企业架构工具只是提供建立秩序的手段。想象一下，例如，一张纸条说在没有与客户获取团队交谈的情况下不要关闭服务器。如果该团队在 3 次重组前被分散，并且没有人更新该注释怎么办？

软件开发人员经常发现，当文档偏离代码时，文档可能会导致问题。突然间，人们在假设一件事，而代码却在做另一件事。企业架构工具仍然是解决方案，但它们并不神奇。他们承诺维护数据。它们只是您的团队带来秩序的途径。他们不会自己带来秩序。

企业架构打破孤岛

随着差异的增加，组织可能会遭受孤立。一个团队选择技术 A，而另一个团队选择 B。安装企业架构软件不会解决这些深刻的差异，但它会更容易发现这些差异。在企业架构工具中对企业资产进行编目的过程揭示了许多区别，这是建立某种统一性的第一步。中央数据库是变革的催化剂。

当然，仅仅因为 EA 工具可以发现不一致，并不意味着它们都应该得到解决。我们可能会直截了当地谴责那些拼凑出几乎无法通信的软件包集合的傻瓜，但这些差异通常提供了一点安全性和弹性。单一文化更容易受到攻击，更容易受到灾难的影响。影响一个角落的问题将影响所有角落。这并不是说不和谐的软件集合的精神杂音是令人愉快的或可取的。只是它有一些优点。

指标识别问题

商学院的教训很清楚：你无法管理你无法衡量的东西。 EA 软件带来了一系列工具，用于衡量数字领域的运作方式。现在有一种方法可以相互比较团队、部门和部门。 EA 可以发现落后的服务器、过载的数据库和负载过重的网络。

但请记住，指标会带来噪音。数据就在那里。它可以被聚合、清理并显示在一个光滑的仪表板上。但仅仅因为这些位可用并不意味着它们带来任何真正的洞察力。这些工具提供了有关企业资产的大量信息，但需要专业知识才能了解这些数字的含义。

自动化节省时间

许多 EA 工具都为它们能够连接到计算机网络并自动收集大量信息而感到自豪。我们已经达到了一个开发水平，已经通过 API 和调试工具提供了相当多的遥测。这一切都可以归结为一个有用的界面，这样我们就可以看到发生了什么。

当然，自动化很少是万无一失的。迈克尔克莱顿的小说侏罗纪公园的情节取决于计算机程序未能对岛上的恐龙进行准确的人口普查。它只被编程为跟踪它所知道的恐龙，因此它忽略了恐龙正在繁殖的事实。这种盲目性也是 EA 系统的危险。他们只能跟随集成到其中的计算机。

单一的事实来源至关重要

花费太多时间搜索正确的信息。企业架构工具充当节省时间的单一信息源。构建基础设施可能会很昂贵，但一旦运行，就很容易找到真相。

同时，重要的是要知道，尽管 EA 软件承诺提供单一事实来源，但很少存在单一事实来源。即使他们这样做了，他们也可能是错的，而且没有办法知道。只有一种意见，就没有共识，也没有分析的机会。

尽管如此，手电筒，无论多么微弱，总比在黑暗中摸索要好。与其纠结于软件如何无法完美地映射您的企业，不如放下这些犹豫，继续完成对您的企业交付的数据处理的聚宝盆进行编目和跟踪的艰巨任务。

原文：https://www.cio.com/article/191560/6-reasons-to-invest-in-enterprise-ar…

本文：https://jiagoushi.pro/node/2111

敏捷组织正变得越来越普遍，因为人们越来越欣赏他们的转型收益。 通过这一运动，我们正在协助出现一种新型的企业架构师，这些架构师在使他们的公司更加敏捷方面发挥着重要作用。 它需要重大的文化转变，企业架构师需要经常与组织内的不同利益相关者协作。

太多的企业架构师仍将自己限制在编写封闭的“解决方案架构定义文档”并躲避实际行动。然而，我们看到了一种新的趋势。越来越多的业务和企业架构团队正在参与并融入其组织的业务优先级战略规划、投资组合管理、路线图优化、产品管理、以客户为中心的计划、敏捷项目微调、更新和更现代的面向业务的 KPI 定义等.

简而言之，我们正在协助新一代企业架构师的出现，这些架构师在使他们的公司更加敏捷方面变得非常重要。

敏捷组织

敏捷组织正变得越来越普遍，因为人们越来越欣赏他们的转型收益。但要实现敏捷的运营模式很困难，尤其是对于成熟的和更传统的公司而言。 “敏捷组织之旅”一文很好地解释了成功的敏捷转型如何在其敏捷转型中共享共同元素：

“传统组织是围绕静态的、孤立的、结构化的层次结构构建的，而敏捷组织的特点是在快速学习和决策周期中运行的团队网络。传统组织将其治理机构置于最高层，决策权沿层级向下流动；相反，敏捷组织灌输一个共同目标，并使用新数据将决策权授予最接近信息的团队。敏捷组织可以将速度和适应性与稳定性和效率完美地结合起来。”

这种转变包括跨越两个广泛阶段的几个元素：

• Aspire、设计和试点
• 扩展和改进

企业架构师通常主要参与第一阶段。

在这个阶段，转型始于高层管理人员的战略理解和抱负（Aspire），制定蓝图以检测敏捷将如何提供价值（设计）并使用敏捷试点（Pilot）进行学习，通常通过提供至少在一种快速和迭代的方式，为组织提供足够的指示来继续测试其设计。

下面的图 1 更详细地描述了企业级的敏捷运营模型，包括五个维度：

• 目标和价值
• 结构
• 敏捷团队
• 骨干
• 制定路线图和项目

首先，“目标和价值”维度应包括明确的战略和可衡量的目标，解释可以在哪里创造价值以及组织如何与竞争对手区分开来。其次，敏捷运营模型的迭代“结构”不是根据经典的组织结构图交付的，而是通过围绕共同使命和可衡量目标分组的具有清晰报告线的几个团队来交付的。第三，需要识别和建立迭代的“敏捷团队”，确保每个团队都有明确的目标，并且他们已经定义了他们的最佳工作流程。第四，迭代的“主干”需要包括对基本流程、人员和技术的概述要求，以实现最大的敏捷性。第五，需要详细说明高层次的“路线图”，其中包含项目的积压清单，以及它们在哪些方面被优先考虑以立即进行下一步。

企业架构和敏捷组织

在“使用架构微调 SAFe”中，我展示了架构和敏捷团队之间的协调如何有助于交付成功的项目，尤其是针对 Scaled Agile Framework (SAFe)。它展示了企业架构师和敏捷团队应该如何停止在孤岛中工作。他们的方法是互补的，而不是冲突的。架构和敏捷团队之间的协调有助于交付符合公司战略的成功项目。

“站在 SAFe 方面：业务架构和敏捷如何结合在一起”，还表明：

“业务架构不会妨碍敏捷团队，而是与他们一起工作以帮助他们最好地专注和做好准备——这可以加快工作速度而不是减慢速度。而且，它确保团队的敏捷性和成功应用于业务的最高价值部分。”

上面的图 1 还更详细地描述了企业架构在企业敏捷运营模型的每个阶段的影响。

• 首先，在“目标和价值”期间，至少需要详细说明关键价值流。商业动机模型也将非常有助于确定战略、战术及其相应的目标和目的。至于商业模式画布，它通常是确定一个组织如何与竞争对手区分开来的最短路径。
• 其次，在“结构”阶段，关键价值流按具有共同使命的团队进行分组。识别每个关键价值流/阶段的启用和有问题的能力。需要确定拥有关键价值流支持能力的组织单位。
• 第三，企业架构师应该包括在“敏捷团队”中。他们应根据战略目标和目的，定义关键战略举措及其可衡量的成果。
• 第四，在“主干”阶段，企业架构师可以帮助定义需求并使用他们的业务架构模型元素微调业务流程。目标价值流/阶段的使能能力与其相关的应用程序和数据库相关联。
• 第五，企业架构师将敏捷的“路线图和项目”与战略计划联系起来，这些计划基于关键和目标价值流/阶段及其支持和问题能力。项目将优先考虑财务比率和风险因素。

企业架构的新生态系统

在敏捷企业中，企业架构师在数字化转型计划的规划、架构和交付过程中需要与许多不同类型的协作者合作。 正如“使用业务架构的数字化转型”中所解释的，五个步骤可以描述如何使用企业架构完成敏捷的数字化转型，如下图 2 所示。 这些步骤包括：

• 制定目标和战略
• 业务和企业架构
• 制定路线图
• 敏捷交付解决方案
• 衡量绩效

对于这些步骤中的每一个，企业架构师都需要与不同类型的内部和外部协作者进行交互。

• 在第一步“制定目标和战略”中，企业架构师需要收集公司目标和战略，以便在组织的较低级别将其传播为有意义的目标和策略。他们可能与 CXO、总部战略家、业务部门经理、业务经理和/或变革经理互动。一次有几个计划，企业架构师需要构建一个详细的业务和企业架构模型，以尽可能多地反映他们企业的当前状态以及他们期望的与预期计划相关的未来状态。
• 在第二阶段，企业架构师通常需要与至少其中一些利益相关者合作：客户/合作伙伴、主题专家、业务经理、变更经理、产品经理、营销人员、应用程序架构师、解决方案架构师、数据架构师、商业智能架构师、IT 架构师和/或软件架构师。在这个阶段，企业架构师的主要目标是找到需要解决的支持和有问题的能力，以优化关键的战略价值流并使期望的未来状态成为现实。
• 在第 3 步中，企业架构师应与财务分析师一起协助 CIO、项目经理和/或投资组合经理交付高级路线图，该路线图可以详细分解以供以后交付。
• 一旦选择了路线图，企业架构师还应该参与第 4 步“解决方案的敏捷交付”，通常是客户、合作伙伴、用户、敏捷专家、业务流程专家、业务分析师、软件开发人员、IT 架构师和/或软件建筑师。
• 最后，在第 5 步中，企业架构师可能会参与需要完成的测量，以检查目标、目标和结果是否已达到。

对于许多企业架构师来说，这需要重大的文化转变，他们的任务变得更加多样化，并且他们需要能够以更高的频率与组织内的外部和内部利益相关者进行协作和沟通。

它涉及了解如何与那些提供解决方案的人建立技术对话，并与那些需要战略变革的人进行业务对话，正如“业务和企业架构师的 7 个令人信服的品质”中所解释的那样。这是并且不会是容易的。为了保持相关性，越来越多的企业架构师需要适应、变得更加灵活并接受这一挑战。

原文：https://www.cio.com/article/220107/the-enterprise-architects-ecosystem-…

本文：https://jiagoushi.pro/node/2106

谁说 EA 对于转型来说太死板了？ 现代敏捷企业架构师从小处着手，快速交付价值，并与产品团队协作。

当 Adrian Jones 在 2018 年成为快速发展的诊断巨头 SYNLAB 的唯一企业架构师时，他知道他过去看到的传统的、官僚主义的 EA 方法行不通。

SYNLAB 企业架构组负责人 Jones 需要快速收集和分析足够的信息，以便在 40 个国家/地区的数百个站点和 20,000 多名员工中部署新系统，并将实验室测试等服务数字化，以使其客户更轻松访问。

在 15 个月内，琼斯认为传统 EA 流程所需时间的一半，来自 SYNLAB 的 EA 工作的见解正在帮助这家价值 26 亿欧元的公司更好地管理其应用程序和技术风险，并评估其技术债务（未决工作所需的成本维护其应用程序和 IT 基础设施）。琼斯说，EA 洞察力还帮助 SYNLAB 推出了新服务，例如 COVID 测试计划，以帮助欧洲足球联赛安全地重返赛场。

这是敏捷时代的企业架构。敏捷的 EA 从业者和供应商不是花费数月或数年时间对企业的技术和业务流程进行建模和编目以执行产品标准，而是寻求与开发“产品”（例如为员工或客户的应用程序）的团队更紧密地合作.他们试图快速交付价值，与产品团队密切合作，并制定架构原则，而不是允许产品开发人员使用的平台的僵化列表。

不是你父亲的 EA

EA 旨在识别、理解和最大化 IT 基础设施公司在从大型机到分布式计算的过程中创建的成本效益。这需要有关其 IT 基础架构及其支持的应用程序和业务流程的信息中央存储库。但是，根据批评者的说法，EA 往往专注于削减成本和控制创新，描述技术而不是利用它的业务流程。在这个企业必须更快地改变的时代，它的步伐常常成为转型的障碍。

Forrester Research 的一项调查发现，55% 的客户仍在使用旧形式的 EA，其中包括“将企业架构视为美化的资产管理，专注于成本控制，而不是为了员工、客户和业务合作伙伴的利益最大化 IT 能力。”

Gartner 的副总裁 Marcus Blosch 说，传统的 EA “非常关注技术架构”，“试图以命令控制模式控制一切。”传统的 EA “自找麻烦，很多用户还是这么想的”。

快速交付价值

Forrester 的首席分析师 Gordon Barnett 说，敏捷 EA 的一个原则是在提供见解或建议之前，不要通过收集有关组织的每一点信息来沸腾海洋。为了加快流程，敏捷 EA 从业者会参考“最小可行架构”或“刚好够用架构”来解决紧急业务问题，并根据需要对 EA 流程进行频繁更改。但是，Barnett 警告说，关键是要选择正确的元素来包含，以确保这样一个最小的架构不会限制其未来的用途。

对于严重依赖 SaaS 应用程序和云的组织，“最小可行架构有助于将分布式生态系统与技术标准和更具协作性的治理模型结合在一起”，即使它没有提供分布式资产的中央存储库，现在Gartner 的 Blosch 补充说，支持业务。

在 SYNLABS，Jones 开始专注于“我们在应用程序组合方面了解业务所需的关键信息”，并将他的搜索范围缩小到最多“关于应用程序的 20 条信息”。然后，他使用 Ardoq 的 EA 工具中的调查功能来捕获额外的数据，例如他们的业务所依赖的系统的成本和风险“让 [用户] 参与......立即给他们一些回报。”

他还利用这些调查让用户提供有关他们自己的技术和流程组合的信息，并使用 Ardoq 将这些数据输入到存储库中，即使在采访用户时也是如此。他说，这很快让用户“非常清楚地了解他们现有的架构，他们可以用它来模拟未来的期望状态”。

一个例子是检查一个国家的血液样本采集过程。 “我能够向他们回放，‘这就是我们对你们系统的理解，’”琼斯说。 “他们完全被那件事震惊了。这是他们第一次对整个过程有自上而下的看法。”

教练，不要强制

自从两年半前开始敏捷转型以来，咨询公司麦肯锡公司的 EA 与其说是“标准的执行者和度量和图表的维护者”，不如说是“推动者”和合作伙伴，跨敏捷团队专注于业务成果，企业架构总监 Michael Sioufas 说。

“我们不一定要以规定的语气说，‘团队必须这样做或那样做’。我们为他们提供工具（例如最佳实践框架）、指导并帮助他们尽可能地利用这些工具，”他说。

Forrester 的 Barnett 表示，EA 团队鼓励的原则可能反映了，例如，“一个组织是否在一个对价格非常敏感的市场中运营”，这意味着“我们将把成本置于我们所有架构决策的中心”。他说，对于不同的企业，质量可能是一个驱动原则。

这些原则还使产品组或业务部门能够选择最能满足其需求的工具。例如，Barnett 说，“对于大容量 [商业智能] 数据仓库，您可能应该使用 Oracle，但如果是小型办公室，则可能是 Excel 数据库。你可能有混合云，有人们应该何时使用每一个的标准。”

但是，如果“EA 不想授权交付团队，交付团队不想接受 EA 的指导”，这种努力可能会动摇。 EA 流程可以让他们获得更多的咨询角色。

Vale 的全球企业架构经理 Marcelo Menard 说，敏捷 EA 的另一个特点是“数字实验室”，在全球矿业公司 Vale，它作为机器人和物联网等领域的实验来源。这些实验室以及为满足特殊需求而开发的全球 IT 供应商网络是新 EA 方法的一部分，该方法帮助 Vale 的 EA 团队从“一种警察”转变为“推动创新的主要团队之一”，他说。

产品组的权力

Sioufas 说，麦肯锡的 EA 小组已经取消了传统的企业架构审查委员会，转而采用去中心化模型，该模型检查敏捷团队正在处理的史诗（用户故事的集合），专注于“哪里最需要帮助，哪里需要帮助”。架构产品团队内部有很多重叠或协同作用。”

使组织的 IT 资产清单保持最新可能是一项重大挑战，特别是对于由容器和 API 构建的基于云的可组合应用程序，这些应用程序仅在需要时使用。 Blosch 说，业务部门可以负责执行这些更新，并且可以根据该部门的需要自由决定要更新哪些组件。

工作中的敏捷 EA

Sioufas 是该咨询公司人力资源和财务部门的领域架构师，他说麦肯锡的分散式 EA 结构以及对各种工具和框架的使用“帮助我们对我们所从事的不同业务领域有更多的洞察力。”

当团队发现 API 安全性薄弱、进行系统整合或管理技术债务等问题时，他们会通过专家“架构群”来解决这些任务，这些专家聚集在一起就像敏捷团队应对挑战一样。 “我们将其视为一个小冲刺——一个快速的问题陈述：问题是什么，我们需要找哪些人，我们试图实现什么结果，以及我们如何衡量成功？”苏法斯说。

Vale 的 EA 实践使用 LeanIX 的企业架构管理来帮助它快速响应由 COVID 驱动的突然变化，例如启用对设备的远程检查和向远程工作的转变。 Menard 说，EA 帮助 Vale 确定了“我们需要改进的能力和流程”以及自动化所需的流程。他说，用 IT 资产和应用程序的“单一事实来源”取代以前由各个业务线维护的孤立的架构信息存储库，有助于 Vale 避免重复并确定 IT 项目的优先级。

支持者说，无论过去有什么缺点，EA 都不会消失，因为它不能。无论组织多么敏捷，它都有一个以硬件、软件和工作流形式驱动业务的企业架构。通过采用敏捷的 EA 原则，EA 从业者可以快速而清晰地跟踪、描述和推荐对该架构的更改，以使其适应不断变化的业务需求。

原文：https://www.cio.com/article/302381/enterprise-architecture-in-the-agile…

本文：https://jiagoushi.pro/node/2114

今天的内容构成了名为“2021 年谁仍然对企业架构感兴趣？”系列的六个部分中的第二部分。在本系列中，我将就当今企业架构的足迹、企业架构师角色的潜在死亡、大型参与者（例如 The Open Group、AWS 或 Azure 的 TOGAF）以及EA 工具提供商的角色以及其他相关证书和市场上的发展。

在今天的第二部分中，我将深入了解第一部分的 Google 趋势分析，并对 The Open Group 的认证环境进行更深入的调查。两者都证实，尽管许多企业架构术语变得不那么重要，但实际内容仍然是最新的。

无论您是在阅读这篇文章还是在收听我网站上的播客版本，请务必尽快查看该系列的其他部分！

2021 年谁还对企业架构感兴趣？

– 第 2 部分，共 6 部分
本系列的第一部分以一些关于 EA 是否已死的问题结束——基于几个不同的发现。第二部分反对这种观点。

一个主要论点来自谷歌趋势的结果，该结果显示对一些关键 EA 搜索词的兴趣明显下降。将这一点放在上下文中，重要的是要了解谷歌搜索已经从一般术语转移。架构层的一般管理就是此类通用术语的一个示例。如今，人们对企业和 IT 架构的更具体的主题和概念感兴趣。

对特定企业架构术语的高需求

图 2 再次以蓝色显示了“企业架构”一词的搜索请求数量。这一次，它与术语“主数据”、“规模化敏捷框架”、“云原生计算基础”和“微服务”进行了比较。虽然这些关键词显然也与 EA 领域相关，但它们显示出过去几年搜索量的强劲增长。

有趣的是，子主题越具体，它们的表现就越普遍。例如，作为应用程序环境子集的“微服务”具有更高的搜索量。此外，作为数据管理子集的“主数据”总体上优于“企业架构”的搜索量。

换句话说，来自 Google 趋势的见解表明：通用 EA 术语的兴趣降低，而更具体的搜索术语——也是 EA 的核心——兴趣增加。

新的 TOGAF 战略

第一部分的第二个主要论点是 TOGAF 标准的更新不足以回答数字时代的组织所面临的问题。

令人惊讶的是，降低 TOGAF 的重要性甚至可能是 The Open Group 战略的一部分。在这样做的过程中，他们为加强新开发产品和指南的市场占有率留下了空间。示例包括数字从业者指南、TOGAF 业务架构指南和系列指南。

此外，The Open Group 还建立了几个新证书。其中一些涵盖了新主题，但其中一些还涵盖了人们期望成为 TOGAF 标准的一部分。将此类内容从 TOGAF 标准中剔除表明，The Open Group 的战略是实现认证多样化，而不是仅仅关注 TOGAF。

在极端情况下，它也可能意味着“TOGAF”一词作为认证可能会慢慢消失。同时，内容将转向更多和新的认证，这些认证听起来现代且更合适。然而，TOGAF 标准将不再收到显着的更新。

如果您想了解更多相关信息，请务必查看下面提供的我的其他文章的链接。

另外，非常感谢您对本系列第一部分的积极反馈和评论。你同意还是不同意第二部分的主要论点？很高兴在下面的评论部分继续讨论！

原文：https://digitalroadmap-management.medium.com/new-enterprise-architectur…

本文：https://jiagoushi.pro/new-enterprise-architecture-terms-and-certificate…

领先的 CIO 正在构建“刚刚好”的企业架构，以平衡速度与长期战略洞察力，以实现更好的业务价值。

在 Vault Health，首席技术官 Steve Shi 开始企业架构 (EA) 工作，他对整个 IT、应用程序、系统和数据基础架构进行了现场调查，但将其限制在两周内，并针对每个功能进行一小时的采访。

Shi 说，客户，无论是员工还是为产品或服务付费的人，都必须“喜欢”这种最低可行的 EA 方法的结果。 “如果你没有得到客户的认可，你就会失去动力，如果你失去动力，在最小可行的发布之后继续迭代就更难了，”他说。

像许多 IT 领导者一样，施正试图在未使用的复杂架构研究和缺乏足够范围和深度以提供持久价值的简陋 EA 报告之间取得平衡。找到这种平衡需要紧贴业务需求，削减繁重的工作，适当地确定项目范围，并设置和执行正确的架构标准和原则。以下是熟悉该流程的 CIO 推荐的五个步骤。

贴近业务

与业务利益相关者保持密切沟通是了解最小可行企业架构在哪里可以最好地帮助业务并随着业务需求的变化为持续的 EA 评估提供资金的唯一途径。

在 Carrier Global Corp.，CIO Joe Schulz 通过业务指标来衡量 EA 的成功，例如员工生产力如何受到应用程序质量或服务中断的影响。

Schulz 说：“我们不会将企业架构视为一群看门人，他们在本质上对某件事情应该如何工作有更多的理论性。”他使用 EA 工具 LeanIX 生成的报告和见解来描述生态系统的互连性以及整个产品组合的系统功能，以识别冗余或差距。这使得智能建筑和冷链解决方案的全球供应商能够“使许多决策民主化……（以）在我们的组织中发挥所有最佳思维和投资能力。”

破产技术和服务公司 Stretto 的首席技术官 George Tsounis 建议使用 EA 来“建立信任和透明度”，方法是告知业务领导者当前的 IT 支出以及平台与业务战略不一致的领域。他说，这使得未来与 EA 相关的对话“比企业架构师在孤岛中工作并且没有这种关系要容易得多”。

修剪繁文缛节

冗长的问卷调查和模板驱动的访谈是 EA 工作中常见但通常不受欢迎的一部分。最低可行的 EA 从业者建议消除任何不能提供基本信息并允许用户反馈的问题。

云超大规模企业 Amazon Web Services 的企业战略总监 Gregor Hohpe 建议从“重量级、主要是单向”的 EA 流程转变为与业务用户进行更简单、更快和迭代的对话。

在金融服务公司 State Street，全球首席架构师 Aman Thind 试图通过只提出精确且相关的问题而不是 EA 模板中的所有问题来简化 EA 流程。他说，专注于最重要的问题可以将架构审查和提交所需的时间减少至少一半，并使流程更加有效。例如，SaaS 应用程序用来提供用户界面的框架不如确定用户如何与其交互的身份和访问管理程序重要。

除了使用自动合规检查和自助服务平台外，Hohpe 还建议消除“大量被忽略的标准列表”，召开审查会议，所有文件都根据各自团队的首选结果进行逆向工程，“调整”会议增值主题，以及“从从未用于决策的重量级 EA 工具生成巨大的挂毯”。

在数字医疗保健公司 Vault，Shi 发现应用程序可观察性工具 New Relic 通过提供对整个架构的即时可见性，在加速 EA 工作方面很有价值。

 他还使用新的术语和流程来避免常见的减速，并让人们意识到他的新颖方法。一个例子是“网站报告”，它要求用户设想最终的 EA 产品。这有助于定义关键要求，例如应用程序必须支持的事务数量和流程类型，“来自客户端并向后工作”。 Shi 没有使用要求用户预先就关键技术决策达成一致的“一次性完成”流程，而是要求他们确认或修改“开发假设”，例如系统每天必须支持的数据库调用数量。他说，这种方法可以加快就数据库等组件的选择达成一致。

在应用程序推出期间，Shi 避免使用通用项目计划，而是采用他所谓的“特定宏排序计划”，即围绕里程碑（如 alpha 和 beta 测试及其相关的验证里程碑）构建的步骤。这为部署的每个阶段定义了业务方面的成功，例如收入或用户采用率以及从降低持续支持成本的支持流程中吸取的经验教训。他说，这也提醒每个人，“在我们知道架构已经交付了可衡量的客户价值之前，项目不会结束。”

范围正确

在一个最小可行的 EA 项目中承担太多，在完成之前它就会过时，交付结果太晚，无法满足并从商业领袖那里获得未来的资金。将其缩小太多，将无法提供充分利用 IT 投资所需的技术和业务的全面视图。达到适当的平衡通常需要专注于业务中的一个应用程序或痛点，或者由于新的业务或监管需求而导致需求快速变化的领域。

Gartner Inc. 副首席分析师 Nolan Hart 将适当的 EA 范围称为“最少数量的可交付成果，例如观点、参考模型和设计模式，有助于确保及时、合规地交付产品和解决方案。”他建议，与其花太多时间了解当前架构，不如“首先了解你想要的结果”。他说，“永远、永远、永远地迷失记录你当前功能失调的架构”是没有价值的。

Shi 建议最小可行的 EA 考虑“从用户界面到将系统链接到数据架构的 API 的所有内容，而不是单个孤立的组件或服务。”他说，提议的架构还必须能够在生产规模上进行测试，并且能够处理与它所取代的系统相同的峰值需求。

适当的范围也适用于 EA 组织。 Carrier 不是专门的 EA 团队，而是为 CRM、现场服务、ERP、分析和数字工厂功能等关键需求创建了卓越中心。 Schulz 说，这些中心提供了核心组件的简化基础，使其能够快速创新，而无需进行 EA 练习来评估每个业务部门的单独平台。

如果企业中的一个小组对最小可行的 EA 项目不感兴趣，“还有很多其他人会花时间，”Hart 说。将该需求与 EA 团队的技能相匹配，以确定“您可以提供的三到五种服务，以用最小可行的方法交付这些业务成果”。

制定和执行标准

Tsounis 说，实施设计原则以及关注业务需求有助于缩短“关于哪种解决方案最佳的哲学争论”。他鼓励的原则包括“始终尝试创建尽可能简单的解决方案，不要过度设计，允许在整个组织中最大限度地重用，在构建新东西之前利用已建立的架构设计模式以及基于云的服务。”

Thind 说，网络安全、数据治理、生产管理和部署最佳实践等领域的参考架构和标准提供了“现成的剧本”，可以有效地构建健壮、合规和弹性的可组合应用程序。此类架构由“定义非常明确……在 API、可扩展性和互操作方式方面”的微服务构建，允许企业在不影响任何其他微服务的情况下替换任何微服务，从而创建面向未来的设计。

Hohpe 说，一些标准扼杀了创新，而另一些则促进了创新。例如，统一接口对于创建易于适应的架构至关重要。然而，过于严格的标准会导致糟糕的技术选择。他记得有一个应用程序团队选择 XML 作为组件接口而不是更快的通信协议。当被问及原因时，该团队回答说架构团队需要它，显然没有考虑 XML 解析对应用程序性能的不利影响。

从某个地方开始

如果不出意外，Thind 说，任命一名“......首席架构师，一名高管评估整体标准、整体治理、整体平台和应用程序设计的整体纪律。仅仅担任这个职位就表明了架构对整个公司的重要性，并灌输了我们创建高效和创新 IT 组织所需的正确行为。”

开始一个最小可行的企业架构可以从简单地“盘点”开始，Thind 说，识别超支，例如“为什么我们有六个不同的应用程序用于相同的流程，五个不同的合同（用于）相同的 BI 工具，多个市场数据合同范围相同，24×7 Hadoop 集群用于月度报告，等等。”但即使是这种最低限度的可行努力也能带来巨大的好处。 “只要确保将正确的工具用于正确的工作，并且围绕它们的使用进行标准化和最佳实践，就可以对底线产生相当大的影响，并减少技术债务，减少支持需求，并允许更快的创新，”他说。

原文：https://www.cio.com/article/307187/5-steps-to-minimum-viable-enterprise…

本文：https://jiagoushi.pro/node/2103

颠覆性时代需要有弹性、前瞻性的企业架构。 不要让错误的框架破坏您的组织实现当前和未来目标的能力。

企业架构为成功的业务 IT 计划奠定了基础。如果设计和实施得当，企业架构将帮助业务领导者实现他们的目标，使组织变得更具响应性、效率和竞争力。

不幸的是，仅仅几个常见的错误就会使企业架构无法满足其设计者的预期目标。事实上，随着时间的推移，有缺陷的企业架构可能会将企业引向完全错误的方向。

在开发或更新您的企业架构时，请退后一步，确保它没有落入以下七个陷阱中的任何一个。

1. EA 工作与业务需求不一致

企业领导者可能会设计一个连贯、详细的架构，但除非它专注于现实世界的业务需求，否则它不会在长期内取得成功。

在计划开始之前，通信基础设施服务提供商 Zayo 的首席信息官 Ginna Raahauge 建议收集企业最具影响力的用例，以对现有企业架构进行压力测试，以发现潜在的漏洞。她建议，确保用例是相关的。 “如果您遇到订单准确性方面的挑战，[例如]，请务必考虑导致前端和后端出现这种情况的原因，以及架构的变化如何解决这个问题。”

Raahauge 认为企业架构永远不会真正完成。 “它是活生生的，”她说。 Raahauge 建议至少每五年重新审视一次企业架构。 “随着技术的发展速度越来越快，我们需要能够在五年的技术变革中幸存下来，”她解释道。

2. 不采取客户至上的方法

商业和 IT 咨询公司 Capgemini 的副总裁 Phillip Hattingh 表示，在设计企业架构时，将设计计划与以客户为中心的方法保持一致非常重要。他说，应在整个设计过程中启用以客户为中心的目标和结果 KPI，促进真正的全渠道客户旅程，解决数字和物理相互作用。 “设计将如何实现组织的预期结果应该是明确的，并且可以很好地沟通，以支持成功的转型。”

以客户为中心的企业架构设计方法标志着对传统以产品为中心的模型的重大改变。 “客户至上的方法将挑战传统模式，并有可能导致未来的运营模式发生变化，”Hattingh 指出。 “如果不采用以客户为中心的设计，组织也可能会失去市场竞争力。”

3. 忽视集中核心目标和能力

无法集中核心业务目标和能力的企业架构注定会产生或保留孤岛。

Adobe 前首席企业数字政府解决方案技术总监乔纳森·贝内特警告说：“当不同的办公室和部门遇到相同的挑战并部署经常重叠的解决方案时，他们会陷入冗余、低效的系统中，从而阻碍实现业务目标的进展。”美国农业部建筑师。 “此外，一旦工作流被孤立，实施任何企业架构都会变得越来越困难。”

Benett 说，在担任政府机构企业架构师期间，他目睹了孤岛的破坏性影响。 “拥有预算和人力资本来解决当前问题的办公室将开发自己的应用程序和方法，而不是构建具有多种用途并满足跨机构需求的应用程序的平台，”他说。 “当办公室和部门分开工作时，他们倾向于反对精简……因为他们缺乏对整体业务目标的好处的可见性。”

拆除孤立的企业架构的一种有效方法是邀请代表主要业务功能的团队对他们所有的数字工具进行分类，包括应用程序、网站和劳动力管理程序。然后包括企业范围的流程和策略。 Benett 说，一旦创建了这个包罗万象的目录，就可以识别并建立差距和优势。 “从那里，能力驱动的业务架构可以开始形成，”他指出。

4. 将技术置于灵活性和业务目标之前

医疗数据和软件公司 Arcadia 的首席技术官 Jonathan Cook 表示，在开发企业架构时，很容易陷入以技术为中心的世界观，而忽略了商业价值模型。 “业务需求在不断变化，作为技术领导者和专业人士，我们需要支持、支持和加速这种变化。”

当被以技术为中心的前景蒙蔽或束缚时，企业领导者可能会发现自己陷入了争论各种技术方法的优越性，而不是专注于如何支持当前和未来的业务需求。 “如果我们不能提供灵活、有弹性的架构，我们可能会阻碍我们的组织有效竞争，”库克警告说。 “在这场大流行的过去 18 个月中，我们看到能够迅速适应不断变化的市场条件的企业能够生存甚至蓬勃发展。”

5. 困在当下

在没有预见未来增长需求的情况下开发的企业架构可能最终会失败。保险经纪公司 World Insurance 的首席信息官/首席信息安全官 Liz Tluchowski 说：“如果没有路线图，您将遇到创造效率的限制，以及支持业务目标的限制。” “当你发现你所构建的东西不能满足企业的运营需求时，你还将面临重新发明轮子的额外费用。”

Tluchowski 建议在构建任何随着企业发展和/或业务需求变化而可能需要可扩展性的系统时保持开放的心态。 “使用以其开放式架构而闻名的平台和服务，因为技术永远在变化，即使您制定了计划，也有很多不可预测的事情。”

6. 安全漏洞

随着网络威胁形势的发展，企业架构在过去几年中被迫改变。网络安全技术公司 Deep Instinct 的网络安全倡导主管 Chuck Everette 说：“在过去，安全是一种附加或事后的想法。 “安全性现在是企业架构和设计的核心和前沿，”他指出。 “其他一切都建立在它之上或周围。”

哈里斯堡科技大学网络安全管理研究生项目的负责人 Bruce Young 警告说，在企业架构设计阶段开始时不包括安全是一个危险的错误，因为系统、应用程序和数据可能会受到威胁。 “网络威胁不断增加，对组织的成功网络攻击每天都在发生，因此必须从设计阶段开始将安全纳入企业架构流程。”

Everette 说，基本的安全考虑必须在设计和规划阶段以及最终签核前的测试和验证中进行，他建议在企业架构开发中采用安全设计方法。 “Security-by-design 根据业务风险、价值以及违规和漏洞的影响强制执行设计的优先级。”

7. 追求完美

大多数才华横溢的人，包括 IT 和业务人员，都希望构建完美的东西。虽然完美可能是一个令人钦佩的目标，但在开发企业架构时，这并不是一个特别好的追求，尤其是在面向未来的架构或规模化构建时。

云计算服务提供商 Fastly 的工程副总裁 Laura Thomson 解释说：“这当然很重要，但过度旋转会导致大量问题，主要是各种过度构建和过度架构。”

汤姆森警告说，为企业构建管理层希望在五年内拥有的完美架构将导致复杂性和成本大幅增加。 “它推迟了交付期限，使系统构建速度变慢，更容易出错和中断，并推高了成本。”

Thomson 建议瞄准一个只是好的架构，而不是完美的架构。 “完美的系统并不存在，”她说。获得 80% 的短期解决方案，为企业带来价值。 “你可以而且应该迭代改进，”汤姆森补充道。

本文:https://jiagoushi.pro/node/2110

企业架构是组织标准化和组织IT基础架构以符合业务目标的过程。这些战略支持数字化转型、IT增长和IT现代化。

企业架构定义

企业架构（EA）是分析、设计、规划和实施企业分析以成功执行业务战略的实践。EA帮助组织构建IT项目和策略，以实现期望的业务结果，在快速变化面前保持敏捷和弹性，并使用架构原则和实践（也称为企业架构规划（EAP））来掌握行业趋势和中断。

现代EA战略现在将这一理念扩展到整个企业，而不仅仅是IT，以确保企业与数字化转型战略和技术增长保持一致。EA对于正在进行数字化转型的大型企业尤其有用，因为它专注于将遗留流程和应用程序结合在一起，以形成更无缝的环境。

企业架构目标

EA以组织的业务需求为指导——它有助于规划信息、业务和技术如何一起流动。这已经成为那些试图跟上云、物联网、机器学习等新技术以及其他推动数字化转型的新兴趋势的企业的优先事项。

根据EABOK，该过程是由“从所有者、设计师和建设者的角度对整个企业进行全面描述”驱动的。与其他框架不同，EA不包含正式的文档结构；相反，它旨在为企业提供更全面的视角。

EA的另一个主要优先事项是敏捷性，确保您的EA战略高度关注敏捷性和敏捷采用。有了可靠的EA战略，公司可以更好地应对复杂和快速变化，甚至可以让您的组织在动荡时期茁壮成长。在最近的Bizzdesign调查中，EA成熟度排名前四分之一的组织报告组织敏捷性的可能性要高出三倍，这在过去几年的新冠肺炎疫情中至关重要。只有20%的受访者表示，他们的EA计划允许更快的创新和更快的上市时间，而只有6%的受访者声称企业架构师被纳入敏捷团队，并有权影响技术决策。

一个好的EA战略考虑业务流程、组织结构、敏捷性、信息系统和技术方面的最新创新。它还将包括业务流程的标准语言和最佳实践，包括分析可以在整个组织中集成或消除哪些流程。任何好的EA战略的目标都是提高业务信息的效率、及时性和可靠性。当然，要实施任何EA战略，您还需要确保获得其他高管和利益相关者的支持。

然而，EA及其目标在不断发展。根据Bizdesign对1000多名企业架构师和IT业务领导者的调查，2022年提高EA影响的首要任务包括改善EA对业务价值的沟通（56%）以及改进EA流程的开发和采用（50%）。其他优先事项包括提供更多的战略见解（41%），从高级管理层获得更积极的支持（33%），以及投资额外的EA资源、培训和认证（32%）。

企业架构的好处

企业架构有几个好处，包括弹性和适应性、管理供应链中断、员工招聘和保留、改进产品和服务交付以及跟踪数据和API。EA可以为重新设计和重组提供支持，特别是在重大组织变更、合并或收购期间。通过标准化和整合流程以提高一致性，这也有助于为组织带来更多的纪律。

Bizdesigns询问了受访者，他们的EA计划目前提供了哪些IT好处，最高的回答是改进了IT投资决策。其他好处包括通过API和云改进服务导向、合理化和成本更低的应用程序组合、降低不支持技术的风险和成本、改进信息管理和安全性、重用现有IT资产的解决方案、更好的性能和弹性、更快更成功的实施和更新以及更好的自动化。

在业务效益方面，受访者列举了能力与战略、业务投资决策、合规性和风险管理、业务流程、职能之间的协作、业务洞察力、业务敏捷性和连续性以及更快的上市和创新时间的一致性方面的改进。与EA成熟度落后的公司相比，领先于EA成熟度的公司更有可能从公司的EA战略中获得这些好处。

EA还用于系统开发、IT管理和决策以及IT风险管理，以消除错误、系统故障和安全漏洞。它还可以帮助企业导航复杂的It结构，或使其他业务部门更容易访问It。

根据CompTIA，EAP的好处包括：

• 允许IT部门和业务部门之间更开放的协作
• 赋予企业优先投资的能力
• 更容易根据长期目标评估现有架构
• 建立评估和采购技术的流程
• 为IT以外的所有业务部门提供IT架构的全面视图
• 提供基准框架，将结果与其他组织或标准进行比较

企业架构方法

企业架构作为一个框架可能显得模糊，因为它旨在解决整个组织，而不是单个需求、问题或业务单元。因此，根据CompTIA的说法，已经发展了几个更具体的框架来帮助公司有效地实施和跟踪EAP，包括以下四种主要的EA方法：

• 开放组架构框架（TOGAF）：TOGAF提供了设计、规划、实施和管理企业IT架构的原则。TOGAF框架帮助企业创建标准化的EA方法，包括通用词汇、推荐标准、合规方法、建议的工具和软件以及定义最佳实践的方法。TOGAF框架作为一种企业架构框架广受欢迎，据The Open Group称，它已被全球80%以上的领先企业采用。
• Zachman企业架构框架：Zachman框架以企业架构的创始人之一命名，是另一种流行的EA方法。根据CompTIA的说法，它被更好地理解为“分类法”，它跨越了六个架构焦点和六个主要利益相关者，以帮助标准化和定义IT架构组件和输出。
• 联邦企业架构框架（FEAF）：FEAF于1996年引入，作为对克林格·科恩法案的回应，该法案在联邦机构中引入了IT有效性授权。它是为美国政府设计的，但也可以应用于希望使用该框架的私人公司。
• 高德纳：2005年收购Meta Group后，高德纳建立了EAP的最佳实践，并将其应用于公司的一般咨询实践。虽然它不是一个单独的框架，但CompTIA认为它是一种“实用”的方法，它专注于业务成果，“很少有明确的步骤或组件”

其他EA方法包括欧洲航天局架构框架（ESAAF）、国防部架构框架（MODAF）和SAP企业架构框架等。这些框架专门针对单个行业或产品，与上面列出的更广泛的EA方法相比，它们更多地针对利基市场。

企业架构师角色

企业架构师通常向CIO或其他IT经理报告。他们负责分析业务结构和流程，以确保它们与业务目标高效一致。作为一名企业架构师，您还将负责确保这些结构和流程是灵活和持久的，以便它们能够快速适应并经受住重大变化。

根据PayScale的数据，这是一个利润丰厚的职位，据报道平均年薪为137900美元，年薪范围为97000至201000美元。企业架构师通常继续担任首席技术官、软件工程或开发总监或首席信息官。

要想成为一名企业架构师，你需要计算机科学、信息技术或相关领域的本科学位，以及至少10年的IT或相关领域经验。您还需要使用计算机系统、硬盘驱动器、大型机和其他架构技术的实践经验。企业架构师需要一些软技能才能成功，包括沟通、解决问题、批判性思维、领导力和团队合作。

根据PayScale，IT企业架构师最常见的硬技能包括：

• Microsoft SharePoint Server
• Artificial intelligence (AI)
• Microsoft Azure
• Data warehouse
• Business intelligence
• Data modeling
• Strategy development
• Enterprise solutions
• Enterprise application integration
• Software architecture

有关更多信息，请参阅“成功企业架构的7个特点”

企业架构工具和软件

Microsoft Excel和PowerPoint是您将用于企业架构规划的两个最基本的工具。然而，还有其他第三方工具和软件套件可以帮助您为业务创建高级EA策略。

有很多方法可以将EA工具集成到您的组织中，以便它们支持业务中的其他系统和流程。在Bizdesign调查中，受访者被问及哪些系统和内容类型被集成到公司的EA管理工具和业务流程模型（59%）、数据建模系统（49%）、项目管理工具（35%）、ITSM工具（31%）和配置管理平台（31%）中。

根据Gartner Peer Insights的数据，以下是目前市场上流行的一些选项：

• Orbus Software
• Sparx Systems
• Software AG
• Avolution
• Mega
• Erwin
• BiZZdesign
• Planview
• SAP
• BOC Group

有关详细信息，请参阅“顶级企业架构工具”

企业架构认证

有几个证书可以证明你的EA技能，包括更具体的证书，这些证书侧重于云和安全架构等技能。

企业架构认证包括：

• TOGAF 9 Certification
• The Open group Certified Architect (Open CA)
• AWS Certified Solution Architect
• Salesforce Certified Technical Architect (CTA)
• Axelos ITIL Master certification
• Microsoft Certified: Azure Solutions Architect Expert
• Google Professional Cloud Architect
• Virtualization Council Master Infrastructure Architect certification
• CISSP Information Systems Security Architecture Professional (ISSAP)
• Dell EMC Cloud architect training and certification
• Red Hat Certified Architect
• EC Council Certified Network Defense Architect (CNDA)

See also: 12 certifications for enterprise architects.

企业架构的起源

根据《企业架构知识书》（EABOK），EA始于20世纪60年代，诞生于“杜威·沃克教授关于业务系统规划（BSP）的各种架构手稿”。沃克的学生之一约翰·扎克曼（John Zachmann）帮助将这些文档制定为EA的更结构化格式。这段时间，两人都曾为IBM工作，扎克曼于1987年在《IBM系统杂志》上发表了该框架。

EA框架是对商业技术增长的回应，尤其是在20世纪80年代，当时计算机系统刚刚在工作场所占据主导地位。公司很快意识到，他们需要一个计划和长期战略来支持技术的快速增长，这一点在今天仍然是正确的。

组织视图

什么是组织视图？

组织视图用于描述组织单元的组织结构，例如企业、公司、部门，甚至公司网络。通常，结构以嵌套的方式呈现。然而，像传统的组织结构图一样呈现并不少见。组织视图通常用于确定组织单位的能力和职责。

下表详细介绍了组织观点。

组织视点示例

下图显示了在Organization视点下绘制的架构图。

业务流程合作视图

什么是业务过程协作视图?

业务流程合作视图用于对企业的主要业务流程流建模。它可用于创建业务流程的高级设计，为运营经理提供对其依赖关系的洞察。您还可以用业务功能对业务流程的映射建模，以及如何通过业务流程实现业务服务。

下表更详细地描述了业务流程协作观点。

业务流程协作观点示例

下图显示了在业务流程合作视角下绘制的Archimate图。

原文：https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/

本文：http://jiagoushi.pro/node/1310

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

基本视图

ArchiMate基本视图包括ArchiMate元素和ArchiMate三个主要层的概念:业务、应用程序和技术。下面列出的是ArchiMate 3.1示例视点表，分为四类，指明了它们所涵盖的方向和范围:

• 组合:定义元素的内部组合和聚合的视图。
• 支持:您所查看的元素被其他元素所支持的视图。通常从一层往上到上一层。
• 合作:朝向相互合作的对等元素。通常跨不同的方面。
• 实现:您正在查看实现其他元素的元素的视图。通常从一层向下到下一层。

组成视图

支持视图:

合作视图:

实现视图:

产品视图

什么是产品视图?

产品视图关注的是产品能为顾客提供的价值。它根据构成(业务、应用或技术)服务以及相关的合同或其他协议显示了产品构成。您还可以显示提供该产品的接口，以及与该产品相关的事件。产品视角通常用于为使用产品所涉及的服务建模，产品视角可以是现有服务或需要创建的新服务的组合。

下表更详细地描述了产品视图。

产品的视图的例子

下图显示了在产品视角下绘制的Archimate图。

应用合作的视图

什么是应用程序合作视图?

应用程序合作视角展示了应用程序组件之间的信息流，以及组件提供和要求的服务。人们使用这个视点来创建应用程序前景的概览。此外，这个视图还可以用于建模服务之间的协作，这些服务共同支持业务流程的执行。

下表更详细地描述了应用程序合作视图。

应用程序合作视图示例

下图显示了在应用程序合作视角下绘制的原型图。

原文：https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/

本文：http://jiagoushi.pro/node/1311

全网同号：【首席架构师智库】

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

基本视图

ArchiMate基本视图包括ArchiMate元素和ArchiMate三个主要层的概念:业务、应用程序和技术。下面列出的是ArchiMate 3.1示例视点表，分为四类，指明了它们所涵盖的方向和范围:

• 组合:定义元素的内部组合和聚合的视图。
• 支持:您所查看的元素被其他元素所支持的视图。通常从一层往上到上一层。
• 合作:朝向相互合作的对等元素。通常跨不同的方面。
• 实现:您正在查看实现其他元素的元素的视图。通常从一层向下到下一层。

组成视图

支持视图:

合作视图:

实现视图:

----------

应用程序使用视图

什么是应用程序使用视图?

应用程序使用观点显示了应用程序如何协同工作以支持业务流程，以及其他应用程序如何使用应用程序。它可用于标识业务流程和其他应用程序所需的服务，或用于通过描述可用的服务来设计业务流程。

下表更详细地描述了应用程序使用观点。

应用程序使用视图示例

下图显示了在应用程序使用观点下绘制的原始图。

实现和部署视图

什么是实现和部署视图?

实现和部署视角显示了基础设施上应用程序的实现。这涉及到将应用程序和组件映射到工件，以及将这些应用程序和组件使用的信息映射到底层存储基础设施。

下表更详细地描述了实现和部署观点。

实现和部署视角示例

下图显示了在实现和部署视角下绘制的原型图。

原文：https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/

本文：http://jiagoushi.pro/node/1313

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

基本视图

ArchiMate基本视图包括ArchiMate元素和ArchiMate三个主要层的概念:业务、应用程序和技术。下面列出的是ArchiMate 3.1示例视点表，分为四类，指明了它们所涵盖的方向和范围:

• 组合:定义元素的内部组合和聚合的视图。
• 支持:您所查看的元素被其他元素所支持的视图。通常从一层往上到上一层。
• 合作:朝向相互合作的对等元素。通常跨不同的方面。
• 实现:您正在查看实现其他元素的元素的视图。通常从一层向下到下一层。

组成视图

支持视图:

合作视图:

实现视图:

技术视角

什么是技术视角?

技术视角显示了软件和硬件技术元素(如物理设备、网络或系统软件(例如，O/S、数据库和中间件)如何支持应用层。

下表更详细地描述了技术视角。

技术视角的例子

下图显示了在技术视角下绘制的原始图。

技术使用视角

什么是技术使用视角?

技术使用视角显示了软件和硬件技术如何支持应用程序。当需要进行性能或可伸缩性分析时，通常会应用这种观点，因为它将物理基础设施与应用程序的逻辑世界联系起来。

下表更详细地描述了技术使用视角。

技术使用视角示例

下图显示了在技术使用视角下绘制的原始图。

原文：https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/#technology-viewpoint

本文：http://jiagoushi.pro/node/1314

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

基本视图

ArchiMate基本视图包括ArchiMate元素和ArchiMate三个主要层的概念:业务、应用程序和技术。下面列出的是ArchiMate 3.1示例视点表，分为四类，指明了它们所涵盖的方向和范围:

• 组合:定义元素的内部组合和聚合的视图。
• 支持:您所查看的元素被其他元素所支持的视图。通常从一层往上到上一层。
• 合作:朝向相互合作的对等元素。通常跨不同的方面。
• 实现:您正在查看实现其他元素的元素的视图。通常从一层向下到下一层。

组成视图

支持视图:

合作视图:

实现视图:

本节主要介绍信息结构视图和服务实现视图：

信息结构的视图

什么是信息结构视图?

信息结构视图的工作原理类似于开发信息系统时通常创建的传统信息模型。视点显示了企业中使用的信息的结构。它还可以显示业务层的信息如何在应用程序层以所使用的数据结构的形式表示，以及如何将这些信息映射到底层技术基础设施。

下表更详细地描述了信息结构视点。

信息结构视图示例

下图显示了在信息结构视点下绘制的ArchiMate图。

服务实现的视图

什么是服务实现视图?

服务实现视角为业务服务如何由底层流程/应用程序组件实现建模。

下表更详细地描述了服务实现的视图。

服务实现视图示例

下图显示了在服务实现视角下绘制的ArchiMate图。

原文：https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/

本文：http://jiagoushi.pro/node/1317

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

基本视图

ArchiMate基本视图包括ArchiMate元素和ArchiMate三个主要层的概念:业务、应用程序和技术。下面列出的是ArchiMate 3.1示例视点表，分为四类，指明了它们所涵盖的方向和范围:

• 组合:定义元素的内部组合和聚合的视图。
• 支持:您所查看的元素被其他元素所支持的视图。通常从一层往上到上一层。
• 合作:朝向相互合作的对等元素。通常跨不同的方面。
• 实现:您正在查看实现其他元素的元素的视图。通常从一层向下到下一层。

组成视图

支持视图:

合作视图:

实现视图:

本节主要介绍物理视图和分层视图：

物理视图

什么是物理视图？

物理视图显示可以创建、使用、存储、移动或转换材料的设备，以及如何通过分发网连接设备，以及分配给设备的其他活动元素。

下表详细描述了物理视图。

物理视图示例

下图显示了在物理视角下绘制的架构图。

分层视图

什么是分层视图？

分层视点提供了企业架构所有层和方面的核心元素的鸟瞰图。完全分层视图背后的结构原理是，每个专用层通过“实现”关系公开服务层，服务层进一步“服务”下一个专用层。通过这个视图，您可以很容易地将专用层的内部结构和组织与其外部可观察的行为（表示为专用层实现的服务层）分开。

下表详细描述了分层视点。

分层视图示例

下图显示了在分层视点下绘制的架构图。

原文：https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/

本文：http://jiagoushi.pro/node/1321

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

我已经在 ICT 行业工作了一段时间。 我刚开始一份新工作，在第一次客户参与开始之前我有一些时间，所以我想我会好好利用这些时间，并考虑在不参加课程的情况下通过 TOGAF 9 认证。 我有一些自学材料、视频和练习考试，所以我并不完全靠我自己，但肯定有很多材料要读。 我想我会分享我的笔记，也许他们会帮助其他人抓住牛角。

过去，由于 TOGAF 标准的高度理论性质，即使我曾担任技术领导职务，我的上级也没有真正看到认证的必要性。在年度绩效评估中，我曾多次说我想参加企业架构培训。有些年我没有得到许可，有些年我更喜欢接受其他培训，所以我从来没有时间完成它。现在 EA 是我工作的主要部分，获得认可肯定会对我有利。

TOGAF 9.2 的高级视图

完整的标准由五个部分组成。审查所有五个确实需要相当长的时间，如果您完全按照自己的时间完成，可能需要长达两个月的时间。由于我现在或多或少地全职工作，而且我有一些背景知识，我希望我能更快地采用这些信息。当然，由于信息量太大，我需要调整自己的节奏并以可消化的方式工作。我已经将这些笔记分解成这样的块，所以最好分段阅读它们。

就像在敏捷方法中一样，TOGAF 从某种宣言开始。伟大的想法是在企业和解决方案级别重用通用解决方案。通过创建可交付成果、工件和构建块 (ABB)，将架构连续统一体的宏大思想变为现实。 TOGAF 在四个不同的架构域 (BDAT) 中工作：业务、数据、应用程序和技术。帮助您定义的工具在架构内容框架以及如何在架构能力框架中设置架构实践中进行了描述。

TOGAF 的实际主要设计框架架构开发方法 (ADM) 围绕四个领域工作，由 8 个阶段 (A-H) 组成。您需要能够详细描述每个阶段的目标、步骤和可交付成果。此外还有初步阶段和需求管理。该标准的很大一部分用于描述每个阶段的工具和文档实践。

需求管理

在非常重要的 TOGAF 图中，所有阶段都围绕需求管理展开，因此这实际上是开始了解 ADM 的好地方。有趣的是，它实际上是在标准中最后引入的，因为它代表了架构设计的持续服务模式。在许多情况下，作为一名建筑师，您不会从一个绿色领域开始，而是跳进一辆移动的火车，并使用现有的输入。当前的解决方案和相应的需求已经记录在架构存储库中，存在架构愿景以及可交付成果和工件。

期望作为新的企业架构师，您将按照此阶段的步骤确定基线需求的优先级，识别新需求或变更需求的影响，并相应地更新需求存储库。此阶段的输出是具有冲突和优先级的影响评估，其中考虑了成本、时间表和业务指标。正确的方法是动态的，并且依赖于周围的 ADM 阶段。您应该考虑所有假设、约束、原则、政策、标准、组织指南和要求规范。

注意：我已突出显示每个阶段您需要了解的关键变量（输入、步骤、输出、方法）

初步阶段

一旦进入蓝月亮，您可能会遇到您所服务的公司没有现有的架构实践的情况。初步阶段就是为您提供建立架构指导流程的框架，并对其进行定制以适应公司的需求。老实说，对于大多数入门级企业架构师来说，您不会被分配这样的工作，但是了解该标准有助于您在熟悉现有实践时提出有关存储库的正确问题。

令人困惑的是，初步已添加到 ADM 图中，作为主圈之外的附加元素。如果您考虑一下，这是有道理的，因为在您运行节目时它并没有真正发挥作用。作为输入，您将拥有 TOGAF 和您想要使用的任何其他框架。您还需要了解业务和现有文档实践。作为输出，您应该组织模型和定制的架构框架。如果您认真完成所有步骤，您应该拥有您的第一个架构存储库。

您需要采取的步骤是定义谁将受到您所做设计的影响（范围），确认管理支持（治理），确保分配所有关键角色（团队）并确定背景（指导原则）。如果你做了所有这些，你应该能够定制你的工作方法（术语、过程和上下文分类）。困难的部分是想出策略和工具来真正让它发挥作用，从而实现你的架构能力成熟度目标。

概括

了解 TOGAF 的第一天到此结束。我们已经对标准的部分内容进行了高级审查，您现在知道 ADM 是如何开始和结束的。在下一篇文章中，我将写更多关于架构领域的内容，在以后的日子里，我们将回顾每个阶段。最终，如果您阅读了本系列的所有部分，您应该对如何进行企业架构有一个很好的理解，并且通过一些额外的学习，您至少应该能够通过基础考试。

本文：https://jiagoushi.pro/node/2208

在您的项目中，您是否直接与企业架构师合作？您是否收到企业架构师（EA）的文档？企业架构师是否是项目设计和评估活动的瓶颈？你和我一样，对企业架构师的角色有点困惑吗？

一个小小的谷歌搜索将让你确信EA是某种组织向导，他们可以看到所有并且知道所有。她是否住在一座塔楼里并且像一个熟悉的人一样养了一只乌鸦。

定义很难得到。有很多，听起来好像它们是由混淆机器生成的。但似乎有几种不同的口味：

1. IT-业务桥梁 - The Bridge负责了解当前的业务战略并将其转化为支持该战略的IT项目。
2. 集成大师 - 大师了解整个生态系统 - 应用程序，数据库，服务 - 以及它们如何相互连接。她为IT项目团队提供文档和指导，以确保他们了解生态系统变化和约束的影响。
3. 生态系统设计师 - 设计师是组织中的顶级技术分析师，负责制定项目团队负责详细设计和交付的系统设计决策。
4. Enforcer - Enforcer为组织设置软件标准，并确保所有项目团队都接受有关这些标准的教育。
5. 创新者 - 创新者的任务是展望行业趋势和尖端技术，以确保她的组织具有竞争力。

当然，EA，如PM或PdM，不是一个可以轻松融入任何盒子的角色。 EA的作用部分取决于她所在的组织和她自己的专业领域。根据具体情况，她可以完成所有这些角色。我和同一家公司的不同EA合作过，这些公司采用了截然不同的方法。有些是“这里是一个为您的技术设计提供信息的架构图”。有些人“邀请我参加每次会议，让我审查你们的所有要求”。当你搬到不同的项目或工作岗位时，这会让你很难知道你应该期待什么。

敏捷世界中的企业架构师

这种混乱在敏捷世界中更为明显。我见过的大多数模型都说明了团队的责任，他们非常重视EA的活动，将实际的软件团队显示为EA团队想象和设计的能力的提供者，有时将业务分析完全排除在外。这与Agile软件开发的现实并没有真正同步。那么组织如何将EA集成到敏捷中呢？

我们对敏捷的关注主要集中在用户故事上，这是一种提供软件功能以提供业务价值的请求，通常范围非常小。无论您是将用户故事视为更大功能的细分还是作为独立请求，都将重点放在用户身上。但如果用户故事是整个故事，那么你就遇到了问题。可以一次建造一座乐高城堡一座塔，但是如果你没有从足够大的底板开始，你最终会把它拆掉并重新开始。

我向EA询问了我是否曾在敏捷组织中就构建权进行了一些见解。他解释了他与敏捷团队合作的理想方式。我将把它作为我下一个项目的路线图，以确保我有效地参与建筑师团队。

原文：

本文：https://jiagoushi.pro/node/56

TOGAF可以帮助组织设计和开发IT基础架构，而不会带来很多麻烦。TOGAF专家对于实施优秀的IT基础设施开发战略至关重要，目前正在广泛寻找。目前，拥有TOGAF认证的人不够多，这对专业人士非常有益。TOGAF专家通过与部门主管沟通，帮助快速有效地设计IT基础架构。

现在进入主要问题，让我们知道，在2021年TOGAF认证仍然值得吗？

2021年TOGAF认证是否仍然值得？

2020年是一切发生剧烈变化的一年。全世界的专业人士都受到了影响，企业现在已经意识到员工技能的价值，因此他们急切地寻找更多的技能型员工。现在是每个人都努力提高素质的时候了。

是的，TOGAF认证在2021年仍然有效，因为各地拥有TOGAF认证的人数不足。报告显示，世界上80%的组织已经采用TOGAF作为框架。一些雇主甚至将其列为工作的强制性要求。许多大型咨询公司，如凯捷、甲骨文、惠普都已经在使用它。这也是一个全球公认的认证，它将帮助你在世界任何地方抢夺工作。

让我们了解您为什么应该在2021年获得TOGAF认证的其他几个原因。

2021年获得TOGAF认证的5个原因

TOGAF是一种越来越流行的认证。全世界的员工都已经报名参加了这门课程。TOGAF被认为是IT架构的通用框架。以下是您应该在2021年获得TOGAF认证的一些原因。

成本效益高且易于启动

TOGAF具有极高的成本效益。它更多的是一种技能，而不仅仅是一种认证。TOGAF没有任何先决条件。你可以马上开始。TOGAF无疑是2021年的年度认证。你花在学习上的每一分钱都是值得的。一旦你注册，你需要通过不同的培训级别和一些考试才能最终获得认证。

全球公认

TOGAF是全球公认的有价值的认证。到目前为止，全世界只有大约100000名TOGAF认证人员。需要更多的电流。有了这个，你可以在世界上任何一个国家找到一份出色的工作。这是一个多才多艺的学位，它将帮助你在一个职位上获得更高的职位，主要是领导职位，所以很明显，你的薪水会很高。

多才多艺的

TOGAF不仅适用于架构师和IT专业人员，也是管理领域的认证。在考试期间，您还将接受一些管理基本概念的测试。因此，你也可以在其他领域获得行政职位。

世界顶级公司使用

世界顶级雇主已经开始使用TOGAF，并寻找越来越多的TOGAF认证员工。如果你愿意在这些公司中的任何一家找到一份工作，你必须尽快获得认证。这些公司包括凯捷、惠普、甲骨文等。

更高的工资和可雇佣性

拥有TOGAF认证的人会自动获得更高的可雇佣性，并有资格获得更高的薪酬，因为目前世界上没有太多TOGAF认证的专业人士。各公司都在拼命寻找越来越多经TOGAF认证的员工。已经有80%的世界顶级组织采用了TOGAF架构模型，还有更多的组织也将采用TOGAF架构模型。

获得TOGAF认证的成本也大大降低。你可以从任何地方获得认证，大约300-400美元。对于更高级别的认证，您可能需要多付一点钱。有两种类型；也就是说，ToAF基金会和ToAF认证。它更被建议获得认证，而不仅仅是在基础阶段退出。一份TOGAF认证证书的费用大约为500美元。

底线

努力工作是无法替代的。这一点大家一定知道。世界正在迅速变化。员工越来越需要独特的技能，而不仅仅是学位。记住，总有比你更好的人在等待机会，所以要不断发展！！

希望你喜欢这篇文章。请与大家分享。

原文：https://www.pulseheadlines.com/is-togaf-certification-still-worth-it-in…

本文：http://jiagoushi.pro/node/1523

讨论：请加入知识星球【首席架构师圈】或者小号【csa_cea_cto】

ArchiMate示例

ArchiMate示例视图

框架视图

此视图表示构建所有开发方面和相关图表的框架。视图可以根据具体情况进行修改。因此，此视图可用于图之间的导航。这个版本的观点是从ArchiMate（3）框架中应用的。动机在这里被引入为“层”而不是“方面”。

动机观点

动机观点

此视图可用于分析指导组织及其企业架构的设计或更改的动机或原因。这些动机分析是组织中所有变革活动或业务转型的起点。该视图代表了开发工作的愿景——无论规模和范围是整个组织还是仅部分组织（如业务线），还是单个计划或项目（解决方案级别）。注意：可以将值添加到结果（或任何其他ArchiMate元素）中，以指示什么是真正的增值！

激励要素基于商业激励模型（BMM）【规范v.1.32015，OMG】。

使命价值观愿景

此视图可用于表示组织的使命、愿景和核心价值观。使命表达了例如“组织的目的是什么，它实际上在做什么或打算做什么，它存在的主要原因是什么？”愿景是组织打算发展的未来状态。核心价值观是支持愿景、塑造文化和反映组织价值观的东西。为了实现组织的愿景，需要实现战略目标。

参考文献：Alda，A.–Iacob，M.–E.–Hillegersberg，J.–Quartel，D.–Franken，H.（2015）ArchiMate建模策略。

战略价值图视图

此视图可用于组织策略的可视化。这一观点包含战略价值要素，所有发展活动都必须直接或间接地从中衍生出来。通过可视化战略价值，可以追踪与实际战略执行相关的所有其他元素。有了这种观点，战略就可以实现：可视化、沟通并与现实联系起来。

利益相关者分析视图

此视图可用于业务开发目的的利益相关者分析：变革的驱动因素是什么。首先，确定相关的利益相关者，然后确定符合他们利益的变革驱动因素。“评估”概念可用于对驱动因素进行详细分析，例如根据SWOT（优势、劣势、机会、威胁）方法。通常，可以从不同的角度创建不同的利益相关者视图图。将大型图拆分为小型图的另一个原因是为了保持图的紧凑性和可读性——为了简单起见。

利益相关者观点

此视图可用于将利益相关者的驱动因素与业务目标联系起来。目标是组织发展的关键要素。所有后续要素都应追溯到所有变更活动的这些主要原因。

原理视图

Risk & Security View

风险与安全观。风险和安全概念到ArchiMate的映射。安全和数据保护事项是风险管理的一部分。这种建模方法涵盖了这两者。

参考文献：

《如何使用ArchiMate®语言对企业风险管理和安全进行建模》，Open Group，文件编号：W1722017。

用ArchiMate®语言建模企业风险管理和安全，Open Group，2015。

SWOT分析视图

Goals View

Objectives and Key Results

OKR模式。

OKR是一种流行的管理策略，定义目标并跟踪结果。它有助于围绕可衡量的目标建立一致性和参与度。OKR有两个重要部分：你想要实现的目标和关键结果，这是衡量实现目标的方法。

目标：

–是对你想要实现的目标的令人难忘的定性描述。目标应该简短、鼓舞人心、引人入胜。目标应该激励和挑战团队。

关键结果：

–是一组衡量你实现目标进展的指标。对于每个目标，你应该有一组两到五个关键结果。不止这些，没有人会记得它们。

另一个版本的操作如下所示。

Strategy Views

Strategy Layer Views

Strategy View

ArchiMate版本3现在支持与业务战略相关的概念，如“行动过程”、“能力”和“资源”，这些概念可用于组织的业务战略建模。这种观点的价值和重要性在于如何将组织的目标与战略联系起来，以及如何通过能力将这些目标与企业架构联系起来。这种观点可用于应用“基于目标的战略模型”（Azevedo等人，2015），其中目标构成了一个层次结构，从而将更高级别的目标分解为更低级别的目标。

业务战略视图

商业动机模型（BMM）视图

理论上，ArchiMate®模型可以使用笔和笔，白板和标记来创建。还有一些软件平台提供ArchiMate建模环境，它具有许多自动化功能和分析功能。

但是在这篇文章中，我们将重点关注一个重要的元素，即成熟为一个先进的关键任务建模功能：模型库。

模型库

ArchiMate用于描述和分析企业的多个视角，包括现状和未来状态，以及规划两者之间的可能步骤。这很有用，因为企业架构（EA）的主要焦点可以说是支持变更计划。

虽然有几种方法，技术和最佳实践可供遵循，但这仍然不是一项简单的任务。这是因为它经常涉及在不同团队中工作的几个人来实现相同的目标：建立集成的企业架构模型。

支持和组织建模工作的集中存储库是必不可少的。存储库本身可以采用数据库的形式，但不一定。许多组织使用文档管理系统来实现EA工件的存储库（的一部分）。

存储库概念的核心方面是模型和信息的重用。在ArchiMate模型库中，对象只存储一次，并且可以在对象相关的其他图中重用。存储库充当所有对象，关系和属性信息的中心保留位置，其中维护模型并保持最新。

这使得基于存储库的ArchiMate建模与使用绘图工具根本不同：重用对象的能力导致生产力的大幅提升。

由于存储库汇集了来自企业的不同区域，视角和状态的信息，因此可以执行集成分析。将定性和/或定量数据作为对象的属性包含在内，可以得到非常高水平，有趣的分析。示例包括基础结构对象的安全信息，或应用程序组件或业务流程的性能信息（KPI）。

使用ArchiMate扩展，需求和项目计划信息也可以包含在存储库中，与体系结构相关，并成为分析的一部分。这样，ArchiMate模型不仅仅是对象，关系和视图的连贯集合;它是一个综合的“企业知识体系”。

设置模型存储库

建立模型库的最佳方法是“思考大，从小做起”。

一旦达到初始级别的ArchiMate建模成熟度，通常在两个或更多“域”（例如，信息，应用，业务和/或技术）中，建立集中式存储库就变得必不可少。这不仅仅是一项技术练习;还需要考虑人员和流程因素。

设置模型存储库时的关键考虑因素

人

应围绕谁建模什么来建立清晰的图景，并应解决模型内容所有权问题。应明确定义和记录，例如使用RACI矩阵。使用自动存储库解决方案时，ArchiMate建模的组织结构可以实现为基于角色的访问级别。

另一个重要问题是为组织特定使用ArchiMate语言提供指导。介绍模型样式指南可以防止“方言”的出现以及在不同域中使用不兼容的细节级别。同时，样式指南促进使用组织特定的可重用模型模式作为（域）体系结构的一部分。

流程

应确定并记录治理流程，角色和职责。这可以通过使用传统格式来完成，包括流程图和组织结构图。治理流程应指明组织设置和维护模型存储库的顺序。

在模型内容和属性数据的一致性和准确性方面，还应存在审查流程以保持高质量。

技术

如前所述，ArchiMate模型库可以使用各种类型的技术实现。 BiZZdesign Enterprise Studio提供了一个集中功能的中央集成模型库。存储库具有灵活性和可配置性，允许为ArchiMate建模实现各种组织和治理结构。

良好的存储库具有许多管理和发布模型内容的功能，包括版本管理，签入/签出功能和基于角色的授权。在模型库中，可以描述不同的状态（原样，将要）以及版本（草稿，审查，发布等）。

结论

ArchiMate模型库对于有效管理和管理架构团队的建模活动是必不可少的。 ArchiMate模型库的采用和实施应该作为一个项目来处理，不仅要关注技术，还要关注人员和流程问题。 至少在我们的经验中，基于“思考大，但从小做起”的战略已被证明是成功的。

原文：https://bizzdesign.com/blog/archimate-modeling-in-practice-using-a-model-repository/

本文：http://pub.intelligentx.net/node/395

讨论:请加入知识星球【首席架构师圈】

想在Facebook上做个调查吗?它会很有趣——我们可以学习哪种动物或颜色最能代表你的个性，或者其他类似的傻事。你所要付出的代价就是收集到的所有关于你的微观数据。你不喜欢那些小测验和调查?没问题，因为如果你Facebook上的任何一个朋友曾经同意过其中的一项，那么不管怎样，你的连接都有可能让其他人访问你的数据。

你知道这是怎么回事。本周，Facebook因允许第三方开发者在未经其许可或同意的情况下，从5000多万用户那里获取远远超出其预期的用户数据而备受指责。这个故事有很多角度，也有很多人指责是谁做了什么，事情应该如何处理。尽管事实仍在调查中，但这是一件严肃的事情。在我写这篇文章的时候，Facebook的市值自消息传出以来已经暴跌了50个基点。该公司目前正卷入一场公关噩梦，包括要求国会作证，这将导致在未来几个月里，乌云笼罩在该股头上。

为什么Facebook会给你敲响警钟?

这是一个警钟，因为Facebook并不是传统意义上的数据泄露，即一个坏人获得了对服务器的未经授权的访问，或者在传输过程中获取了数据。Facebook关注的是社交网络平台固有的弱点，在这些平台上，价值创造与社区成员提供的个人数据量成正比，这些成员认为积极参与社区活动不会损害个人和财务安全。

是否你的业务是一个社交平台,您的客户和员工可能Facebook等社交平台的成员,因为滥用潜力强劲的消费者数据,客户和员工现在想知道他们可以相信他们提供的数据你会呆在可靠的人手中。

将数据保存在安全的地方是欧盟一直非常关注的问题，同时也让消费者决定是否允许公司保存客户的数据。你可能已经听说过《一般资料保障规例》，该规例把个人资料的控制权交还给个人。该法案将于2018年5月25日生效。GDPR的规则之一是，收集消费者数据的公司必须证明拥有这些数据的目的是正当的。这意味着，虽然Facebook、Twitter和类似的播放器仍然允许你分享和喜欢的东西，但它们将不允许保留(当然也不允许出售)你的数据。任何像贵公司这样在欧洲开展业务、导致客户或员工个人数据被保留的公司，都必须遵守GDPR，否则将面临高达全球营收4%或2,000万欧元的罚款，以更高的金额为准。

尽管GPDR被大肆宣传，需要更严格的数据隐私法规，个人有权知道何时、何地以及如何管理他们的数据，但许多企业似乎对这个问题采取了一种从容不迫的态度。Facebook的崩溃提醒我们，数据隐私和合规并不是一件“值得拥有的好事”。我们有一种“必须有的”方法来应对这个每一家大公司在2018年都必须面对的紧迫挑战。理解您的数据隐私漏洞就是要完全理解您的IT投资组合和允许数据在业务单元之间流动的管道。对您的IT投资组合、信息架构和定义您的业务生态系统的支持流程的可见性对于成功地运行业务是必要的。我们遵循GDPR的方法是基于这样一个前提，即推动数据通过管道的技术是业务流程不可或缺的一部分。

原文：https://community.mega.com/t5/Blog-EN-Business-IT/Will-the-Facebook-Debacle-Finally-Wake-Everybody-Up/ba-p/16724

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

Nicholas G. Carr 撰写他的文章“IT 无关紧要”已经 18 年多了。我记得读过标题；令一位年轻的 IT 顾问感到震惊，认为本世纪这个世界会如此需要我和我的同事。但是在阅读这篇文章时，我很快就明白了卡尔的意思；电子数据处理成为一种商品，就像电力已经存在了几十年一样。电子数据处理对其早期采用者具有战略优势，但时间有限。因此，随着每个人都可以使用这种信息技术，认为您可以通过“购买 IT”来获得公司的战略优势显然是一个错误的愿景，它仍然适用于新技术。在 IT 集合中，人工智能、物联网、量子计算、虚拟/增强现实、机器人过程自动化等技术不会让您与众不同，因为它们变得可供所有人快速访问。早期采用者优势的窗口随着每项新技术而减少。但是，如果 IT 本身并不重要，那又有什么关系呢？

这与拥有 IT 无关，而是关于您的数字业务技术平台如何实现持续的战略竞争优势。

当公司进行战略转型计划时，他们还将检查数字化及其数字业务技术平台在多大程度上可以直接或间接地为其客户促进收入流或创造附加值。今天可以购买的组件越多——包括维护、支持和优化它们的服务——在同时实现常绿、可持续和敏捷方面的风险就越小。对于一些独特的战略业务流程，需要构建平台组件或定制标准产品。但只要定制不能创造竞争优势，公司就应该问他们是否真的重要。

一家公司可以通过 IT 实现的真正不同之处在于其数字业务技术平台的组成方式。如何以对公司重要的方式构建战略、业务流程和工具。

声称构建这样一个平台很容易是自相矛盾的，但就像建造房子一样，它始于架构。在这种情况下，企业架构必须是动态的。这意味着公司的企业架构师对业务和 IT 融合的成功负有很大责任。当我寻找我访问过并拥有成功的数字业务技术平台的公司时，我发现他们的企业架构师的方法有一些显着的相似之处：

1. 他们是 Rockstar 企业架构师：他们了解企业架构不仅仅是设计、原则和规则，而且还是指导组织中实质性变革的一种手段。为此，无论他们使用哪种架构框架，它都必须牢牢地锚定在组织的变革过程中。另一方面，他们确切地知道自己在组织中的位置，不会将其与专注于构建公司未来业务的业务架构师角色混为一谈。
2. 他们认为以行业为中心：一旦涉及特定于公司垂直行业的业务流程，他们就会寻求购买可以支持其大部分流程的组件，并寻找能说他们的行业语言并具有实施这些流程经验的专家选择的组件。
3. 他们采用常青应用架构方法：当购买的组件需要定制时，他们知道可升级性方面的风险。如果无法选择产品更改，他们首先会考虑如何尽可能地将更改与产品隔离，同时在复杂性和可持续性之间保持平衡。他们了解本质复杂性和偶然复杂性之间的区别，在使用新技术的痛苦和收益之间做出权衡。简而言之：他们减轻了常青树状态的风险，并且总是问“为什么”。
4. 他们寻找彻底的技术集成：他们选择经过验证的集成组件和可以一起使用的供应商。他们寻求具有特定产品集成经验并负责成功交付的合作伙伴。
5. 他们从不低估主数据管理：他们为公司的共享主数据资产制定了计划，以确保不同主数据收集的数据保护、统一性、准确性、一致性、管理和问责制。
6. 他们认为设计的劳动力体验：每一次实施或变更都必须迅速为企业所采用，并带来高水平的劳动力体验。 在某些情况下，由变更经理领导的变更管理跟踪是必要的。
7. 他们促成协作：他们善于将组织中具有不同背景和职责的人聚集在一起，并协调他们的利益。 他们发现合适的人成为他们的大使，并对他们的 T 型档案有所了解。

因此，如果您的公司中有一位采用这些方法的 Rockstar Enterprise Architect，那么您可以确定他或她很重要！

原文：https://medium.com/@dimitri.buyse/it-doesnt-matter-but-enterprise-archi…

本文：https://jiagoushi.pro/node/1870

有关企业架构 (EA) 治理、相关框架以及角色和职责的所有内容。 了解如何开发可持续的 EA 治理！

捷径

• 什么是企业架构治理？
• EA 治理上下文
• EA 治理框架
• EA 治理的指导原则
• 组织结构
• EA 治理角色和职责
• EA 治理流程
• EA 分类
• EA 指标
• EA 工具
• 结论

什么是企业架构治理？

企业架构 (EA) 治理是一种实践，涵盖了管理业务的基本方面。 它涉及坚定的领导力、对组织结构的全面了解、自信的方向以及启用有效的 IT 流程以促进企业战略。

但是，如果仅提炼出一个领域，EA 治理的目标就是将企业的架构要求协调为一组可理解的政策、流程、程序和标准——所有这些都是为了确保组织的愿景和标准与 实际业务需求。

它不是一门脱离现实的学科，也不是基于对什么正在发生什么没有发生的推测。 EA 治理是部署和维护业务战略不可或缺的一部分。

而且，在许多方面，这是一项永恒的工作。

如果没有 EA 治理，组织可能会陷入非标准化技术、不良产品采购或开发以及单一架构（即“孤岛”）的网络。这些习惯将不可避免地对财务和运营产生长期影响，从而在企业层面造成越来越难以纠正的协作和标准化问题。

借助 EA 治理模型，运营可以实现显着的成本节约并实现以下优势：

• 通过管理监督提高角色和责任的清晰度
• 通过提高透明度和问责制，制定清晰、快速的决策以克服挑战
• 架构一致性与简化的合规性
• 通过务实的方法进行相关且有用的企业架构管理
• 在整个企业中扩展和提升架构的业务价值
• 鼓励新受众对架构的开阔视野
• 对正确活动的架构工作进行优先级排序
• 了解改进领域以确定真正的最佳实践

不要将 EA 治理与 IT 治理混为一谈。 IT 治理是有效和高效地利用 IT 来实现组织目标的过程。下表更详细地解释了这种差异：

EA 治理不仅是 IT 主管（CIO 和 CTO）的职责，也是业务主管（在企业架构师、领域架构师、主题专家和整个组织内的各种其他支持人员的关键支持下）的职责。

EA 治理上下文

从概念上讲，EA 治理是一种方法、一系列流程、一种文化导向和一组自有职责，可确保组织架构的完整性和有效性。

下图表示 EA 治理框架中涉及的三个关键组件。

要使治理成功运作，所有三个要素必须协同工作。 这种与内容无关的方法确保了框架的灵活性。 此外，这些流程通常独立于内容，并实施经过验证的最佳治理实践方法。

EA 治理框架

组织要实现其 EA 目标，需要一个完善的治理框架来支持企业架构的实施和管理。

维护企业架构的治理框架由以下组件组成：

• 组织结构
• 角色和职责
• 流程
• 标准和指南
• 指标
• 工具

下图显示了这些基本元素的组成部分。

在建立 EA 治理时，解决这些要素中的每一个都至关重要。

EA 治理的指导原则

建立成功的 EA 治理的主要指导原则是：

• 纪律：所有相关方都承诺遵守商定的程序、流程和权限结构。
• 透明度：所有已实施的行动及其决策支持将可供授权组织和提供方检查。
• 独立性：建立用于最小化或避免潜在利益冲突的所有流程、决策和机制。
• 问责制：组织内的可识别群体——例如，采取行动或做出决定的治理委员会——被授权并对其行为负责。
• 责任：每个缔约方都必须对组织及其利益相关者负责。
• 公平：所有做出的决定、使用的流程及其实施都不允许为任何特定方创造不公平的优势。

对组织 IT 解决方案交付流程的 EA 治理侧重于实现多个解决方案。这些包括：

• 标准化：制定和推广企业范围的 IT 标准。
• 一致性：实现所需级别的信息、流程和应用程序集成和互操作性。
• 重用：在设计、实施和产品组合级别重用和利用 IT 资产的策略和支持功能。这可能包括流程/治理和资产存储库考虑。
• 质量：提供满足业务功能和技术要求的解决方案，并具有确保解决方案质量的生命周期管理流程。
• 成本效益和效率：通过可重复的决策治理流程利用标准、重用和质量，从而降低总解决方案生命周期成本并更好地实现 IT 投资。

组织结构

启动企业架构组织以开发和支持采用围绕 EA 的设计、审查、执行和治理功能。这些功能包括许多关键要素，包括：

• EA 框架：一套标准、程序和操作协议，用于指导和指导组织中围绕信息技术的采用、重用、报告和停用的决策。这些包括指导原则、方法、程序、指标、最佳实践和参考模型。
• EA 审查委员会：一个跨组织、多学科的架构审查委员会 (ARB)，得到企业 IT 执行管理层的支持，负责监督技术治理战略和框架定义的实施。
• EA 合规性：定义 EA 合规策略并制定一套一致的、可重复的流程以确保该 EA 合规策略。建立正确的组织职责和结构，以支持架构治理过程和报告要求。
   

EA 治理角色和职责

EA 中的角色和职责涵盖广泛的活动，包括但不限于：

• 提供领导和沟通
• 构想、领导和指导整体解决方案架构合规性与 IT 转型的发展
• 了解映射到业务能力模型的业务领域
• 对映射到技术能力模式的技术的理解
• 建立和维护架构实施、企业架构中体现的架构战略和目标以及业务战略目标之间的联系
• 通过共识和授权发布提供架构的正式接受和批准机制
• 提供基本控制机制以确保架构的有效实施
• 提供解决方案架构和设计技能

EA 领导者需要致力于整合“业务和 IT”，而不是协调“业务和 IT”。重点必须放在实现业务战略上，而不仅仅是保证和合规。

EA 治理流程

该过程是一系列操作或事件，可能会占用时间、空间、专业知识或其他资源，从而产生特定的结果。

EA 治理流程是用于实施技术解决方案的整体 EA 治理框架的组成部分。下面列出了五个主要过程：

• 架构文档流程
• 架构审查流程
• 架构沟通过程
• 架构合规流程
• 架构框架活力过程

企业架构成功的深度指南 [白皮书]：设计您想要的架构以及您的公司需要的架构。 »

EA 分类

分类是定义术语的集合，是对关键组件和架构概念结构的连贯描述。下面列出了关键概念和术语的具体定义：

• 方法：执行任务、活动或过程并衡量绩效以满足涵盖原则、政策、系统、过程、方法和技术的标准的一种方式。
• 最佳实践：完成业务功能或流程的一种方式或方法，优于所有其他已知方法。
• 蓝图：
  • 计划或指南，常用于建筑，布局合理，包括基本要素，以解决和遵循建筑进度。
  • 蓝图是记录企业架构的计划和/或设计。
• 指导原则：原则是一般规则和指导方针，旨在经久不衰且很少修改，为组织着手履行其使命的方式提供信息和支持。
• 方法论：方法论代表给定活动领域的一系列实用想法和经过验证的实践，例如基于 IT 的系统的规划、设计开发或管理。
• 协议：
  • 管理数据传输和接收的规则。
  • 指定数据格式和在数据通信和网络环境中要遵循的规则的标准。
  • 执行功能或服务时各种角色之间的参与规则。
• 标准：一组标准（其中一些可能是强制性的）、自愿准则和最佳实践。 EA 指南和标准规定：
  • 架构必须根据架构的预期用途以及企业范围标准的开发和推广进行适当的范围界定、计划和定义。
  • 企业架构必须反映组织的战略计划。
  • 架构不断变化，需要过渡。
  • 架构必须允许许多不同的硬件和软件系统相互连接和集成。他们需要交换数据以执行所需的业务交易。
  • 企业架构将需要继续刷新和更新框架以及分类，并改进企业架构模型。
  • 企业 IT 必须在整个组织内提供架构规范的定义、设计、实施和实践方面的政策指导和帮助。
  • 通过可重复的决策流程实现标准、重用和质量的一致优势，从而降低解决方案成本并更好地实现 IT 投资。
  • 支持在设计、实施和产品组合级别重用和利用 IT 资产的能力的策略。这可能包括流程/治理和资产存储库。

EA 指标

指标在 EA 实施的早期阶段估计 EA 的进度。它还有助于衡量 EA 的效率和有效性，以确保为业务提供真正的价值。

测量 EA 指标对于：

• 确定流程或服务如何有效和高效地满足客户
• 识别改进机会
• 根据事实和数据做出决策

测量应该：

• 将组织期望转化为目标
• 评估流程的质量
• 跟踪改进
• 支持企业战略

为了使 EA 程序成功，需要根据一组定义的指标定期对其进行监控和测量。可以使用 EA 记分卡或仪表板有效地捕获、呈现和传达整个组织的指标状态。

EA 工具

企业架构工具捕获、存储、构建和分析与企业架构相关的信息，因此，选择适合您组织的正确工具至关重要。

EA 工具通过捕获重要的企业环境以及跨业务、信息、技术和解决方案架构的内容开发和分析功能，为战略决策制定提供支持。

它帮助利益相关者分析和优化业务战略、组织结构、业务流程/任务和活动、信息流、应用程序和技术基础设施的组合。

EA 工具涵盖以下功能特性：

• 建模能力
• 框架和标准支持
• 能够创建或导入模型和工件
• 强大而灵活的存储库和元模型
• 易用性
• 集成到多个企业使用工具
• 影响企业领域各个层面的能力
• 满足各种需求的管理功能，例如安全性、审计控制、协作、配置和版本控制

结论

精心设计的企业架构治理结构对于降低 IT 成本和风险、同时加快决策制定和交付至关重要。 EA 治理可确保正确管理 EA 程序以生成真正代表组织目标和需求的工件和计划。同样，EA 治理确保投资决策从启动到实施都与 EA 保持一致。

治理是任何变革计划的重要方面。 EA也不例外。治理为各种利益相关者提供了一个定期交互和维护企业架构的平台。

EA 程序定义不应跨越数年。它应该在短时间内提供商业价值。计划输出应该是可操作的，并且应该始终衡量其影响——而不是其活动。

在现代 EA 中，EA 治理的象牙塔方法不起作用。这种方法会导致 EA 程序失败，尤其是当 EA 程序不考虑数字业务的需求时，这是由价值创造转向生态系统、平台和面向外部的架构所驱动的。 EA治理在现代EA中的作用总结如下：

• 不关注当前状态架构
• 继续将 EA 程序推进到下一个成熟度级别
• 了解组织的业务战略、业务模型和目标，并确定 EA 如何帮助实现业务价值
• 不会被 EA 框架、行业参考模型、治理和 EA 工具分心
• 将重点从自上而下的治理转移到 EA“卓越中心”
• 对 EA 程序采用持续创新的方法，完善每个周期
• 在不了解其用例和功能的情况下不使用 EA 工具
   

编者注

此内容由 Wipro 的 GEA 实践部门的高级企业架构师 Gopala Krishna Behara 博士提供。他拥有超过 22 年的 IT 经验，可以通过 gopalkrishna.behra@wipro.com 与他联系。作者要感谢 Wipro Technologies 的 GEA 实践部门的 Hari Kishan Burle 和 Raju Alluri 在撰写本文时提供的支持和知识。

原文：https://www.leanix.net/en/wiki/ea/enterprise-architecture-governance

本文：https://jiagoushi.pro/leanix-enterprise-architecture-governance

定义：

企业是一个由相互依赖的人员、流程和支持技术组成的网络，不受任何单一实体的完全控制。信息密集型企业是其成功运营在很大程度上依赖于网络化信息系统的企业。设计信息密集型企业专注于管理企业中的不确定性和相互依赖性，它涉及对企业和支持企业的系统进行设计。信息密集型企业的工程设计旨在构建有效且高效的单个系统网络，以满足整个企业的目标。

关键词：

架构、变化、可组合、设计模式、信息密集型、创新、任务保证、开放系统、不确定性

MITRE SE 角色和期望：

MITRE 系统工程师 (SE) 有望开发平衡本地创新与全球创新和发展的企业解决方案。他们开发的解决方案 (1) 提供定制的创新以满足最终用户的本地需求，以及 (2) 与不断变化的环境互操作、响应和共同发展。

语境

我们赞助商组织的成功越来越依赖于信息。如果在需要时无法获得正确的信息，企业的使命和成果就会变得不那么有效、高效或成功。

一个企业有许多组件和信息必须结合在一起才能实现任务成功。数据、业务规则、应用程序、通信和传感器需要在企业架构、设计、现有系统和任务保证要求的约束下创建或组合成能力。这里有一些例子：

• 对于国土安全，通信能力必须支持第一响应者以及州、地方和部落合作伙伴的需求。
• 在国防部，网络安全威胁需要在使用之前仔细考虑和仔细检查开放能力和新兴技术，例如社交网络。
• 在空中交通管理中，对公众信任的需求可能会推动与自由飞行和在国家空域使用无人驾驶系统相关的商业规则。
• 对于像 IRS 和 VA 那样的现代化工作，鉴于运营组织准备好吸收它们及其相关的新流程和程序，出现了如何以及何时插入新技术和能力的问题。

最佳实践和经验教训

• 信息作为资本。将企业数据和信息视为具有长期价值的资本资源。强调数据策略在您的工作中的重要性。
• 数据互操作性。采取数据互操作性设计以确保实现跨企业能力的观点。
• 适应企业周期。有长期和短期的赞助商周期。前者包括预算、需求、合同和实施等活动。后者包括响应紧急的运营需求。了解并区分它们，并根据它们调整系统工程。
• 考虑能力寿命。了解用户所需功能的可能寿命。使您的观点和系统工程方法适应您设计的功能的这方面。当前的情况/环境可能需要某种能力，但下一次危机或以后不再需要这种能力。在危机中，能力进化的考虑可能不是系统工程分析的关键部分，但不应该完全放弃对未来使用的考虑。例如，设计模式可用于创建即时功能，同时便于在未来危机中使用。可组合的能力策略可以使组件能够被创建并“上架”以支持未来的情况。开源能力可以为“立即使用”提供基础。
• 不要抛弃“一次性”的想法。许多赞助商的发展强调一切都必须能够被其他人重用（这在面向服务的世界中得到了加强）。虽然这种情况经常发生，但有时谨慎的做法是建立一种更快、更便宜、一次性的能力。了解在您的企业内和其他人重用的价值，但也要了解在某些情况下，构建一次性版本是更好的行动方案。

该主题下的文章

本主题下的文章旨在帮助工程信息密集型企业中的 MITRE 员工。

• 架构由我们的赞助商使用，用于各种目的——支持对运营的理解，帮助系统设计和实施，并为企业能力提供基本的构建块。联合架构有助于处理工程跨企业需求的规模和复杂性，以提高整体任务效率。架构联盟一文讨论了联合架构如何在企业的主要部分实现本地创新、企业集成和演进——其中许多可能本身就是企业。
• 软件中的设计模式不是软件的具体部分，而是在某些情况下应用的最佳实践模板。 MITRE SE 可能会在开发或审查系统组件之间的接口或更高级别的跨系统边界时遇到并使用它们。文章设计模式描述了在面向工程服务的环境和接口标准化活动中使用这些模式的基本方法、最佳实践和经验教训。
• 可组合的按需功能 (CCOD) 文章描述了一种新的、不断发展的策略，以使功能能够快速拼凑在一起，以满足最终用户的需求，在某些情况下，用户自己需要。 CCOD 具有许多 Internet 工具的风格，这些工具使各种服务能够快速应用于数据或信息，以构成满足用户需求的“用户定义”或定制视图/透视图。
• 开放系统方法增强了在信息密集型系统中快速创建能力的能力。文章开源软件 (OSS) 提供了关于 OSS 的历史视角，描述了 OSS 快速变化的观点及其与工程信息密集型企业的关系，强调了政府对 OSS 的兴趣和使用，并以一套全面而详细的应用开放系统技术和使用开源软件的最佳实践和经验教训。
• MITRE SE 应了解适用于联邦机构收集、使用、维护和披露个人身份信息的法律要求。隐私系统工程一文提供了有关如何将隐私构建到系统工程生命周期中以及如何利用技术来保护隐私的指导。

原文：https://www.mitre.org/publications/systems-engineering-guide/enterprise…

本文：

定义：

架构联合是用于企业架构开发、维护和使用的框架，它对齐、定位和链接分离但相关的架构和架构信息，以向用户提供无缝的外观。

关键词：

企业架构，联邦架构，适合联邦，语义对齐，分层责任，接触点

MITRE SE 角色和期望：

MITRE 与各种政府赞助商合作，帮助他们构建企业架构，通常是在支持其整体企业现代化或转型计划的背景下。许多发起人都面临着以一种有凝聚力和安全的方式共享其业务流程、信息存储、技术系统和人力资源以完成共同使命的复杂问题。 MITRE 系统工程师 (SE) 应了解并应用架构联合的原则，以实现跨企业架构或多机构企业架构的主要部分的本地创新、企业集成和演进。通过帮助他们构建各自的产品来满足共同的规定方向，MITRE 的赞助商将能够通过像 LEGO® 积木一样“将它们拼接在一起”来重用组件架构，以构建范围更广和适用性更广的复杂架构。

介绍

近年来，MITRE 一直在支持联邦政府范围内的架构工作。事实上，联邦政府现在要求为任何重大信息技术投资寻求资金的机构使用企业架构。赞助商通过增强美国企业（例如空军企业）与联合部队和联军部队、其他军种和国家机构的互操作性和整合，使用架构来提高作战和业务能力。

为了完成这些工作，MITRE SE 需要理解和应用联合架构的原则来解释架构相互关系并表达架构如何相互连接。联合架构支持跨企业主要部分的本地创新、企业集成和演进——其中许多可能本身就是企业。架构联合在实践中的原则需要合并(merging)、整合(integrating)和联合(federating )大量不同的组织架构，例如联邦航空管理局、国防部、国土安全部、CBP 和联邦紧急事务管理局，以及航空公司等行业参与者的贡献、机场、IT 行业、气象局等。本文探讨了架构联邦的基本概念，并提供了经验教训，以帮助 MITRE SE 了解联邦原则如何帮助从业者更有效地构建架构。

什么是企业架构？

架构涉及组件的结构、它们彼此之间和与环境的关系，以及指导它们所描述的实体的设计和演变的原则 [1]，无论该实体是一个组织（例如，联邦部门或机构），一个系统（例如，联合监视目标攻击雷达系统），或一个功能或任务领域（例如，财务管理、国土安全）。架构产品和工件可以采用多种形式，包括存储在架构工具或数据库存储库中的结构化数据模型、硬拷贝或电子格式的信息图形描述，或非结构化数据或文本。

“企业”的一个良好的工作定义是具有一组共同目标或原则或单一底线的任何组织或组织群（例如，公司、单个部门、政府实体、地理位置偏远的组织网络）。企业架构提供了清晰而全面的企业图景。它包括当前运营和技术环境的快照、目标环境以及从“现状”环境过渡到“未来”环境的资本投资路线图。换句话说，它充当了前进道路的路线图。快照包含“视图”，每个视图都包含一个或多个架构产品，这些产品为特定的利益相关者组 [2] 提供企业感兴趣的某些部分的概念或逻辑表示。

联合的架构是什么意思？

开发单片集成架构的历史方法效果不佳，因为这些产品通常变得过于复杂和笨拙。相比之下，联合架构是用于企业架构开发、维护和使用的框架，它对齐、定位和链接分离但相关的架构和架构信息，以向用户提供无缝的外观。它使复杂的架构能够从组件架构中以零碎的方式构建。通过这种方式，联合架构方法可以识别单个架构的独特性和特定目的，并允许它们的自治和本地治理，同时使企业能够从它们的集体内容中受益。

联合提供了在定义的上下文和当前/未来环境中组织企业关于其活动（流程）、人员和事物的知识体系（架构）的方法。联合架构通过链接整个企业的架构来支持决策制定，提供一个整体的企业视图，允许评估诸如互操作性、重复和差距的识别以及可重用性的确定等问题 [1]。

为什么要开发支持联邦的架构？

集成和/或联合架构的能力对于解决跨广泛领域（例如联邦部门或机构）的企业问题至关重要。联合使多个团队能够以最能满足他们当前需求的重点来开发架构，同时提供一种链接和关联这些架构的方法，以解决跨多个领域的问题。单一架构可能无法充分解决整个企业的问题，以支持具有多种任务的大型组织所需的分析。联合多个架构的能力导致了一个更强大的结构，可以以更小的、一口大小的块来理解企业。

架构联合在某种程度上作为一个过程，通过查找重叠并在它们的公共架构信息之间建立映射来关联从属架构和父架构。联邦部门和机构也在寻求另一种使用架构联合策略的方法，将企业划分为可管理的、大小合适的组件，每个组件都可以由与其最密切相关的社区进行描述 [3]。每个人都使用一小组规则、通用术语和标准来保持一致性，以便组件可以根据需要“拼凑在一起”。例如，部门架构描述部门范围的规则和约束，组件架构描述特定任务的服务和能力，解决方案架构描述符合更高规则和约束的解决方案。

联邦的概念在环境发展和信息共享方面也发挥着重要作用。例如，随着联邦部门和机构企业的网络化程度越来越高，事实证明，联邦架构在组织信息阵列和复杂关系方面至关重要。联合架构元数据也可用于评估现有系统和程序的组合，以决定实现所需功能所需的更改或添加。

那么，什么是联合企业架构？

根据企业范围的定义，联合企业架构是一组具有以下属性的架构：

• 它以协作方式运作，治理在中央机构和组成单位之间划分，平衡组织自主权和企业需求。
• 中央机构的架构可以专注于规模经济、标准和企业福祉的动态。
• 组成单元的架构具有追求自主策略和独立流程的灵活性[4]。

哪些核心元素支持架构联盟？

在联合方法中，架构开发的责任由企业内的不同层级分担。要将这些单独但相关的努力结合在一起，需要：

• 分层问责制：建立架构的层次结构，使层次结构中较低的架构继承较高层次架构的特征。使用接触点来关联各个级别或层级的架构。
• 分类：关联和分组“相似的”的架构和工件。
• 语义对齐：使用通用词汇和映射关系来建立共享理解。
• 参考架构：为其他架构提供父分类法以供使用。
• 搜索和发现：允许授权用户查找和访问相关架构以获取信息和重用 [3]。

架构联盟的一些关键构造是什么？

图 1 描述了架构联合的关键构造。每个构造都包含一组特定利益相关者感兴趣的架构产品。

Figure 1. Key Constructs for Architectures Federation

主题架构是为特定目的驱动解决方案的架构。它解决了交付功能所需的所有业务、信息、业务服务和技术组件。主题架构所依赖的那些解决方案的架构称为支持架构；而那些依赖于主题架构的解决方案的架构称为受支持的架构。

每个架构接口点（也称为接触点）是两个架构之间有目的连接的抽象表示。这些架构接口点是现实世界接口的抽象，将体现在实现相应架构的解决方案中。简单来说，接口点是架构可以加入更大的联合架构的地方，因此从操作的角度来看，它们是有目的的联合的关键。

合规在联邦中的作用是什么？

如果一个架构将被共享并用于支持与其他架构的联合（例如，指导其他架构或程序的开发），那么符合一组标准的架构就很重要。这些标准以规定方向的形式出现，称为合规标准。合规标准包括业务规则和流程，例如信息、服务和技术标准。程序或其他架构必须遵守这些，才能符合给定的结构。合规标准增加了对这些标准将被验证的方式的描述。因此，合规性标准明确说明了程序或架构必须在功能、遵守标准和满足特定质量要求方面展示什么。

组织可以从创建满足最低标准集的架构开始，从而更容易共享架构并将它们定位用于构建架构联盟，以支持构建可互操作解决方案的联盟。

合规标准有哪些例子？

Fit for Federation 是特定合规性评估的一个示例，可应用于将成为架构联合的一部分的任何架构。适合联邦由以下合规标准确定：

• 该架构的目的已由用户和用途记录和验证。
• 输入已被验证为来自权威来源，并记录了权威来源。
• 架构和/或分析（输出）已被验证符合目的。
• 识别、记录和验证支持的架构接口点和相关标准。
• 支持架构接口点被识别、记录并与供应商协商。

• 建立、记录和验证其他合规标准（例如，企业范围的标准和/或定性要求）。

在评估符合性标准时可能应用的一些定性要求的例子是可负担性、可靠性、可扩展性、性能和信任。

对于面向服务的环境，特定的合规标准将被打包为服务水平协议 (SLA)。单个合规性标准可以分配给多个 SLA。例如，支持给定词汇表将适用于处理主题（领域）词汇表的所有服务。

最佳实践和经验教训

实现语义一致。

为了联合架构，必须有语义协议，以便相关信息可以适当地关联。 MITRE SE 可以建议他们的发起人通过以下方式达成语义协议：

• 遵循通用框架，包括对所有架构描述实体或对象使用通用数据元素定义、语义和数据结构。
• 符合通用或共享架构标准。
• 使用企业分类法和权威参考数据。

符合标准。

一般来说，符合通用或共享架构标准会增加互操作性并使其更容易联合。 MITRE SE 应鼓励其发起人选择适合其目的的标准，并帮助他们建立强制合规的方法。例如，商定的企业分类法建立了用于调整任务领域活动和相关参考模型以及对组件架构进行分类和组织的上下文，从而促进跨联盟中各种架构的语义理解。

启用信息共享。

支持信息共享的环境促进了架构的联合。

确保健全的治理和企业架构服务：

MITRE SE 首先必须认识到架构共享环境需要健全的治理和企业架构服务。他们必须帮助他们的发起人建立健全的治理结构，以将问责制应用于架构的开发和维护，以实现既定目标，这最终将促进他们的联合能力。这种方法将责任放在配置管理和质量保证等流程上。 MITRE SE 还必须鼓励其发起人建立企业架构服务，以使架构信息始终如一且高效地可见、可访问和理解。

公开架构及其元数据：

联合工作的成功还取决于公开架构和架构元数据，以供分析师、规划人员和决策者在各个级别进行潜在的链接和重用。共享已经存在的架构和服务有助于加快架构开发和联合。注册功能 [5] 提供架构元数据的注册和链接，以支持创建可导航和可搜索的联合企业架构。架构的企业执行策略和治理加强了健壮的接口和数据关系 [1]。 MITRE SE 应该帮助他们的赞助商积极参与这些架构共享场所，方法是在重新发明之前重用工件，并发布他们自己的元数据和产品供其他人重用。

鼓励发起人的联合架构：

MITRE SE 应在发起人组织内促进和促进联合架构的发展，以帮助提高决策的可靠性和效率。当组织跨越边界对齐语义和结构数据时，就会发生这种情况，这样他们就可以确保使用正确的信息来回答关键决策者的问题。 MITRE SE 应继续使用联合架构机会并改善利益相关者节点之间的信息流，从而改善决策者之间的信息流。

概括

MITRE 与各种政府赞助商合作，帮助他们构建企业架构，通常是在支持其整体企业现代化或转型计划的背景下。 MITRE SE 需要具备的一项关键技能是了解业务需求、信息技术和人员如何在构建良好的架构中融合在一起。

MITRE 的许多赞助商都面临着多机构企业架构的复杂问题。不同的政府实体如何以一种有凝聚力、安全的方式共享他们的业务流程、信息存储、技术系统和人力资源，以完成共同的使命？架构联盟可以促进这种共享。通过构建各自的产品以满足共同的规定方向，MITRE 的赞助商将能够通过像 LEGO® 积木一样“将它们拼凑在一起”来重用组件架构，以构建范围更广和适用性更广的复杂架构。

参考资料和资源

1. Department of Defense, April 23, 2007, DoD Architecture Framework Ver. 1.5, Vol. I: Definitions and Guidelines.
2. Hite, R. C., and G. D. Kutz, March 28, 2003, Observations on Department of Defense's Draft Enterprise Architecture, GAO-03-571, accessed October 8, 2017.  
3. Frey, B., July–September 2008, "Department of the Navy Architecture Federation Pilot," CHIPS, pp. 41–43, accessed October 8, 2017. 
4. Air Force Chief Architect's Office, December 2007, Air Force Architecture Framework.
5. Department of Defense, DoD Architecture Registry System.

其他参考资料和资源

DoD Deputy Chief Information Officer, DoD Architecture Framework (DoDAF), accessed October 8, 2017.  

DoD Deputy Chief Management Officer, Business Enterprise Architecture, accessed October 8, 2017.

Government Accountability Office, August 5, 2010, Organizational Transformation: A Framework for Assessing and Improving Enterprise Architecture Management (Ver. 2.0), GAO-10-846G, accessed October 8, 2017.

原文：https://www.mitre.org/publications/systems-engineering-guide/enterprise…

本文：https://jiagoushi.pro/node/1940

Togaf架构师模块在第一次加载时提供了3个默认模型组织，Togaf、SOA或BPM。

视角选择

这些模型组织是建模帮助，但是您仍然可以以不同的方式组织您的模型。

Togaf结构

TOGAF架构组织在以下结构中:

业务体系结构在业务层中定义。

• 数据体系结构分为业务层和技术层，前者定义数据的概念层(“业务层/业务实体”下的业务实体)，后者定义持久数据的模型(“应用程序层/数据体系结构”)。在“业务实体”阶段，建模师关注概念及其属性，但不关注逻辑和物理方面，如存储库、关系模型等。建议首先对业务的重要概念建模，然后定义企业组织、业务流程和其他业务体系结构元素。
• 应用架构是在“应用层/应用架构”下构建的。它有两个应用程序域:“服务数据”，用于建模业务服务和系统用例之间交换的数据，以建模与IS的主要应用程序组件相关的用例。
• 技术架构是在“技术架构”技术领域下构建的。

SOA结构

SOA架构组织在这个结构中:

• 应用程序体系结构
• 硬件部署

BPM结构

BPM/业务架构组织在这个结构中:

• 业务层

根据目标Togaf架构的性质，这些域是专门的包，其中Modelio菜单建议创建适当类型的Togaf模型元素或Togaf图。

原文：http://forge.modelio.org/projects/togaf-modelio3-user-manual-english/wiki/Modeling_Model_Organization

本文：

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【1110777】

在本系列的前几部分中，我们讨论了国防和工业中体系结构的常见驱动因素，国防和民用领域的体系结构实践之间的共性，以及为什么选择ArchiMate语言作为在NATO体系结构框架中表达体系结构的推荐标准V4。在最后一部分中，我们将讨论在NAF v4环境中使用ArchiMate仍需要完成的工作。

 -  Kevin Wallis（MOD ISS）和Marc Lankhorst（BiZZdesign）

术语的差异

在此之前，我们概述了ArchiMate如何发展到其概念涵盖防御领域中企业架构的所有重要方面的程度。这并不意味着它是一个完整的一对一契合。 ArchiMate是为民间组织，组织和组织开发的。此外，防御领域的术语有时与政府或金融领域的术语不同。但是，通过简单的术语映射可以在很大程度上克服这些差异。完整的术语表对于博客文章来说太大（而且太无聊），但下表给出了相应术语的印象。

该映射表明，ArchiMate的概念世界足以表达防御域的需求。 有时，ArchiMate的专业化和刻板印象特征可能会有所帮助，但英国国防部决定直接使用ArchiMate，而不进行此类定制，以促进模型与行业的交流。

NAF v4的观点
在这种情况下，ArchiMate最重要的用途在于表达NAF v4规定的各种观点，这些观点列在下面所示的网格中。

Overview of NAF v4 viewpoints (from NATO Architecture Framework v4) 

重要的是，NAF v4对视点的使用是以信息为中心的;它将框架划分为建筑信息类别，而不是如何呈现信息（这是NAF v3方法）。这与ArchiMate在架构模型的内容和视图中的表示之间的区别完全一致;相同的模型元素可以存在于多个视图中，但是以不同的方式描述以解决各种观众。

以上所有观点都在NAF v4规范中有更详细的描述。下一步重要的是为这些提供ArchiMate示例。一些观点最好用简单的表格或网格（TOGAF术语中的目录和矩阵）表示，不使用ArchiMate的标准表示法，而是基于同一个底层模型。同样，使用统一架构框架配置文件（UAFP）可以更好地阐明一些详细的设计观点，这是另一个被批准用于NAF的标准。由于ArchiMate在设计时考虑了与其他标准的互操作性，因此同时使用它们不会带来任何概念上的问题。事实上，开放组和对象管理组都在与北约合作，就如何在两个标准之间有效地交换信息达成一致。

北约的联邦任务网络（FMN）参考架构，可以在Tidepedia上找到具有适当安全权限的人，在ArchiMate中表达，作为当前使用的符号的替代。这是一个相对简单的练习，虽然由于信息被分类，这里无法显示某些结果，但以下视图显示了一些工作。

MOD的方法
国防部信息系统和服务部（MOD ISS）也决定尽可能地利用通用的行业标准。为此，它将自己的架构方法集中在TOGAF和ArchiMate的组合上，与NAF v4一致。它目前正在实施“设计即服务”方法，其中行业合作伙伴可以负责设计某些架构。为了确保最终设计工件的兼容性和质量，它使用EA加速器，根据TOGAF架构开发方法（ADM）的各个阶段组织必要的架构视图。这也预先填充了模型，其中包含要遵循的模板和可重复使用的模式，以便标准化输出并重用现有知识。

这些模型的交换是通过独立于工具的ArchiMate Exchange格式完成的，允许承包商自由选择任何符合ArchiMate标准的工具。利用他们与NATO合作开发FMN参考架构的经验，MOD ISS正在开发他们的参考架构，称为防御作为平台（DaaP）服务架构。第一次迭代计划于2018年9月在英国政府网站GOV.UK上发布。

最后的笔记
总之，我们认为在防御中使用广泛接受的行业标准如TOGAF和ArchiMate提供了巨大的优势。在民用和国防领域使用的知识，经验和设计文物的轻松传输，以及广泛的工具支持和咨询经验肯定会有益于防御领域。相反，将ArchiMate作为北约批准的标准进行宣传将提升其受欢迎程度并进一步扩大其用户社区。这将使两个世界的建筑师能够相互学习，并相互受益于彼此的经验。

如果您想了解更多有关这些发展的信息，请随时与我们联系！

原文：https://bizzdesign.com/blog/nato-architecture-framework-archimate/

本文：http://pub.intelligentx.net/node/377

讨论： 加入知识星球【首席架构师圈】

“如果你想要新的东西，你必须停止做旧的东西。”
——彼得·德鲁克，《公司概念》的作者

这篇文章介绍了 Salesforce 运营、治理和架构框架 (SOGAF)，这是一个新的大规模治理框架，由对跨多个行业的学术文献、现有框架和转型案例研究的广泛研究提供支持。

为什么我们需要另一个治理框架？

我们已经看到技术驱动转型的两个根本性转变：技术模型本身以及实施和运营的方法。技术模型发生了变化，因为从内部部署到云计算的转变带来了许多好处，例如敏捷性、可扩展性、成本节约、最小的资本支出、增强的协作、随时随地工作等等。随着技术的这种转变，实施和运营的方法也从基于瀑布的、以项目为中心的交付模型转变为敏捷的、以产品为中心的持续改进模型。

转型三难困境

启动技术驱动转型的公司通常面临三难困境，即一组目标会产生不同的结果并带来特定的风险；他们必须从三个目标中选择两个来“保持在转型三角形的一侧”并推动成果。

让它纯净

• 这里的目标是通过快速实施标准技术来跟上业务的步伐，为所有用户组使用相同的设置⁠——“采用，不要适应”。
• 风险在于触发“意外后果法则”。一个架构层的标准化可能需要其他架构层的定制。例如，标准化数据库层可能需要对 UI 进行自定义。

做这一切

• 这里的目标是满足所有业务需求，避免回归（即丢失以前对最终用户可用的功能），并确保未来用户组的可扩展性，以满足他们的特定需求。
• 风险在于重建“云中的遗产”。通过解决遗留痛点来设计应用程序通常会导致将这些痛点“提升并转移”到新系统，而不是让架构随着业务发展而面向未来。

让它好

• 此处的目标是提供完整的技术驱动型业务转型（例如，从“实体”到在线）以及从瀑布到敏捷技术交付方式的过渡
• 风险在于，这可能会导致混乱。业务和 IT 都将摒弃旧方法，学习新方法，替换现有流程和系统，同时构建新的流程和系统。

为了成功实现数字化转型并降低这些风险，建议公司从三个可能的目标中选择最有可能单独实现且彼此最兼容的两个目标。例如，追求“纯”快速和标准化 Salesforce 实施的公司将难以在不损失功能的情况下满足所有业务需求。

这对 Salesforce 架构师意味着什么？

Salesforce 架构师负责管理技术驱动的转型并交付构建其业务未来的成果。架构师面临着许多与大规模治理相关的问题，例如：

• 如果以可比公司为基准，我们今天在哪里？
• 要自力更生，我们从哪里开始？我们可以从多小的开始？考虑到我们的背景，我们必须走多远？
• 我们需要哪些组织实体、能力、结构、角色和技能？什么时候？
• Salesforce 卓越中心 (CoE) 做什么？它与 Salesforce 设计授权 (DA) 有何关系？
• 我们如何确保端到端的一致性（业务、IT、项目、治理方法等）？
• Salesforce 的企业运营模式是什么？
• 我们如何将运营模型转化为架构或组织战略？

大规模的 Salesforce 治理

Salesforce 治理可以定义为组织公司能力、领导力、人员和管理的战略。 组织能力定义了如何管理 Salesforce 平台并确保最佳实践。 领导层决定了如何以及何时完成，以及由 CoE、变更控制委员会或架构审查委员会等实体完成。 人员和团队负责设计和交付价值，而管理层则确保一致性、合规性和兼容性或原因。
例如，治理的一个关键功能可能是确保交付团队遵循配置最佳实践。 这是通过与架构师和开发人员举行定期审查会议来以一致和合规的方式管理平台，最大限度地减少技术债务，并决定配置与定制来完成的。

介绍 SOGAF

我开发了一个新的大规模治理框架，因为现有的架构和实现框架，例如 TOGAF 和 Zachman，并不是为平台设计的。 Salesforce 运营、治理和架构框架 (SOGAF) 通过七种不同的功能及其端到端的一致性来大规模解决治理组件。 SOGAF 以学术文献为基础，并通过案例研究进行了实证验证，检查了这些能力中的每一个，以期回答有关大规模治理的常见问题。

1. 组织能力。设计、开发和部署所需的结构、角色和技能。
2. 共同实体 (CoE)。 CoE 的使命、范围和组织（或公司可能使用的该实体的任何其他名称）及其管理、启用、优化和确保产品采用的责任。
3. 设计权威。人员和流程的组织，以确保一致性、合规性和兼容性。
4. 运营模式。根据所需的业务流程标准化和数据集成水平，在整个公司内提供效率和可预测性的战略。
5. 架构类型和组织策略。基于运营模型确定 Salesforce 组织战略的能力、系统和功能的架构层。
6. 实施轴。 Salesforce 实施方法源自运营模式和业务目标。
7. 使命、范围和组织。基于 CoE、运营模型和实施轴的有组织的大规模治理支持计划。

SOGAF——一个由研究提供信息的框架

SOGAF 应用 MIT-CISR EA 模型和基于经验的实地研究方法来构建 Salesforce 转型计划和大规模治理框架。我分析并比较了转型计划的组成部分和功能与跨行业案例研究，以验证这个新框架。

SOGAF的创建包括三个部分：

• 第 1 部分。基于学术文献（五部分模型）、Salesforce 经验、案例研究和研究，定义大规模治理能力。
• 第 2 部分。应用 MIT-CISR EA 模型、价值学科和相关理论来定义规模模式的 Salesforce 治理。
• 第 3 部分。创建转型案例研究，以验证跨制造业、高科技、金融服务、消费品和能源行业的模型。案例研究的目的是为框架提供信息并特别回答以下问题：
  • 在实践中，治理模式是否真的可以识别？
  • 它们与运营模式相关吗？
  • 公司的实际用例是什么？
  • 组织和治理的成功模式是什么？

SOGAF 入门

您可以立即开始使用 Architect Digital Home for SOGAF Operating Models、Common Entity Framework 和 Architecture Types 上的可用资源，以帮助链接您的操作模型和组织战略。
作为即将推出的 Salesforce Enterprise Architect (EA) 计划的一部分，我还将发布有关 SOGAF 剩余功能的其他资源。这些剩余的能力将帮助架构师定义卓越中心的范围、使命和实施的具体重点。 EA 计划将包括业务架构课程中的几门课程，旨在为架构师提供大规模治理的最佳实践，并指导以业务为先的方法来推动技术决策。

有关 SOGAF 和更多 Salesforce Architect 内容的更新，请访问 Architect Digital Home。

原文：https://medium.com/salesforce-architects/an-operating-governance-and-ar…

本文：https://jiagoushi.pro/node/1871

Zachman和TOGAF是用于实现企业架构的框架。在本文中，我们将讨论两个最流行的企业架构框架：TOGAF和Zachman。我们还将包括如何选择以及额外资源的提示。

什么是企业架构？

企业架构（EA）是一种结构，用于传达组织的整个企业系统，包括技术、流程和信息资产。它从技术和业务的角度提供了各种各样的观点，允许组织采用一种有纪律的方法来管理这些系统。

换句话说，您的企业架构定义了可应用于企业IT和业务系统的选择约束，并且可以有三个核心组件：框架、方法和工具。使用EA解决了技术驱动型业务组织面临的两个关键问题：

• 在高度依赖的企业系统子集之间建立一个透彻的理解允许组织降低架构的总体复杂性。
• 帮助建立一个结构化和信息充分的决策过程，使技术与业务目标保持一致。

TOGAF：开放组架构框架

TOGAF是事实上的行业标准框架，为企业架构设计、规划、实现和治理提供了一种方法论方法。它提供了架构工件的一致视图，组织内的所有涉众都可以很好地理解。该框架的开放性使组织能够防止供应商锁定专有企业架构解决方案，允许他们在不遇到重大成本、安全和技术集成问题的情况下进行扩展和调整。

TOGAF框架在架构过程中提供了一系列可操作的步骤，称为架构开发方法（ADM）。ADM过程不是一个规定性的模板，而是一种通用的、适应性强的方法，可以应用于开发企业架构的各种组织用例。这些阶段可以根据不断变化的需求进行修改和重新排序，考虑到TOGAF-ADM使用迭代周期来管理和开发新的企业架构需求，这一点特别有用。

TOGAF的ADM部分提供了一个实现决策选择和生成所需模型的过程。这些步骤描述如下：

1. 架构（Architecture）远景：描述项目范围、确定涉众并获得必要批准的初始阶段。沟通业务目标和驱动因素。可以执行能力评估来评估现有的企业架构。
2. 业务架构（Business Architecture）：用于满足架构（Architecture）愿景的流程在此阶段定义。在此阶段，将与多个涉众协作执行详细的业务分析和建模。还规定了基线和目标的正式目标。
3. 信息系统架构（Architecture）：与前一阶段类似的活动现在针对支持架构（Architecture）远景的数据和应用程序架构（Architecture）执行。数据和应用程序架构的目标设计原则将在此阶段指定。
4. 技术架构（Architecture）：支持架构愿景所需的技术架构，特别是与业务和信息系统架构相一致的技术架构，在本阶段进行了详细说明。主要利益相关者将包括负责技术决策和投资批准的IT部门和高管。
5. 机会和解决方案：随着架构设计选择在早期阶段最终确定，将评估各种实现场景。此评估同时考虑了技术和业务方面，并确定了最佳折衷方案。
6. 迁移规划：这一阶段将吸引到上一阶段定义的最可行的决策选择和企业架构模型。根据成本、机会和风险制定实施策略。这些项目按优先顺序列出。
7. 实现治理：在此阶段，为所选项目指定必要的架构规范。在此阶段提供了一个完整的架构监督，描述了变更请求、合规性评估和解决方案构建块的描述。
8. 架构变更管理：在这个最后阶段，新的变更管理过程被定义为包含新的变更。

TOGAF有三大支柱，通过它们可以探索您公司的架构：

1. 企业架构域
2. ARM
3. 企业连续体

有关实现这个企业架构的TOGAF三大支柱和技巧的更多详细信息，请参见什么是TOGAF？TOGAF初学者指南。

Zachman企业架构

John Zachman是一位IT先驱，他了解IT驱动企业所面临的问题。为了解决这些问题，他在1987年开发了一个早期的企业架构方法论Zachman框架。

Zachman框架提供了一种基于模型的方法：

• 指定可交付成果
• 将企业系统子集的各个方面分类为矩阵形式
• 将它们与business-I环境的决策选择相关联。

使用矩阵，行根据列中指定的决策条件对组织中不同参与者的视图进行分类。列标题描述了什么、如何、在哪里、何时以及为什么。利用这些信息，每个矩阵单元描述每个企业子系统与组织的适当方面的关系。虽然框架没有提供实现指南或方法，但它通过提供整个企业架构的透视图，提供了工件的描述性焦点。

行类别包括：

1. 执行视角：描述业务目标和战略的范围上下文。
2. 业务管理视角：描述企业模型、设计选择和组织采用的流程的业务概念。
3. 架构师视角：描述如何满足业务需求的系统逻辑。
4. 工程师观点：技术物理学描述了如何使用技术解决方案来实现系统选择。
5. 分包商观点：这些描述了关于特定模块化工具组件的要求。
6. 企业视角：用户在其操作环境中所看到的运行系统。

有关框架的更多详细信息以及将其应用于公司的技巧，请参见Zachman框架简介。

选择TOGAF还是Zachman

您选择哪种企业架构取决于您的方法。

• TOGAF框架为定义创建或改进企业架构的过程提供了一种系统方法。通过它的ADM，框架提供了一个实现决策选择的过程，以便生成所需的模型。
• 另一方面，Zach框架更多的是一个本体论——一组结构化的表达式，描述了工件如何分类，从而创建、操作和更改。与TOGAF不同，Zachman使用各种企业透视图来确定、定义和计划有关企业系统的各个子集的详细信息。

您的组织可以选择使用其中一个，也可以同时选择这两个。这些框架可以相互补充，TOGAF描述了创建企业架构的详细过程，Zachman对人工制品进行了分类。

或者，您可以选择使用其他知名选项（包括ITIL？、PRINCE2或COBIT）来补充一个框架。

原文：https://www.bmc.com/blogs/togaf-vs-zachman/

本文：http://jiagoushi.pro/node/1075

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

您需要了解的关于使用企业架构管理工具管理TOGAF®架构开发方法的一切。

• TOGAF®是什么?
• TOGAF®和ADM流程的价值是什么?
• TOGAF®在现代环境中的挑战是什么?
• TOGAF®的敏捷方法
• 基础(TOGAF®A期)
• 基线和目标架构(TOGAF®阶段B、C、D)
• 转型路线图(TOGAF®E、F期)
• 实施(TOGAF®G、H期)
• 如何获得TOGAF®认证
• 总结

TOGAF®是什么?

TOGAF(开放式集团架构框架)已经被企业架构师(EAs)用作规划IT开发策略的通用语言超过25年了。该计划于1995年成立，目的是协助企业和企业架构师以有组织的方式协调跨部门项目，以促进主要业务目标的实现。特别地，根据Open Group architecture Forum, TOGAF®的基本目标是通过以下方式支持关键业务需求:

• 确保每个人都说同样的语言。
• 通过对企业架构的开放方法进行标准化，避免锁定于专有的解决方案。
• 节省时间和金钱，更有效地利用资源。
• 实现可演示的ROI。

为了确保以系统和可重复的方式实施上述内容，可以在不同阶段遵循名为TOGAF®架构开发方法(ADM)的可定制过程，以管理任何大规模IT现代化工作的需求。

TOGAF®和ADM流程的价值是什么?

TOGAF®的ADM流程是专门为加快企业架构的四个领域的工作流程而设计的:

• 业务架构，它负责映射业务的操作层次结构、策略、功能和计划之间的关系。
• 应用程序架构，负责定义处理公司数据的相关应用程序，以及在整个基础设施中实现和部署这些应用程序的方法。
• 数据架构，它负责定义存储和集成数据的规则和标准。
• 技术架构，定义平台、服务和所有周围的技术组件，作为开发团队的参考。

图1:TOGAF®架构开发方法

通过TOGAF®ADM过程的九个阶段，这四个架构域将被迭代开发，以创建一个能够确保组织变革的平衡架构。作为一个行业不可知的过程，该方法旨在限制猜测，并促进企业架构程序的成熟——所有这些都同时聚集了企业特定的架构存储库来支持未来的项目。

TOGAF®在现代IT环境中的挑战是什么?

TOGAF®目前处于9.2版本，随着其定义和符号库的不断发展，以敏捷的方式与框架保持一致是不可避免的。这在很大程度上是由于TOGAF®的全面的架构遵从性审查过程，一个检查表涉及数百个项目的类别，例如:信息和系统管理;硬件和操作系统;软件服务和中间件;应用程序(业务、基础设施和集成规范);和信息管理。

然而，尽管遵从性是架构治理中不可缺少的元素，虔诚地遵守框架的标准对任何企业架构程序来说都是一项困难的任务。因此，对于希望有效地维护TOGAF®最佳实践的现代组织来说，为了有效地评估和编目it项目，在整个组织中获得利益相关者的参与是非常必要的。敏捷和TOGAF®确实能够共存，但为了实现这一点，必须建立团队间it实体标准化的协作途径。

敏捷方式的TOGAF®

一种弥合TOGAF和敏捷架构框架之间差距的流行解决方案是用于协同执行企业架构管理的共享平台。例如，LeanIX自己的企业架构套件(EA套件)提供了在ADM过程的每个阶段协同定义、实现和跟踪IT实体的功能。

特别是，它的好处可以在以下方面得到不同的应用:

基础阶段(阶段A)

当铺设ADM的第一块砖时，一个人必须:(1)定义一个架构愿景;(2)审查整个项目的范围;然后(3)计划哪些利益相关者将参与。LeanIX EA套件提供了一个灵活的数据模型，能够支持任何TOGAF®项目。

您公司的特定战略和业务模型将决定您的架构愿景的范围，因此考虑将TOGAF®“架构工作请求”和“架构定义文档”直接附在LeanIX事实表中——用于架构对象的所有信息的单页存储库——以补充阶段a。

项目事实表还可以为您的adm存储中心信息。这些页面可以定制，以显示估计的设置和实现时间线、预算成本、涉及的供应商，以及所有相关的应用程序及其相关的业务能力。

在ADM的早期阶段，LeanIX EA套件可以促进TOGAF®:

事实表格订阅

通过将个人分配到事实表中，列出与您的操作属性相关的名称和角色——无论是“负责的”、“观察者”还是“负责的”。这是一种简单的方法，可以看到谁参与了架构的开发以及出于什么原因。同样，事实表不仅可以配置为显示高层次的战略驱动，还可以显示对正在审查的应用程序负责的个人。

举例:在以下的“AC管理V1”情况说明书中，有三个不同工作职能和职责的人附在申请中。因此，谁负责维护数据就很清楚了(见图1)。

图1:IT管理角色设置

LeanIX EA套件中相关项目和应用涉众的视图。

基线和目标架构(阶段B、C、D)

在阶段A中设置了您的架构视野之后，是时候确定基线和目标架构之间存在什么差距了(例如，您拥有什么和您想要什么)。从业务到信息系统到技术架构，阶段B、C和D是揭示操作中实际存在的内容的阶段。

这时来自LeanIX EA套件的以下报告工作得最好。

在您的IT应用程序版图中实现合并后的协同作用[白皮书]:找出存在哪些巩固IT应用程序版图的方法，以及应该采取哪些步骤来从合并中巩固IT版图。»

应用景观

一旦应用程序被映射到业务功能并与如何使用它们的信息结合在一起，就可以对应用程序环境进行战略概述，以确定它们在未来架构中可能提供的好处。根据应用程序的使用级别和价值，判断应用程序是否应该保持不变，是否应该通过投资进行现代化以保存正在进行的业务价值，是否应该由于冗余而合并或替换，或完全消除(参见图2)。

图2:LeanIX应用程序景观报告

一份应用前景报告，通过五个等级(“不适当”、“不合理”、“适当”、“完全适当”和“不适当”)来说明某项行动的应用在技术上的适用性。

数据流可视化工具

数据流可视化工具详细说明了如何处理和交换数据对象。在visualizer中可以使用多种级别的技术属性，以帮助企业架构师获得应用程序完全集成的全面知识。

下面看看“AC Management V1”在操作中与其他服务绑定的方式。它直接发送到“HR Admin”，而“Payroll Europe”则与“Payroll Europe”通信，从而为“Salary Compact”提供数据(如图3所示)。

图3:LeanIX数据流

图表化应用程序的集成和处理的数据流可视化工具(“AC管理V1”)。

IT组件矩阵

检查IT组件(例如，数据库、操作系统、Web服务器等)及其相应的技术属性和服务生命周期，这些技术属性和服务生命周期来自IT组件矩阵报告中的所有操作层次结构。值得注意的是，LeanIX EA套件使用技术栈对IT组件进行分类，以实现对技术环境的完整概述。例如，如下面的图4所示，可以检查为提供者提供服务的生命周期。

图4:LeanIX IT组件矩阵

IT组件矩阵报告，显示操作中的各种技术组件(按提供商和技术堆栈进行安排)。

转型路线图(E、F阶段)

在架构被有效地描述和目标明确之后，E和F阶段是具体地定义未来步骤的时候。架构的重新设计发生了什么变化——蓝图能够指导涉众吗?

有了LeanIX EA套件，用户可以设计技术路线图，以避免淘汰和预见价值使用:

项目组合

按原样，一个项目对整个操作的现值是多少?LeanIX项目组合报告根据业务价值和项目风险对应用程序进行分组，以识别当前的需求。如果IT经理想知道保留或抛弃哪些应用程序，可以通过查看报告来进行评估(如下面的示例所示)。

如图5所示，架构数据的集群对业务价值提出了“显著的好处”，但也存在问题的分组只提供“边际好处”。

图5:LeanIX项目组合

显示业务价值与项目风险的项目组合报告。

应用矩阵

通过LeanIX应用程序矩阵报告的生命周期视图，确定不可或缺的应用程序何时将被淘汰——或者它们是否已经被淘汰了。请注意下面的图片，它显示了按部门和国家/地区列出的应用程序。巴西的“AC管理V1”服务将于2019年结束，但“AC管理V2”正在排队取代它。

除了生命周期之外，还有许多其他视图。根据功能是否适合应用程序质量的高级细节进行排序，以确定它是“不合理的”、“不够充分的”、“合适的”还是“完美的”。

图6:LeanIX应用程序矩阵

操作应用程序的生命周期，按年和工作状态安排，如LeanIX应用程序矩阵报告所示。

一个用LeanIX实现TOGAF的敏捷框架[海报]:一个循序渐进的演示如何使用精益EA工具遵循TOGAF的原则。»

应用路线图

很重要的一点是，要知道当申请的期限结束时，是否有合适的继任者。LeanIX应用程序路线图报告清楚地向用户展示了哪些是活动的、持续多长时间的，以及哪些正在准备取代它。此外，应用程序路线图列出了任何应用程序相应组件的生命周期。

在下面的路线图中，我们可以看到“AC管理V1”及其相关继任者的生命周期时间表。尽管它似乎在逐步淘汰(黄色)的过程中发生冲突，但应用程序的替代品(“AC Management V2”)保证会上线，以确保一个干净的过渡。

图7:LeanIX应用程序路线图

LeanIX应用程序路线图报告，按年显示应用程序的服务生命周期和后继程序。

实施(G、H阶段)

一切决定。愿景已经草拟，需求已经完美地向建设者表达。现在是实现架构的时候了。

使用LeanIX的变更管理协作方法密切监控其构建。LeanIX EA套件实现了TOGAF®ADM最后两个阶段的跟踪:

指示板

在与LeanIX EA Suite主页绑定的可配置拖放仪表板中，可以观察到与项目相关的新操作和未决操作。仪表板展示了治理体系结构需要什么，所有这些都在一个地方，以指导工作流和支持响应EA行为。

图8:LeanIX仪表板

LeanIX EA套件中的仪表盘显示“每个业务的应用程序临界性”和“数据敏感性”统计数据。

调查工作流程

更新项目所需的信息可以从所有责任方收集，而无需发送单独的邮件。使用LeanIX调查，EAs可以请求关于紧迫主题(如GDPR)的当前数据，将信息保存在模板中以供重用，并以明确的术语返回结果——即使调查仍在运行。

如下图所示，在一个与IT安全标准相关的示例中，用户可以向LeanIX调查添加自定义参数。

图9:LeanIX调查

查看LeanIX EA套件中的调查模板(“根据IT-Grundschutz评估应用程序安全性”)。

应用景观

检查过去、当前或计划的公司范围内的应用程序的生命周期。在LeanIX EA套件中直接查看这些数据，或者直接下载到。pdf表单中。

在下面的例子中(图10)，许多分配给客户关系管理类别的应用程序都处于“淘汰”或“生命结束”阶段。

图10:LeanIX应用程序的景观

应用程序全景报告中的应用程序的生命周期。

如何获得TOGAF®认证?

要理解LeanIX EA套件带来的变革好处，最可靠的方法之一是花时间学习TOGAF®的基础知识。要做到这一点，TOGAF®9.2认证可在通过开放组的两项资格考试后获得，培训可通过自主课程或经认证的项目进行。

TOGAF®提供的两种认证是:

• TOGAF®9.2 Foundation(验证个人理解“TOGAF®术语、结构和基本概念，并理解企业架构和TOGAF®标准的核心原则”)。
• TOGAF®9.2认证(确认了除了TOGAF®9.2基础之外，候选人能够分析和应用这些知识)。

更多关于获得TOGAF认证的信息，请访问开放集团的网站。

总结

今天的IT管理敏捷方法的成功很大程度上归功于TOGAF®首先设置的架构标准。然而，在蓬勃发展的现代企业中，数字化的热潮要求企业体系结构——不管是新体系结构还是老体系结构——认识到所有最佳实践，以便真正集成信息、业务和技术网络。

在LeanIX EA套件中使用报告和数据收集方法来简化TOGAF®ADM的各个阶段，这是一种将数十年的EA最佳实践全部利用起来的方法。

是否建立你的

• (1)基础架构愿景使用全面的事实表,
• (2)评估current-to-future业务基础设施与应用景观的视图,
• (3)做投资决策的应用程序使用详细的指标和矩阵,
• 和(4)监督实现可配置的仪表板和调查,

LeanIX EA套件旨在满足企业架构师的每一个品种。

原文：https://www.leanix.net/en/togaf

本文：http://jiagoushi.pro/node/1226

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

Zachman框架是John Zachman在1987年提出的，成为工程企业架构中广泛使用的方法。它以信息系统架构框架（frameworkforinformationsystemarchitecture）的名义发表在IBM的系统期刊上。Zachman于1964-1990年在IBM工作，是IBM业务系统规划（BSP）的创始人之一。

Zachman框架背后的基本思想是，可以使用不同类型的描述，以不同的方式为不同的目的描述相同的复杂项。这个框架提供了36个必要的类别来完全描述任何东西，特别是复杂的东西，如制成品。这36个类别由6行6列组成，采用二维矩阵的形式。

框架的六行是：

1. 计划者视图（范围上下文）-此视图描述业务目的和策略，为其他视图定义竞争环境。
2. 所有者视图（业务概念）–此视图显示企业的哪些部分可以自动化。
3. 设计器视图（系统逻辑）–此视图概述了系统将如何满足组织的信息需求。
4. 实现者的观点（技术物理）–这是一个系统在解决生产约束时如何实现的表示。
5. 子构造函数视图（组件组装）-这些表示说明了特定系统元素的实现细节。
6. 用户视图（操作类）-这是操作环境中运行系统的视图。

这些列表示向企业提出的疑问或问题。

1. 什么（数据）–什么是业务数据、信息或对象？
2. 如何（功能）–通过定义流程，业务是如何工作的？
3. 哪里（网络）-业务运营在哪里？
4. 何时（时间）-何时执行业务流程？
5. 为什么（动机）–为什么选择解决方案，它是如何产生的，以及是什么激励了某些活动的执行？

Zachman框架的规则

Zachman定义了7条使用框架的规则。

规则1：不要向框架添加行或列。

几千年的语言经验将确定这六种原始疑问句是谁、什么、何时、何地、为什么以及如何。如果你能回答所有这六个问题，那么你就可以得到关于主题或对象的任何其他问题的答案。向框架中添加行或列将使分类方案非规范化。

规则2：每一列都有一个简单的泛型模型。

在我们的案例中，框架的每一列都描述了分析目标企业中的一个独立变量。因此，任何一列的基本泛型模型都非常简单：它表示的变量（抽象）与自身相关。

规则3：每个单元模型专门处理其列的泛型模型。

任何给定单元格的特定模型都必须根据行透视图的约束、语义、词汇表、术语和事实进行自定义。此外，考虑到单元描述构成了管理变更的基线，因此（元）模型将必须表达由变更到该单元模型所影响的所有概念。因此，给定单元格的特定（元）模型将从通用的列模型开始，根据行的语义约束进行调整，然后可能进行扩展，以容纳所有相关概念，用于表示单元格行透视图的约束以及管理对单元格模型本身的更改。

规则4：任何元概念都不能分为多个单元。

该框架构成了一个干净的规范化分类系统，每一列都是唯一的。没有一个元概念可以分为多个单元。没有冗余。这是使框架成为良好分析工具的一个基本因素。

规则5：不要在单元格之间创建对角线关系。

首先，业主、设计师、建筑商和分包商都在用同一个词来表示完全不同的东西，这就造成了一个非常混乱的沟通问题。企业中的人可能会说同一种语言，使用同一种语言，但可能无法有效地相互沟通。禁止对角线的结构原因是因为细胞关系是传递的。在逻辑上更改单元格可能会影响同一列中的上下单元格以及同一行中的每个其他单元格。

规则6：不要更改行或列的名称。

不要在通用框架或企业特定框架中更改行或列的名称。如果更改行和列的名称，也会更改受影响行或列的含义。您可以对框架进行反规范化，使其不再全面。

规则7：逻辑是通用的和递归的。

框架的逻辑是通用的。它可以用于对任何事物的描述进行分类，并分析与其架构组成相关的任何事物。它是递归的。它可以用来分析建筑结构本身。框架是惰性的。它不知道用来分析什么。只有分析人员知道分析对象并确定分析的边界，所选择的分析边界具有深远的影响。

Zachman框架是如何使用的，在哪里使用的？

在当今复杂的业务环境中，许多大型组织很难应对变化。这一困难的部分原因是缺乏对组织不同领域中复杂结构和组件的内部理解，在这些领域中，有关业务的遗留信息被锁定在特定员工或业务部门的头脑中。

Zachman框架提供了一种对组织架构进行分类的方法。它是一个主动的业务工具，可用于为组织的现有功能、元素和流程建模，同时帮助管理业务更改。该框架借鉴了Zachman在复杂产品中如何管理变更的经验。John Zackman强调框架可以扩展到整个企业架构，而不仅仅限于信息架构。

John Zachman认为框架被用作：

1. 一个计划工具-帮助你定位问题并做出明智的选择。
2. 一个解决问题的工具——控制业务抽象的复杂性，实现单个业务变量的隔离。
3. 通过将工具和方法映射到框架来评估它们，从而证明一种中立的方式来对它们所做和不支持的事情进行编目。
4. 用于构建灵活的组件架构和系统的上下文，这些架构和系统能够支持高比率的企业更改，并替换由于“上下文外”而“未集成”的“现有系统的库存”

将Zachman框架付诸实践。

在Zachman框架中开始的逻辑点应该在二维矩阵的左上角，然后沿着表格向下。用于表示特定业务领域的相关业务信息或模型可能已经存在于业务计划、项目计划、系统规范、程序指南或其他文档中。

当你浏览这个矩阵时，会有一些空白需要填补，其中只有一个人或少数专家知道的隐含信息需要明确，并提供给更广泛的受众。可能存在重叠或冗余的情况。目标是管理变更，减少冗余和重叠。

本文：http://jiagoushi.pro/node/1076

讨论：请加入知识星球【首席架构师圈】或者加小号【ca_cea】

我惊讶于有人发现他或她可以通过企业架构和 IT 架构实现什么时闪闪发光的眼睛。
这种奇妙的效果通常始于一次随意的对话，例如当您在某个活动中第一次见到某人时发生的一种情况，揭示了您所在行业的颠覆性变化。
前几天我进行了那次谈话。
从主会议室出来，我口渴了，就往吧台的方向走去。新饮料？当然，算我一个。这种饮料异常绿色。与我童年在巴黎时使用的“空竹薄荷”中的一种颜色相同。但是这个玻璃是有雾的。当我看着接受者试图猜测魔法药水是由什么制成的时，调酒师正在观察我。犹豫的时候，他说：“是从日本来的。你会喜欢的”。尽管他很有信心，但他并没有说服我。他怎么会知道我的口味呢？尽管如此，我还是喝了神秘的饮料，而且，天哪，他是对的。 ——不管叫什么名字——都很好吃。
我旁边的人正在尝试一种雾红色的丹药。当她看到我脸上的惊讶时，她参与了谈话。
“这是一个有趣的演示。很棒的演讲者。如今，一切似乎都被技术加速了，不是吗？嗨，我的名字是 X，我是 {cool company name} 的数字主管。”
我礼貌地回答，自我介绍。
“很高兴见到你。我叫扬尼克。 ING 首席架构师”。我和她握手，接着说：“确实，我们正在经历有趣的变化。为了更好，我相信。”

“啊，所以你是从事房地产建设的？非常好！事业蒸蒸日上，你一定是个幸福的人！”

“我确实在施工。然而，我建造的是企业，而不是架构。”

她停顿了几秒钟。 “你是什么意思？你不是在管理自己的建筑公司吗？”

“不是一家公司，而是地球上最大的金融技术集团之一的企业架构部门。不过，这感觉就像经营自己的企业一样。我团队的专长包括以最优化和可持续的方式有条不紊地设计和规划产品、服务甚至整个业务线的开发。我们提供的一切都符合客户的需求，并根据其财务、时机、机会、技术、监管范围等进行。我们考虑所有方面。基本上，无论多么复杂，我们都能为您提供解决方案。”

“啊，有趣！我什至不知道有这样的工作。 “所有方面”，你的意思是……？”

• “假设您想出了一个绝妙的主意，通过提出新的产品线或重新考虑您的服务来使自己与众不同。使用企业架构构建方法，我将首先指导您定义和详细说明您的需求和您想要实现的目标。很多时候，你认为你想要的并不是你需要的。

• 其次，我会问你一些问题来发现需求，包括一些你一开始没有考虑过的问题，还有一些你不认为关心它们很重要的问题。

• 第三，我们将列出您的限制条件并找出您必须遵守的法律框架。鉴于您的预算和资源，我将与您核实您期望的结果。目的是从一开始就揭开信仰的神秘面纱，然后我将与您分享如何获得您想要的东西。它类似于建筑行业，您必须遵守一些规则，例如环境准则、使用的材料、施工许可等。”

“好吧，我现在开始明白了。告诉我更多。”

“当然。

完成上述活动后，架构师进行第一次设计。这是满足您期望的解决方案的草图。目的是评估影响，同时使产品更加直观和有形。随后进行了一些研究，以尽可能最好的方式确定可以满足您需求的组件。我用 S 说“方式”，因为重要的是您在此过程中所做的选择。这一切都归结为为您提供替代方案以保持您的选择自由。
最终，架构师将引导您做出最佳决策。
在这个设计阶段，它们是几个研讨会、讨论、谈判和信息会议，以详细说明主解决方案设计并精简财务分析。

从那时起，我们将根据协议和工作范围共同启动档案。这种相互理解就像合同一样。

• 第一阶段从订单开始，其结果将是对您的需求、架构蓝图、施工规划、报价的迭代分析，与产品开发公司的任何合作伙伴都可以从中制造您的产品和服务。”

“这看起来是一项非常有趣、非常复杂且要求很高的工作。你能在所有这些领域都有知识吗？ “

• “视情况而定”——这是架构师最喜欢的名言。

“架构师至少是两个领域的专家：业务领域和技术领域。它们是 PI 形的。例如，我的职业生涯始于开发工程师，后来发展成为信息系统集成专家，专业是金融服务和保险。

此外，他们必须了解其他领域的目的和机制，以及它们如何组合在一起。他们培养了系统思维。例如，一家公司有一个营销部门、一个财务部门、一个 IT 部门、一个销售部门等。它们中的每一个都有其存在的特定理由，并且它们由大量的活动组成，这些活动是其基本要素。公司机器。在销售之前，营销的目的是展示、展示、吸引客户，同时分析潜在客户，同时继续吸引现有客户。为了更好地销售，IT 将产品的销售目录和规格数字化，同时在移动应用程序上提供 CRM，以便销售人员可以随时随地与潜在客户联系。
我可以继续说下去，但重点是架构师将这些领域中的每一个、每个用户交互、每个流程、每个应用程序、每个技术、每个数据、每个技能都视为一个构建块，需要组装起来以满足您的需求并遵守与商定的要求。这就像得到几盒乐高积木，找出相关的积木，并详细说明实现构建的说明。因此，无需成为多个领域的专家，但您需要了解他们的目的并了解行业如何与您的客户相关。在实践中，我们会在需要时联系专家。”

“嗯。这听起来很容易理解，但执行起来却很复杂。”

“你是对的。”

• “但我以前怎么没听说过企业架构师？想想看，从企业达到一定规模的那一刻起，你的工作就显得很有必要了。”

“也许你做到了，架构师比你想象的要多。由于各种历史原因，架构与信息技术部门相关联。因此，大多数时候，公司里的人都认为我们就像做 IT 工作的 IT 人员，而我们提供的是业务和技术战略、业务和工程分析、业务和工程设计、业务和工程规划以及业务和工程创新。
价值链中的几乎每一个变化和改进都需要软件和硬件。所以这并不让我感到惊讶，我们的核心技能是工程。我们在制造可预测性和精度方面茁壮成长。
尽管如此，我完全理解为什么人们将架构师仅归类为技术领域，如果他们不断地使用他们的专业知识的一部分来展示自己。有时候很舒服！”

“或许。既然你提到了。通常，每当我们需要更改、创建新功能或修复问题时，我们都会与 IT 专家讨论。我们信任他们，但有时感觉他们让事情变得过于复杂。”
我们俩都开怀大笑。
“我只是在这里分享我的感受。我无法评估他们是否可以做得更快或更好。我们知道他们会尽力而为。然而，我们希望我们拥有更灵活、更现代的 IT 系统、更自动化的东西和漂亮的用户界面。好吧，至少他们确实有效！”

“相信我，这才是最重要的。我有一个非常简单的架构座右铭：

• 第一，它需要一直工作得很好，
• 第二，它必须易于使用、记忆、教学和维护
• 第三，它应该看起来很棒。”

“但愿如此。不过，这让我想知道……如果业务和 IT 人员已经可以构建东西，我为什么需要架构师？”

“好问题。为了回答你，我要开始：我更喜欢你不需要我。”

“我没想到会这样。我很困惑……也很好奇！”

“我知道。为什么您需要土木建筑师来修理灯泡、更换厨房水槽，甚至更换建筑物的外墙？不，您不需要参加活动。你打电话给电工、水管工或者你自己做。您需要专业的建筑商或维修人员。自治对每个人来说都是最好的。但是，如果您正在寻找建造新房子、用新房间扩建房子或改变浴室的位置，您可能需要致电您的建筑师。最终，您可以在没有人的情况下做到这一点。但是，您决定冒着风险花费比预期更多的钱，让建设花费比预期更多的时间，收到可能不符合您期望或更糟的东西。
决定权完全在你。”

“我明白你的意思。那么我应该何时何地聘请架构师？我需要蝙蝠符号吗？”

“对于大多数小的变化，你不需要架构师。经验法则，如果结构没有改变，影响的规模和数量保持相似，您就不会触及您的基础，也不会带来任何新的实质性数据或业务功能，请询问您的工程师或高级业务分析师做出改变。但是在某些时候，您的公司变得足够大，以至于人们开始失去视线、控制权和对一切如何结合在一起的理解。企业的系统过于复杂，无法由每天忙于特定任务的人处理。此外，这既不是他们的核心知识，也不是他们的核心活动。似乎这还不够，技术颠覆的步伐还在不断加快。
根据经验，当您执行以下操作时，您需要一名架构师：

• 想要一些定制的东西
• 正在处理复杂的工作计划
• 不知道从哪里开始
• 需要获取或利用一项技术
• 寻求指导以构建可持续和可扩展的企业功能
• 需要以良好的准确性计划可行的策略
• 要么你想要每个人都能得到的东西，要么你想要定制的东西。”

“有不同类型的架构师吗？我的意思是，我们有不同类型的建筑工人，比如水管工、木匠、电工等。”

“架构师是……架构师。有架构师的味道。假设他们有专长。他们中的一些人是基础设施方面的专家，一些是数据方面的专家，还有一些是软件方面的专家，而另一些人则专注于特定行业的专业知识。从客户的角度来看，唯一重要的是他们提供相同的服务并且他们一起工作。
他们具有相同的基本知识和操作方式。不过，架构师的技术可能有所不同。随着 Zachman、TOGAF 等各种架构方法的实践。一些公司建立自己的，因为它更适合他们的行业和他们的组织，例如 EAgile for ING。有些更专业，比如我针对初创公司和创新组织的 AMASE 方法。
我可以告诉你更多，但我会把这个留到下一次。”
“我感谢您的这些解释和您的时间。坦率地说，这令人大开眼界。我需要和我的执行同事谈谈。”
“我很高兴，X 女士。还有一件事。你知道“架构师”这个词的由来吗？”
她看着上方，仿佛在看记忆深处的答案。然后一秒钟后，火花。她用闪烁的眼睛说：“架构大师！”。

原文：https://yannick-huchard.medium.com/leading-you-to-the-best-decision-70a…

本文：https://jiagoushi.pro/node/1886

在这个圣帕特里克节，当您选择最适合您的组织的企业架构(EA)解决方案时，如果有一罐金子和爱尔兰人的运气在您这边不是很好吗?为自己倒上一杯醇厚、柔滑、奶油味的吉尼斯黑啤酒，然后悠闲地考虑该选择哪种EA工具，这听起来很愉快，但其实还有更好、更有效的方法来选择合适的工具。当你完成了工作，并为你的公司选择了最好的EA工具之后，那么无论如何你都应该获得吉尼斯——你已经赢得了它!

投资于企业架构解决方案是一个明智的业务决策，它将增加透明度，并为提高效率和业务增长提供机会。考虑将应用程序链接到流程，以了解IT系统在多大程度上支持业务活动。或者，您可能希望对系统有更高的可视性，这样就可以执行影响分析，并在计划更改时更快地做出决策。EA解决方案将帮助您执行这样的计划。

无论您是希望实现一个工具来解决一个特定的挑战，还是推出一个企业范围的解决方案，在为您的公司选择最佳工具之前，都有一些重要的问题需要回答，还有许多问题需要考虑。您应该评估哪种工具?您与解决方案供应商的关系有多重要?你的员工的过渡会有多顺利和容易?这些是选择EA工具时需要考虑的基本问题的示例，然后再决定是否使用EA工具，并沿着实现路径开始赚钱。

为了让您开始您的成功之路，这里有3个步骤来帮助您为您的组织选择正确的EA工具。

1. 确定你的短期和长期目标。

您的组织正在经历什么样的挑战?您认为您的新EA工具将提供哪些好处来帮助克服这个挑战?确定你希望在最初的6个月到1年内实现的可衡量的目标。这些目标不需要是大规模的、无所不包的变更，但是每一个都应该使您更接近于向业务交付价值。对于你设定的每一个目标，考虑问问自己这对企业有什么特别的帮助?

2. 寻找灵活的EA解决方案供应商，与您合作，而不是与您作对。

理想情况下，您应该热爱您的EA工具供应商，并将该公司视为您的合作伙伴和可信任的顾问。一个有知识的专业人员，为你腾出时间，并真正有你的公司的最佳利益，将是你最好的资产之一，并为你提供宝贵的指导，你开始这一旅程，以改善你的运作。他们以前已经成功地做到了这一点，也可以帮助你做到这一点。

3.确保解决方案能够随着业务的增长而增长。

灵活的、可扩展的、可以集成到日常业务操作中的解决方案将比点解决方案提供更多的长期ROI。你不希望每隔几年就购买新的EA解决方案。因此，在今天扑灭紧急的、燃烧的大火很重要的同时，您还需要利用特性和可见性来满足明天扩展操作的需求。要从EA解决方案中获得最大的投资回报，请在评估供应商时考虑您现在和以后的需求。

愿爱尔兰人的好运(和一些明智的选择策略)与你同在!

愿你的双手永远有工作可做

愿你的钱包里总是装着一两个硬币;

愿阳光永远照在你的窗玻璃上;

愿每一次雨后都有一道彩虹;

愿朋友的手常在你身边;

愿你的EA工具使你心中充满喜悦。

 

Zachman 框架使用 36 列矩阵来帮助组织您公司的企业架构并深入了解您组织的 IT 资产。

什么是 Zachman 框架？

Zachman 框架并不完全是一种方法论，至少不像大多数 IT 管理框架那样，主要是因为它不提供处理数据的特定流程。相反，它被认为是一种“本体”或“模式”，可以帮助组织企业架构师工件，例如文档、规范和模型。该框架考虑了受工件影响的人，例如企业所有者，并将其与正在解决的问题或问题进行权衡。

Zachman 框架最初由 IBM 的 John Zachman 于 1987 年开发，此后经过多次更新。它旨在组织和分析数据、解决问题、规划未来、管理企业架构和创建分析模型。
Zachman 框架在今天仍然与现代企业息息相关，主要是因为技术环境变得越来越复杂，遗留技术和信息分散在整个组织中，经常被转移到其他系统和解决方案的员工所迷失。借助 Zachman 框架的 36 列矩阵，您可以对组织的所有架构进行分类，通过让您详细了解公司的 IT 资产，帮助您的组织在面对变化时保持敏捷和灵活。

Zachman 框架模板

Zachman 框架使用 36 个类别来描述从产品到服务，再到硬件和软件的任何事物。类别按六行六列组织，形成一个包含 36 个单元的二维矩阵，可帮助您可视化主题、问题或产品。

Zachman 框架模板的列概述了围绕所讨论架构的基本问题（谁、什么、在哪里等），而行代表项目中涉及的每种类型的利益相关者的观点。然后根据每个单元格中代表的基本问题和观点，在完成的矩阵中填写流程、必要的材料、重要角色、相关位置以及与项目相关的任何目标或规则。

Zachman 框架矩阵的六行包括：

• 规划者的观点（范围）：这一行是您确定业务计划或战略并确定矩阵中将解决哪些问题或关注点的地方。
• 所有者的观点（业务概念）：第二行是您将确定业务需求和业务执行计划所需的资源的位置。
• 设计师的观点（系统逻辑）：第三行确定计划将如何满足业务需求。这一行对应于处理业务流程的数据、流程和功能的系统分析师所做的工作。
• 工程师的观点（技术物理）：第四行包括有关如何实施战略以及团队将使用哪些工具、技术、材料和约束的相关信息。
• 技术人员的观点（组件组装）：在这一行中，您将包含对产品、服务或硬件的需求表示。
• 用户视图（操作类）：最后一行包含有关功能系统及其在 IT 或业务环境中如何工作的信息。

Zachman 框架模板的六列包括您将在此过程中提出的所有问题：

• 什么（数据）：您可以在此处确定项目所需的业务数据、信息和要求。
• 方式（功能）：“方式”或“功能”列标识流程如何工作和影响业务。
• 地点（网络）：此栏包括“地点”，其中包括所有系统网络和进行业务运营的相关地点。
• 谁（人员）：在第四栏中，您将确定关键利益相关者并确定项目的所有相关人员。
• 何时（时间）：第五列是您将确定何时何地在公司中执行业务流程的位置。
• 为什么（动机）：最后一栏是您将确定选择最终解决方案的原因以及倡议或项目背后的动机。

Zachman 框架规则

该框架旨在与物理对象和概念想法一起工作。要填写矩阵的列和行，您需要来自利益相关者的输入，并且可能包括冗余和重复信息。我们的目标是尽可能减少这些冗余，最后以一份简洁的文档为您的组织的企业或 IT 架构提供清晰的画面。

Zachman 为完成二维矩阵建立了七项指导规则或原则：

1. 列没有顺序，但应从最重要的类别开始按自上而下的顺序排列。这将特定于您的 IT 项目或关注点，并且在应用于其他产品或服务时可能会发生变化。您应该避免添加或删除任何列或行，因为您将需要它们来获得完整的画面。
2. 每列都有一个简单的通用模型，并且可以在该列中拥有自己的元模型。
3. 每列的基本模型必须是唯一的，并且避免在任何其他列中重叠或复制数据。
4. 每一行都描述了一个独特的、独特的视角。您应该避免将任何元模型或概念归于多个单元。该框架的一个关键元素是它避免了最终二维矩阵中的所有冗余。
5. 如果您成功使用规则 2、3 和 4，您应该有一个矩阵，其中每个单元格都是唯一的。强烈强调这一点，也是该框架的基石之一，从而为您的架构提供了独特的详细和信息丰富的视图。
6. 避免更改行或列的名称。如果利益相关者以不同的方式使用相似的术语，这可能会改变含义或引起混淆。
7. 该逻辑是递归和通用的，这意味着它可用于分类或分析与所讨论的企业架构相关的任何内容。由分析师来确定目标和边界，这些决策会对矩阵的最终结果和计划或项目产生重大影响。

Zachman 框架培训和认证

Zachman 框架是一个敏捷且灵活的框架，它提供了二维矩阵的严格结构。在您完成的 36 个单元中，您将能够为问题建立解决方案并在您的组织中实施更改。但是，如果您想了解有关该框架或如何使用它的更多信息，Zachman International 通过 Zachman International 提供官方 Zachman Framework 培训和认证。

在为期四天的“动手建模研讨会”中，您将看到 Zachman 框架的真实示例，并学习如何构建和实现原始模型。您将学习如何在您自己的公司中实施 Zachman 框架和概念，以及一些有助于支持该框架的方法和工具。

原文：https://www.cio.com/article/193229/what-is-the-zachman-framework-a-matr…

本文：https://jiagoushi.pro/node/2115

Marc Lankhorst，Fabian Aulkemeier

企业架构，敏捷软件开发和DevOps有时被认为是不和的。我们认为他们可以进行富有成效的协作和界面，但您如何做到这一点？如何协调这些世界的概念和流程，弥合文化差距？

在之前的博客文章中，我们和我们的同事已经写过关于以精益和敏捷的方式进行业务转型的必要性，企业架构和敏捷开发流程可以协同工作的方式，以及如何将敏捷概念映射到ArchiMate建模语言支持这种合作。

在本博客中，我们想讨论几个突出企业架构，敏捷开发和DevOps之间协作的用例。我还将讨论BiZZdesign的软件如何与敏捷和DevOps工具协同工作，以简化组织变更流程中的价值流，帮助您成为适应性企业。

为什么要关联EA和敏捷/ DevOps？

敏捷方法对提高对变化的响应能力有很大帮助。但是，它们并不是您需要的唯一方法，如果应用不正确，它们甚至可能会损害企业的整体适应性。

一般而言，组织越大，其各部分（能力，资源，流程，系统）之间的互连和依赖性就越大，企业架构就越重要，就会提高适应性，使部分与整体战略方向保持一致。

在较小的组织中，一些敏捷/ DevOps团队可以协调他们之间的变更，管理层的线路足够短，可以直接向团队传达战略方向。然而，在大型组织中，可能有数百个敏捷团队，每个团队都在大型“企业机器”的一部分上工作，并且需要更多的协调。如果敏捷团队建立了无视环境的敏捷孤岛，那么您仍然无法获得适应性和灵活性的最终结果。此外，未来的变化可能会变得更加困难，这就是良好的架构至关重要的原因。

已经创建了诸如LeSS和Scaled Agile Framework（SAFe）等方法来处理这些情况下的协调团队。下图显示了SAFe的简化版本，突出显示了一些重要的术语和反馈循环。

他们的架构方法主要关注软件开发的需求，因此，主要从软件和解决方案的角度来看待企业。但是，企业不仅仅是软件。这是EA提供的“全局”视图增加价值的地方，因为它还包括除软件用户之外的其他利益相关者，包括所需（和不需要的！）业务成果，要开发或改进的功能，所需资源，业务流程，IT和要实现的物理基础设施等等。

EA和敏捷的用例

在许多情况下，企业架构和敏捷开发的结合是非常宝贵的。例如，在以下情况下，此协作至关重要：

1. 优先考虑业务价值。基于对企业体系结构的分析，您可以了解不同的epics和功能如何与业务流程，功能，业务目标和相关的利益相关者相关联。通过跟踪您的体系结构模型，您可以了解哪些业务目标以及哪个利益相关方对该功能做出了贡献，以及这是否比其他功能更重要。像这样的客观信息可以帮助产品所有者停止“分贝驱动”的优先级排序，其中具有最响亮的声音的用户获得他们的愿望。
2. 规划工作的连贯性。您的体系结构中的依赖项可用于规划敏捷活动：如果功能A依赖于功能B，则首先构建B.这在SAFe称之为“促成因素”中更为重要：解决方案的各个方面不直接向用户提供功能，但间接支持此功能并实现长期质量和发展。它的“建筑跑道”概念就是一个例子，您可以及时为新功能奠定技术基础。不过，这个概念可以扩展到软件之外。例如，投资于员工技能可以为许多未来的发展和改进提供基础。
3. 跟踪进度。如果某个功能或启用程序被延迟，例如敏捷团队希望将其推送到下一个sprint，则需要将对整个解决方案的影响纳入该决策。这个团队可能有充分的理由优先考虑其他事项，但通常他们没有足够的信息来理解后果。能够追溯到总体目标将证明决策将如何影响发布，项目完成日期等。它还可以帮助团队提出诸如“这对组织的业务目标有何影响？”等问题。哪些客户群体会受到影响？我们可以通过优先考虑其他功能（可能是其他团队）来减轻这些影响吗？“这就是体系结构模型非常有用的地方，特别是对于推动者而言。由于启用程序不提供最终用户功能，因此当您推迟它们时，很少有人会抱怨。但是，它们对于许多不同的功能和解决方案的长期可行性通常很重要，因此跟踪这些依赖关系是关键。
4. 使用新见解更新架构。在敏捷环境中，企业架构不是对长期未来状态的静态描述。相反，它是一种共享工具，可以根据自上而下和自下而上的输入提供愿景，指导并确保整个企业的一致性。业务战略，目标和期望的结果提供了自上而下的方向，而本地创新和改进提供了自下而上的变化。因此，企业中的各个团队从他们自己的角度共同致力于架构。

EA和DevOps的用例

当我们使用DevOps扩展敏捷开发时，还有其他用于架构的用例可以添加到上面的列表中。一般而言，运营管理并不总是意识到架构的好处。但是在敏捷/ DevOps的快速变化周期中，以及解决问题的“失败前进”方法，DevOps的架构变得更有价值。例如，架构模型可用于：

1. 事件相关。架构模型允许您以集成的方式查看整个企业中的事件。例如，如果黑客试图同时使用不同的攻击媒介危害您的安全性（例如社会工程，网络钓鱼，病毒和物理入侵），那么架构模型可以帮助您将这些关联起来以了解其实际目标。
2. 根本原因分析。通常，必须追踪整个系统链以找出故障或问题的原因。架构模型在这方面提供了很大帮助，因为它们为运营管理提供了可能需要调查的各种互连和依赖关系。
3. 风险分析。在实施更改之前，您需要知道企业的哪些部分可能会受到影响。低风险变化可以快速实施，但高风险变化需要更彻底的分析和缓解措施。

在本系列的下一部分中，我们将介绍如何使用模型和工具支持在Enterprise Studio和HoriZZon中集成敏捷开发和体系结构。敬请关注！

本文: http://pub.intelligentx.net/enterprise-architecture-enterprise-architecture-and-agiledevops-adaptive-enterprise-cornerstones

讨论:加入知识星球【首席架构师圈】

作为开放小组的一员，多年来我一直是企业架构师协会加州分会的成员和官员，同时也属于INCOSE——国际系统工程委员会(SE)。几年前，我们举行了一次两章的联席会议，讨论企业架构(EA)与系统工程(SE)的关系。在那次会议中，发生了一场激烈的辩论，当时的INCOSE当地分会主席强烈主张，EA不仅包含在SE学科中，而且两者之间的区别是无关紧要的。他认为，系统的系统(SoS)和企业之间没有区别，使用后者不仅是多余的，而且过分强调了业务的概念。

东南社区并没有完全认同这一立场;事实上，在INCOSE中有一个INCOSE架构工作组(AWG)，其任务是“在系统工程中扩展架构实践并推进知识体系”。这个定义将EA的实践放置在SE的规程中，而不是与它一起实践的联合规程。在现任政府之前，国防部举行了年度DoDAF (Department of Defense Architecture Framework)会议。

在其中一次演讲中，国防大学的一位讲师发表了一篇关于如何将DoDAF纳入SE学科的论文，这与AWG的观点是一致的。我们中的一些人指出EA所涉及的远不止工程，因为它还包括企业中的社会、文化、业务、管理和其他行为因素。另一位与会者问出席全体会议的500多人，有多少人认为自己是工程师。作为回应，只有10%的人举起了手。这强调、支持并导致了对EA(在这里的DoDAF上下文中)作为其自身实践的完整性的额外讨论。

认识到EA来源于多个规程，包括SE，是自TOGAF 8以来实践的开放组架构框架(TOGAF)的基础。现在在TOGAF 9.2中有一个强烈的认识，即在TOGAF的架构开发方法(ADM)中，阶段B(业务架构)是其他架构领域(数据、应用程序和技术)的主要发展。目前，有许多不同的架构框架。TOGAF认为它可以与其他框架和方法结合使用。这一立场是当前国际重大倡议在OMG(对象管理组织)协调建立一个新的统一架构框架(UAF)，作为一个扩展试图协调的主要防御架构框架（major defense architecture frameworks）——DoDAF MoDAF(国防部架构框架-在英国使用)和NAF(北约体系结构框架)。这一努力被称为UPDM或DoDAF、MoDAF和NAF的统一概要。与这一进步相一致的是，人们也认识到整合来自其他主要框架的领先实践的重要性，包括联邦机构管理和预算办公室(OMB)管理的FEAF 2(联邦企业架构框架)，以及来自各种商业架构框架。

在使用SysML或系统建模语言作为UPDM和UML开发的主要语言时，OMG的这个活动具有很强的系统工程重点。这再次提出了EA与SE的关系。诚然，这两个学科之间有一个共享的词汇表和关注点。例如，根据MITRE的Mary Tolbert的说法，以下是使用SysML的OMG试图从基于文本的实践转移到基于模型的实践的主要系统工程过程。这些过程包括项目管理、需求管理、体系结构(系统体系结构)、测试用例的测试、配置管理和风险管理。然后，一般的SE远景是确保从架构建模工件相关联的信息中创建各种各样的可交付成果(这里定义为从集成的模型存储库生成的报告)的能力:规范、系统体系结构模型、接口需求和替代分析。我们的愿景是将这些基于开放文本的模型转化为可执行模型——这里使用的是SysML。

根据INCOSE的说法，基于模型的系统工程(MBSE)是“一种形式化的建模应用，用于支持从概念设计阶段开始并贯穿整个开发和随后的生命周期阶段的系统需求、设计、分析、验证和验证活动”。“基于模型意味着模型存储库中架构/工程元素的独特表示;模型的任何元素只有一个定义，尽管基于这些元素可以有任意数量的表示;并且模型被集成，这样元素之间的关系本身就是模型元素。同样地，对于MBSE和基于模型的EA，其目的是促进传统的SE和EA活动，从而增强通信、规范和设计精度、系统设计集成和系统工件的重用。因此，MBSE和基于模型的EA的输出都是定义的元素和关系的系统模型。

SE和EA模型的好处是能够捕获、分析、共享和管理信息;改善利益相关者之间的沟通(利益相关者管理);通过一个明确和精确的系统模型，提高管理复杂性的能力，该模型可以评估其正确性和完整性;以及增强知识获取、重用和变更管理。

根据INCOSE和OMG，“OMG Systems Modeling Language (OMG SysML)是一种通用的图形化建模语言，用于指定、分析、设计和验证可能包括硬件、软件、信息、人员、过程和设施的复杂系统。OMG为软件模型、系统模型和DoDAF模型提供了SysML建模。他们主张SysML加上DoDAF = UPDM (DoDAF和MoDAF的统一配置文件)。

对于SE社区，UPDM被描述为使用UML和SysML表示DoDAF工件的一种方式。国防部已经授权了该标准，现在已经由许多工具供应商实现，包括Atego、IBM、No Magic和Sparx。这使得架构师能够以一致的方式在较高的抽象级别上开发架构。

UPDM的目的是提供一种简洁的语言来捕获涉众的关注点，并表达处理这些关注点的高级架构。它是一种标准化，减少了通信中的歧义(包括外部涉众)，并支持优化体系结构以支持设计。

UPDM并不是一个新的体系结构框架，正如ISO/IEC/IEEE 42010所定义的那样:“架构框架建立了在特定应用领域或利益相关者社区中创建、解释、分析和使用体系结构描述的实践。架构框架的例子:MODAF, TOGAF, Kruchten的4+1视图模型，RM-ODP。此外，UPDM不是一种方法或过程。相反，它是一种图形企业建模语言。

UPDM的未来是UAF或统一架构框架。新UAF的基本原理是解决UPDM支持的框架大量增加的问题，以及支持工业、联邦和军事使用的需求，支持附加框架(包括TOGAF)的能力，并允许使用非SysML工具和使用SysML的工具实现。

UAF的支持者提倡一种新的网格方法，如下图所示:

网格的使用之所以得到推广，是因为在管理视图时遇到了许多相互竞争的框架，这导致了复杂的映射表和笨拙的描述。

现在回到讨论开始时提出的关于SE和EA的问题，EA是包含在SE中，与SE冗余，还是彼此平行?在一系列的论文和演讲中，MITRE和其他人将框架产品或工件相互映射。

一个这样的映射显示了DoDAF模型与TOGAF内容元模型的关系:

虽然SE和EA共享许多相同的建模特征，并处理共同的涉众集，但是我们需要考虑每个人如何拥有不同的视角和目标。我们认为EA与转型项目的启动是相关的，而转换项目又被移交给系统架构师，而系统架构师又为SE实现人员提供这些模型和描述。因此，这些学科之间有协同作用。在EA中，重点是业务以及信息技术(通过数据、应用程序和技术体系结构领域)如何支持业务。通过这种方式，EA为业务转型提供了路线图，并为系统工程师创建和实现系统提供了指导。

原文：https://www.eaprincipals.com/content/enterprise-architecture-and-systems-engineering-component-or-relationship-disciplines

本文：http://jiagoushi.pro/node/1285

讨论：请加入知识星球【首席架构师智库】或者小号【jiagoushi_pro】或者QQ群【11107777】

企业架构被认为是通过信息技术获取竞争优势的关键途径之一。降低成本、增加灵活性和规范技术环境的需求越来越大。

企业架构在概念上可以划分为不同的架构层，包括业务架构和IT架构(数据、应用程序和技术架构)。

然后，解决方案体系结构接受一个问题，并提出构建块来解决它。它经常重用企业架构提供的其他元素(企业构建块、企业功能、架构标准和指导方针)

因此，企业架构师在企业架构团队和组织的其他地方有许多不同的角色和职责。但是，人们可能会混淆这些角色和职责，例如，企业架构师有时会与解决方案架构师混淆，或者技术架构师与基础设施架构师的角色混淆。这不仅是因为他们的职位听起来相似，而且他们的职责也有部分重叠。然而，每个角色对于一个项目的成功都是至关重要的，不能被其他职位取代。让我们在本文中更精确地看看它们的区别。

四个架构域

企业架构指导组织的业务、信息、流程和技术决策，以使其能够执行其业务策略并满足客户需求。通常有四个架构领域，它们通常是相互关联的:

• 业务架构描述了企业在组织上是如何构建的，以及交付业务远景所需的功能。业务架构解决了什么和谁的问题:
  • 指导业务服务或功能创建的组织的业务远景、战略和目标是什么?
  • 谁在执行定义的业务服务或功能?
• 应用程序架构描述单个应用程序、它们的交互以及它们与组织的核心业务流程的关系。应用程序架构解决了如何:
  • 之前定义的业务服务或功能是如何实现的?
• 数据架构描述了一个组织的逻辑和物理数据资产和数据管理资源的结构。通过数据分析了解您的客户，使您能够改进和持续改进业务流程。
• 技术体系结构描述实现业务、数据和应用程序服务所需的软件和硬件。

企业架构师

企业架构师负责通过与关键人员协作来定义业务目标并创建支持这些目标的企业基础设施，从而确保公司的业务战略。企业架构师的职责包括协助创建和执行信息技术架构路线图，与领域架构师一起设计所有领域的路线图，并确定操作缺口和开发改进方法。

企业架构师的角色和职责包括:

• 分析技术架构领域的当前趋势并提供建议
• 评估应用程序是否符合企业标准和业务标准
• 确定与组织变更相关的架构的生存能力
• 就治理模型和框架等领域的最佳实践对技术人员进行培训

解决方案架构师

解决方案架构师专门评估业务需求，并将它们转换为解决方案、产品或服务。各种行业都需要解决方案架构师，包括专业服务公司或技术咨询机构。解决方案架构师通常花费大部分时间来协调正在进行的活动，参与活动的所有方面和活动，从概念定义到需求的分析和实现，最后转移到IT操作。

解决方案架构师的角色和职责包括:

• 在设计和构建阶段管理应用程序开发团队
• 为初级员工提供培训和指导
• 与应用程序开发人员协作以实现业务目标
• 在技术环境中监督战略关系

领域架构师

领域架构师是在其专业领域具有深入知识的专家。他们可以是企业架构团队的一部分，或者在各种交付项目中工作。词域是用来与一个小范围的知识领域所需的技能集相关的。

• 业务架构师
• 应用程序架构师
• 信息架构师
• 技术架构师
• 数据架构师
• 安全架构师

企业架构师vs解决方案架构师vs领域架构师

• 企业架构师定义需要解决的问题。
• 解决方案架构师将问题转化为解决方案。
• 领域架构师负责一个解决方案(例如，业务架构师与企业架构师一起负责业务架构，同样，应用架构师负责应用架构师与另一个领域架构师一起工作)

本文：http://jiagoushi.pro/node/1217

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

访谈是工作赢或输的地方。简历 - 尤其是强大的简历 - 将确保您踏上门，但要确保在面试中确保您需要发光的位置，这意味着要做好准备。准备让你看起来知识渊博，轻松，这是人们通常在工作同事中所珍视的两个特征。

为了在面试过程中为您提供额外的优势，在BiZZdesign，我们准备了100个问题，帮助您完成企业架构师角色访谈。其中一些针对初级企业架构师，另一些针对更有经验的专业人士 - 他们将共同为您提供一个非常好的想法。不用多说，以下是企业架构工作面试的100个问题：

1. 从大局的角度来看你是多么容易想到它，你能举例说明你在工作中汲取这种品质吗？
2. 为什么你认为自己适合我们公司？
3. 你如何改善你的专业网络？
4. 您之前是否处理过具有孤立结构的组织，以及您是如何处理它的？
5. 你参与过的最成功的倡议是什么？你如何描述你对它的贡献？
6. 您如何平衡与不同利益相关方群体的关系，特别是那些挑战您的想法的群体？
7. 您如何评估自己的领导能力？
8. 架构在敏捷环境中的作用是什么？
9. 您是否有使用安全架构框架的经验，如果有，哪些？
10. 在职业明智的十年后，你认为自己在哪里？
11. 您对数据管理标准和实践有经验吗？
12. 您是否有与供应商协商服务水平协议的经验？
13. 您是否曾经未能成功交付项目，如果是这样，您从经验中学到了什么？
14. 您认为企业架构在哪个领域？
15. 建立EA实践的成功第一年对您来说是什么样的？
16. 你在建筑师中寻找什么品质？
17. 您能否提供企业架构的简要定义？
18. 根据您的经验，哪些利益相关方团体将参与企业架构生命周期？
19. 简单来说，什么是架构模式？
20. 您如何发展在易变环境中运行的公司的企业架构？
21. 您能否列举一些最近的技术发展，您认为这些发展对EA专业人士来说很重要？
22. 您对EA在战略决策中的作用有何看法？
23. 您是否有任何与整个组织的团队合作的例子？
24. 您与高级业务利益相关者打交道的经验是什么？
25. 您如何从管理层获得支持？
26. 企业架构如何支持业务目标和战略？
27. 您能简要介绍一下成熟的企业架构实践吗？
28. 您是否有在敏捷环境中工作的经验？
29. 您如何描述寻找关键增值业务活动的方法？
30. 您是否有构建建筑路线图的经验？
31. 您参与过的最困难的项目是什么？您是如何应对挑战的？
32. 您评估EA实践的成熟度有多舒适？
33. 您如何确保解决方案与架构保持一致？
34. 你职业生涯中到目前为止使用了哪些工具？
35. 您是否有建立架构治理功能的经验？
36. 当你为解决问题的方法感到自豪时，你能想到一种情况吗？
37. 您如何确保遵守业务利益相关方的要求？
38. 您将使用哪些指标来证明EA实践对业务产生积极影响？
39. 您能举例说明您向高层管理人员传播架构和策略吗？
40. 您为此做出了哪些业务目标以及如何实现这一目标？
41. 您是否通过最新版ArchiMate标准认证？
42. 您喜欢参与定义业务战略吗？
43. 你如何强调同事工作中的弱点或错误？
44. 架构如何为DevOps做出贡献？
45. 您之前是否进行过风险影响分析？
46. 当一位同事纠正你时你如何回应，初级建筑师是否能够纠正高级职员？
47. 您如何鼓励跨部门合作？
48. 你能简单介绍一下TOGAF吗？
49. 您对敏捷方法和框架的体验是什么？
50. 企业架构实践在不同的组织文化中有何不同？
51. 您能举例说明如何成功实施最小化业务成本的解决方案吗？
52. 你能简单地定义ITSM吗？
53. 您如何定位业务架构相对于企业架构？
54. 您是否有为EA部门引入新标准的经验？
55. 您是否曾使用架构引导组织摆脱危机？
56. 您能简要定义应用程序组合管理吗？
57. 您目前最感兴趣的技术趋势是什么？
58. 您如何保持技能并与IT趋势保持同步？
59. 您是否有使用建模工具的经验？
60. 您能描述一下如何利用以前职位的工作流程来增加工作量吗？
61. 在交付项目时，您在EA部门之外与哪些利益相关方群体进行了互动？
62. 您最有经验的EA框架是什么？
63. 您是否有使用ArchiMate认证工具的经验？
64. 您是否获得最新版TOGAF认证？
65. 你能描述一下你曾经参与过的最成熟的EA实践吗？
66. 架构师可以做些什么来最大化他们在敏捷环境中带来的价值？
67. 您将如何提升组织的EA成熟度？
68. 什么“及时，足够”的架构意味着什么？
69. 您对微服务有何看法？
70. 您是否有应用程序云迁移的经验？
71. 您是否曾在之前的职位中有过基于能力的计划经验？
72. 什么是ArchiMate？
73. 您是否可以提供一些示例，说明您之前如何帮助识别安全威胁，然后提供控制措施来缓解这些威胁？
74. 您是否具有面向服务的体系结构的经验？
75. 在评估EA成熟度时，您会考虑哪些方面？
76. 您使用ArchiMate有什么经验？
77. 你能说出一些个人身份信息的例子吗？
78. 您有使用ITIL的经验吗？
79. 你能简单地定义业务架构吗？
80. 您是否曾经通过架构改善组织的客户体验？
81. 你能简单地定义安全架构吗？
82. 你有指导初级建筑师的经验吗？
83. 你知道GDPR是什么吗？
84. 你能解释面向对象和面向方面设计之间的区别吗？
85. 您参与的最全面的技术架构升级计划是什么？您是如何为其成功做出贡献的？
86. 您能描述一下您的客户旅程映射体验吗？
87. 您是否亲眼目睹了安全漏洞，如果是这样，您的经验教会了什么？
88. 关于企业架构师如何完成工作，您会改变哪些方面？
89. 你认为有一个“最重要的”建筑层吗？
90. 您能否分享一个成功的APM实践的例子，您可以参与并描述您在成功中的角色？
91. 参考架构的作用是什么？
92. 出于什么目的，您将分别使用ArchiMate，BPMN或UML建模语言，以及如何将它们联系起来？
93. 在您看来，什么是项目成功的最重要预测因素？
94. 您是否能够在软件开发生命周期中简要描述解决方案架构师的角色？
95. 你工作的最佳方面是什么？
96. 您是否参与过物联网项目的实施？
97. 您是否曾经运行情景分析来指导投资决策？
98. 您是否有实施GDPR合规计划的经验？
99. 您认为TOGAF中的哪些架构观点在低成熟度实践中特别相关？
100. 您是否可以提供一个示例，说明在项目目标意外更改后您是如何成功调整的？

我们认为，提前回答这些问题将使您在面对企业架构师角色的真实面试中毫无压力地工作，并增加您成功的机会。要了解有关当今数字化转型的更多信息以及组织变得适应性的重要性，请随时下载我们的电子书，自适应企业：在变革时代蓬勃发展。

原文:https://bizzdesign.com/blog/100-questions-to-ace-an-enterprise-architect-job-interview/

本文:http://pub.intelligentx.net/enterprise-architecture-100-questions-ace-enterprise-architect-job-interview

讨论:加入知识星球或者小红圈【首席架构师圈】

从这里开始使用试用帐户创建动画企业架构框架图。 快来看看Dragon1循序渐进指南吧。

这是在Dragon1上创建的企业架构框架图的示例。 Dragon1是一个协作平台，您作为Business Professional可以在其上学习，创建，共享和控制交互式内容。

什么是企业架构框架图？

企业架构框架图是架构的分类方案（治理架构，业务架构，信息架构，技术架构，人力资本架构，安全架构，系统架构，软件架构，基础架构架构等）及其重要工件。 企业架构框架可用作背景来报告一种或多种类型的工件，例如构成架构的概念。

为什么这个企业架构框架示例？

此示例企业架构框架图是为您创建的，以显示在Dragon1上创建企业架构框架的效率。

在此页面上，您可以阅读并了解Dragon1在建模和可视化交互式企业架构框架方面的强大功能。

此示例还说明了Enterprise Architect如何能够并且应该如何向利益相关者报告正在进行的EA兼容企业体系结构定义的工作状态。

从Architecture Diagram到Management Report视图

上图显示了企业体系结构框架图的管理报告视图。这不是一个沉闷的无意义的建筑模型图片，而是一个支持报告框架的决定：红色意味着：现在采取行动，因为目前的情况阻碍了目标的实现！

下面的第二张图显示了企业架构框架的概念视图。它给出了一个问题的答案：我们的框架中的架构最重要的概念是什么。

Dragon1，节省了大量宝贵时间！

现在，您立即了解为什么您作为Enterprise Architect需要EA工具。上面的企业架构框架有很多可能的视图，当管理员要求新情况，方面或时间段的新视图时，您不希望手动创建和更新每个报表视图。

不，您只是希望经理提供可点击的企业架构框架，并让他自己根据存储库中的信息生成视图，方法是设置一些时间段等参数。

阅读有关如何创建企业架构框架的更多信息。

交互图示例

例如，您可以通过单击图层或过滤掉某些信息来构建自己的企业体系结构框架视图。单击此Watch页面上的企业体系结构框架的此交互式示例。这可能会让您了解框架图应该如何以及您希望如何使用它。

还读

您可能还对Enterprise Architecture Framework上的以下资源感兴趣：

• Terms > Architecture Diagram Definition
• Terms > Enterprise Architecture Framework Definition
• Visualizations > Ideal Enterprise Architecture Framework
• Blogs > Enterprise Architecture Framework Diagram - A First Aid Kit for Projects
• Frameworks > Zachman Framework
• Wikipedia > Enterprise Architecture Framework
• Terms > Architecture Principle Definition
• Training > Dragon1 Foundation

入门

我们希望我们能够激励您创建企业架构框架。

你想立刻开始吗？您可以通过Paypal在线购买Dragon1 PRO用户许可证。

如果您没有时间并且需要在短时间内获得企业架构框架图，我们可以为您创建框架。

今天的内容构成了名为“谁仍然对企业架构感兴趣？”系列的六个部分的第三部分。在本系列中，我将就当今企业架构的足迹、企业架构师角色的潜在死亡、大型参与者（例如 The Open Group、AWS 或 Azure 的 TOGAF）以及EA 工具提供商的角色以及其他相关证书和市场上的发展。

在今天的第三部分中，我将更广泛地了解与企业架构相关的组织、框架和模型。具体来说，我们考虑了云领域，并得出结论认为，当今 EA 最佳实践的重要部分是由云组织和提供商开发的。

无论您是在阅读本文还是在收听播客版本，请务必尽快查看该系列的其他部分！

谁仍然对企业架构感兴趣？

– 第 3 部分，共 6 部分
有两种不同类型的组织与企业架构相关。

- 一些组织，例如 The Open Group 和 Bizzdesign 完全专注于该主题。

- 此外，还有一些新的市场参与者也在开发企业架构框架，但并不完全专注于这个主题。

云原生计算基金会（CNCF）是一个重要的参与者

第二类的一个例子是云原生计算基金会（CNCF）。它的创始公司包括 Google、Docker、Red Hat、Twitter 和 IBM。它的目标是成为许多增长最快的开源项目的供应商中立之家，促进开发人员、最终用户和供应商之间的协作。因此，他们的主要目标是为开源项目提供一个进一步合作和发展的平台。然而，作为其中的一部分，他们还不断开发合适的生态系统。

如今，CNCF 还提供工具和技术的培训和认证，以帮助轻松有效地管理云原生应用程序（例如微服务）的整个环境（例如，服务网格、Kubernetes）。虽然毫无疑问，此类解决方案是其产品组合的合适扩展，但它们位于企业架构的核心。

AWS、Azure 和 GCP 等超大规模企业也在开发最佳实践

与 CNCF 一样，大型云提供商开发的最佳实践正在成为如何管理云架构的行业标准。例如，AWS 在 2018 年首次提供了 AWS 架构完善的框架，其中包括五个支柱以及一组用于设计和构建云环境的设计原则。 2020 年底，MS Azure 还发布了他们的架构完善的框架版本。这两个框架都建立在相同的五个支柱之上。这使得它们很可能成为整个行业的标准。尽管这些支柱主要关注 IT 架构，但它们也会影响企业架构活动。

除了 Well-Architected Framework，前面提到的云提供商还提供了大量的参考架构。与无边界信息流或来自 TOGAF 标准的集成信息基础设施参考模型相比，它们相似，但更现代。

最后，MS Azure 云采用框架或类似模型很可能会取代 TOGAF 的架构开发方法。随着云变得越来越重要，并且两个框架都遵循类似的概念，我相信这种发展将继续下去。

您对云组织和提供商在企业架构最佳实践开发中的作用有何看法？你同意还是不同意我的推理？我期待您在下面的评论部分中发表评论！

原文：https://digitalroadmap-management.medium.com/new-sources-for-enterprise…

本文：https://jiagoushi.pro/new-sources-enterprise-architecture-frameworks-em…

企业架构(EA)是“一种定义良好的实践，用于执行企业分析、设计、规划和实现，在任何时候都使用一种全面的方法，以实现战略的成功开发和执行。企业架构应用架构原则和实践来指导组织完成执行其战略所必需的业务、信息、流程和技术更改。这些实践利用企业的各个方面来识别、激励和实现这些变化

企业架构师负责执行业务结构和流程的分析，经常需要从收集的信息中得出结论，以实现企业架构的目标:复杂业务操作的有效性、效率、敏捷性和连续性。

概述

美国法典44第3601节企业架构的定义:(4)“企业架构”- (A)指- (i)定义任务的战略信息资产基础;执行任务所需的资料;执行任务所需的技术;执行新技术以应付不断变化的特派团需要的过渡过程;(B)包括:(i)基线架构;(2)目标架构;(iii)测序计划;

EA不仅仅是关于IT的。它是关于充分详细地理解任务，以便您能够及时地在整个企业范围内做出知情的购买决策。

布鲁贝克说:“国会、行政管理和行政管理办公室以及IT界都被克林格-科恩法案的潜在阴谋分散了注意力——这从来不是关于技术，而是关于如何通过深思熟虑的技术应用来转变任务和支持过程。”“各机构将展示他们是如何深思熟虑地应用技术的，通过提供清晰而令人信服的商业案例来投资于技术，然后对在任务和业务绩效方面产生可衡量的改进负责。”遗憾的是，行政管理和预算办公室(OMB)、政府总务管理局(GSA)、各机构和首席信息官(cio)都无法抵抗诱惑，过度规定合规要求，并推动那些过于关注技术和基础设施的任务，而这些工作完全没有抓住重点。“保罗布鲁巴克

https://federalnewsnetwork.com/reporters-notebook-jason-miller/2019/02/…

企业架构知识体系将企业架构定义为一种实践

分析组织内部或组织之间共同活动的领域，在这些领域信息和其他资源被交换，以从战略、业务和技术的综合观点来指导未来状态

IT分析公司Gartner将这个术语定义为一种引导企业经历变化的规程。根据他们的术语表，

企业架构(EA)是通过识别和分析朝着期望的业务远景和结果的变更执行，主动地和全面地领导企业对破坏性力量的响应的规程。EA通过向业务和IT领导提供已签名的建议来实现价值，这些建议用于调整策略和项目，以实现利用相关业务中断的目标业务结果。EA是用来引导未来状态架构发展的决策制定

上面的每一个定义都低估了企业架构产生于记录和规划信息系统架构的方法的历史现实，以及大多数企业架构从业者向CIO或其他IT部门经理报告的当前现实。在当今的业务组织结构中，企业架构团队执行正在进行的业务功能，帮助业务和IT经理找出支持和实现业务开发和业务变更的最佳策略——与业务所依赖的业务信息系统相关。

主题

术语企业和架构

企业这个术语可以定义为描述一个组织单元、组织或组织集合，这些组织共享一组共同的目标，并协作为客户提供特定的产品或服务

从这个意义上说，企业这个术语涵盖了各种类型的组织，而不管它们的规模、所有权模型、运营模型或地理分布如何。它包括那些组织的完整的社会技术系统，[5]包括人员、信息、流程和技术。

术语架构指的是系统在其环境中的基本概念或特性，体现在系统的元素、关系以及设计和发展的原则中

企业被理解为社会技术系统，术语企业定义了企业架构的范围。

作用域

企业架构从业者和学者持有的关于企业架构意义的观点或信念，通常倾向于三种思想流派的一种或混合:[7]

1. 企业IT设计——EA的目的是使IT和业务关注点更一致。企业架构的主要目的是指导计划和设计企业的IT/ is能力的过程，以满足预期的组织目标。通常，架构建议和决策仅限于企业的IT/IS方面;其他方面仅作为输入。
2. 企业整合——根据这一学派的思想，EA的目的是在企业的各种关注点(人力资源、IT、运营等)之间实现更大的一致性，包括战略制定和执行之间的联系。通常，架构建议和决策包含企业的所有方面。
3. 企业生态系统适应——EA的目的是培养和维护企业的学习能力，从而使企业能够持续发展。因此，提高企业自身的自我完善能力、创新能力和与环境协同发展的能力成为企业研究的重点。通常，建议和决策包括企业及其环境。

一个人对企业架构意义的信念将影响他如何看待它的目的、它的范围、实现它的方法、执行它所需的技能，以及执行它的责任所在[7]

企业的架构描述

参见:架构领域

根据标准ISO/IEC/IEEE 42010，用于描述系统架构的产品称为架构描述。在实践中，架构描述包含各种列表、表格和图表。这些模型称为视图。对于企业架构，这些模型描述了逻辑业务功能或能力、业务流程、人工角色和参与者、物理组织结构、数据流和数据存储、业务应用程序和平台应用程序、硬件和通信基础设施。[引文需要]

英国国家计算中心EA最佳实践指导[8]声明:

通常EA采用一组全面的内聚模型的形式，描述企业的结构和功能。EA中的各个模型以逻辑的方式进行安排，从而提供了关于企业的越来越多的细节。

描述企业的架构是为了提高业务的可管理性、有效性、效率或敏捷性，并确保在信息技术(IT)上的花费是合理的。[引文需要]

对于更改企业架构，最重要的是确定赞助者。他/她的使命、愿景和策略，以及治理框架定义了预期转换中涉及的所有角色、职责和关系。企业架构师考虑的变化通常包括:

• 组织结构或过程的革新
• 在使用信息系统或技术方面的创新
• 业务流程的集成和/或标准化
• 提高业务信息的质量和及时性。

用于开发和使用架构来指导业务从基线状态到目标状态的转换(有时通过多个转换状态)的方法通常称为企业架构框架。框架提供了流程、技术、工件描述、参考模型的结构化集合，以及针对特定企业架构描述的生产和使用的指导。

好处

企业架构的好处是通过它对组织目标的直接和间接贡献来实现的。人们发现，企业架构最显著的好处可以在以下方面观察到:[9]

1. 组织设计——企业架构在合并、收购或一般组织变革期间，为组织结构的设计和重新设计提供支持
2. 组织过程和过程标准——企业架构帮助加强业务过程的规程和标准化，并支持过程整合、重用和集成
3. 项目组合管理——企业架构支持投资决策和工作优先级划分
4. 项目管理——企业架构增强了项目干系人之间的协作和沟通。企业架构有助于有效地确定项目范围，并定义更完整和一致的项目可交付成果
5. 需求工程——企业架构通过发布企业架构文档，提高了需求捕获的速度和需求定义的准确性
6. 系统开发——在系统开发和测试期间，企业架构有助于优化系统设计和有效的资源分配
7. 资讯科技管理及决策制定-企业架构有助推行资讯科技规划活动的纪律及标准化，并有助缩短作出与科技有关的决策的时间
8. IT价值——企业架构有助于降低系统的实现和运营成本，并最大限度地减少跨业务单位的IT基础设施服务复制
9. IT复杂性——企业架构有助于降低IT复杂性，整合数据和应用程序，并改善系统的互操作性
10. IT开放性——企业架构通过增加对法规遵从性的数据可访问性和增加基础设施变更的透明度来促进IT的更加开放和响应性
11. IT风险管理——企业架构有助于减少系统故障和安全破坏带来的业务风险。企业架构有助于降低项目交付的风险

例子

企业架构的文档记录是在美国联邦政府[20]的资本计划和投资控制(CPIC)过程中完成的。

联邦企业架构(FEA)参考模型指导联邦机构开发它们的架构

公司如独立蓝十字、英特尔、大众[22]和洲际酒店集团使用企业架构来改善他们的业务架构，并提高业务绩效和生产力。

由于各种可以理解的原因，商业组织很少发布实质性的企业架构描述。然而，政府机构已经开始发布他们开发的架构描述。例子包括:

1. 美国内政部（US Department of the Interior）
2. 美国国防部（US Department of Defense）企业架构，[23]或2008 BEAv5.0版本
3. 财政部企业架构框架（Treasury Enterprise Architecture Framework）

与其他学科的关系

根据EA专业组织联合会(FEAPO)的说法，企业架构与广泛的业务设置中常见的其他学科相互作用。根据FEAPO:

企业架构实践与许多相互联系的学科,包括性能工程和管理、过程工程和管理、IT和企业项目组合管理,治理和合规、战略规划、风险分析、信息管理、元数据管理、和各种技术规程以及组织学科如组织发展、转型、创新和学习。越来越多的从业者强调企业架构与新兴的整体设计实践(如设计思维、系统思维和用户体验设计)之间的重要关系

随着企业架构在各种组织中出现，其广泛的影响已经导致该业务角色被包括在许多组织的信息技术治理过程中。虽然这可能意味着企业架构与IT紧密相连，但应该在更广泛的业务优化上下文中来看待它，因为它处理业务架构、性能管理和流程架构，以及更多的技术主题。

各种IT分析公司已经发表了关于企业架构和各种IT实践交叉的讨论。Gartner和Forrester强调了企业架构与新兴的整体设计实践(如设计思维和用户体验设计)之间的重要关系。[26]分析公司Real Story Group认为，企业架构和新兴的数字工作场所概念是“一枚硬币的两面”。Cutter Consortium将企业架构描述为一种信息和基于知识的规程

组织的企业架构过于复杂和广泛，无法完整地记录下来，因此知识管理技术提供了一种方法来探索和分析这些隐藏的、默认的或隐式的领域。反过来，企业架构提供了一种记录组织组件及其交互的方法，以一种补充知识管理的系统和整体的方式

在各种场合，[30]企业架构都被讨论为与面向服务架构(一种特定的应用集成风格)的关系。研究指出，企业架构促进了SOA作为企业范围集成模式的使用

工具

下表列出了Gartner和Forrester Research在2013、2014、2017和2018年报告中列出的一些著名的企业架构工具。[33][34] b[36] [37]

批评

尽管企业架构声称提供了许多好处，但在十多年的时间里，作者和组织一直在关注企业架构作为一种有效的实践。以下是部分反对意见:

• 2007年,计算机科学家Ivar Jacobson(一个主要贡献者UML和面向对象软件开发的先锋)给他的评估企业架构:“世界各地引入企业架构EA一直是主动对大多数金融机构(银行、保险公司、政府等)在过去五年左右,并没有结束。我一直在与这些公司合作，帮助他们避免犯最严重的错误。大多数EA计划都失败了。我猜超过90%的人从来没有真正得到任何有用的东西。
• 在2007年的一份关于企业架构的报告中，Gartner预测“……到2012年，40%(2007年的)企业架构项目将被停止
• 鹿特丹伊拉斯谟大学和软件公司IDS Scheer在2008年进行的一项研究得出结论，三分之二的企业架构项目未能改善业务和IT的一致性
• 在2009年的一篇文章中，行业评论员Dion Hinchcliffe写道，传统的企业架构可能会被“打破”:“在最好的情况下，企业架构提供了清晰的线条，清晰地阐明了业务的所有可能性，甚至描述了如何实现它……最近，越来越多的人认识到，如今经常实践的传统企业架构可能在某些重要方面被打破。现在的问题是问题出在哪里以及如何解决
• 2011年，联邦企业架构顾问Stanley Gaver发布了一份报告，调查了美国联邦政府企业架构项目中的问题。加弗的结论是，联邦企业架构项目基本上失败了;这个结论被联邦政府在2010年10月的一次会议上做出的一个类似的结论所证实，那次会议是为了确定联邦企业架构项目为什么没有“过去那么有影响力和成功”

由于EA项目的粗线条和经常不透明的本质，一个关于EA的关键关注一直是很难达到成功的度量标准

另请参阅

• 企业架构的构件
• 企业架构框架
• 建筑模式(计算机科学)
• 综合信息系统的架构
• 互操作信息系统的架构
• John Zachman，企业架构的倡导者
• 企业架构服务生命周期- SOMF

原文：https://en.wikipedia.org/wiki/Enterprise_architecture

本文：http://jiagoushi.pro/node/1097

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

企业架构通常被认为是一种抽象的，概念性的，有些深奥的学科，由“大祭司”实践，他们为他们崇高的“建筑原则”提供指导。架构师经常关注的是总体而言，跨领域的问题并不总是如此。在战壕中人们可以看到，但这种企业架构的观点充其量是错误的，并且越来越错过了这个标志。

自上而下和自下而上变化之间的一致性

企业架构的任务是根据公司战略，企业生态系统以及各利益相关方团体的需求和愿望，一致地设计和改进企业运营方式。这应该是组织中每个人都关心的事情，每个人都在自己的范围内，从他们自己的角度来看。 Mintzberg和Waters1在20世纪80年代已经将故意（自上而下）和紧急（自下而上）战略区分开来，Ciborra2认为当地的“修补”可能会带来战略优势，竞争对手难以复制。

在采用敏捷，DevOps和精益方法的现代组织中，创新和改进同样是自下而上的事情。但是，要想在当今不稳定的商业环境中取得成功，您需要一种协调和协调这些自上而下和自下而上的变化的方法。这是企业架构可以提供帮助的地方。在之前关于Agile / DevOps与EA之间关系的博客中，我的同事Fabian和我解决了其中的一些问题，概述了企业架构如何为Agile和DevOps的工作方式增加价值。对此关系的考虑有助于您分析各种事件和变更的影响，根据业务价值确定变更的优先级，协调不同学科的工作，并为创新提供背景。

让每个人都成为架构师

从长远来看，我们看到架构角色发生了更为深刻的转变：将企业架构定位为高层次，自上而下的运营规则，而不是不同类型的变革之间的连接结构。在企业内部，这意味着每个人都将以某种方式在架构的开发和发展中发挥作用。从本质上讲，每个人都成为架构师！

当然，这并不意味着每个员工都应该参加TOGAF课程。相反，您应该为每个人提供工具，让他们了解当地或全球变化的选项和效果，并采取相应措施。所有这些变化都可以与共享的企业愿景保持一致，并协同工作，从本地流程改进的结果或敏捷用户故事的优先级到合并的影响或新监管要求对您业务的影响模型。

架构师：从'超级设计师'到变革的管家

这种重点转变的主要驱动力是企业对速度的需求。为了生存和竞争，组织需要适应不断变化的环境。这是一个战略性问题，越来越多地胜过传统成本或收入，特别是在我们经常在数字领域看到的“赢得所有”市场。以前，我们已经写过关于Adaptive Enterprise的愿景以及支持它的功能。任何大型企业都需要本地团队之外的协调机制进行本地更改：如果您只有一群敏捷团队构建敏捷孤岛，那么您最终可能会获得“即时遗留”，并且您的企业可能会变得更少 - 而不是更多 - 适应其环境。

下图来自BiZZdesign的EA成熟度模型，展示了我们如何看待这种演变，从脱节的非正式努力到专注于适应性和创新的协作。这既适用于学科本身的发展，也适用于个体企业的应用方式。

Maturity stages of Enterprise Architecture 

现在，这种转变并不意味着企业架构师将会消失。相反，他们的角色将从“超级设计师”转变为企业内部变革的管家。他们不会自己设想，而是越来越多地向参与变革的其他人提供帮助，并确保建筑作为组织的结缔组织的质量和企业范围的一致性。

EA的消费化

让每个人都参与企业架构需要对所使用的工具采用新方法。在不久的将来，架构师，流程设计师，软件开发人员，投资组合经理和其他“变革专家”使用他们的专用建模和分析工具，每个工具都在他们自己的领域。跨这些领域的合作，更不用说与“非专家”合作，这很困难。因此，我们需要通过组织内任何人都可以访问的协作工具来增强这一点，其中架构信息以易于消费的方式共享，并根据不同利益相关方群体的需求进行定制。这也意味着使用常规的消费者市场工具并在协作环境中集成这些工具 - 从而建立EA的消费化。

这种协作平台的功能包括：

1. 针对不同用户社区的各种视图和仪表板
2. 交互式分析工具，可以创建全面的概述和详细的深入分析
3. 团队支持，以组织团队内部和团队之间的工作
4. 社交功能让人们可以轻松地协同工作，相互学习，提供反馈并随时了解情况
5. 工作流支持，以实现必要的协作和治理流程
6. 与各种内部和外部信息源的数据集成
7. 一种可靠的访问控制机制，可确保信息安全而不会妨碍协作

好消息是，这不是科幻小说！

由于您正在阅读BiZZdesign博客，您将猜到这正是我们的协作平台提供的。 Enterprise Studio是专家使用的建模和分析环境。 HoriZZon是非专家用户的可视化和协作门户，两者都以Team Platform为基础，提供模型管理，工作流，安全性，数据集成等等。我们正在快速发展这一功能，以适应这种转向EA的消费化。在以后的博客中，我将更详细地介绍其中一些功能。

原文:https://bizzdesign.com/blog/the-consumerization-of-enterprise-architecture-everyones-an-architect/

本文:http://pub.intelligentx.net/enterprise-architecture-consumerization-enterprise-architecture-everyones-architect

讨论:请加入知识星球【首席架构师圈】

介绍

在当今的数字时代，大多数企业的运营都依赖于技术。这项技术有多种形式，但软件系统最为人所知。
众所周知，每家公司要么提供要销售的产品，要么提供服务。这些公司由其所有者、经理或企业最高管理层管理，但他们不一定是技术专家。
这些所有者不做出技术决定。这就是为什么他们需要帮助来构建和购买运行其业务的信息系统。这就是企业架构的用武之地。
在本文中，我们将讨论什么是企业架构师以及他们的工作。好，那我们开始吧。

什么是企业架构 (EA)？

企业一词代表任何使用软件系统的组织，并且不仅限于公司。它可以是政府机构、非营利组织、非政府组织和慈善机构。
企业架构 (EA) 是一种实践和一套技能，用于使技术战略与业务战略保持一致。此外，EA 处理企业/组织、其人员、其支持的业务流程以及自动化这些流程的系统之间的复杂关系。
这就是为什么在企业环境中，业务领导者依赖企业架构师作为值得信赖的技术顾问。
在我个人看来，企业需要 EA 不是因为 IT 项目的复杂性，而是因为它们弥合了业务利益相关者和开发人员之间的沟通鸿沟。
试想一下，由于开发人员和业务利益相关者之间缺乏沟通，项目状态可能并不理想。
这就是为什么您会看到 EA 充当解释器，将业务需求转换为解决方案设计，最后转换为企业系统。
因此，我们可以得出结论，企业架构师支持业务主管将他们的愿景转化为帮助公司成功的技术战略。

开发人员和架构师之间的区别？

一般来说，大多数架构师的职业生涯都是从软件开发人员开始的。
并不是每个人都同意软件开发人员是一个伟大的职业，特别是如果你不喜欢在软件空间内构建东西并通过将业务问题转换为代码来解决问题。
你想在未来成为一名建筑师吗？成为一名软件开发人员是一个很好的垫脚石。
现在，让我们关注开发人员和架构师之间的区别。
在我看来，开发人员专注于树木，而建筑师专注于森林。这些树代表开发人员关注的技术或相关技术，而森林代表 EA 关注的一系列连接系统。
另一个区别是软件开发人员，他们的第一直觉是编写代码来满足业务的请求。
这就是为什么如果公司没有架构师，业务用户会直接与开发人员交互。这就是为什么一切都被视为软件问题的原因。
虽然架构师善于提出驱动目的和意图的正确问题，但 EA 有助于继续专注于交付业务价值，避免中断。
例如，当业务用户要求新的系统或功能时，架构师会帮助他们表达他们在实际业务成果中真正需要的东西。

三种主要类型的架构范围

应用架构师

应用程序架构师最接近软件开发团队。这些人也被称为软件架构师。
这些人专注于由平台、可重用组件和软件组成的复杂 IT 系统。简单来说，我们可以说应用架构师主要关注与他们所专注的特定平台相关的工程问题和技术解决方案。
通常，大多数软件高级或软件工程主管通常会成为或被提升为团队的应用程序架构师。这就是为什么这个角色仍然可以编写代码。此外，我喜欢这些角色的原因是测试一些概念证明，最终将帮助项目在他们面临的当前问题上取得进展。
此外，当不编码、测试或设计新想法时，该角色会与开发团队进行沟通，以了解他们在设计实现方面的进展。这确保了应用程序的持续开发是根据软件架构师给出或建议的计划构建的。

解决方案架构师

解决方案架构师专注于将工作系统连接在一起以处理复杂的业务工作流程。你会看到他们负责弥合业务问题和技术解决方案之间的差距。因此，我们可以说它们处于应用程序和企业级关注点的中间。
这就是为什么我们有时可以将它们视为万事通，因为它们只关注个别应用程序，但在需要时扩展他们的知识和技能以解决更广泛的技术和战略问题。
解决方案架构师不需要编码技能，但其中一些人确实了解编码。这就是为什么他们可以与开发团队进行良好沟通的原因。

企业架构师

企业架构师战略性地运作，与高管合作以实现公司目标。此外，他们的主要目标是使技术与业务战略保持一致。
以下是我在 EA 领域看到的情况：

• 他们保持发展计划的整体愿景
• 协调大型项目的需求
• 通过业务和技术路线图指导敏捷团队。

试着想象一下你是组织中新加入的 EA。您首先要了解公司的使命。
从那里，您得出愿景并询问公司为什么要朝特定方向发展？一旦你回答了原因，你最终会坐下来，与领导层交谈，并确定如何在战略层面调整一切。

在组织内建立 EA 团队的好处

最终，公司在战略决策方面超越了咨询、承包或外包公司。这是公司可能决定创建内部 EA 团队或部门的时候。在一家外包公司工作时，我见过很多这样的案例。
好的，也许您会问：“在组织内拥有 EA 团队有什么意义？”。为了回答这个问题，它基本上从企业使命和产品开发之间的一致性开始。
在大多数情况下，拥有内部开发团队的组织通常专注于技术并面临许多手头的问题。随着时间的推移，它们可能与组织的真正业务价值脱节。这就是为什么拥有一个 EA 团队可以帮助组织专注于提供真正的业务价值。
另一个显着的好处是不断评估不断变化的需求，并且可用于支持其业务需求的技术也在不断变化。敏捷和敏捷架构等实践可以使开发适应变化。
最后，EA 收集、记录和管理的知识很有价值。这将帮助组织集中其知识存储并使其可供架构师、开发人员和业务利益相关者使用。

概括

在本文中，我们讨论了以下内容，

• 什么是企业架构 (EA)？
• 开发人员和架构师之间的区别
• 三种主要类型的架构范围
• 在组织内建立 EA 团队的好处

我希望你喜欢这篇文章，因为我喜欢写它。
请继续关注更多。直到下一次，快乐的编程！
请不要忘记收藏、点赞和评论。
干杯，谢谢！

原文：https://lock29down.medium.com/introduction-to-enterprise-architecture-e…

本文：https://jiagoushi.pro/introduction-enterprise-architecture-ea

我是一名建筑师。 我设计系统。 我专注于返回值。 我不断地学习。

在我设计系统时，我不断寻求了解如何使该系统变得更好，或者至少我可以发现哪些要点可以使下一个解决方案变得更好。 通常这些不是技术问题——技术是简单的部分——而是本质上更广泛的问题。 有时他们在本质上更个人化，比如努力成为更好的沟通者。 作为一个内向的人，我敏锐地意识到我的这个弱点。

An Archimate-based Metamodel is a metacognitive tool to visual a complex technology ecosystem.

这些更广泛的担忧是什么？那么如何改进技术交付平台以使其更好地满足业务需求。这些问题通常属于企业架构 (EA) 领域。什么是企业架构？这是一个有很多答案的问题。对我来说，它是跨业务和 IT 协调资源以确保 IT 资产的战略交付的纪律。

在我多年的咨询和创建系统中，企业架构是我看到几乎每个组织都重复出现的一个失败领域。为什么呢？出于多种原因。但主要是因为大多数组织中不存在企业架构的实践。当它被实践时，它被错误地实践或定义为企业级的解决方案架构。我看到的主要错误是：

• 业务不是企业架构的一个元素——EA 的一个主要部分是确保交付业务价值。大多数高管（来自业务或 IT 方面）都不愿意让 IT 进入业务领域。墙仍然存在，我相信将企业架构围在 IT 领域会阻碍 IT 将两者结合起来的能力。
• 感知到的需求就在当下——要做的事情太多了，EA 只是分散了在接下来的几周或几个月内交付软件的注意力。短期思维对于随着时间的推移提高性能或确保您交付业务实际需要的东西没有任何作用。交付的最低价值组件意味着没有交付价值更高的组件，从而降低了 IT 输出实现的价值。
• C 级套件的狂妄自大——世界各地的 CTO、CIO、CFO、COO 和 CEO 都有过成功的职业生涯。大多数人的外表和身高都高于平均水平。他们通过他们的能力和他们的能力达到了他们所在的位置。他们对自己的能力过于自信，因此不愿意支持可能挑战他们非结构化信念的结构化技术。 EA 利用元认知工具来构建分析并帮助为有效决策提供信息。
• 过度使用 EA — 最受欢迎的 EA 框架是 TOGAF。这是一个复杂而雄心勃勃的框架，有很多行话。 TOGAF 已经过时，源于瀑布思维。在敏捷的世界中，它适合哪里？好吧，有很多东西可以带走，也有很多东西可以留下。 EA 本身不应该是一个目标。努力应该集中在为组织带来价值上，尽可能地轻量化和自动化。

如何避免这些错误并有效执行 EA？它是通过使用数据和元认知工具来塑造您分析复杂系统的方式，并结合不懈地敲响为技术执行提供指导的原则。它还需要不懈地关注回报价值。

将来，我将撰写更多关于企业架构以及如何将其引入您的组织的文章。如果您有任何问题或意见，请告诉我。我喜欢反馈！

原文：https://www.naviger.com/enterprise-architecture-an-unknown-art-b16f4780…

本文：https://jiagoushi.pro/enterprise-architecture-unknown-art

它需要高级领导的支持和正确的企业架构工具来创建企业架构(EA)程序，从而成为增长、创新和业务战略的强大驱动力。房利美是抵押贷款机构的主要融资来源，它已帮助5000多万中低收入家庭实现了住房所有权。该公司的电子艺界项目已经取得了巨大的成功，这表明如果处理得当，电子艺界可以帮助公司克服一些最大的挑战。

使企业架构具有可操作性是大多数组织努力追求的目标，但是由于缺乏对项目的支持、协作、采用和清晰的目标，这一目标常常难以实现。同样重要的是，房利美的企业架构已经摆脱了其作为治理功能的形象，成为提高敏捷性、协作、透明度和加速数字转型的催化剂。

业务操作的变化比以往任何时候都要快，正因为如此，EA程序(以及支持它们的工具)必须促进敏捷性和变革性的计划，例如改进客户体验。

从企业架构治理开始

房利美(Fannie Mae)的企业架构计划最初是一项治理功能，如今已发展为在确定公司数字战略直至执行过程中提供可衡量的价值。房利美的成功之路可以教会我们所有人企业架构的最佳实践，以及如何开发一个为组织带来最大价值的EA程序。

房利美(Fannie Mae)的企业架构计划与许多公司一样，以治理为重点。该公司使用企业架构来执行策略、标准和过程，以确保遵从性，并减少风险。

将企业架构连接到业务

在兆丰企业架构解决方案的支持下，房利美通过促进协作和加强沟通的战略，将其企业架构计划从以治理为重点发展为以使能者为重点。房利美邀请了不同的商业用户组访问该软件并获取他们的数据。随着越来越多的信息开始进入存储库，它变得更丰富、更准确、更有价值。

今天，该公司的存储库是健壮的，数据准确，组织良好，支持自助服务，从而节省了时间和资源。MEGA的HOPEX软件促进了数据平台之间接口的建立，使得数据能够被拼接在一起，从而更容易准确地查看公司的it平台、流程和业务操作。大量准确的数据和对公司流程的不断增加的可见性使房利美有能力建立新的仪表盘和报告来推动可操作的工作。

利用企业架构做出战略决策

房利美通往企业架构成功之路的全部内容都是关于集成、协作、增加可见性，以及培养包容和支持的文化。房利美通过向决策者提供关键信息和指标，使他们能够看到所收集数据的价值，从而消除了EA的神秘感。通过提供可见性和信息来做出正确的决策，这些数据可以作为战略计划的良好起点。

加快创新和数字化转型的企业架构

投资组合架构师在房利美(Fannie Mae)颇具影响力，是所有与他们在各种项目上合作的人值得信赖的合作伙伴。实现了工具和过程，以便更好、更有效地使用技术。由于这些新工具及其自动化能力，房利美已经看到了数字文档的标准化和增长。

房利美继续使用EA促进创新和数字转型，并将兆丰的HOPEX软件视为未来业务现代化计划和客户体验改进的推动者。这需要时间和决心，但房利美成功地开发了一个EA项目，为公司提供了巨大的价值和洞察力。

原文：https://community.mega.com/t5/Blog-EN-Business-IT/Making-enterprise-architecture-actionable-Fannie-Mae-s-success/ba-p/17519

本文：https://pub.intelligentx.net/making-enterprise-architecture-actionable-fannie-maes-success-story

讨论：请加入知识星球或者小红圈【首席架构师圈】

在之前的Marc Lankhorst博客中，参考架构的价值得到了突出体现，包括原因和方式。在这篇博客中，我想深入一点，专注于我们（或我们中的一些人）熟悉的“产品” - 参考模型，使用ArchiMate作为语言。

什么是参考模型？

首先，我们退后一步，并参考参考架构，这些架构被描述为“为特定领域，行业或领域提供参考框架的标准化架构”。

参考模型带来的是一个非常清晰的视图（通常是在页面上）的感兴趣的领域 - 可以重复使用的东西，当然可以调整以适应组织。

参考模型类型的示例：

• 业务参考模型（或BRM）
• 技术参考模型（或TRM）
• 信息参考模型（或IRM）

有许多行业参考模型可供任何人使用，但真正的优势在于将这些模型转化为组织特定的参考模型 - 这些模型可以促进讨论，​​促进重用，并为其他建筑领域提供可追溯性。

我如何使用ArchiMate表示这一点？

参考模型通常只是PowerPoint幻灯片，Visio图表，甚至是Excel电子表格中的一些填充单元格。这非常适合进行通信，并且可以一次性获取消息。

当我们谈论企业架构时，很少有参考模型被孤立使用 - 我们需要将它们“链接”到其他区域，因此需要使用标准将参考模型元素绑定到 - 例如ArchiMate。

一次又一次出现的问题是 - “我应该使用什么概念来表示这个特定参考模型上的'块'？”

这是一个通常需要花费数天甚至数周讨论的主题领域 - 并且争论它实际上只是违背了使用参考模型的目标，因为，参考 - 我们需要就表示达成一致，然后只是始终如一地使用它！为了建议或回答这个问题，我们确实需要放大相关的参考模型。我将回顾上面提到的三个例子。

业务参考模型

基本上描述了“在页面上的商业”，我们将父母“区域”分解为儿童，然后是孙子等。它应该描述“组织的作用”，这通常提供了一个很大的线索。

对于那些至少具有ArchiMate工作知识的人来说，某种“行为”正在被描述，它本质上应该是“商业性的”。这听起来像商务功能！

Microsoft Industry Reference Architecture for Banking

技术参考模型

与业务参考模型类似，TRM通常描述“基于页面的基础结构”，但同样在更具功能性的角度 - 它不应该是关于服务器x，y和z，处理器和服务器的细节级别。 技术信息的类型。

考虑到这些要点，我们再次关注基础设施服务和基础设施功能（即行为）。

The Cloud Ecosystem Reference Model

信息参考模型

到目前为止，在上面的两个例子中，我们注意到“行为”概念似乎被使用 - 这通常是一系列参考模型的情况。 毕竟，“结构”概念通常更接近于实施。

IRM描述了组织内部可用的常见“信息”（TM论坛SID就是很好的灵感）。 从正确的角度来看，行为概念的使用并不合适 - 因此我们在逻辑上看待“被动结构”专栏（描述某种“对象”）。

正如ArchiMate的忠实用户所知，可能会决定是否使用Business Objects或Data Objects来表示IRM的元素。 这再次受到解释，但通常像“信息”这样的高级别可能最适合作为业务对象。

 The Information Framework (SID)

结论

因此，我们有它。 使用ArchiMate使用参考模型的一些建议。

您可以使用各种ArchiMate概念来表示模型中的元素; 但最重要的一点是要就标准达成一致（并坚持下去），在使用中保持一致，并分享结果！

最后一个结论侧重于向“非技术”利益相关者展示 - 记住，虽然建筑师可以用标准化的ArchiMate表示法创建参考模型（创建有效的关系以执行影响分析等），但没有理由不输出 是不同的（它可以是“通知”类型的观点）。

本文：http://jiagoushi.pro/reference-architecture-models-archimate

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

在此之前，我写过关于数字化变更功能以及企业架构如何支持并为您的组织提供价值的需求。 我还讨论了如何在不同的抽象层次上对架构描述进行分类。 但是有一个方面我没有深入研究：与您的组织相比，架构描述的概念性或具体性如何？

在过去的十年中，已经开发了参考架构，并且已经发布了许多参考架构。 它们是描述企业的一个非常有用的开端，架构或多或少地特定于我们的企业。 我不想在学术讨论中迷失自己应该归类为什么，所以我将专注于背后的想法的重点。

从通用架构到特定于组织的架构

上图中显示的频谱从左侧开始，具有最通用的架构类型，即Foundation Architectures。通用技术或基础架构体系结构通常属于此类，例如TOGAF 9.1规范所涉及的技术参考模型（TRM）。在这里，我们经常发现技术或技术平台的架构描述。

向右移动，Common Architectures可以基于Foundation Architectures构建。通常，这些对于组织的体系结构更具体，但是，这些体系结构仍然可以应用于所有行业。我想提出可以在不同行业中使用的企业资源规划（ERP）参考架构或ERP系统的示例。

如果体系结构更具体，但仍可能在同一行业的多个组织中重复使用，则这些体系结构可归类为行业体系结构，例如， ERP汽车参考架构。另一个例子是开发用于能源和水行业的ERP系统，其中一些国家的公司面临着许多不断变化的监管变化。

特定于组织的体系结构是您为组织描述的体系结构，主要用于支持程序或项目。因此，它们是您企业最具体的架构描述。

TOGAF称架构描述为“工件”，它是“描述架构方面的架构工作产品”，可以用表格，矩阵或图表表示（TOGAF 9.1,2.5）。 TOGAF规范中有关于此类别频谱如何相互关联的更多信息，但让我关注最实用的部分。

你在实践中用了什么？

在实践中，我经常看到特定于组织的体系结构（我们的体系结构描述）和特定于行业的体系结构。如果您找不到适合您所在行业的参考架构，您可能需要再次尝试寻找更通用的架构 - 通用架构或基础架构。这些参考模型存在于各种架构领域中;例如用于功能，业务流程（例如ITIL），功能，应用程序，技术或风险和安全性。

现在，您可以根据功能/解决方案描述并根据其特异性对体系结构描述进行分类。以下示例将有助于在实践中应用此分类。

体系结构分类的实例

为了实现这一目标，您可以使用提供技术信息服务的公司提供的技术分类分类法。其中一家公司是Flexera BDNA Technopedia，它提供有关技术生命周期的信息等。这是对技术进行分类的良好起点，是旧版TOGAF TRM的替代品。此外，如果您错过了某些分类，请记住TOGAF所说的“根据您的需要定制参考模型”。

下表显示了企业连续体中的示例：

现在，您可以通过该方法对架构描述进行分类。 为了实现EA成为自适应企业的价值主张，您可以仔细研究架构和解决方案构建块，这可以防止您在管理作为EA架构师的所有已部署实例时迷失方向。

在本系列的下一篇博客中，我将概述如何使用ArchiMate以全球标准符号描述这些体系结构。 这将帮助您标准化有关架构描述的沟通，以支持战略变更！

要获得有关ArchiMate及其在BPMN，UML和其他符号旁边的定位的简要说明，请阅读将ArchiMate 3.0与其他标准结合使用。

讨论:请加入知识星球【首席架构师圈】

在之前关于我们协作平台功能的博客文章中，我们已经解释了如何通过结构化工作流支持人们在架构和其他模型上一起工作。在那篇文章中，我们展望了未来的功能，以支持这种协作。是时候向您介绍最新动态了！

 -  Marc Lankhorst，Fabian Aulkemeier

首先，我们需要区分不同类型的用户。一方面，我们有建模专家使用Enterprise Studio来创建，分析和更新不同类型的模型。另一方面，有各种类型的临时用户，他们不需要完整建模环境的力量，但他们想要获得洞察力，提供反馈，审查，批准或以其他方式与这些模型交互。这些用户更可能习惯于我们的协作和发布门户网站HoriZZon。

至少有两个常见案例，这两个小组紧密合作：

• 收集来自更广泛组织的意见。例如，来自“业务”的某人想要请求更改某个需要由专家实施的流程模型，或者组织中的应用程序所有者需要提供有关他们负责的应用程序的某些属性的信息。
• 在围绕体系结构，业务流程或数据模型的治理流程中。在这里，具有一定管理职责的人（比如架构委员会的成员，安全官或数据所有者）需要审查和批准某些模型，并且专家（例如架构师）需要处理此反馈。

在Enterprise Studio和HoriZZon中，我们现在通过输入表单和自定义工作流为这些场景提供广泛的支持。

在HoriZZon输入表格

为了帮助您从组织收集相关输入，例如在上述场景中，在下一版HoriZZon中，您将能够配置输入表单。这种形式由一组各种类型的字段组成，从简单的名称和数字到更复杂的字段，如模型对象和需要参与的用户ID。
在下面的示例中，此类表单用于从应用程序管理器收集数据。他们需要填写许多不同的领域，从名称，首字母缩略词和所有者到生命周期状态，支持层和它提供的服务。

以这种方式收集的输入不会直接放入模型中。这将是有风险的，因为不是每个人都是建模专家，并且这些领域中的一些（例如所提供的服务）需要在模型中创建某些关系。这是应该由专家检查和执行的事情。出于这个原因，来自这种表单的输入被发送回具有Enterprise Studio的用户，然后Enterprise Studio可以简单地应用建议的更改，改进甚至拒绝它，以防它导致一些不一致。

这种工作方式的各个步骤是使用工作流程配置的，我们的下一个主题。例如，您可以使用此类工作流将上述调查表单发送给所有应用程序所有者，或者用于更高级的治理目的。

自定义工作流程

在许多组织中，对架构，流程和数据的更改进行明确而严格的管理至关重要。例如，监管合规或风险管理可能要求特定的工作人员批准某些变更。在大型组织中，这可能需要多个步骤并涉及各个部门和角色。还有其他场景需要这样一个结构化的过程，如上面提到的调查。

为了支持这些类型的流程，HoriZZon整合了一个完整的工作流引擎，可以根据您的特定流程进行配置。基本的批准和更改工作流程是开箱即用的，但您也可以配置自己的自定义工作流程，在BPMN模型中定义。

下面的示例显示了如何通过在与应用程序架构师对话的情况下提供信息的输入和潜在补救来使前一示例中的应用程序管理器参与架构的维护。

在这样的工作流程中，您可以定义需要执行特定步骤的人员，从而确定所涉及的每个人之间的协作。通过电子邮件通知需要执行步骤的人员在HoriZZon中有等待他们的任务;例如，架构委员会成员需要批准一些更改。您可以使用表单配置事物（如上所述）以从任务执行者获得各种输入;例如，如果进行了一些更改，架构板成员可以给出有条件的批准。此输入将通过Enterprise Studio发送回建模人员，Enterprise Studio会将其选中并处理输入;在该示例中，架构师应用架构板成员建议的更改。然后可以将结果发送回HoriZZon以供架构委员会最终批准。

上面的示例仍然非常简单，但您可以根据需要将这些工作流程设置为高级，涉及多个个人，组或角色。结合这两个功能，输入表单和自定义工作流，为您提供了组织模型周围各种组和角色协作的方法。鉴于我们平台的灵活性和可配置性，这方面的机会是无穷无尽的。

您想了解更多有关我们平台的这些和其他功能的信息吗？参加我们的网络研讨会或申请免费试用！

ALSO CHECK: Data Analysis with Dashboards in HoriZZon

原文:https://bizzdesign.com/blog/organizing-architecture-governance-with-workflow-and-forms/

本文：

讨论:加入知识星球【首席架构师圈】

Dragon1是企业架构建模和设计的专用软件。在此页面上，我们提供了创建EA蓝图的教程。首先，我们介绍一些关于创建EA蓝图的开放式Dragon1 EA方法理论，接下来我们将在Dragon1平台上创建EA蓝图的步骤布局。

学习目标

本教程的学习目标是：

• 什么是企业架构？它的功能是什么？
• 什么是EA蓝图？为什么要创建一个？
• 企业架构师的主要任务是什么？
• 如何在Dragon1上创建交互式EA蓝图？

介绍

作为架构师，您通常需要为利益相关者创建景观，蓝图和路线图。因此Dragon1被优化以创建这三种类型的可视化。

企业架构蓝图，五大＃1

作为EA方法的一部分，Dragon1定义了一个包含参考模型和体系结构的开放EA框架。

五个最重要的蓝图被命名为“五大”，其中EA蓝图是最重要的蓝图。那个我们将在这里讨论。

在创建EA蓝图之前，请务必按照“入门”区域的“跳转右侧”页面中的建议开始使用第一个教程。

为什么要创建EA蓝图？

有许多不同类型的组织，如企业，公司，学校和政府机构。所有这些都是组织，因为他们是使用手段和资源共同实现目标的人群。

您越了解人员，手段和资源的组织方式，就越能够更好地管理它们以实现目标。管理我们的意思是：设定目标，检查进度和（重新）指导项目或工作。

但是，组织通常缺乏结构的概述和依赖性。这是因为组织不断创新并适应他们变化的环境（在改变客户需求，技术和立法方面）。蓝图是在组织所包含的部分之间存在相互关系或依赖关系时创建概述和见解的最佳实践。

结构（总元素）

企业架构作为一个工作领域和Dragon1开放EA方法将组织视为流体系统。

在逻辑层面，系统由元素组成。没有一秒钟，组织与另一秒组织相同。系统中的所有元素都与其他元素直接或间接相关。这意味着如果要更改组织中的元素，则更改的内容将超过直接结构。您还将更改您不想要或不想要的相关部件。或者反过来说，其他部分可以阻止或阻碍您的预期变化。

架构（总体概念）

了解组织如何存在元素以及它们如何相关，就是了解组织的结构。它是组织的物理（技术）或逻辑（功能）级别视图。但是当你知道元素组如何协同工作作为产生结果的概念时，你就会知道组织包含哪些概念（及其原理）。换句话说，您就知道了组织的企业架构。为什么这很重要？好吧，如果您更改元素（在逻辑级别）或组件（在物理级别），您可能会干扰或启用元素的组协作（即概念的原则）。

假设您的组织正在打印书籍，但新购买的干净再生纸比以前使用的纸张厚。然后，使用当前的打印机打印可能不会成功，并且还必须购买新的打印机。因此，这篇新论文破坏了当前组织的印刷原则：通过使用廉价和薄纸，我们可以使用任何低成本的打印机，并生产大量的书籍，以获得有利可图的价格。

作为一名架构师，您可以通过沟通概念和原则的当前状态以及战略需要哪些新概念和原则以及变革如何影响组织中的概念和原则来获得巨大的附加价值。换句话说：您绝对应该创建企业架构蓝图以增加您的附加值。

设计蓝图

Dragon1 open EA Method将体系结构定义为结构（如组织）的特殊总体概念。架构师被定义为该概念的设计者及其实现的监督者。因此，为了创建EA蓝图，架构师必须选择和分组概念。但要了解组织需要什么概念，架构师必须知道架构在组织治理中的位置。架构被Dragon1定义为战略与转型之间的桥梁。因此，任何总体概念（=架构）都可确保执行正确的转换以实现策略。并且架构为执行转换的所有程序和项目提供了完整的设计或蓝图。

架构师必须去组织的战略利益相关者并获得有关战略的信息（使命，愿景，抱负，起点，问题，关注点，目标，需求和要求等......）

有了这个，他收集，选择，组amd修改和适应概念，因为它们是策略所要求的。在EA蓝图上，架构师将概念，原理，元素和/或组件作为一个整体设计。这些部件通常按层和域分组。在EA蓝图中，通常可视化层：市场和客户，治理，业务，信息（或数据和应用）和技术或这些层的任意组合。这些层填充了来自概念的元素或组件。像业务层中的流程，功能和单元一样。

接下来，架构师定义转换的各个部分：程序，项目，阶段，阶段，里程碑和可交付成果。

因此，在开始在Dragon1上创建EA蓝图之前，了解所有这些是一件好事：为什么，什么以及如何创建EA蓝图。

创建企业架构蓝图

以下是在可视设计器中创建蓝图的步骤。您将在下面看到一个屏幕截图，其中显示了您可以用作编辑模板的示例蓝图。

要创建EA蓝图，请执行以下操作：

• 在电子表格中收集策略，体系结构和转换数据
• 创建文件夹结构
• 自动导入数据或手动输入数据
• 丰富数据 - 如果缺少数据，请填写数据
• 创建模型 - 创建包含所有数据的企业模型，或创建一起形成企业模型的多个模型
• 在模型中创建大约20个数据视图：利益相关者视图，关注视图，产品视图，流程视图，应用程序视图，程序视图，可交付成果视图等...）
• 创建可视化
• 在可视化上绘制每个视图的可视项
• 将Visual Items链接到视图
• 在正常模式下切换蓝图并观察您的蓝图（正在解释可视项目）
• 当然，您可以创建单独的战略和转型蓝图，或为特定项目或解决方案创建解决方案蓝图或路线图。
• 您还可以创建AS-IS蓝图或TO-BE蓝图，并在它们之间定义GAP并显示该GAP。
• 无论如何，创建EA蓝图后还有很多事情要做。
• 将蓝图发布到Content Viewer并与利益相关者共享。
• 请他们在Content Viewer中添加评论。
• 处理评论以改进蓝图。
• 教育利益相关者可以使用蓝图以及如何使用蓝图。
• 下次要创建EA蓝图时，请使用此蓝图从导演获取设计任务，作为架构师的所有者/客户。

下面我们将详细介绍上面的所有步骤。

创建文件夹

要为EA蓝图创建文件夹结构：

• 创建档案结构

导入数据

要自动导入数据或手动输入数据：

• 导入数据
• 输入数据

创建模型

创建包含所有数据的企业模型，或创建一起形成的多个模型和企业模型。

要为EA蓝图创建企业模型：

• 创建模型

创建视图

在模型中创建大约20个数据视图：利益相关者视图，关注视图，产品视图，流程视图，应用程序视图，程序视图，可交付成果视图等...）

要创建视图：

• 创建一个视图

创建可视化

我们现在有数据，模型和视图。最后，这些视图需要在可视化画布上可见，以形成可视化。首先，我们将创建一个可视化画布。

要创建可视化画布：

• 创建可视化
• 插入体系结构视图布局模板

•  

绘制视觉项目

Visual Item是一个形状/数据占位符，放置在可视化文件上并链接到视图。可视设计器将解释在“正常模式”下可视项目中配置的规则，以在可视化画布上显示链接视图的数据。

在每个视图中绘制可视化上的可视项目。

要在可视化画布上插入可视项：

• 插入可视项目

在您希望在可视化画布上生成视图数据的确切位置绘制包含背景颜色的可视项目是一种很好的做法。

视觉项目需要链接到视图。

确保你已经这样做了。

切换到普通模式

在正常模式下切换蓝图并观察跟踪和跟踪蓝图

要在正常模式下切换蓝图：

转到播放器栏并将编辑模式切换到普通模式
现在将解释可视项目，如果所有设置都正确完成，将在正确的位置显示视图的数据。

发布

将蓝图发布到Content Viewer并与利益相关者共享。

要发布蓝图：

• 发布可视化

•  

添加交互性

如果要为EA蓝图添加交互性，可以执行以下操作。您可以在鼠标悬停或鼠标单击形状时生成弹出对话框。您可以通过此蓝图的链接插入时钟到其他可视化。例如，如果单击它，则转到流程或应用程序的详细可视化。

要生成弹出对话框：

• 使用弹出对话框

要插入点击链接：

• 使用点击链接

第三个标准的交互性是跟踪和跟踪。对于跟踪和跟踪，您无需执行任何额外操作。通过可视设计器和内容查看器中播放器栏上的开关，您可以打开和关闭跟踪和跟踪。

示例屏幕截图

原文: https://www.dragon1.com/help/create-enterprise-architecture-blueprint-big-five-1

很少有组织能够系统可靠地将业务战略转化为跨组织所有相关要素的行动。只有在稳定的情况下，才能通过连续的分解，设计和实现步骤来实施长期计划。传统的自上而下策略实施无法跟上快速变化的环境所需的转换速度。

组织需要通过将同时运营的学科与相同的期望业务成果保持一致来开发一致的业务转型管理能力，从而将它们指向同一方向。这种能力协调和协调各相关学科的变革工作。这需要从不同的角度清楚地了解企业的​​结构和发展。我们至少看到了业务转型中涉及的以下相关学科：

• 战略发展
• 基于能力的计划
• 企业组合管理
• 计划和项目管理
• 持续交货
• 服务管理
• 流程，规则和数据管理
• 治理，风险和合规

在之前的博客中，我们描述了企业架构如何在此转型管理中充当“知识中心”。企业架构模型的使用为这种连接作用提供了理想的基础。

在BiZZdesign的Enterprise Studio中，我们为这些关系提供广泛的支持。 Enterprise Studio使组织利益相关者能够将业务战略转换为转型计划，并通过使用EA模型集成各种观点的指标。我们正在扩展我们的工具能力，以实现企业组合管理，决策管理，风险管理，利益相关者协作以及与项目管理和BI工具的集成。因此，Enterprise Studio使用户能够有效地建模和分析目标业务成果与支持它们的计划和项目之间的直接视线联系。

这些关系的一些例子如下所示。该图显示了战略，基于能力的规划和企业架构之间的典型信息流。在这个三角形中，我们看到该战略通知了基于能力的规划和企业架构。战略重点，业务模式和目标运营模式。考虑到架构的当前状态和灵活性，EA提供有关这些选择的成本和可行性的反馈。基于能力的计划根据战略方向定义所需的能力并设定变更目标。 EA用于评估其依赖关系和变更的影响。

Enterprise Studio以各种方式支持这些关系。 例如，您可以使用Business Model Canvas来描述您的业务模型和策略。 有关您的运营模式的战略决策可以转换为有关业务功能标准化和集成的架构原则，这反过来又会影响支持应用程序的设计。 描述业务能力图的体系结构模型在此上下文中是非常有用的工件。

反过来，这样的能力图可以与支持业务流程和IT资源相关联，并且支持您的策略所需的能力级别可以转化为这些流程和资源的改进。 您可以使用Enterprise Studio的Enterprise Analytics模块执行成本计算，分析当前的IT环境或评估更改的影响，并以可访问的管理仪表板的形式显示这些结果。 该信息是您的资产组合和变更计划的投资决策的重要输入。

企业组合管理和企业架构共同为项目和项目管理提供指导。 EPM设定投资优先级并确定各种变更计划的预算，而EA则用于分析其收益，成本，风险和依赖关系。 反过来，程序和项目管理提供了考虑到这些依赖关系的变更路线图。 它还为EPM提供有关计划和项目所交付的价值和预算的跟踪数据。

Enterprise Studio为您提供了一个管理此信息的集成平台。 其坚实的基础，基于您企业的形式化模型，确保了一致和连贯的信息库。 这对于明智的决策至关重要，可以将所有相关的学科都集中在实现战略业务成果上。

原文：https://bizzdesign.com/blog/driving-business-outcomes-with-enterprise-architecture-as-a-knowledge-hub/

本文：http://pub.intelligentx.net/driving-business-outcomes-enterprise-architecture-knowledge-hub

讨论：请加入知识星球或者小红圈【首席架构师圈】

在我之前的博客文章中，我写过关于价值驱动的企业架构及其与企业内不同学科的关系。在这篇博客中，我想关注使用参考体系结构的附加价值。

什么是参考架构？

参考体系结构是标准化体系结构，为特定域，扇区或感兴趣的领域提供参考框架。参考模型或体系结构提供了通用词汇表，可重用设计和行业最佳实践。它们不是解决方案体系结构，即它们不是直接实现的。相反，它们被用作更具体架构的约束。通常，参考架构包括通用架构原理，模式，构建块和标准。

许多域都定义了自己的参考体系结构。众所周知的例子包括：

• 银行业的BIAN服务格局;
• ACORD保险业框架;
• TMforum为电信行业提供的eTOM业务流程框架;
• 各种政府参考架构，例如荷兰NORA及其“女儿”，美国FEAF或澳大利亚AGA;
• NAF，DODAF和MoDAF等国防架构框架;
• 制造和供应链的参考架构，如ISA-95和SCOR。

这些体系结构中的大多数包括域中的公共业务功能/功能和业务流程。除此之外，它们可以包括例如通用数据模型，通信标准和交换格式，有时甚至包括通用软件构建块和其他可重用资产。

为什么要使用参考架构？

那么使用这种参考架构的价值是什么？为什么以及何时应该使用它们？

首先，参考体系结构提供了一个参考框架，可帮助您了解特定域，并为您自己的企业体系结构工作提供了一个起点。它们为您提供基本结构，因此您无需重新发明轮子（无论如何通常都是正方形）。参考体系结构对于您不与其他人竞争的组织的这些方面和元素最有价值。

例如，典型保险公司的业务功能与其竞争对手的业务功能大致类似，其业务流程也很多。竞争差异很可能出现在其产品，定价，客户群和客户关系中。重用参考架构提供的行业最佳实践可确保您不会在这些非竞争方面落后于曲线。我们在许多IT系统的实施中也看到了这一点，其中SAP等供应商为组织的大部分提供参考流程。例如，您的会计流程很少具有竞争优势。

使用参考体系结构的第二个原因是互操作性。在我们日益网络化的世界中，组织需要与各种其他方面建立联系和合作。参考体系结构提供的标准和构建块有助于实现这些连接。一个相关的好处是使用标准提高了灵活性，因为交换通过标准化接口连接的构建块更容易;反之亦然，如果构建模块本身是标准化的，那么开发标准要容易得多。乐高是一个完美的例子，正如我的同事Bas van Gils最近在他的博客中所描述的那样。

这就引出了使用参考架构的第三个原因：兼并和收购以及外包。如果双方使用相同的语言，使用相同的标准，并认识到功能，过程和/或系统之间的相同边界，则以新的方式重新组合它们的元素将更加容易。

使用参考体系结构的第四个原因是为了促进您所在行业的基准测试。通常，公司之间的差异不在于例如他们的业务流程，但在他们的执行。使用参考设计可以更容易地比较这些执行结果。

基准测试将我们引入参考架构非常重要的第五个原因：法规遵从性。通常，监管机构规定（或至少强烈建议）参考架构。例如，会计原则，实践和流程日益标准化和强制执行。这导致了业务报告标准，甚至达到了XBRL等交换标准的水平。

如何使用参考架构？

在决定使用参考架构之前，应该满足一些条件。首先，参考架构应该是基于社区的。用户而非供应商应决定最佳实践，并且应该由用户社区主动维护该体系结构。世界正在发生变化，您的参考架构也应如此。

在描述架构时，使用开放标准可以理想地补充这种积极和开放的社区流程。 BiZZdesign提供了许多开箱即用的参考架构模型。

在组织中使用参考体系结构也需要治理：组织应该真正致力于其使用，并且应该以某种方式“强制执行”。如果人们真正按照预期使用它们并且实际遵循他们的指导，那么参考体系结构才有价值，否则重用行业最佳实践的整个想法就会崩溃。

最后，您选择的参考架构应提供真实，可操作的指导。一般的架构原则是不够的。需要实际结构，例如在业务功能或流程，构建块和标准方面，为您自己的架构工作提供有用的主干。

使用参考体系结构并不意味着您失去了所有的设计自由。相反，您可以将这种自由集中在企业的哪些方面，从而实现真正的改变。这是您作为建筑师可以增加最大价值的地方！

原文:https://bizzdesign.com/blog/the-value-of-reference-architectures/

本文:http://pub.intelligentx.net/node/370

讨论:加入知识星球【首席架构师圈】

近年来，企业架构领域对ArchiMate标准的采用发展迅速。2017年底，它又向前迈进了一步，被北约批准与北约架构框架[1]一起使用。ArchiMate流行起来的原因是什么?

ArchiMate是什么?

ArchiMate®是一种用于描述和可视化企业架构的语言。它最初是在2002年至2004年间由荷兰Telematica研究所开发的。2008年，所有权转移到Open Group®，该公司将其作为开放标准进行管理。企业架构师通常使用一系列不同的表示法。大多数，如BPMN™和UML®，是为特定的目的而设计的，如流程建模或软件开发。ArchiMate通过其企业建模范围将自己与这些工具区别开来，这使得它特别适合于改进业务和it之间的一致性。

为什么ArchiMate企业架构框架如此成功?

ArchiMate旨在成为一种简单的语言，它包含正确的概念，在正确的层次上，支持企业架构的实用建模方法。它在定义语言范围的框架上下文中设置概念。“核心”框架包括用于业务、应用程序和技术的层，以及用于战略、实现和迁移的附加层。通过围绕IT和业务，ArchiMate解决了业务和技术涉众的主要关注点，为他们提供了一组用于描述企业的公共概念和视图。

ArchiMate定义了如何使用定义良好的关系将描述企业的概念链接在一起。使这些关系清晰和明确，使涉众能够评估和交流决策和更改在各个领域的结果。ArchiMate中的许多概念和关系都是基于UML和BPMN中的概念和关系，为这些建模语言提供了一个方便的桥梁。

然而，ArchiMate并不打算取代这些现有的标准。事实上，ArchiMate的成功很大程度上可以归因于这样一个事实，即它的目标是尽可能小，通过只包含那些对其预期目的有用的概念和关系，使学习变得更容易。这可能被认为是限制性的，但正如语言学家Guy Deutscher[2]所指出的:

“如果不同的语言以不同的方式影响我们的思维，这并不是因为我们的语言允许我们思考，而是因为它让我们习惯性地思考。”

把事情省略掉可以帮助我们集中精力描述什么是重要的。ArchiMate提供了企业的视图，作为道路地图集，而不是详细的调查地图。

一些建模符号，特别是那些来自软件分析和设计技术的符号，可以促进对高级业务涉众来说过于详细的方面的关注。此外，它们经常遵循“关注分离”的工程原则。这导致了建模过程、数据、基础设施等的清晰且严格划分的图表类型。相比之下，ArchiMate解决了高级利益相关者看到“大局”的需求。它鼓励使用面向利益相关者的视图来显示感兴趣的对象之间的关系，不管它们是什么。对象可能来自不同的层。例如，可以在一个图表中显示为特定类型的客户提供服务所需的技术、应用程序和流程

越来越多的组织和顾问正在采用ArchiMate。作为一个独立的标准，它不依赖于特定的供应商或工具。这有助于避免厂商锁定并降低培训成本，因为如果用户迁移到新的ArchiMate工具，他们不需要学习新的符号。主要的技能和培训是广泛可用的，所以新员工可以很快变得富有成效。此外，用户可以通过开放群组的ArchiMate论坛来提高自己的知识和分享经验。

在企业架构领域中处于领先地位

ArchiMate并不打算取代现有的建模技术。正如ArchiMate规范所述:

“许多其他语言试图满足所有可能用户的所有需求。为了简单的学习和使用，ArchiMate语言被限制在那些足以建模80%的实际案例的概念上。

ArchiMate通过以超越领域边界的标准方式捕获和可视化架构信息，补充了其他建模技术的使用。这样做实际上有助于利用其他技术。许多EA计划之所以失败，仅仅是因为信息以主要涉众无法理解的模型的形式被捕获(并保留)。ArchiMate提供了一种方法来可视化在其他模型中创建的选定对象和关系，从而使那些模型的价值在更大范围的涉众面前显现出来。通过提供一种通用的沟通方式，ArchiMate为所有的涉众(业务和技术)提供了一个企业的综合视图。

HOPEX ArchiMate如何为您的架构工作增加价值

作为企业架构的领导者，MEGA将ArchiMate 3.0.1标准集成到其通用的企业架构存储库中，以加速时间与价值的转换。这个ArchiMate的新实现构建在一个统一的HOPEX平台上，它通过共享关键对象来提供与其他企业架构产品的兼容性。这使得企业架构师能够轻松地在用例之间移动，例如应用程序组合管理、IT合理化、IT战略规划和业务流程分析。

References

[1] “NATO C3B Adopts OMG Unified Architecture Framework Metamodel”, OMG Press Release, 27 November 2017. http://www.omg.org/news/releases/pr2017/11-27-17.htm

[2] “Does Your Language Shape How You Think?”, Deutscher, G., The New York Times Magazine, 26 August 2010. https://www.nytimes.com/2010/08/29/magazine/29language-t.html?_r=1

[3] “ArchiMate® 3.0.1 Specification”, Section 3.1: Language Design Considerations, The Open Group, 2017. http://pubs.opengroup.org/architecture/archimate3-doc/chap03.html

原文：https://community.mega.com/t5/Blog-EN-Business-IT/How-adding-ArchiMate-to-your-enterprise-architecture-toolkit/ba-p/17266

本文：https://pub.intelligentx.net/how-adding-archimate-your-enterprise-architecture-toolkit-helps-give-you-big-picture

讨论：请加入知识星球或者小红圈【首席架构师圈】或者加微信小号【intelligenttimes】

在 IT 领域工作了二十多年，我遇到了各种描述 IT 环境的不同方法。我最喜欢的模型是我自己提出的数据驱动模型，但需要最新的 CMDB 和 Visio。有像 TOGAF 这样的标准方法，提供 Open Group ArchiMate 图表定义，用于建模企业架构。规格很广泛，但我想我会分享我使用通用办公生产力工具 Powerpoint 的简单解决方案。

通常，要创建企业架构图，您可以使用标准的 Microsoft Visio，或者如果您更认真，则可以使用 Sparx EA。我发现你也可以使用简陋的 Powerpoint 进行管理。您只需要使用我创建的演示模板。它允许您拖放元素以按照您喜欢的方式创建模型。为了帮助您入门，我在这里描述了三个最有用的图表和使用模板创建它们的过程。

所选模型使用 TOGAF 定义的六个不同层（业务、应用程序、技术）中的三个来描述架构。 （战略、物理和实施与迁移层，我们将在下次讨论）

业务层

无论您是为解决方案架构创建图表还是试图描述完整的企业架构，最好的方法都是从业务层开始。第一个图表将用于通过定义角色、服务、流程和数据来设置架构描述的范围。为此，请创建一个列表，然后使用下面的前四个元素并将它们展开在您的第一张幻灯片上。为了清楚起见，我留下了<标准名称>，但您应该使用对您有意义的名称相应地标记元素。

下一步将是创建一个交互图，其中定义了业务参与者和连接。 所以基本上你只需要根据数据流、交互和依赖关系来连接你的元素。 现在 Powerpoint 真的不是一个绘图工具，所以它需要更多的摆弄才能得到你想要的流程。 在我的模板中，标签是与箭头分开的对象，因此一旦您将它们复制粘贴到您需要它们的一般区域，您可能希望将它们取消组合。 您最终将得到一个类似于下面显示的图表。

另一种方法是仅使用标准连接器并更改形状的轮廓以匹配所需的箭头和可能的线条中的破折号。对于专业化、实现和聚合箭头，您需要使用复制粘贴添加自定义箭头。在此阶段，您还希望使用对您的组织有意义的解释来标记连接器。在实践中，很多人只使用普通的箭头连接器，只使用标签。

一个问题是 Powerpoint 幻灯片上的空间是有限的，但由于我们想要保持图片可读，我们并不真的想要创建巨大的图表。将设计拆分为逻辑块是一种很好的做法，其中一个业务角色的交互和流程在单个图表中进行描述。从某种意义上说，这也是一种很好的做法，因为您可以更容易地进入下一步，使用相应的应用程序层元素来描述应用程序的功能。

应用层

现在这一步的主要目标是将业务服务描述为最终可以作为服务实现和管理的技术组件。在现代微服务架构中，应用程序逻辑将由负责实现业务服务的每个不同部分的独立组件组成。我们对数据模型和信息流掌握得越好，以后就越容易将实施工作分解为可管理的任务作为工作包。

应用程序视点图由它提供的服务、它使用组件内部运行的功能实现的流程组成。 因此，首先从业务层收集与业务流程匹配的应用程序流程是最容易的。 现在每个流程都将由 IT 服务实施。 在服务或应用程序中，有一些组件实现了通常对应于流程的功能。 有时存在更高级别的抽象，并且函数实际上被多个进程使用。

无论您是描述现有解决方案、重构它还是创建一个全新的解决方案，接下来的分析任务都至关重要。了解与我们对解决方案的要求相匹配的模式和最佳实践应该可以指导我们找到正确的解决方案。最重要的是，我们清楚哪些组件应该由使能技术提供，哪些实际上是我们自己解决方案范围的一部分。为这些依赖项添加数据对象和技术接口有助于我们了解全局。

技术层

在描述了业务服务的功能之后，我们需要开始设计具体的操作环境。位置为我们提供了所需网络架构的提示。技术是指托管堆栈，节点是实际的应用程序驱动环境。可以有多层节点、技术和位置，以便我们可以根据需要尽可能详细地描述地理分布要求、虚拟化和容器托管。

我喜欢从应用程序组件开始，因为您应该从应用程序级图表中准备好它们。 基本上只需从应用程序层幻灯片复制粘贴行并将它们设置为新幻灯片上的最高。

结论

使用 Powerpoint 绘制企业架构图是开始描述您的需求、所需功能和操作环境的一种简单方法。 我们已经描述了一个基本的图表，但很容易扩展（即颜色元素）模板以满足您的组织需求。 此外，为了使模板更可用，组件可以以 .emf 格式定义并导入到 Powerpoint 工具中。 然而，目前只创建了基本的业务、应用程序和技术形状。 用策略和迁移层的对象填充整个调色板仍然是一项简单的工作。 现在，作为家庭作业，您可以创建自己的图表，并使用 <serving> 连接器将所有三个连接在一起形成一张大图。

原文：https://medium.com/@roxblend/modeling-enterprise-architecture-in-powerp…

本文：https://jiagoushi.pro/node/2182

企业架构是一门完整的科学和专业。 尽管如此，企业架构领域还很年轻，所以对于我们大多数人来说，它都是全新的。 在下面您将找到一个“如何”分步教程列表，以创建有效的，可视化和交互式的架构产品。

当你忙的时候企业架构
在工作中，您很好奇如何创建某些企业架构产品或如何执行某些架构流程？ 本网站上的资源是您的指南，它将引导您完成符合Dragon1开放EA方法的Visual Enterprise Architecture的步骤。

您的分步教程

在这里的每一页上，您都会找到一系列步骤来设计符合Dragon1开放EA方法的非常有用的架构产品。 产品的顺序是创建符合Dragon1开放EA方法的产品的理想/正常顺序。

我们为您提供以下分步教程：

A）企业架构 - 概念架构设计

创建的以下产品都是架构设计应用程序的第1阶段：

1. 如何创建利益相关者需求和需求分析图（利益相关者企业愿景）
2. 如何创建企业结构元素和功能图（企业结构愿景）
3. 如何创建企业架构功能，概念和原理图（企业架构愿景）
4. 如何创建ArchiMate业务功能图？
5. 如何创建企业全面概念的设计草图？

B）企业架构 - 初步架构设计

创建的以下产品都是架构设计应用程序的第2阶段：

1. 如何创建一个概念的原理细节图？
2. 如何创建元模型，用户模型和实例模型？
3. 如何创建流程横向图（具有业务功能）？
4. 如何创建应用程序格局图（静态和动态）？包括域，信息系统，套件，模块，组件，对象，接口，连接，软件和服务。
5. 如何创建技术（服务）路线图
6. 如何创建AS-IS企业架构蓝图
7. 如何设置AS-IS体系结构原理文档/数据库

C）企业架构档案

创建的以下产品都是企业架构档案的一部分：

1. 如何设置EA基准
2. 如何创建AS-IS企业架构框架图？
3. 如何设置术语文档/数据库的词汇表
4. 如何创建AS-IS企业架构（文档）
5. 如何创建AS-IS治理体系结构（文档）
6. 如何创建AS-IS业务架构（文档）
7. 如何创建AS-IS信息架构（文档）
8. 如何创建AS-IS技术架构（文档）
9. 如何创建AS-IS安全体系结构（文档）

通过遵循这些教程，您将涵盖Dragon1开放EA方法中的流程，产品，清单，文档模板和其他实际内容。

阅读

逐步教程的目的是让您对设计架构产品感兴趣。从那里你可以决定跟随一个
训练课程
或者创建一个免费的Dragon1帐户。

如果您对架构设计感兴趣，可能还需要阅读：

• Terms > Architecture Framework Definition
• Software > Enterprise Architecture Tool
• Software > ArchiMate Tool
• Software > BPM Tool
• Examples > Application Landscape Diagram
• Examples > Process Landscape Diagram
• Examples > IT Landscape Diagram
• Examples > IT Infrastructure Enterprise Blueprint

入门

你想自己创建一个架构图吗？可以使用Dragon1 PRO创建这些架构产品。

在我之前的帖子中，我讨论了三个不同的路线图以及它们之间的关系。在这篇文章中，我们将详细介绍能力路线图。能力路线图将能力映射到时间线（duh）。业务能力是做某事的能力。它们是业务架构的常见元素，对战略执行很有用。

能力的例子包括：

• 位置识别——确定最佳位置以建立具有最快投资回报率的实体位置
• 库存优化——最大限度地减少仓库库存的能力
• 功能速度——更快地产生新功能，以更好地满足客户需求。

就像是：

• 提供工作流功能，允许您的客户使用低代码方法定制您的系统

可能看起来像是一种能力，但事实并非如此。它是一个产品功能，即使它在描述中具有功能。

通常，能力被定义为名词。

能力代表降低成本、增加价值或以其他方式推动组织执行战略的活动。这里的关键词是策略。能力需要与战略挂钩。战略是一个完全不同的话题，已经写了很多年了，将来还会继续写。您如何定义战略超出了本文的范围，但出于我们的目的，我们需要制定战略目标。这些是可衡量的目标，表明您执行策略的效果如何。这些能力应该与这些目标直接相关。例如，如果战略增长目标是每年 25 个新的实体店（战略目标），那么平均 60 天来开设新店（可衡量的能力）将支持战略目标。

能力也会随着时间的推移而改变——无论是在规划方面还是在重新评估方面。上面提到的 60 天平均值可能是下一财年的 45 天。这将是一个有计划的变化，它们可能是不同的工作流集来支持每一个。但它们也可能因战略或市场条件的变化而发生变化。也许很明显，由于颠覆性技术，能力不再是战略优势。

能力不是业务流程——业务流程是完成某事的方式以及参与者、系统和任务之间的相互依赖关系以实现这一目标。能力范围更广，更类似于组织技能。能力也不是价值流。价值流分解了为组织创造价值所涉及的步骤。价值流有它们的位置，也是业务架构的重要元素。它们将在以后的文章中讨论。

这些能力是如何发展起来的？它们是通过改进业务流程（例如，减少完成任务的时间）、改进决策制定（通过提高决策所依据的信息质量）、消除任务（通过流程改进）、消除外部依赖性（通过将专业知识引入内部），提高制造或开发吞吐量（通过技术投资或改进）。名单还在继续。这些本质上都是可操作的——战略的战略执行。这是组织战略和执行协调一致的第一步。

制定能力路线图的步骤是：

1. 识别能力。从战略目标中推导出有助于实现目标的能力。它们应该是可衡量的，并尽可能与战略目标挂钩。当然，这假设已定义具有战略目标的战略并与您共享。
2. 对能力进行分类。这是一个可选步骤，但如果您有很多已定义的功能，它会很有帮助。能力可以按大类（制造、运营、供应链）或部门（人力资源、IT、财务、应收账款、采购等）进行分类。就个人而言，我更喜欢按部门定义能力的更精细的方法。我相信，这更具可操作性和可追溯性。但也可以将能力分组为更大的能力集。例如，生产高性能计算机的能力需要设计、组件采购和制造方面的能力。
3. 识别功能的依赖关系。能力可以在一段时间内发生变化。以医疗账单为例。最初的能力可能是为医疗账单提供适当的编码并在 90 天内移交给第三方。未来的能力可能是处理被拒绝的医疗账单付款并在 90 天内返回给第三方。最终的能力可能是以相同或更好的性能在内部进行医疗支付。或者，一些能力可能依赖于其他能力——例如，响应季节性小麦作物产量的能力可能依赖于 IT 部门内商业智能能力的发展。
4. 确定实施时间的长度。这可能是最困难的一步。它需要了解实际掌握该功能所需的努力。它需要与负责变更的团队成员交谈，并了解实施变更所涉及的步骤、依赖关系和风险。
5. 创建路线图。这是基于类别/部门、依赖关系和时间要求的可视化路线图的创建。一般来说，路线图将按照时间线组织，现在代表起点，未来代表正确。
6. 纳入反馈。一旦创建了能力路线图，就需要对其进行验证。特别是，来自技术路线图的反馈至关重要。该技术可能需要更长的时间来实施，这可能会迫使能力路线图发生变化。

Figure 1 — An example layout of a capability roadmap with dependencies.

路线图可以像您想要的那样简单或复杂——最重要的是增加价值。图 1 代表了一个典型的路线图，左侧的类别和箭头表示的功能。能力按类别分组——如上所述，这可以按业务单位、部门或其他有意义的差异化因素进行分组。战略执行中可能存在差距——而且应该存在——来代表资源限制。我喜欢将能力保留为数据点。这使您可以将它们连接到参与者和角色（所有者、执行者、受其影响、应付账款等）、系统（ERP、仓库管理系统）和业务流程（信用检查、履行）。数据是可管理和可查询的。简单地将路线图放在图表中作为一种组织思想的方式具有价值，但它会使数据锁定。

我被问到的一个问题是，路线图应该在未来多远的时间内进行规划。这是一个难题，将取决于组织及其所从事的市场。例如，航空航天等资本密集型行业可能需要比电子商务组织（大多数可能不会超过 2 到 4 年）。

归根结底，业务能力是战略执行的工具。随着时间的推移，它们变得越来越流行，因为它们填补了战略规定的内容以及如何确定如何完成的空白。应根据需要维护和调整能力及其路线图，以反映不断变化的战略，以应对不断变化的业务环境。在本路线图系列的下一篇文章中，我们将深入研究产品路线图。

本文：https://jiagoushi.pro/mapping-future-part-2-capability-roadmaps-defined

产品路线图是我们将在我的 4 部分系列中深入探讨的第二个路线图。如果您尚未阅读它们，请阅读第 1 部分：路线图概述和第 2 部分：能力路线图。顾名思义，产品路线图定义了产品或产品及其功能的预期未来推出。由于我们正在谈论技术，因此我们将假设后者进行讨论。

与我们正在讨论的其他路线图一样，产品路线图随着时间的推移展示了产品的未来。通常，企业架构不会产生产品路线图。通常，这可能是营销或产品管理的功能，或任何这些实体的组合。实际上，它将涉及所有三个方面的输入：EA、产品和营销，因为每个都为路线图提供关键信息。

产品路线图的受众不仅仅是开发人员，它用于提供有关何时创建功能的指导。它被用作一种元认知工具，用于组织产品团队的思想，以及与高管和其他内部利益相关者的沟通媒介。它也可以用于外部利益相关者，但应注意确保外部受众知道这不是合同承诺或对即将发生的事情的硬性定义。许多组织不会在产品发布之前共享产品。苹果因限制对其产品的可见性而臭名昭著，使他们受到许多谣言和猜测的影响。

产品路线图的基本输入，例如战略、当前产品和技术需求以及市场需求，都会影响路线图，应该以批判的眼光进行评估。如果在其中一个影响路线图的变化中发现了变化，则应注意并立即或在其下一次迭代中调整路线图。

您将产品路线图预测到未来多远？与所有优秀的建筑师一样，答案是视情况而定。与功能一样，如果产品具有较长的开发周期或强烈的资本需求（如 CPU），那么它会更长。对于大多数软件产品，您需要 18 到 24 个月，但这实际上取决于您的需求。投影越远，它的价值就越小。换句话说，随着时间的推移，产品路线图的不确定性更大。

Figure 1 — An example of a product roadmap created in Lucid Chart

产品路线图看起来像一个项目计划——它不是。有一些相似之处。两者都有时间线，都可能有依赖关系，并且都可能在垂直轴上有分组。但它们的不同之处在于意图。产品计划更加详细，代表要完成的任务。产品路线图旨在显示功能何时可以推出。请注意，一旦功能完成，它不会自动推出，它只是准备推出。

哦，所以如果功能正在计划中，这不违反敏捷原则吗？并不真地。开发人员不会选择用户故事。有人会这么认为，但不一定。产品路线图并非一成不变。它是根据战略和市场需求确定功能以及何时需要它们。它受到 IT 将基础架构部署到位的能力以及依赖业务合作伙伴提供交付和支持该功能所需的服务或材料的能力的影响。它为开发团队提供指导，但不是强制要求。产品路线图的输入之一是产品的当前状态。这会根据开发人员实际完成的工作向路线图提供反馈。开发人员仍然是自我管理的，但与往常一样，他们需要了解企业想要完成什么，并且路线图为他们提供决策指导。

开发产品路线图的过程并不简单，涉及大量输入和反馈循环。但总的来说是：

1. 确定组织对其产品所遵循的战略。如果您的组织尚未确定战略，请努力确保其确定。首先，它不需要完全充​​实，但它需要提供选择产品功能的基础。
2. 识别特征域。特征宇宙是可以定义的所有可能特征的集合。这并不是说一切都会好起来，也不是说一切都会实施。这可以来自许多不同的来源。市场和客户是最明显的，但它也可以来自审查竞争对手的产品、非竞争对手的产品，以及软件开发人员等内部资源，他们确定了不同数据源之间的协同作用，可用于为客户带来价值.必要时，还将对特征进行分类。类别可以由受众或角色、子系统、地理或其他定义创建。可以定义多个类别，为每个类别生成路线图或具有动态视图。
3. 将功能与策略对齐。这可能是最困难的部分，尤其是在策略没有明确定义的情况下。查看每个功能，看看它在策略中的位置。它提供价值吗？它有助于实现战略目标吗？如果没有，则丢弃该功能——这并不是说该功能不会在以后重新引入，但最初它不会推动组织向前发展。由于合规性或法规或业务合作伙伴的需要，还可能存在强制功能。这些通常具有必须交付的特定日期，因此对于维持您自己或您的业务合作伙伴的运营至关重要。
4. 确定功能的工作量。这是您确定该功能需要多长时间和多少资源的部分。这更像是一种猜测或 SWAG（Scientific Wild-A** Guess），并不意味着 100% 正确，只是一个近似值，以了解这如何适合日程安排。大型功能可能会被分解成更小的块，以便更早地推出部分功能 - 例如，报告功能最初可能会从一些预制报告开始，然后随着时间的推移引入自定义功能。后者将依赖于前者。
5. 识别依赖关系。如步骤 4 所述，当一个特征被分解成更小的特征时，特征之间可能存在依赖关系。但可能还有其他对功能的依赖——例如，提供对某些屏幕的访问或共享数据的功能可能依赖于 OAuth2 和 OpenID。提供特定矩阵视图的功能可能依赖于允许用户在应用程序中创建和编辑特定记录的功能。这些依赖关系将指定至少一些功能的开发或准备推出的顺序。
6. 布局产品路线图。这就是我们将这一切结合在一起的地方。布局和安排优先功能，了解每个功能所需的工作量以及开发功能的时间长度。根据功能的可用性，必须做出一些努力来了解如何设置功能的时间线。一个特性可以被挤压或拉伸到某个点，但这种弹性不一定是线性的（即，在一个特性上投入更多资源并不能保证它会在更短的时间内完成）。依赖映射将确保依赖链中较早的功能首先完成。
7. 冲洗，起泡，重复（Rinse, lather, repeat. ）。好吧，实际上这是一个不断更新或按计划更新或两者兼而有之的问题。产品路线图应该至少每季度更新一次，但在这个瞬息万变的世界中，也许每月一次更合适。每季度进行一次实时调整是一种很好的中间方法。在这种情况下，季度审查将包括更全面的审查，实时调整的范围将受到限制。实时调整将反映来自生产团队、IT 或其他内部服务提供商的反馈循环，以及市场或战略的重大变化。例如，如果您有一个卖方房地产应用程序并且市场转向买方提供更多机会的地方，那么所有这些卖方功能可能会被搁置。制作团队的反馈可能会调整时间表。如果开发人员无法准备好 UI，这将推动功能和任何依赖项的路线图时间表。同样，如果 IT 组织在实施第三方 SaaS 集成时遇到问题，这也可能会延迟某个功能和相关性。如上所述，规划和更新路线图的时间范围取决于您企业的情况。

上面的图 1 提供了使用 LucidChart 开发和修改的产品路线图的表示。 Lucid 的模板有颜色代码作为开发的进展情况（完成、等待、迟到）。我发现这在敏捷世界中相当无用，在这个世界中，迟到并不是什么大事，除了在 sprint 方面——它对于看板来说更不重要。另外，为什么要更新图表以表明它已经晚了，而新的修订版本更好地代表了调整后的计划？我更喜欢用它来定义重要性，因为这为开发团队提供了更大的沟通价值。颜色编码还可用于指示其他关键要素，例如成本、产品领域、领域或团队。

产品路线图既是一份活的文件，也是一份未来计划的快照。因此，出于历史目的，应定期存档。有许多专门用于路线图和产品路线图的工具。质量更好的工具将是数据驱动的，并将更新路线图以反映变化。并非所有更改都可以由数据驱动，很有可能。开发团队的输出等数据可能保存在未集成的不同系统中。战略和市场细节通常也不能用于集成。

总之，产品路线图是一个看似简单的过程，但实际上相当复杂。它涉及许多不同的组织利益相关者，是一个平衡多个关注点的过程。然而，它是推出产品的重要组成部分，有助于调整战略和执行。请继续关注我关于路线图的最后一篇文章——技术路线图——大约一周后会发布。

本文：https://jiagoushi.pro/mapping-future-part-3-product-roadmap

记得回到 90 年代（男孩，我现在正在和自己约会）。口号是 IT 需要与业务保持一致。如今，技术变得如此重要，以至于业务需要与技术保持一致，看起来。在 IT 和业务方面，我从未真正看到过“我们与他们”的现实。但无论你怎么看，它们都需要对齐。这就是路线图的用武之地。

路线图是定义未来方向的过程。您可能听说过产品路线图或技术路线图。也许您甚至听说过能力路线图。但是您如何创建这些路线图，每个路线图做什么以及它们如何协同工作？这就是我们今天要讨论的内容。

在随后的文章中，我将详细讨论不同类型路线图的创建以及它们是如何形成的。正如我所提到的，路线图分为三种类型：

1. 技术路线图。这些在当今的 IT 世界中并不少见。它们在 IT 组织中用于安排在时间范围内提供某些技术所需的工作量。他们通常会提前 24 个月查看并确定技术何时开发、实施和推出。它们用于提供高级别的行军命令、制定预算并为培训和招聘目的确定技能组合需求。通常，它们被开发出来，然后被推入平局或存档在服务器上。
2. 产品路线图。这些在提供软件产品和服务的公司中最为常见，但它们不必仅归入该领域。产品路线图定义了将来可供现有和潜在客户使用的产品和功能。对于商品项目，产品路线图不太重要，可能会延伸到未来。对于短命的产品，例如变化更快的软件，产品路线图很可能在更短的时间内完成。
3. 能力路线图。能力路线图不太常见，但对于战略执行至关重要。它们定义了企业在某些时候需要具备执行战略的能力。什么是能力？它们是在定义的水平上执行的能力。例如，识别具有特定投资回报率的零售店位置的能力或在特定时间范围内完成订单的能力。这些能力会随着时间而变化，应该制定路线图以了解公司的运营需求。

现在我们知道路线图的类型是什么，我们将深入研究谁负责创建它们、它们之间的相互依赖关系、它们具有的外部依赖关系以及它们的使用方式。

路线图通常（但不总是）是企业架构 (EA) 的领域。这来自 EA 在创建技术路线图方面拥有最长的经验。产品管理可能对产品路线图负责，或者他们可能使用架构服务来协助或执行大部分工作。能力本质上更具战略性，可以由首席执行官或 CSO（首席战略官）等 CxO 执行，无论是否有企业架构组的帮助。

我相信企业架构应该参与所有的路线图。这是因为路线图是相互依赖的。至少，EA 将提供反馈，尤其是以会影响能力和产品路线图的调度和预算现实的形式。这种反馈是必不可少的，并证明了 IT 在战略执行中的重要性。能力和产品路线图都依赖于技术路线图。如果预算不能满足实施该技术的需求，或者实施该技术的时间表不切实际，则需要对能力和产品路线图进行更改。

Figure 1 — Interdependencies and dependencies of roadmaps

每个路线图都取决于其先前的迭代。也就是说，路线图应该是活生生的实体，它们是必要的更新，以反映业务和技术环境的不断变化。这并不意味着它们应该每天进行调整，而是按照反映组织需求的时间表进行调整。与在更加稳定的市场中运营的企业相比，处于更加活跃的市场中的企业应该更频繁地调整路线图。之前的路线图代表了愿望。它是根据实际情况调整的。你没有达到能力目标吗？调整它和所有相关的能力以反映现实。是否更改了战略，删除了不相关的功能，添加新功能并修改其他功能以反映新的战略方向。

所有路线图的核心是企业战略。战略是创建所有路线图的镜头，有助于做出创建路线图的决策。战略本身取决于许多其他因素。这包括当前的组织状态，包括当前市场、当前财务状况、当前能力和收购。外部因素也在战略制定中发挥作用，例如 COVID 19 等世界事件、战争、市场状况和技术进步。

另外两个外部依赖项是产品路线图的市场和技术路线图的当前架构状态。市场变化也会影响战略，但在宏观范围内。对于产品路线图，我们正在根据竞争对手的新产品以及我们客户对新功能或产品的需求来研究直接影响产品路线图的变化。这些可能不会改变基本战略，但仍可能需要迅速解决，以确保企业的声誉和市场份额。

当前的架构状态非常重要，并证明了企业架构的重要性。 EA 通常将其保存在存储库（企业架构存储库或 EAR）中。架构的当前状态受到许多因素的影响，包括内部和外部。对于依赖内部软件或硬件开发的组织而言，其中最关键的一项就是架构。糟糕的架构会导致产品死板，不能成为增长的平台。它们可能无法满足不断增长的性能需求，可能无法提高规模效率，或者可能不容易修改以支持新功能。

对当前状态的外部影响包括供应商产品的变化。也许一个供应商与另一个供应商合并或倒闭，改变他们的产品战略或将他们的许可费用提高到一个令人不快的水平。也许出现了一种新产品，以更低的价格带来了额外的好处。这两种情况都可能导致 IT 环境的当前状态发生变化。巨大的辞职也带来了重大变化，人员配备的不确定性（以及由此产生的时间表的不确定性）以及对远程工作和在不同地点工作的人才的需求和期望的变化。有时，新的概念和技术会颠覆计划。大规模的破坏者，例如迁移到云、微服务架构和 NoSQL 数据库，可以影响内部架构，开辟新的可能性和能力。

最后，我想指出，能力也可以在其他层次上使用。 正如我在上面列出的那样，它们是在企业级别定义的。 对于大型企业，也可以根据组织结构在部门级别进行定义。 在部门层面也是如此，以帮助确定在哪里投资以提高部门的能力。 例如，IT 部门可以将其提供商业智能服务、云解决方案、可扩展性或快速生产功能的能力视为能力，并根据技术路线图加强其在必要领域的执行能力。

本文：https://jiagoushi.pro/mapping-future-using-capability-product-and-techn…

许多企业声称，开放组架构框架 (TOGAF) 是一种瀑布模型，无法满足他们对现代企业架构的期望。相反，他们采用规模化敏捷框架 (SAFe) 方法来设计他们的企业。¹

需要注意的是，企业架构的三大支柱是：一致性、洞察力和质量。

• 一致性：企业架构 (EA) 将战略与运营、业务需求与 IT 供应保持一致，并确保变更符合企业战略和目标。
• 洞察力：EA 提供对组织、信息系统和技术的当前和期望状态的洞察力。
• 质量：EA 有助于提高单个解决方案的质量并简化其开发和维护。

作为背景，每一个都用于解决企业今天面临的最大挑战，例如：

• 变得敏捷
• 全球化和数字化
• 系统复杂性增加
• 产品型开发
• 市场竞争

采用 EA 的陷阱

根据作者最近作为企业架构师的经验，以下内容通常与企业架构的采用有关：

• 组织专注于 EA 的技术方面，因为大多数 EA 计划都是由 CIO 或 IT 主管推动的。
• 企业架构团队花费更多时间选择 EA 框架和 EA 工具，而不是定制和使用它来开发企业架构。
• 企业架构师经常被拖入运营活动或日常项目工作中。这意味着虽然他们看起来很有生产力，但实际上他们在解决企业层面的组织问题方面几乎没有做任何事情。

然而，跨行业对企业架构师的看法正在发生变化。为了赢得组织的尊重，企业架构师应该在编码的同时参与制定战略和端到端的实施。今天的企业架构师现在需要与定义企业的业务战略密切合作。此外，企业架构师监督如何以实施的形式实现业务战略。

基于以上问题，定义企业架构需要敏捷最佳实践。以下部分展示了敏捷方法与企业架构之间的联系。还详细解释了企业架构师在敏捷开发中的作用。

敏捷企业架构

敏捷是一种用于软件开发和项目管理的方法。在敏捷方法中，单个项目被分解成更小、更易于管理的部分，以加快设计过程并尽快生产出高质量的产品。

敏捷 EA 框架

使用敏捷，企业架构师的重点是：

• 通过早期和持续交付有价值的软件使客户满意；
• 接受需求（无论处于开发阶段）；
• 交付频繁工作的软件，从几周到几个月不等（越短越好……）；
• 在整个项目中与业务部门和软件开发人员保持持续的日常协作；
• 制定向开发团队和在开发团队内部传达信息的有效方法（通常通过面对面的会议）；
• 衡量工作软件的持续开发进度；和
• 持续关注卓越的技术和良好的设计。

下面描述的敏捷 EA 框架 (AEAF) 的安排是为了打破 IT 和业务之间的障碍，从而通过单位和通过为新项目联合的快速形成的团队来提高协同定位的水平。它的功能是根据实时客户反馈发展和迭代改进最小可行产品 (MVP)。 AEAF 同样通过实施必要的架构来支持云、DevOps、微服务、数据分析、测试自动化和 API 来帮助企业数字化。

AEAF 通过使用迭代生命周期来定义架构，以允许架构设计随着各种问题和约束变得更加清晰而逐渐演变。体系结构和系统的逐步构建必须齐头并进，其后续迭代必须解决或实施任何和所有问题和决策，以促进真正灵活的体系结构。

AEAF 以下列方式涵盖每个活动、目的和相关架构关系的详细信息：

(a) 敏捷 EA 规划

此步骤涵盖架构愿景和所有前期架构规划。在这个阶段，目标是解决核心业务问题和利益相关者的担忧。

架构愿景期间的努力提供了进行进一步目标架构开发所需的文档。它涵盖了问题的整个范围，同时也解决了利益相关者的担忧、优先事项和偏好。

架构待办事项涵盖了产品的价值、复杂性、依赖性和紧迫性。

(b) 敏捷架构定义

此步骤涵盖了与业务、应用程序、数据和技术相关的领域架构的定义。它建立了一组利益相关者批准的域架构，其中包含一致同意的差距列表以及清除它们的相应方法。它还解决了使企业能够满足利益相关者偏好的变化。作为敏捷架构定义的一部分，迭代计划将通过每日“站立”会议和“燃尽/燃尽”图表进行。

在此规划期间，每日站立会议和自组织团队共同开发架构。

(c) 敏捷 EA 分类法

敏捷 EA 分类涵盖了要在整个企业中采用的敏捷架构原则和敏捷价值观等工件。它还涵盖了最佳实践、指南和清单，以帮助那些遵守敏捷架构领域工件的人。

Sprint 交付工作产品的有用部分。 EA backlog 的核心是适当限制的 EA Landscape。

工作软件清楚地表达了预期的结果，而无需详细讨论如何开发和执行某些东西。它将工作限制在相对较短的时间间隔内，以最大限度地减少正在进行的工作量。此外，它还标识了所有的前任和后继包。工作产品可​​以追溯到一个目标，因此如果它的交付延迟（或失败），企业将面临改变目标架构的后果。

(d) 执行

敏捷团队不是采用大爆炸式的方法来决定整个程序的架构需求，而是采用增量方法来确保设计可扩展并与愿景保持一致，同时详细说明和满足企业需求。为了最有效，它有助于架构团队继续着眼于更大的图景，而团队则专注于他们基于冲刺的可交付成果。所有决策都应该一起做出以确保适当的平衡——无论是从商业价值的角度对项目阶段的协议、接受新的技术债务，还是特定框架或组件的设计细节。

作为敏捷架构实施的企业架构师，应重点关注：

• 有意架构（架构即协作）；
• 构建可能可行的最简单架构（既定设计原则）；
• 对其进行编码或建模（尖峰、原型、域和用例模型）；
• 构建它，测试它（为可测试性而设计）；和
• 实施架构流程（架构史诗和投资组合看板）。

(e) 敏捷 EA 组织

EA 实践需要相应的敏捷环境才能蓬勃发展。架构团队必须由企业架构师和解决方案架构师组成，业务架构团队必须将企业架构师与业务专家相匹配。 EA 团队需要每天与敏捷团队密切合作，以确保成功执行愿景，同时整合团队和客户的挑战和反馈。

• 敏捷首席架构师：敏捷首席架构师在整个企业中推广敏捷方法。这个职位的作用各不相同，就像仆人、领导者和促进者一样，可以顺利执行并消除可能的障碍。敏捷首席架构师是组织企业架构计划的最佳产品所有者。作为产品所有者，ALA 确定组织所需的架构。 ALA 拥有 EA 开发冲刺中使用的验收标准。
• 企业架构师：企业架构师是敏捷团队的组成部分，有助于开发、改进和维持企业架构。敏捷架构师是开发团队的活跃成员。他们在适当的地方开发软件，并担任团队的架构顾问。
• 敏捷团队：服务很小，由小团队开发。敏捷使得以小块频繁发布成为可能，从而显示业务进展。遵循 CI/CD 以提高弹性水平。

使用 LeanIX 实施 TOGAF 的敏捷框架 [海报]：逐步说明如何使用精益 EA 工具遵循 TOGAF 原则。 »

(f) EA 存储库

EA 存储库有助于存储敏捷架构和开发工件。

(g) 敏捷 EA 治理模型

敏捷 EA 治理就是在整个组织内创造价值，而不仅仅是在单个项目中。敏捷治理在高层管理人员和正在完成项目的团队之间架起了一座桥梁。

已建立的敏捷 EA 治理模型支持：

• 敏捷团队的自主决策；
• 跨学科敏捷团队处理复杂主题的能力；
• 减少企业架构的管理开销；和
• 企业架构的范围和影响。

概括

不要将所有这些都视为 EA 与敏捷。

敏捷 EA 框架对于任何企业转型都起着重要作用。这种转变有四个维度：功能性；技术的;操作;和业务。在这四个维度中的每一个维度中，EA 和敏捷都支持对方的目标。

在敏捷中，架构师需要始终与团队保持投资。重要的是他们要有远见，同时管理变化和复杂性。敏捷架构师必须参与项目所有功能规范的定义，同时与业务团队共同审查功能规范以了解期望并确保所写的内容是预期的。

不断与利益相关者和团队核对，以确保他们没有偏离既定的设计。架构师必须在很多时候保护团队免受不必要的官僚主义的影响。

产品负责人、敏捷架构师和团队应共同决定 sprint 的范围。架构师应仅在范围界定期间出现问题（或在最后一刻引入更改时）进行干预。

向业务部门演示冲刺输出以获取客户反馈，适应所有必要的更改，并确保团队由经验丰富的工程师和新晋工程师组成。最后，虽然敏捷并未明确推荐文档，但它确实有助于创建尽可能多的文档，以简化未来支持团队的生活。

原文：https://www.leanix.net/en/blog/agile-and-enterprise-architecture-a-stra…

本文：https://jiagoushi.pro/node/1892