体系结构原则的应用

    体系结构原则捕获关于企业将如何使用和部署 IT 资源和资产的基本事实。 可以采用某人担任的角色所预见的任何方式对其进行应用。 定义之后，就可以将其用于开发参考体系结构和参考体系结构的实现（应用程序体系结构）。

    可以采用多种方式使用原则。 在 IT 决策过程中，原则作为基础，可为结构良好切中要点的决策提供指南、约束、非常好的实践和标准。 在决策的治理中，原则可以定义决策流程的控制属性。 此标准可用于评估体系结构遵从性。

    对于产品选择，原则可建立用于选择支持 IT 体系结构的产品的相关评估标准。 也可将其用于基本原则中，重点说明体系结构对企业的价值或用途。 原则可用于说明不使用原则的影响，及其在完成组织的任务时增加的价值（例如，将会出现的操作问题类型或潜在的重用）。

    原则用于为规划决策提供输入信息。 可以将其作为需求中介，以对冲突需求的使用进行平衡。 作为评估措施，原则用于基于公司的优先级确定是否可以通过现有的及建议的 IT 系统满足业务目标。 还可以将原则作为定义体系结构的概念需求的驱动元素使用。

    体系结构原则规范模板

    模板可在定义体系结构原则时提供一致性。 通过使用模板指导原则，可得到各种人员都能理解的内容和形式。 每个原则应该采用有意义的名称和定义语句。 每个原则还应该具有相关的基本原则和影响声明，以促进原则的理解和接受，以及在说明和支持具体决策方面支持使用原则。 下面给出了其模板。

    体系结构模板
　
名称  应该代表规则的本质，而且便于记忆。 此名称还必须对于担任不同的角色和承担不同的职责的人有意义。 
语句  应该简洁而且明确地说明基本规则。 通常，不同的组织间关于管理信息的原则语句都是类似的。 原则语句必须明确，这一点至关重要。 避免含糊的词汇，如：支持、开放、考虑和避免。 关于“管理”之类的术语需要谨慎处理，找出不必要的形容词或副词或各种失误。
基本原则  应该使用业务术语突出说明遵循原则的业务好处。 描述与其他原则的关系，并从一致解释的角度对其目的进行说明。 描述在决策时应该优先考虑某个原则或比其他原则更重要的各种情况。
影响  应该从业务和 IT 的资源、成本和活动及任务的角度对实现原则的影响进行重点说明。 当前系统、标准或实践经常明显地与要采用的原则不一致。 读者应该很容易地确定此问题的答案： “这会如何影响我？”
务必不要将影响的特征过于简单化、琐碎化，也不要轻易下结论。 有些影响只是潜在的，而有些需要仔细分析而不是草草分析了事。
 

    原则示例

    开发原则的价值在于，他们可以对应该治理的内容进行规定。 因此，每个原则应该包含有些可测定的属性。 以下两个示例都使用了上面给出的模板。 示例 1 重点说明了可以如何使用可重用资产减少资产开发成本和开发新应用程序所需的时间。

    示例 1. 测定成本和开发时间的减少
　  名称  重用
    语句  构建应用程序和企业需求时，应该使用 IT 体系结构中的公共组件。
    基本原则  业务单位具有共有需求和需要，不过每个业务单位已自行开发了实现这些共有任务的自有实现。
    影响  *开发共有资产将减少支持成本。
          *加速应用程序开发
          *如果未加以遵循的话，会限制将系统与新应用程序可以补充的功能集成或一起使用的能力。  

    示例 2 说明了可以根据系统可靠性需求测定系统可靠性。 在这两个示例中，都至少有一个属性能够应用治理。

    示例 2. 根据系统需求测定系统可靠性
　  名称  业务连续性
    语句  系统需要在系统中断的情况下保持企业操作。
    基本原则  随着系统操作变得越来越普遍，我们将对其更加依赖。 我们必须在设计和使用过程中考虑系统的可靠性。 企业中的业务机体    必须具有在不受外部事件影响的情况下继续执行其业务功能的能力。 硬件故障、自然灾害和数据破坏不应该中断或停止企业活动。 企业业务功能必须能够在后备信息交付机制上操作。
    影响  *由于依赖于共享系统应用程序，因此必须事先确定业务中断风险并加以管理。 管理包括（但不限于）定期检查、测试漏洞和公开情况或设计任务关键型服务来通过冗余或后备功能确保业务功能持续性。
          *应该在设计阶段考虑可恢复性、冗余和可维护性。
          *必须评估应用程序的临界点和对企业任务的影响，以确定需要何种级别的连续性以及必须提供哪些对应的恢复计划。