TOGAF—架构原则

Posted 2023-04-01 Doker 多克

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了TOGAF—架构原则相关的知识，希望对你有一定的参考价值。

2.1 引言

原则是一般规则和准则，旨在持久且很少修改，为《公约》提供信息和支持。一个组织着手履行其使命。

反过来，原则可能只是一套结构化思想中的一个要素，这些思想共同定义和指导组织，从价值观到行动和结果。

根据组织的不同，可以在不同的领域和不同的级别上建立原则。两个关键领域告知架构的开发和使用：

企业原则为整个企业的决策提供了基础，并告知组织如何设定关于完成其使命
这些原则通常被视为协调整个组织决策的一种手段。特别是，它们是成功的架构治理策略的关键要素。

在企业原则的广泛领域内，在企业或组织内拥有附属原则是很常见的单位。示例包括 IT、人力资源、国内运营或海外运营。这些原则为决策提供了基础在附属域内，并将为域内的架构开发提供信息。必须注意确保用于通知体系结构开发的原则与体系结构能力的组织上下文一致。
架构原则是一组与架构工作相关的原则
它们反映了整个企业的共识水平，体现了现有企业原则的精神和思想。架构原则管理架构过程，影响企业的开发、维护和使用建筑。

通常将一套原则组成一个层次结构，在该段中，原则将由企业层面的原则。架构原则将受到企业原则的启发和约束。

架构原则可以以有效指导架构的术语和形式重申其他企业指南。发展。

本节的其余部分专门讨论体系结构原则。

2.2 架构原理的特点

架构原则定义了使用和部署所有 IT 资源的基本一般规则和准则，以及整个企业的资产。它们反映了企业各要素之间的一定程度的共识，并构成基础用于做出未来的 IT 决策。

每个架构原则都应与业务目标和关键架构驱动因素明确相关。

2.3 架构原理的组成部分

有一个定义原则的标准方法是有用的。除了定义语句外，每个原则还应具有相关的理由和影响声明，既促进对原则本身的理解和接受，又支持使用原则来解释和证明做出具体决定的原因。

表 2-1 中给出了推荐的模板。

名字	既应该代表规则的本质，又应该易于记忆。具体技术平台应不得在原则的名称或声明中提及。避免在名称和声明中使用模棱两可的词语，例如： “支持”，“开放”，“考虑”，对于缺乏良好的衡量标准，“避免”一词本身，要小心“管理（ment）”，并寻找不必要的形容词和副词（绒毛）。
陈述	应简洁明确地传达基本规则。在大多数情况下，原则声明用于管理信息从一个组织到另一个组织是相似的。至关重要的是，原则声明是不含糊。
理由	应强调坚持原则的商业利益，使用商业术语。指向信息技术原则与管理业务运营的原则相似。还要描述关系其他原则，以及关于平衡解释的意图。描述将给出一个原则的情况优先或比另一个更重要，用于做出决定。
影响	应强调对业务和 IT 的要求，以执行该原则 — 在资源、成本和活动/任务。尽管通常很明显，当前的系统、标准或实践将是与采用时的原则不一致，上下文将决定范围的程度。对业务的影响和后果应明确规定通过一项原则。读者应该很容易辨别答案：“这对我有什么影响？它重要的是不要过度简化、轻视或判断影响的价值。其中一些影响将被确定为仅潜在影响，可能是推测性的，而不是充分分析的。

表 2-1：定义原则的建议格式

2.6 示例集中给出了遵循此模板的架构原则示例集.

2.4 开发架构原则

架构原则通常由企业架构师与关键一起开发利益干系人，并由架构委员会批准。

架构原则将由企业层面的原则（如果存在）提供信息。

架构原则必须清晰可追溯并明确阐述，以指导决策。他们被选中以确保目标架构的架构和实施与业务战略保持一致，以及愿景。

具体来说，架构原则的发展通常受到以下因素的影响：

企业使命和计划：企业的使命、计划和组织基础结构
企业战略举措：企业的特点——其优势、劣势、机遇和威胁 — 以及当前企业范围的计划（如流程改进和质量管理）
外部制约因素：市场因素（上市时间要求、客户期望等）;现存和潜在的立法
当前系统和技术：企业内部署的信息资源集，包括系统文档、设备清单、网络配置图、策略和程序
新兴行业趋势：对经济、政治、技术和市场因素的预测影响企业环境

