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 平台