【TOGAF系列】ADF技术第二章架构原理

发布于:2025-02-20 ⋅ 阅读:(108) ⋅ 点赞:(0)

第2章:架构原理

本章描述了企业架构开发中使用的原则。

2.1 介绍

原则是一般规则和指导方针,旨在持久且很少修改,为组织履行使命的方式提供信息和支持。反过来,原则可能只是一套结构化思想中的一个要素,这些思想共同定义和指导着组织,从价值观到行动和结果。

根据组织的不同,原则可以在不同的领域和不同的层次上建立。两个关键领域为架构的开发和利用提供了信息:

  • 企业原则为整个企业的决策提供了基础,并告知组织如何着手履行其使命,这些原则通常被视为协调整个组织决策的一种手段。特别是,它们是成功的架构治理策略的关键要素(见TOGAF标准——企业架构能力和治理)。在企业原则的广泛领域内,在业务或组织单位内有附属原则是很常见的。示例包括IT、人力资源、国内运营或海外运营。这些原则为子领域内的决策提供了基础,并将为该领域内的架构开发提供信息。必须注意确保用于告知架构开发的原则与架构能力的组织背景相一致。
  • 架构原则是一组与架构工作相关的原则,它们反映了整个企业的共识水平,体现了现有企业原则的精神和思想。架构原则管理架构过程,影响企业架构的开发、维护和使用。一系列原则形成一个层次结构是很常见的,因为部门原则将由企业层面的原则提供信息并加以阐述。架构原则将受到企业原则的指导和约束。架构原则可能会以有效指导架构开发的术语和形式重申其他企业指导。本节的其余部分专门讨论架构原则。

2.2 架构原理的特点

架构原则定义了整个企业中所有IT资源和资产的使用和部署的基本一般规则和指导方针。它们反
映了企业各个要素之间的共识水平,并构成了未来IT决策的基础。

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

2.3 架构原理的组成部分

有一个标准的方法来定义原则是有用的。除了定义声明外,每项原则都应该有相关的基本原理和含义声明,以促进对原则本身的理解和接受,并支持使用这些原则来解释和证明做出具体决定的原因。

下表给出了推荐模板。

姓名 两者都应该代表规则的精髓,并且易于记忆。原则的名称或声明中不应提及特定的技术平台。避免名称和声明中的歧义词,如:“支持”、“开放”、“考虑”,以及缺乏良好衡量标准的“避免”一词本身,小心使用“管理
(ment)”,并寻找不必要的形容词和副词(绒毛)。
声明 应简洁明了地传达基本规则。在大多数情况下,管理信息的原则声明在组织之间是相似的。原则声明必须明确无误。
理论基础 应强调坚持原则的商业利益,使用商业术语。指出信息和技术原则与业务运营原则的相似性。还要描述与其他原则的关系,以及关于平衡解释的意图。描述在做出决定时,一个原则优先或比另一个原则更重要的情况。
启示 应强调业务和IT在资源、成本和活动/任务方面执行该原则的要求。虽然通常很明显,当前的系统、标准或做法在采用时与原则不一致,但背景将决定范围的程度。应明确说明采用一项原则对业务的影响和后果。读者应该很容易分辨出“这对我有什么影响?”的答案。重要的是不要过于简单化、琐碎化或判断影响的价值。其中一些影响将仅被确定为潜在影响,可能是推测性的,而不是充分分析的。

第2.6节给出了遵循此模板的架构原则示例集。

2.4 制定架构原则

架构原则通常由企业架构师与关键利益相关者共同制定,并由架构委员会批准。

架构原则将由企业级原则(如果存在)提供信息。

架构原则必须清晰可追溯,并明确阐述,以指导决策。选择它们是为了确保目标架构的架构和实施与业务战略和愿景保持一致。

具体而言,架构原则的发展通常受到以下因素的影响:

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

2.4.1 原则的性质

仅仅有一份被称为原则的书面声明并不意味着该原则是好的,即使每个人都同意它。

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

区分一套好的原则有五个标准:

  • 可理解:整个组织的个人可以快速掌握和理解基本原则,该原则的意图是明确无误的,从而将有意或无意的违规行为降至最低。
  • 稳健:能够就架构和计划做出高质量的决策,并制定可执行的政策和标准,每项原则都应该足够明确和精确,以支持在复杂、可能有争议的情况下做出一致的决策。
  • 完整:定义了管理组织信息和技术的每一项潜在重要原则——这些原则涵盖了所感知的每一种情况
  • 一致性:严格遵守一项原则可能需要对另一项原则进行宽松的解释,这套原则必须以一种允许平衡解释的方式表达。原则不应相互矛盾,以至于坚持一项原则会违背另一项原则的精神。原则声明中的每个词都应该谨慎选择,以便进行一致而灵活的解释。
  • 稳定:原则应该是持久的,但能够适应变化