2.4.1 原则的品质

仅仅有一个被称为原则的书面陈述并不意味着这个原则是好的，即使大家都同意。

一套好的原则将建立在组织的信念和价值观中，并以语言表达企业理解和使用。原则应数量少，面向未来，并得到高层的认可和倡导管理。它们为制定架构和规划决策、制定政策、程序和标准，并支持解决矛盾的情况。一套糟糕的原则很快就会被废弃，而由此产生的架构、政策和标准将显得武断或自私自利，因此缺乏可信度。本质上原则驱动行为。

有五个标准可以区分一组好的原则：

易于理解：整个过程中的个人可以快速掌握和理解基本原则组织
该原则的意图是明确和毫不含糊的，因此，无论有意还是无意的违反行为都是最小化。
稳健：支持就要制定的体系结构和计划以及可执行的策略做出高质量的决策和要创建的标准
每个原则都应该足够明确和精确，以支持在复杂、潜在的争议情况。
完整：管理信息和技术管理的所有潜在重要原则组织被定义 - 原则涵盖感知到的每种情况
一致：严格遵守一项原则可能需要对另一项原则进行松散的解释
这套原则的表述方式必须能够平衡解释。原则不应该矛盾到坚持一项原则会违反另一项原则的精神。原则语句中的每一个字应仔细选择，以便进行一致而灵活的解释。
稳定：原则应该持久，但能够适应变化
应建立修订程序，以便在原则获得批准后添加、删除或更改原则最初。

2.5 应用架构原则

架构原则用于捕获有关企业如何使用和部署 IT 的基本事实资源和资产。这些原则以多种不同的方式使用：

提供一个框架，在这个框架中，企业可以开始对企业做出有意识的决策实现目标企业架构的架构和项目
作为建立相关评估标准的指南，从而对选择产生强烈影响管理企业架构合规性后期阶段的产品、解决方案或解决方案架构
作为定义体系结构功能要求的驱动程序
作为评估现有实施和战略组合的投入，以符合定义的架构;这些评估将为实施架构，支持业务目标和优先级
体系结构原则中的基本原理陈述突出了实现的业务价值与原则一致，并为具有冲突驱动因素或目标的困难决策提供指导
体系结构原则中的含义陈述概述了关键任务、资源和遵循该原则给企业带来的潜在成本;它们还为未来的过渡倡议和规划活动
在以下方面支持架构治理活动：
- 为标准架构合规性评估提供“支持”，其中允许进行一些解释或必需
- 支持启动分配请求的决定，其中特定架构的影响修改无法在当地操作程序中解决

原则可能是相互关联的，需要作为一个集合来应用。

原则有时会竞争;例如，“可访问性”和“安全性”的原则倾向于相互矛盾的决定。每一项原则都必须在“所有其他条件相同”的背景下加以考虑。

有时需要就某一特定问题优先的原则作出决定。这应始终记录此类决定的理由。

对原则进行初读时，一个常见的反应是“这是显而易见的，不需要记录”。事实一个原则似乎是不言而喻的，并不意味着遵循了原则中的指导。有出现的原则显而易见有助于确保决策真正遵循预期结果。

虽然原则宣言中没有规定具体的惩罚，但违反原则的行为一般造成运营问题并抑制组织完成其使命的能力。

2.6 架构原则示例集

过多的原则会降低架构的灵活性。许多组织更喜欢只定义高级原则，并将数量限制在 10 到 20 之间。

以下示例说明了一组体系结构原则的典型内容，以及建议的如上所述，定义它们的格式。

2.6.1 商业原则

原则1：原则至上

陈述：

这些信息管理原则适用于企业内的所有组织。

理由：

我们能够为决策者提供一致且可衡量的质量信息水平的唯一方法是，如果所有组织遵守原则。

影响：

如果没有这一原则，排斥、偏袒和不一致将迅速破坏信息
信息管理计划在检查其是否符合原则之前不会开始
与原则的冲突将通过改变倡议的框架来解决

原则2：企业利益最大化

陈述：

