目录
6、模型种类（Model Kind）与架构模型（Model）
第一章 概述
理解架构开发方法（ADM）以及各个阶段的目的和目标，包括如何对ADM进行调整并确定其范围以便实际应用。
主题包括以下：
1、ADM及其各个阶段
2、可交付物的草拟状态和获批准状态
3、ADM的迭代方法
4、对企业架构实施治理的需要
5、如何确定架构范围
6、架构备选项和权衡
7、ADM各阶段的目的和目标
8、如何应用架构以支持敏捷软件开发
第二章 ADM概览
ADM是一个用于开发架构，经测试的并可重复的流程。
所有这些活动均在一个连续的架构定义与实现的迭代周期内实施，使组织能够以受控的方式实施企业转型，以响应业务目标和机遇。
一、预备阶段
描述创建架构能力所需的准备和启动活动，包括按需定制TOGAF框架并定义架构原则。
二、阶段A：架构愿景
描述架构开发周期的初始阶段。
该阶段包括确定架构开发举措的范围、识别利益相关者、创建架构愿景，并获得继续推进架构开发的批准。
三、阶段B：业务架构
开发业务架构，以支持得到认同的架构愿景。
四、阶段C：信息系统架构
开发信息系统架构，以支持得到认同的架构愿景。
五、阶段D：技术架构
开发技术架构，以支持得到认同的架构愿景。
六、阶段E：机会和解决方案
进行初始实施规划，并识别此前阶段确定的架构之交付载体。
七、阶段F：迁移规划
最终确定一个详细的实施和迁移计划，以解决“如何实现从基线架构向目标架构的转移”。
八、阶段G：实施治理
在架构层面监督实施。
九、阶段H：架构变更管理
一系列步骤，用于管理向新架构的变更。
十、需求管理
运行贯穿整个ADM的架构需求管理过程。
第三章 ADM阶段
ADM周期的各个阶段进一步划分步骤，这些步骤的定义在各阶段的详细描述中给出。
需求管理阶段是一个持续的过程，确保通过适当的治理流程处理任何需求变更，并且将这些变更反应在其他各个阶段。
一、“草拟”和“获批准”可交付物
在 ADM 中，处于开发中，尚未经过正式审核和批准流程的文档称为“草拟”。
在 ADM 中，根据组织治理实践，经过审核和批准的文档称为“获批准”。获批准并不一定意味着最终定稿。
二、迭代和ADM
ADM在整个过程中，各阶段之间和各阶段内均可迭代。
ADM的每次迭代必须更具以下因素重新决策：
1、待确定的企业涵盖范围
2、待确定的详细程度
3、目标时间区间范围，包括任何中间时间区间的数量和范围
4、待利用的架构资产
三、企业架构创建、开发、维护、治理
与其他架构制品一样，ADM也是需要管理的关键流程之一。应当在架构开发迭代的各阶段正确运用该方法，以达到架构委员会满意。
与ADM的符合性对架构治理具有基础性意义，从而确保未遗漏任何应当考虑的事项，并且产出全部所需的可交付物。
从业者应当在受控范围内开发架构。
在该受控范围内，从业者应当遵从利益相关者的偏好。
治理测试将考察利益相关者的关注点是否得到从业者的回应。
四、如何划定架构范围
通常，架构范围首先通过广度、深度和时间来表达。一旦形成对这些维度的理解，便可以选择与要应对的问题相适合的架构域组合。
时间区间：需要为架构愿景指明怎样的时间区间？在详细的架构描述中涵盖同样的时间区间是否合理？
架构域：完整的企业架构描述应当包括全部四个架构域（业务、数据、应用、技术）。
广度：企业的完整范围是什么？这个架构工作涉及到的范围是哪个部分？
深度：架构工作应当深入到怎样的详细程度，能力级别是最深的，分段级别中等，战略级别浅。
五、备选架构、关注点和权衡
为什么要考虑架构备选项？
答：一种常见的情况是：存在一个以上的符合架构愿景、架构原则和需求的目标架构。通过识别和考虑备选目标架构，可以理解备选项之间的各种可能性一级识别出的权衡。向利益相关者展示不同的备选项和权衡有助于架构师挖掘可能对最终目标架构产生影响的隐含动机、原则和需求。
如何备选架构，方法：
六、预备阶段
预备阶段的目的是开发企业架构能力（或是实践能力）。
作为按需定制的TOGAF ADM旅程来设计。
需要使用 架构能力成熟度模型。
主要是要有两个能力：
1、确定组织期望的架构能力
审视开展企业架构工作的组织背景环境。
识别并确定架构能力所影响的企业组织要素的范围。
识别与架构能力相交叉的已有框架、方法和流程。
确立能力成熟度目标。
2、建立架构能力
定义并建立企业架构组织模型。
定义并确立用于架构治理的详细流程和资源。
选择并应用支持架构能力的工具。
确定架构原则。
七、目标：阶段A
架构愿景：识别关键利益相关者，并就目标概述和实现目标所需的工作达成一致，记录架构愿景文档中。
架构愿景一定是 高阶的、概念的、可见性的。
常见的产出物是 价值链图和解决方案概念图。
1、起始设置关键内容
确定架构项目的范围；
识别利益相关者、关注点和相关需求；
评估企业架构团队的能力；
2、完成关键内容包括
关键利益相关者就目标概述和实现目标所需的工作达成一致；
3、输出和结果
充分的文档记录，以获得继续推进的批准；
获准继续腿精开发目标架构，以证实所概述的目标；
4、关键知识
问题范围得的确认；
利益与问题具有根本性联系的群里得到确认（利益相关者和关注点）；
对于利益相关者，对问题给出怎样的概括性答案是可接受的？
利益相关者的优先事项和偏好；
概括性答案能提供什么价值？
5、目标
形成将由提议的企业架构交付的能力和业务价值的高层期望愿景；
架构工作申明获得批准，该申明确定了开发和部署架构愿景中概述的架构所需的工作项目群。
八、目标：阶段B
开发目标业务架构，该架构描述企业需要如何运行，从而以符合架构工作申明和利益相关者关注点的方式达成业务目标，并响应架构愿景中设定的战略驱动因素。
根据基线和目标业务架构之间的差距，识别备选架构路线图的组成部分。
基线架构和目标业务架构之间差距较大，中间点可以有过渡架构或者迁移中架构。
九、目标：阶段C
信息系统架构即“数据架构”和“应用架构”。
开发目标信息系统架构，描述企业信息系统架构如何以符合架构工作声明和利益相关者关注点的方式实现业务架构及架构愿景。
根据基线和目标信息（数据和应用）架构之间的差距识别备选架构路线图的组成部分。
1、数据架构
以符合架构工作申明和利益相关者关注点的方式、开发使业务架构和架构愿景得以实现的目标数据架构。
根据基线和目标数据架构之间的差距识别备选架构路线图的组成部分。
2、应用架构
以符合架构工作声明和利益相关者关注点的方式，开发使业务架构和架构愿景得以实现的目标应用架构。
根据基线和目标应用架构之间的差距识别备选架构路线图的组成部分。
需要有一个 应用之间的组合关系图。
十、目标：阶段D
技术架构以符合架构申明和利益相关者关注点的而方式，开发通过技术组件和技术服务交付架构愿景、目标业务、数据和应用构建块的目标技术架构。
根据基线和目标技术架构之间的差距识别备选架构路线路的组成部分。
主要有两个层级的思考，一个整体技术的配合组合图，一个是单一技术组件内部的技术架构图。单一技术突破例如网络架构、微服务架构等等，可以很深。
十一、目标：阶段E
基于阶段 B C D，的差距分析和备选架构路线图的组成部分，生成架构路线图初始的完整版本。
确定是否需要增量方法，如需要，则识别将交付连续业务价值的过度架构。
定义整体解决方案构建块（SBB）吗，从而基于架构构建块（ABB）最终确定目标架构。
1、输出和结果
一组针对差距的工作包，并且指示所产出的价值和所需的工作量，以及为实现调整后的目标，各工作包之间的依赖关系。
2、关键知识
变更之间的依赖关系（工作包和差距依赖关系）与各项变更和工作包相关的价值、工作量和风险。
利益相关者的优先事项和偏好如何根据变更的价值、工作量和风险做出调整。
十二、目标：阶段F
实施和迁移计划，最终确定架构路线图和作为支持的实施和迁移计划。
确保实施和迁移计划与企业在其整体变更项目组合中管理和实施变更的途径相协调。
确保关键利益相关者理解工作包和过渡架构的业务价值和成本。
1、输出和结果物
获得批准的一组项目，包含目标和必要的约束、所需的资源、开始和结束时间。
2、关键知识
实施变更的可用资源。
利益相关者的优先事项和偏好如何根据变更的价值、工作量和风险作出调整。其中也包含对利益相关方的需求的考量。
十三、目标：阶段G
实施治理：通过实施项目确保与目标架构的一致性。
为解决方案以及任何由实施驱动的架构变更请求执行适当的架构治理能力。
1、输出和结果物
达到调整后的目标状态所需的变更项目完成实施。
2、关键知识
实施团队的目标和约束（差距、架构需求规范、控制）。
利益相关者的优先事项和偏好如何根据变更的成功、价值、工作量和风险作出调整（利益相关者需求）。
十四、目标：阶段H
架构变更管理：确保架构生命周期得以维持、确保架构治理框架得以执行、确保企业架构能力满足目前需求。
1、输出和结果物
继续推进的指令，开始着手开发一个目标架构，以弥补企业与利益相关者偏好之间的预知、实际或预期差异。
2、关键知识
获得批准的目标或偏好与此前工作实现结果之间的差距（价值实现）。
偏好或优先事项的变更（利益相关者需求）。
十五、需求管理
确保需求管理流程在ADM所有相关阶段持续运行。
对在ADM周期或其中一个阶段实施过程中识别出的架构需求进行管理。
确保在任一阶段实施过程中，相关架构需求处于可用状态。
1、架构开发的中心
在TOGAF框架中，需求管理和利益相关者参与居于架构开发的中心位置。
利益相关者是架构以及期望通过架构实现的价值偏好和优先事项的所有者。
有效的需求管理取决于从组织愿景、使命、业务、商业模式和战略直到最详细的需求声明的清晰可追溯性。
十六、信息流
TOGAF ADM 是一个逻辑方法，通过将关键活动步骤组合在一起来理解活动关系并明确信息流。
十七、支持敏捷软件开发
架构可用于识别企业所需的产品、产品边界和产品负责人受到的约束。
架构也可用于为限制敏捷团队的选择而确立约束条件。
在阶段G（实施治理），从业者通过维护使命、愿景、目标和投资路线图，服务于利益相关方。
第四章 ADM技术简介
一、单元目标
介绍可用于支持ADM应用的技术。主题包含：
1、ADM与指导原则和技术支持之间的关系
2、架构原则
3、业务场景
4、差距分析
5、互操作性
6、业务转型就绪度评估
7、架构风险管理
二、ADM与指导原则和技术支持之间的关系
图中展示的是 TOGAF 框架的核心结构，特别强调了 ADM (Architecture Development Method) 以及它与其他要素的关系。
ADM (架构开发方法)：是 TOGAF 框架的核心，它定义了一个迭代的、分阶段的架构开发过程，帮助组织逐步实现架构目标。它包括需求管理、架构视角的定义、架构评估与设计等。
指导原则：TOGAF 的指导原则在整个架构开发过程中起到了引导作用。它们为架构设计和实施提供了方向，确保所有设计决策都符合组织的长期战略目标。指导原则与 ADM 的步骤紧密结合，确保架构开发过程中的每个阶段都符合这些原则。
技术支持：技术支持部分主要涉及在架构开发过程中所采用的工具和技术。这包括在架构设计时的技术标准、方法学、工具支持等。技术支持为 ADM 的执行提供必要的基础设施和技术框架。
关系：ADM 和指导原则的关系是ADM 的每一个阶段都要遵循指导原则，以确保开发出来的架构能够最大程度地与组织的战略目标一致；ADM 和技术支持的关系是ADM 的实施往往依赖于技术支持，例如建模工具、数据分析工具等。技术支持有助于提升 ADM 各个阶段的效率和有效性，确保架构的可执行性和实现性。
三、架构原则
1、架构原则目的
架构原则应当致力于实现以下目的（可能的考点）：
1) 推动决策
在权衡讨论时设立优先权以及在必要时“打破平局”的权利，这个做法十分重要。
2) 实现企业的对齐
原则将主观性和偏见摒弃在外，并驱动客观且符合企业价值观的关键对话。
3) 确保治理
企业如何确保在恰当的时机由合适的决策者作出正确的决策？此外。如何对决策和执行决策的途径进行监控？
4) 理解价值观和文化
有助于更透彻地理解企业文化和价值观；为判断企业是否娴熟应对变化提供路径和洞察。
2、现有架构原则
如果已有来自此前EA能力相关工作的架构原则，则这些原则可提供此前工作背景，用于构建企业架构能力。
这些原则提供以下信息：如何看待企业架构能力，企业架构能力的自我认知，及其明示或暗含的目的。
3、开发架构原则
通常由企业架构师与以下关键利益相关者协同开发：企业CIO、架构委员会、业务利益相关者；并由架构委员会批准。
企业级原则（如有）为架构原则提供信息。
架构原则必须具备清晰的可追溯性并且清楚的表达以指导决策。
4、企业原则模板
四、高质量的架构原则标准
五项特征如下：
1、可理解性
整个组织内的人员均能迅速领会和理解隐含的宗旨。原则的目的明确无歧义，从而尽可能减少有意或无意违背原则的情况。
2、健壮（鲁棒性）
有助于作出关于架构的高质量决策和计划，并确立可执行的方针和标准。每项原则均应当具备足够的确定性和精确性，以支持在复杂且可能存在争议的情景下做出连贯一致的决定。
3、完整
每项具有潜在重要性，用于治理组织的信息和技术管理的原则都得到确定——原则覆盖意识到的每种情景。
4、连续一贯
严格遵守一项原则可能需要在阐释另一项原则时流于宽泛。
表述一系列原则时，必须确保对各项原则阐释的平衡。
原则之间不应该冲突而导致遵循一项原则必须违反另一项原则的精神。
原则陈述必须措辞严谨，使其阐述连贯一致但具备灵活性。
5、稳定
原则应当长期持续但能够适应变化。
应当建立一个修订流程，用于原则在最初的批准之后的补充、删减或更改。
五、业务场景
这一方法用于帮助识别和理解架构必须设法满足的业务需求。是重大业务需求或问题的呈现，使供应商理解一个解决方案对于客户的价值。
业务场景描述：
1、真实的业务问题
不仅仅是问题的陈述，更是对现状“痛点”或未来“机遇”的精准描绘，需要清晰地阐述问题带来的负面影响或错失的潜在价值。
2、这些问题发生的业务及技术环境
提供问题发生的完整背景，帮助理解约束条件和可用资源，是构建现实可行解决方案的基础。可以从业务环境和技术环境入手分析。
3、由能力实现的价值流
这一点要求将视角从内部流程转向外部客户价值。价值流 (Value Stream) 描述了从客户提出需求到最终价值交付的端到端过程，而业务能力 (Business Capability) 则是支撑价值流每个阶段所必须具备的“做什么”的本领。
4、正确执行的期望结果（一个或者多个）
这一点是将业务需求转化为可衡量、可验证的目标，为解决方案的设计和最终验收提供了明确的标尺。采用 SMART原则 或类似框架来定义期望结果，确保其清晰、具体、可量化。
5、提供能力的人员和计算机组件（施动者）
这一点用于识别与系统进行交互的所有实体，包括人类用户和其它系统，他们是实现业务场景和价值流的执行者。
六、差距分析的目的
差距分析的目的是以文档形式记录基线架构和目标架构的差距。
识别架构中添加、删除、更改的组件（构建块）。
七、互操作性
1、定义
共享信息和服务的能力
2、类别
运行或业务互操作性：定义如何共享业务流程；
信息互操作性：定义如何共享信息；
技术互操作性：定义技术服务如何共享或者至少彼此关联；
3、A-B阶段中运用互操作性
架构愿景：运用业务场景方法发掘信息和业务交换的性质和安全考量。
业务架构：进一步以业务术语定义信息和服务交换。
4、D-E-F阶段中运用互操作性
技术架构：明确规定允许信息和服务共享的适当技术机制。
机会和解决方案：选择实际解决方案，例如商用现货（COTS）套件；
迁移规划：从逻辑上实施互操作性；
八、业务转型就绪度评估
1、评估
企业架构通常设计较大规模的变革。
变革涵盖诸多方面，但最重要的是人的因素。
理解组织接纳变革的就绪程度，识别问题并在实施和迁移计划阶段解决问题，是阶段E和F中成功实现架构转型的关键。
需要公司（特别是人力资源）人员、业务线和IT规划人员协力合作。
2、开展活动
确定将对组织产生影响的就绪度因素；
使用成熟度模型呈现就绪度因素；
评估就绪度因素，包括确定就绪度因素的排名顺序；
评估每个就绪度因素对应的风险，并识别减缓风险所需采取的改善行动；
将这些行动整合到阶段E和F的实施和迁移计划中；
九、风险管理与ADM
1、定义
根据ISO 31000的定义，风险管理“是指针对风险指挥和控制组织的协调活动”。
描述为在实施架构项目时减缓风险的技术。
2、ADM中的风险管理
在阶段A中识别风险是业务转型就绪度初步评估的一部分。风险识别与减缓评估工作单作为治理制品得到维护，并在阶段G（实施治理）中更新，同时风险管理也在这一阶段实施。
实施治理能够识别未经减缓的重大风险，这可能需要启动另外一个完整或部分ADM周期。
第五章 ADM应用
一、单元目标
介绍用于支持ADM应用的指导建议，包括迭代、分区、敏捷交付和数字化企业中的应用。
包括：
从何处获取指导建议；
如何通过ADM内的迭代实现共时运行；
架构景观；
构建架构目的；
如何应用TOGAF标准支持数字化企业；
二、如何应用TOGAF标准
三、迭代与ADM
1、迭代周期
2、ADM周期内迭代
一个项目可能有多个共时开展的ADM阶段。
项目可能按照跨多个阶段的计划周期，在ADM阶段之间循环。
项目可能以新增信息更新工作产品。
3、用于开发综合架构景观的迭代
项目自阶段A开始，在整个ADM周期内开展。
ADM的每个周期都受到架构工作需求的约束。
架构输出将填充架构景观，或是扩展所描述的景观，或是在必要时变更景观。
彼此独立的项目各自的ADM周期可能共时运行，不同的项目之间随之产生联系。
一个项目可能出发另一个项目。
四、架构景观的层级
1、架构景观
定义：企业在特定时间点使用或计划中的资产架构呈现。
2、架构层级
战略架构：为运行和变革活动提供组织框架，并且允许在管理层上确定方向。
切分架构：为运行和变革活动提供组织框架，并且允许在项目群或谱系层上去确定方向并开发有效的架构路线图。
能力架构：为变革活动和实现能力增量的有效架构路线图开发提供组织框架。
五、为简化企业架构开发而切分
1、定义
为便于开发和管理而分割架构所得出的架构子集。
2、切分
切分用于简化企业架构的开发和管理；
切分位于架构治理的基础；
切分不同层级和架构连续序列的组织概念；
3、架构切分原因
组织单元架构彼此冲突；
不同的团队需要同时就架构的不同要素开展工作，通过切分可以使得特定的架构师和团队得以专门负责并开发架构的特定元素；
有效的架构复用需要模块化的架构切分，能够获取并整合到范围更广的架构和解决方案中；
六、以目的为基础的架构项目
1、架构支持战略
企业架构的交付用于提供端到端的目标架构，以及创建时间跨度为三年到十年的变革路线图。
以此为目标的企业架构通常跨多个变革项目或者谱系。在这一背景环境下，架构用于识别变革举措并支持谱系和项目群，确立参考条件，识别协同关系并通过谱系和项目群治理战略的实施。
2、架构支持谱系
企业架构的交付用于支持跨职能部门、涵盖多阶段和多项目的变革举措。
以此目的的企业架构通常只涵盖一个谱系，在这一背景下，架构用于识别项目并确立参考条件，对齐方法途径，识别协同关系并治理项目的实施。
3、架构支持项目
企业架构的交付用于支持企业的项目交付方法。
以此为目的的架构通常只涵盖一个项目，在这一背景下，架构用于明确项目的目的和价值，识别应对协同关系和未来依赖关系的需求，确保符合架构治理要求并支持项目间的集成和对齐。
4、架构支持解决方案交付
企业项目的交付用于支持解决方案部署。
以此为目的的架构通常是一个项目或者项目中重要的一环，在这一背景环境下，架构用于确定如何设计并交付变革，识别设计需要遵守的约束、控制和架构需求，以及最终作为变革的治理框架。
七、应用TOGAF标准支持数字化企业
1、数字化企业
公司想数字化企业演进的必要性与若干驱动因素相关，其中之一便是技术的迅速变革催生了新的工作，社交和娱乐方式。
企业架构支持敏捷环境并为其赋能，提供多个领域的洞察，使之更快捷，更便利的交付和改善数字化产品和服务。
2、支持敏捷环境并为其赋能
以连贯一致和相互链接的方式对sprint导致的技术负债进行响应管理。
积极主动管理技术负债并通过以下方式对敏捷开发做出预判：
1）识别支持缩短敏捷开发周期的标准及可复用标准组件
2）适当的治理或护栏，以监督组件的复用
通过以下方式管理成熟的数字化产品并实现运营卓越：
1）简化数字化生态系统的复杂性
2）构建在数字化产品和服务管理中驱动运营卓越的企业架构能力
第六章 架构治理
一、单元目标
理解架构治理在架构开发中起到的作用。主题包括：
1）架构治理的概念
2）架构治理为何有益
3）架构委员会的角色和职责
4）架构契约
5）架构合规性
二、治理的概念
1、定义
ISO/IEC 38500:2015将治理定义为：一个指导和控制当前及未来状态的系统、
治理是一个关系结构确定的决策过程，旨在指导和控制企业实现所提出的目的。
2、治理的含义
决策途径解释：谁来负责？与谁相关？向谁负责？
3、治理的实践
对企业架构的管理和控制实践，包括：
1）对创建并监控组件和活动的控制——确保架构的引入、实施和演进；
2）确保符合内部及外部标准并遵守监管义务；
3）支持以上各项的管理；
4）确保对内部和外部的利益相关者负责；
4、治理范围
架构治理通常在治理结构的等级内进行，可能包括下列属于各学科和流程领域的项目：
1）公司治理
2）技术治理
3）IT治理
4）架构治理
各个治理领域在整个企业内可能处于不同的地理范围——全球、地区和本土。
三、架构治理为何有益
1、纪律
参与各方均恪守组织建立的流程、规范和权利结构。
2、透明
采取的所有行动及决策依据可供相关部门及提供者审查。
3、独立
采用的所有流程、决策和机制将以尽量减少或避免潜在利益冲突的方式建立。
4、可问责
组织内可识别的群体——例如采取行动或作出决策的治理委员会——得到授权并对其行动负责。
5、负责任
契约各方的行动必须对组织及其利益相关方负责。
6、公平
任何作出决策、采用的流程及其具体实施均不得为任何一方带来不公平的优势。
四、架构委员会的角色和职责
1、角色
架构委员会负责监督治理战略的实施。
委员会应代表架构中全部关键利益相关者。
2、常见的失败模式
建立架构委员会的一个常见误区是认为架构委员会保留与目标架构、架构变更、解除和执行相关的决策权。
与目标架构、解除和实施相关的决策权始终由架构利益相关者掌握。
架构委员会负责流程，以及与实现目标架构所需工作的完整性和信息相关的建议。
3、职责
为所有架构相关决策提供基础；
确保子架构之间的一致性；
确立组件复用的目标；
执行架构合规性；
为超出范围的决策提供明显可见的能力升级支持；
4、实际运行角度的职责
架构契约监测和控制的各个方面；
定期举行会议；
确保架构得到有效的连贯一致的管理和实施；
解决歧义、问题或冲突升级的情况；
提供建议、指导和信息；
确保与架构相符合并给予在符合技术战略和目标前提下的豁免；
产出可用的治理资料和活动；
提供一个通过共识和授权发布，正式采纳和批准架构的机制；
提供一个确保架构有效实施的基本控制机制；
识别背离架构和计划活动的情况，并通过豁免或更新方针实现重新对齐；
五、架构契约
1、定义
架构契约是开发合作伙伴与发起人就架构可交付物、质量和适用性达成的协议。
2、对契约的治理确保
持续监测所有架构相关活动的完整性、变更、决策和审计；
符合现有或开发中的架构原则、标准和要求；
识别（一个或多个）架构所有方面的风险；
一系列流程和实践，确保在全部架构制品的开发和使用上可问责、负责任并遵守纪律；
3、契约与ADM
阶段A中的架构工作申明实质上是架构契约；
架构领域可通过契约外包；
企业架构的实施可在阶段F结束/阶段G开始时通过契约外包；
六、架构合规性
确保企业架构内各个项目的合规性是架构治理的重要方面。
1、通常有两个相辅相成的流程
架构：职能部门需要准备一系列的项目架构，即具体到企业架构的视图，表明企业架构对组织内重大项目的影响（见ADM阶段A至阶段F）;
企业和IT治理：职能部门将定义正式的架构合规性审查，用于审查全部企业架构项目的合规性；
2、必要性
尽早发现羡慕架构中的错误；
确保在架构工作中应用最佳实践；
提供强制性标准合规情况的概览；
识别标准本身是否可能需要调整；
识别当前专门应应用所设，但可能作为企业基础设施的一部分提供的服务；
向管理层汇报项目的就绪度状态；
识别重大架构差距并向产品和服务提供方告知；
第七章 架构内容
一、单元目标
理解ADM的执行过程中能够得到哪些输出。
主题包括：
1）利益相关者、关注点、架构视图和架构视角的概念
2）架构构建块（ABB）
3）架构可交付物
二、利益相关者、关注点、架构视图、架构视角及概念之间的关系
1、利益相关系统（System of Interest）
关系：“利益相关系统”通过“架构”来表现（1 对 1 关系）。它与“利益相关方”之间存在利益关系（1 对多）。
含义：这是你要构建架构的系统主体，比如一个软件平台、业务系统或复杂工程。
2、利益相关方（Stakeholder）
关系：利益相关方对系统有利益关系（1..* 对 1..*）。每个利益相关方识别一个或多个“关注点”。利益相关方也可以识别出需要在“架构描述”中体现的内容。
含义：系统相关的各类人员、组织、机构等，他们有目标、期望或需求。
3、关注点（Concern）
关系：由利益相关方识别。一个关注点可能被一个或多个“架构视角”框定（frame）。关注点会通过架构视图进行回应（address）。
含义：利益相关方关心的特定问题，如安全性、性能、扩展性、可维护性等。
4、架构视角（Viewpoint）
关系：一个架构视角框定一类关注点。架构视角用于**治理（govern）**架构视图的生成和内容。架构视角与模型种类相关联（治理关系）。
含义：一种用于指导如何构建某类架构视图的方法论或模板（规定需要展示哪些模型、内容、格式等）。
5、架构视图（View）
关系：架构视图是按照架构视角来创建的（受其治理）。它是架构描述的一部分。架构视图回应一个或多个关注点。架构视图由架构模型组成。
含义：实际的可视化或文档化结果，如部署图、时序图、模块图等。
6、模型种类（Model Kind）与架构模型（Model）
关系：模型种类规定如何治理某类架构模型。架构模型是架构视图的组成部分。
含义：模型种类是建模方法的类别（如 UML 类图、C4 模型的 Context 图等），而架构模型是实际画出来的具体实例。
7、总结概括
利益相关方提出关注点，架构视角规定如何满足这些关注点，产生架构视图，架构视图由具体的架构模型组成，而这些模型基于特定的模型种类构建，所有这些构成完整的架构描述来体现系统的架构。
三、利益相关者
利益相关者即与系统存在利益关系的个人、团队、组织或其群组，是在系统中扮演关键角色或具有关注点的人员。例如用户、开发者等。
四、构建块与ADM
1、特性
为满足整个组织内业务需求而定义的功能包。
通常具有与元模型相符的类型（例如施动者、业务服务、应用或数据实体）。
具有确定的界限，通常被领域专家识别为“某事物”。
可能与其他相互依赖的构建块互操作。
2、组成
系统由若干组构建块构成。
可在不同细节水平上定义构建块：
1）在反映架构需求的基础功能水平上分类称为架构构建块（ABB）
2）在采购或定制开发的实际产品称为解决方案构建块（SBB）
五、ADM各阶段可交付物
1、架构可交付物的角色
架构可交付物是架构项目的契约产物或正式工作产物。
TOGAF标准中给出的可交付物定义作为基线。
因此可将其作为按需定制的起点。
2、可交付物
架构构建块
架构契约
架构定义文档
架构原则
架构存储库
架构需求
架构路线图
架构愿景
业务原则、业务目标和业务驱动因素
能力评估
变更要求
沟通计划
合规性评估
实施和迁移计划
实施治理模型
企业架构组织模型
架构工作请求
需求影响评估
解决方案构建块
架构工作声明
按需定制的架构框架
扫一扫
1228
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