应建立修正程序,以便在原则最初批准后添加、删除或更改原则。

2.5 应用架构原理

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

  1. 提供一个框架,企业可以在其中开始对企业架构和实现目标企业架构的项目做出有意识的决策
  2. 作为建立相关评估标准的指南,从而在管理企业架构合规性的后期阶段对产品、解决方案或解决方案架构的选择产生重大影响
  3. 作为定义架构功能需求的驱动因素
  4. 作为评估现有实施和战略组合是否符合既定架构的输入;这些评估将为实施架构所需的过渡活动提供有价值的见解,以支持业务目标和优先事项
  5. 架构原则中的基本原理陈述强调了与该原则一致的实施的商业价值,并为具有冲突驱动因素或目标的困难决策提供了指导
  6. 架构原则中的含义陈述概述了企业遵循该原则的关键任务、资源和潜在成本;它们还为未来的过渡倡议和规划活动提供了宝贵的投入
  7. 从以下方面支持架构治理活动:
    • 在允许或需要某些解释的情况下,为标准架构合规性评估提供“后盾”
    • 在特定架构修改的影响无法在本地操作程序中解决的情况下,支持发起豁免请求的决定

原则可能相互关联,需要作为一套原则来应用。

原则有时会相互竞争;例如,“可访问性”和“安全性”原则

倾向于做出相互冲突的决定。每项原则都必须在“所有其他条件都相同”的背景下加以考虑。有时,需要决定在特定问题上哪个原则优先。此类决定的理由应始终记录在案。对原则进行初读时的常见反应是“这是显而易见的,不需要记录”。一项原则看似不言而喻,并不意味着遵循了原则中的指导。拥有显而易见的原则有助于确保决策真正遵循预期的结果。虽然原则宣言中没有规定具体的处罚,但违反原则通常会导致运营问题,并抑制组织履行其使命的能力。

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域中。

启示:

  • 虽然保护知识产权资产是每个人的事,但大部分实际保护都是在IT领域实施的——即使是对非IT流程的信任也可以通过IT流程(电子邮件、强制性说明等)来管理
  • 将需要一项管理人员和IT参与者的安全政策,以大大改善对知识产权的保护;这必须既能避免妥协,又能减少负债
  • 关于此类政策的资源可以在SANS研究所找到( 请参阅www.SANS.org/securityresources/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:响应式变更管理

声明: 企业信息环境的变化得到及时 实施。
理由: 如果人们希望在企业信息环境 中工作,那么该信息环境必须能够满足他们的需求。

启示:

  • 必须制定不会造成延误的管理和实施变更的流程
  • 认为需要改变的用户需要与“业务专家”联系,以促进对该需求的解释和实施
  • 如果要进行更改,则必须不断更新架构
  • 采用这一原则可能需要额外的资源
  • 这将与其他原则相冲突(例如,最大化企业范围的利益、企业范围的应用程序等)

原则20:控制技术多样性

声明:控制 技术多样性 ,以最大限度地降低在多个处理环境中保持专业知识和连接的非微不足道的成本。

理由: 支持处理环境的替代技术所需的基础设施成本非常高。

为了保持多个处理器结构的互连和维护,还需要额外的基础设施成本。限制支持组件的数量将简化可维护性并降低成本。技术多样性最小的商业优势包括:组件的标准包装;可预测的实施影响;可预测的估值和回报;重新定义测试;效用状态;以及提高灵活性以适应技术进步。整个企业的通用技术为企业带来了规模经济的好处。当有限的资源可以集中在这套共享技术上时,技术管理和支持成本可以得到更好的控制。

启示:

■ 管理技术获取的政策、标准和程序必须直接与这一原则联系起来

■ 技术选择将受到技术蓝图中可用选择的限制,必须制定和实施增加可接受技术集以满足不断变化的要求的程序。
■ 技术基线没有被冻结,技术进步受到欢迎,当与当前基础设施的兼容性、运营效率的提高或所需能力得到证明时,技术进步将改变技术蓝图。

原则21:互操作性

声明: 软件和硬件应符合促进数据、应用程序和技术互操作性的既定标准。

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

启示:

  • 除非有令人信服的业务理由实施非标准解决方案,否则将遵循互操作性标准和行业标准
  • 必须建立制定标准、定期审查和修订标准以及批准例外情况的流程
  • 必须识别并记录现有的IT平台


网站公告

今日签到

点亮在社区的每一天
去签到