制定信息管理决策是为了给整个企业带来最大的利益。

理由：

这一原则体现了“服务高于自我”。从企业范围的角度做出的决策具有更大的长期价值而不是从任何特定的组织角度做出的决定。最大的投资回报需要信息管理遵守企业范围的驱动因素和优先事项的决策。任何少数群体都不会减损整体的利益。然而，这一原则并不排除任何少数群体完成其工作。

影响：

要实现企业范围的最大好处，需要我们改变规划和管理信息的方式 — 仅靠技术不会带来这种变化
一些组织可能不得不放弃自己的偏好，以争取整个企业的更大利益
在可行的情况下，应用程序开发优先级必须由整个企业为整个企业确定企业
应用程序组件应跨组织边界共享
应根据企业计划进行信息管理举措
各组织应采取符合蓝图和企业确定的优先级。计划将根据需要进行更改。
根据需要，必须调整优先事项;一个具有全面企业代表性的论坛应使这些决定

原则3：信息管理是每个人的事

陈述：

企业中的所有组织都参与完成业务所需的信息管理决策目标。

理由：

信息用户是应用技术来满足业务需求的关键利益相关者或客户。挨次为了确保信息管理与业务保持一致，企业中的所有组织都必须参与所有方面的信息环境。来自整个企业的业务专家和负责开发的技术人员维护信息环境需要作为一个团队聚集在一起，共同定义 IT 的目标和目的。

影响：

要作为一个团队运营，每个利益相关者或客户都需要承担开发信息环境
执行这一原则需要承付资源

原则 4：业务连续性

陈述：

尽管系统中断，企业仍能保持运营。

理由：

随着系统操作变得越来越普遍，我们越来越依赖它们;因此，我们必须考虑可靠性这样的系统贯穿其设计和使用。必须为整个企业提供以下功能：无论外部事件如何，都能继续操作。不应允许硬件故障、自然灾害和数据损坏中断或停止企业活动。企业必须能够运营替代信息交付机制。

影响：

对共享系统应用程序的依赖性要求必须在高级和管理
管理包括但不限于定期审查、漏洞和暴露测试或设计任务关键型服务，通过冗余或替代功能确保业务连续性。
应在设计时解决可恢复性、冗余性和可维护性问题
必须评估应用程序的关键性和对企业任务的影响，以确定哪些需要连续性级别以及需要哪些相应的恢复计划

原则5：通用应用程序

陈述：

开发整个企业使用的应用程序优先于开发类似或重复的应用程序仅提供给特定组织。

理由：

重复功能成本高昂，并且会扩散相互冲突的数据。

影响：

依赖于不能为整个企业服务的能力的组织必须转变为更换企业范围的能力;这将需要制定并遵守要求这样做的政策
不允许组织开发与自己使用的功能相似/重复企业范围的能力;通过这种方式，花费稀缺资源来发展基本相同的能力略有不同的方式将减少
用于支持企业决策的数据和信息将比以前
这是因为较小的组织能力会产生不同的数据（这些数据在其他组织）将被企业范围的功能所取代。添加到整个企业范围的动力能力很可能来自一个组织，为以前产生的数据/信息的价值提出令人信服的理由。通过其组织能力，但由此产生的能力将成为企业范围系统的一部分，并且数据产品将在整个企业内共享。

原则6：面向服务

陈述：

该体系结构基于服务设计，这些服务设计反映了构成企业（或企业间）业务流程。

理由：

面向服务可提供企业敏捷性和无边界信息流。

影响：

服务表示利用业务描述来提供上下文（即业务流程、目标、规则、策略、服务接口和服务组件），并使用服务编排实现服务
面向服务对基础结构提出了独特的要求，实现应使用开放实现互操作性和位置透明度的标准
实现是特定于环境的;它们受上下文约束或启用，必须在那背景
需要对服务表示和实施进行强有力的治理
需要确定“良好服务”的“石蕊测试”

原则7：遵守法律

陈述：

企业信息管理流程符合所有相关法律、政策和法规。

理由：

企业方针是遵守法律、政策和法规。这不会排除业务流程改进导致政策和法规的变化。

影响：

企业必须注意遵守有关收集的法律、法规和外部政策，数据的保留和管理
教育和获得规则
效率、需求和常识并不是唯一的驱动因素。法律和法规的变化可能会发生变化推动我们的流程或应用发生变化。

原则 8：IT 责任

陈述：

IT 组织负责拥有和实施 IT 流程和基础结构，使解决方案能够满足用户定义的功能、服务级别、成本和交付时间要求。

理由：

有效地使期望与能力和成本保持一致，以便所有项目都具有成本效益。高效和有效解决方案具有合理的成本和明显的收益。

影响：

必须创建一个流程来确定项目的优先级
IT 职能部门必须定义流程来管理业务部门的期望
必须创建数据、应用程序和技术模型，以实现集成的质量解决方案，并最大限度地提高结果

原则9：保护知识产权

陈述：

企业的知识产权（IP）必须得到保护。这种保护必须反映在 IT 体系结构中，实施和治理流程。

理由：

企业 IP 的主要部分托管在 IT 域中。

影响：

虽然保护 IP 资产是每个人的事，但大部分实际保护是在 IT 中实施的。域 — 即使是对非 IT 流程的信任也可以由 IT 流程（电子邮件、强制性注释等）进行管理
将需要管理人员和 IT 参与者的安全策略，该策略可以显著改善对知识产权;这必须能够避免妥协并减少责任
有关此类政策的资源可以在 SANS 研究所找到（请参阅 www.sans.org/security-resources/policies)

2.6.2 数据原理

原则10：数据是一种资产

陈述：

数据是对企业有价值的资产，并得到相应的管理。

理由：

数据是宝贵的企业资源;它具有真实的、可衡量的价值。简单来说，数据的目的是帮助决策。准确、及时的数据对于准确、及时的决策至关重要。大多数公司资产都经过精心管理，并且数据也不例外。数据是我们决策的基础，所以我们也必须仔细管理数据，以确保我们知道它在哪里，可以依靠它的准确性，并且可以在我们需要的时间和地点获得它。

影响：

这是关于数据的三个密切相关的原则之一：数据是一种资产;数据是共享的;和数据是交通便利
这意味着有一个教育任务，以确保企业内的所有组织了解数据价值、数据共享和数据可访问性之间的关系。
监管员必须拥有管理他们负责的数据的权力和手段
我们必须从“数据所有权”思维向“数据管理”思维进行文化转型
数据管理员的角色至关重要，因为过时、不正确或不一致的数据可能会传递给企业人员并对整个企业的决策产生不利影响
管理数据的数据管理员的部分职责是确保数据质量
必须制定和使用程序来防止和纠正信息中的错误，并改进这些错误产生有缺陷的信息的过程。需要衡量数据质量并采取措施提高数据质量——这是可能还需要为此制定政策和程序。
一个具有全面全企业代表性的论坛应决定管家
由于数据对整个企业来说都是有价值的资产，因此数据管理员负责正确管理数据必须在企业级别分配

原则11：数据共享

陈述：

用户可以访问履行其职责所需的数据;因此，数据在企业职能部门之间共享，并且组织。

理由：

及时获取准确的数据对于提高企业决策的质量和效率至关重要。它更少在单个应用程序中维护及时、准确的数据，然后共享这些数据的成本高于在多个应用程序。企业拥有丰富的数据，但它存储在数百个不兼容的烟囱数据库中。这数据收集、创建、传输和同化的速度取决于组织有效共享的能力整个组织的数据孤岛。

共享数据将导致改进决策，因为我们将依赖更少（最终是一个虚拟）来源。为我们所有的决策提供准确及时的管理数据。以电子方式共享数据将提高效率何时可以使用现有数据实体（无需重新键入密钥）来创建新实体。

影响：

这是关于数据的三个密切相关的原则之一：数据是一种资产;数据是共享的;和数据是交通便利
这意味着有一个教育任务，以确保企业内的所有组织了解数据价值、数据共享和数据可访问性之间的关系。
为了实现数据共享，我们必须制定并遵守一套共同的政策、程序和标准，这些政策、程序和标准管理着短期和长期的数据管理和访问
在短期内，为了保护我们对遗留系统的重大投资，我们必须投资于能够将旧系统数据迁移到共享数据环境中
我们还需要开发标准数据模型、数据元素和其他定义此共享的元数据。环境并开发一个存储库系统来存储此元数据以使其可访问
从长远来看，随着遗留系统的更换，我们必须采用并实施通用的数据访问策略和新应用程序开发人员的准则，以确保新应用程序中的数据仍可用于共享环境，以及共享环境中的数据可以继续由新应用程序使用
对于短期和长期，我们必须采用通用的方法和工具来创建、维护和访问整个企业共享的数据
数据共享将需要重大的文化变革
这种数据共享原则将不断“与”数据安全原则相抵触“——在数据共享原则会导致机密数据泄露的情况
所有用户都必须依赖可供共享的数据来执行各自的任务
这将确保决策只依赖最准确和及时的数据。共享数据将成为企业范围的“虚拟单一数据源”。

原则12：数据是可访问的

陈述：

用户可以访问数据以执行其功能。

理由：

广泛获取数据可提高决策效率和效力，并及时对信息作出反应请求和服务交付。必须从企业的角度考虑使用信息，以允许广泛的访问各种用户。节省了员工时间，提高了数据的一致性。

影响：

这是关于数据的三个密切相关的原则之一：数据是一种资产;数据是共享的;和数据是交通便利
这意味着有一个教育任务，以确保企业内的所有组织了解数据价值、数据共享和数据可访问性之间的关系。
可访问性涉及用户获取信息的难易程度
访问和显示信息的方式必须具有足够的适应性，以满足广泛的企业需求用户及其相应的访问方法
访问数据并不构成对数据的理解 - 人员应注意不要误解信息
访问数据并不一定授予用户修改或披露数据的访问权限
这将需要一个教育过程和组织文化的改变，目前组织文化支持：相信职能部门对数据的“所有权”。

原则13：数据受托人

陈述：

每个数据元素都有一个负责数据质量的受托人。

理由：

架构环境的好处之一是能够在企业。随着数据共享程度的提高和业务部门对通用信息的依赖，只有数据受托人对数据内容做出决策。由于数据在多次输入时可能会失去其完整性，因此数据受托人将全权负责数据输入，从而消除多余的人力和数据存储资源。

注意：

受托人不同于监管员——受托人负责数据的准确性和时效性，而责任的监管员可能更广泛，包括数据标准化和定义任务。

影响：

真正的托管消除了数据“所有权”问题，并允许数据可用于满足所有用户的需要
这意味着可能需要从数据“所有权”到数据“托管”的文化变革。
数据受托人将负责满足对受托人的数据征收的质量要求负责
受托人必须能够根据以下属性为用户提供对数据的信心，这一点至关重要作为“数据源”
必须确定数据的真正来源，以便可以为此分配数据权限受托人责任
这并不意味着机密来源将被披露，也不意味着来源将是受托人。
信息应以电子方式捕获一次，并立即验证尽可能靠近来源
必须实施质量控制措施，以确保数据的完整性。
由于在整个企业内共享数据，受托人对准确性和准确性负责其指定的数据要素的货币，随后必须认识到这种托管的重要性责任

原则14：常用词汇和数据定义

陈述：

数据在整个企业中定义一致，并且定义是可理解的，并且可供所有用户使用。

理由：

将用于开发应用程序的数据必须在整个总部有一个共同的定义，以便启用数据共享。一个共同的词汇将促进沟通并使对话有效。此外，它是需要接口系统和交换数据。

影响：

我们被哄骗认为这个问题得到了充分的解决，因为有些人有“数据” 行政“职称和论坛，章程暗示责任
必须为这项任务投入大量额外的精力和资源。这是努力成功的关键改善信息环境。这与数据元素定义问题分开，但与之相关，该问题已解决由一个广泛的社区 - 这更像是一个共同的词汇和定义。
企业必须为企业建立最初的通用词汇;将使用定义在整个企业中统一
每当需要新的数据定义时，定义工作将与企业数据描述“词汇表
企业数据管理员将提供此协调。
由数据的多个狭隘定义导致的歧义必须让位于企业范围内的公认定义和理解
需要协调多个数据标准化计划
必须分配功能数据管理职责

原则15：数据安全

陈述：

数据受到保护，防止未经授权的使用和披露。除了国家安全的传统方面分类，这包括但不限于对决策前、敏感、源选择敏感的保护，以及专有信息。

理由：

通过相关立法公开分享信息和发布信息必须与需要相平衡限制机密、专有和敏感信息的可用性。

现行法律法规要求维护国家安全和数据隐私，而允许免费和开放获取。必须保护决策前（正在进行中，尚未授权发布）信息：避免不必要的猜测、误解和不当使用。

影响：

数据的汇总，无论是分类的还是非分类的，都会产生一个需要审查和取消分类的大目标保持适当控制的程序
数据所有者和/或功能用户必须确定聚合是否会导致分类增加水平。需要适当的政策和程序来处理这种审查和解密。基于以下条件获取信息需要知道的政策将强制定期审查信息主体。
目前使用单独的系统来包含不同分类的做法需要重新考虑
是否有软件解决方案来分离分类和非分类数据？目前的硬件解决方案是笨拙、效率低下且成本高昂。在分类系统上管理未分类数据的成本更高。目前，唯一的办法将两者结合起来就是将未分类的数据放在必须保留的分类系统上。
为了在保持信息安全的同时充分提供对开放信息的访问，安全需要必须在数据级别而不是应用程序级别进行识别和开发
可以采取数据安全保护措施，将访问限制为“仅查看”或“从不查看”
用于访问决策前、决策、分类、敏感或专有信息的敏感性标记必须确定。
必须从一开始就将安全性设计到数据元素中;以后无法添加
必须保护系统、数据和技术免受未经授权的访问和操纵。信息在必须保护总部免受无意或未经授权的更改、破坏、灾难或披露。
需要制定新的政策来管理决策前信息和其他信息的保护期限在制品，考虑到内容新鲜度

2.6.3 应用原理

原则16：技术独立

陈述：

应用程序独立于特定的技术选择，因此可以在各种技术上运行平台。

理由：

应用程序独立于底层技术允许在最具成本效益和及时的方式。否则，技术会不断过时和依赖供应商，就会变成驱动程序而不是用户要求本身。

意识到与IT有关的每一个决定都使我们依赖于该技术，其意图是原则是确保应用软件不依赖于特定的硬件和操作系统软件。

影响：

这一原则将需要支持可移植性的标准。
对于商用现货（COTS）和政府现货（GOTS）应用，电流可能有限选择，因为其中许多应用程序都依赖于技术和平台
需要开发子系统接口，使遗留应用程序能够与应用程序和在企业架构下开发的操作环境
应使用中间件将应用程序与特定软件解决方案分离
例如，这个原则可能导致使用Java，以及未来的类似Java®的协议，这些协议给出了高度平台独立性的优先级

原则17：易用性

陈述：

应用程序易于使用。底层技术对用户是透明的，因此他们可以专注于手头的任务。

理由：

用户越了解底层技术，用户的工作效率就越低。易用性是积极的鼓励使用应用程序。它鼓励用户在集成的信息环境中工作，而不是开发隔离的系统，用于在企业的集成信息环境之外完成任务。大部分知识操作一个系统所需的系统将与其他系统类似。培训保持在最低限度，并降低系统使用不当的风险很低。

使用应用程序应该像驾驶不同的汽车一样直观。

影响：

应用程序将被要求具有共同的“外观和感觉”并支持人体工程学要求;因此，必须设计通用的外观和感觉标准，并制定可用性测试标准
用户界面指南不应受到有关用户位置、语言、系统训练或体能
语言学、客户身体缺陷（视力、使用键盘/鼠标的能力）等因素，以及熟练使用技术在确定应用程序的易用性方面具有广泛的影响。

2.6.4 技术原理

原则18：基于需求的变更

陈述：

只有响应业务需求，才会对应用程序和技术进行更改。

理由：

这一原则将营造一种氛围，使信息环境根据业务需求而变化，而不是让业务更改以响应 IT 更改。这是为了确保信息支持的目的—— 业务交易 — 是任何拟议变更的基础。

由于 IT 更改而对业务的意外影响将降至最低。

技术的变化可能会提供改进业务流程的机会，从而改变业务需要。

影响：

实施中的更改将在使用企业对提议的更改进行全面检查后建筑
除非有记录的业务需求，否则没有资金用于技术改进或系统开发存在
将制定和实施符合这一原则的变更管理流程
此原则可能会与响应式变更原则相冲突
我们必须确保需求文档流程不会妨碍响应更改以满足合法业务需要。这一原则的目的是将重点放在业务上，而不是技术需求上——响应式变革也是一种业务。需要。

原则19：响应式变革管理

陈述：

及时实施对企业信息环境的更改。

理由：

如果要期望人们在企业信息环境中工作，那么该信息环境必须响应他们的需求。

影响：

必须制定不造成延误的管理和实施变革的流程
觉得需要改变的用户需要与“业务专家”联系，以促进解释和 A. 落实这一需要
如果要进行更改，则必须保持体系结构更新
采用这一原则可能需要额外的资源
这将与其他原则相冲突（例如，企业范围的最大利益、企业范围的应用程序、等）

原则20：控制技术多样性

陈述：

控制技术多样性，以最大限度地降低维护专业知识和连接之间的非平凡成本多种处理环境。

理由：

支持处理环境的替代技术需要实际的、非平凡的基础设施成本。保持多个处理器结构的互连和维护会产生进一步的基础设施成本。

限制支持的组件数量将简化可维护性并降低成本。

最小技术多样性的商业优势包括：组件的标准包装;可预言的实施影响;可预测的估值和回报;重新定义测试;效用状态;并提高了灵活性适应技术进步。整个企业的通用技术为企业带来了规模经济的好处企业。当有限的资源可以专注于这组共享的科技。

影响：

管理技术获取的政策、标准和程序必须与此直接相关。原则
技术选择将受到技术蓝图中可用选择的限制
必须制定程序，以增强可接受的技术组合，以满足不断变化的要求，落实到位。
技术基线未被冻结
技术进步受到欢迎，当与当前兼容时，技术蓝图将改变基础设施、运营效率的提高或所需的能力已经得到证明。

原则21：互操作性

陈述：

软件和硬件应符合定义的标准，以促进数据、应用程序和科技。

理由：

标准有助于确保一致性，从而提高管理系统的能力，提高用户满意度，并保护现有的 IT 投资，从而最大限度地提高投资回报并降低成本。互操作性标准也提供了帮助确保多个供应商对其产品的支持，并促进供应链集成。

影响：

除非有令人信服的商业理由，否则将遵循互操作性标准和行业标准实施非标准解决方案
制定标准、定期审查和修订标准以及授予例外的程序必须是既定
必须识别和记录现有的 IT 平台

Atitit.研发管理---TOGAF架构跟（ADM开发方法）总结

1. TOGAF是在过去二十年间出现的企业架构框架 1

2. TOGAF内容结构 1

3. TOGAF 实现过程 2

4. 參考 4

1. TOGAF是在过去二十年间出现的企业架构框架

。其目标是成为 EA 开发的标准。

TOGAF 是由 Open Group consortium 成员创建的， TOGAF 不是一開始就体现总体的 EA 焦点。

最初。TOGAF 仅仅包含技术架构(版本号 1 到 7)。然而，近期该框架中增加了业务架构领域(版本号 9。Enterprise Edition)，这高速地将 TOGAF 推向当今 EA 框架选择的第一把交椅。

TOGAF的各部分内容以及他们之间的关系通过例如以下的示意图进行了表述：

作者::老哇的爪子Attilax艾龙，EMAIL:[email protected]

转载请注明来源：http://blog.csdn.net/attilax

2. TOGAF内容结构

TOGAF的内容被分为三个主要部分：

· TOGAF能力框架（TOGAF Capability Framework）：为了在一个企业中有效地操作企业架构并使其发挥最大的效能。一系列适当的组织结构、流程、技能、角色和责任须要被定义并结合起来。而TOGAF的能力框架正为怎样组织好这些元素提供了指南。

· TOGAF架构开发方法和内容框架（TOGAF ADM（Architecture Development Method）& Content Framework）：此部分是TOGAF的核心部分，它包括了两个方面的内容。当中架构开发方法是TOGAF针对企业架构建设方法的论述，它以一个循环迭代模型为基础将企业架构的建设过程划分为前后衔接的若干步骤，并对每一个步骤的输入、输出以及所採用方法都进行了详尽的阐述；作为新晋的内容框架部分，它针对企业架构中所包括的各种工作产品以及他们之间的关系作出了具体的描写叙述。

· TOGAF企业连续体和工具（TOGAF Enterprise Continuum and Tools）：企业连续体是企业架构资源库的一张视图，它为企业中的各种架构和解决方式制品提供了一种分类和组织的方法。企业架构过程是一个动态的过程。因而这一针对工作制品进行组织分类的方式也不不过一个静态方法，还是一种可以随着企业架构演进而变化其分类方式的动态方法。在此方法的视角中，随着企业架构的演进发展，其内容也从通用走向特化，其具体程度也由简略转为详尽，而随着实践的沉淀。原来特化的架构或解决方式制品也可能成为在更广泛范围内通用制品。除此之外，该部分内容还提供了几个用于帮助企业架构建设的參考模型以及其它的一些辅助工具。

3. 　TOGAF 实现过程

架构开发方法为实现和运行组织的企业架构提供完整的指导。该过程包含闭合循环中的多个，连续的阶段。

图 1：TOGAF 架构开发方法(Architecture Development Method，ADM)

　　初期的目标是确定实现过程涉众，而且让它

过程的阶段 A 用于明白 EA 远景。架构远景(Architecture Vision )工件利用业务推动者明白企业架构工作的目的。而且创建基线和目标环境的粗略描写叙述。假设业务目标不清楚，那么该阶段中的一部分工作是来帮助业务人员确定其关键的目标和对应的过程，这些企业架构都必须支持。相同是该阶段中生成的架构工作描写叙述(Statement of Architectural Work)。勾勒出 EA 的范围及约束。而且表示出架构工作的计划。

　　阶段 B 用于详述关于业务领域架构的工作。架构远景(Architecture Vision) 中概括的基线和目标架构在此被具体说明。从而使它们作为技术分析的实用输入。业务过程建模、业务目标建模和用例建模是用于生成业务架构的一些技术。这又包含了所期望状态的间隙分析。

　　阶段 C 涉及应用和数据(信息)架构的交付。该阶段利用基线和阶段 A(Architecture Vision)中開始的目标架构，以及业务间隙分析(业务架构的一部分)的结果。在范围内，并依据架构工作描写叙述(Statement of Architectural Work )中所概括的计划，为眼下和展望的环境交付应用及数据架构。

　　阶段 D 利用技术架构的交付完毕了 TOGAF ADM 循环的具体架构工作。

如前面的阶段里。间隙分析和草案架构用作基线，因为初期对架构指导原则达成一致。建模标记，比如 UML，在此阶段中被积极地使用。从而生成各种观点。

　　阶段 E 的目的是阐明目标架构所表现出的机会。并概述可能的解决方式。此阶段中的工作环绕着实现方案的可行性和有用性。此处生成的工件包含实现与移植策略 (Implementation and Migration Strategy)、高层次实现计划(High-level Implementation Plan)，以及项目列表(Project List)，还有作为实现项目所使用的蓝图的已更新的应用架构。

　　阶段 F 将所提议的实现项目划分优先级，而且运行移植过程的具体计划和间隙分析。该工作包含评估项目之间的依赖性。而且最小化它们对企业运作的整个影响。在此阶段中。更新了项目列表(Project List)，详述了实现计划(Implementation Plan)，而且将蓝图传递给了实现团队。

　　随着项目列表的稳定，重点就移动到为每一个实现项目明白更详细的目标和推荐。在阶段 G 中。建立起了治理架构(TOGAF)和开发组织之间的关系(比如，可能由 RUP 和项目管理知识体系((Project Management Body of Knowledge，PMBOK) 的组合，或其它项目管理方法所规定)，而且在正式的架构治理下实现所选的项目。

阶段的交付内容是开发组织所接受的架构契约(Architecture Contracts)。

阶段 G 终于的输出是符合架构的解决方式。

　　阶段 H 中的重点转移到实现的解决方式的交付所达到的架构基线的变更管理。

该阶段可能会生成为企业架构工作的后继循环设置目标的架构工作请求(Request for Architecture Work)。