对于“什么是体系结构”的答案取决于提出这个问题的人。要确定对于开发强大的体系结构需要进行什么工作，甚至更难。不过，有一些在进行体系结构设计时应该采用的广为人知的原则。在本文中，我们将讨论其中的原则之一：体系结构原则。
本文讨论原则 在开发体系结构（无论是参考体系结构、应用程序体系结构或其他体系结构类型之一）中的作用。 体系结构设计是一项复杂的工作，必须将业务的需求与技术能够如何为其提供支持的现实进行权衡。
体系结构可以定义为：
- 计算机系统的总体设计或结构，包括运行其所需的硬件和软件
- 关于 IT 系统的设计、构造和修饰原则
- 创建任意复杂对象或系统的实际或隐含计划的艺术 与规程
原则是进行与采用体系结构系统的设计与构造相关的决策的基础。 原则还讨论 IT 体系结构决策的接受度和治理。 本文将分析原则对体系结构的影响。
原则代表一个或多个观点，支持规范或规则的形成，以指导您运作所需的企业文化的发展。 通过将规则还原为原则，对于当前的用途，除非创建新规则，否则不能对原则进行质疑或进一步派生。
原则由组织用于支持其总体任务。 之所以将其用于决策参考，因为这些都是通用的规则和指导原则。 原则应该长期适用，很少会发生更改。
原则基于行业最佳实践，反映通过策略、过程和标准实现的企业目的、远景和价值。
目的
体系结构原则是通用原则的专门化子集。 它们可指导企业体系结构的开发及其持续发展。 体系结构原则在开发满足企业需求的信息和技术系统的过程中担当“指南针”的角色。
体系结构原则由首席架构师制定，首席架构师要与企业 CIO、体系结构委员会和其他主要业务涉众进行合作。 如果组织的业务或任务发生变化，这些原则也会随着时间而发生变化。
图 1 显示了原则如何反映企业的目的、远景和价值，而这些都是企业的业务基础。 这些概念性属性捕获为原则后，将作为开发企业体系结构的驱动力量。
体系结构原则：
- 首选方向或实践的声明。 可反映企业内各种组织的一致性级别，此类组织包括业务单位、IT 和支持团队等。
- 要求开发一个框架，在其中包括相应的策略和过程，以支持原则的实现。 策略和过程用于支持将治理应用到体系结构的信息与技术组件。
治理 是关系和流程的结构，用于指导和控制适用组件，以通过在平衡风险与回报的情况下增加价值来实现企业目标。
- 建立设计决策上下文，以用于将业务条件转换为语言和规范。 然后技术经理可以在规划、设计、开发、实现、测试和部署整个企业内的信息系统
IT 资源和资产时使用此信息。
- 长期声明简单而直接，说明组织如何对 IT 进行决策。 这些原则对实现公司的目标非常重要。
图 1. 体系结构原则
好原则的属性
好原则的主要属性是重用（现在和以后）。 创建原则是为了推动和指导开发体系结构及其实现的实例所需的行为。
这些原则必须相关，并采用恰当的方式进行表述，以便不同的团队能够了解其含义，并了解何时使用它们。 这非常重要，因为有些原则可能相互存在冲突，具体取决于其使用的上下文。
只有获得了高层管理的技术和业务支持，原则才非常重要。 原则数量应该相对较少——平均 10 到 20 个。此数字根据工作的复杂性和规模不同，可能会更大。
原则太多会增加混淆，从而失去其价值。
要定义一组好的原则，请记住以下条件。
- 简单性
- 关键点必须清楚，组织内不同的团队能够了解其含义。 注意不要设置太多的原则，否则就会导致混淆。
- 解释的一致性
- 可靠的原则包括策略和标准，从而支持以一致的方式对治理提供支持。 为了支持此概念，必须谨慎地选择定义原则的字句，确保不会出现对同一原则的多种解释。
- 相关性
- 原则必须涵盖组织的所有相关和重要的构造。 原则的价值在于支持适用于组织的 IT 需求的体系结构的领域。
- 粒度
- 原则的粒度都较大。 必须注意不要定义过于细粒度、关注的范围过小的原则。
- 灵活性
- 必须采用恰当的方式表述原则，以便能够与其他原则相适应，尽可能减小其间的冲突。 存在冲突的原则的冲突程度不应达到一个原则会使得另一个原则的用途失效的地步。
- 稳定性
- 原则应该具有长期适用性，不过还应该能够包含变更。 原则具有生命周期；必须开发允许对原则进行修改的流程，以便添加、删除和更新原则。
体系结构原则捕获关于企业将如何使用和部署 IT 资源和资产的基本事实。 可以采用某人担任的角色所预见的任何方式对其进行应用。
定义之后，就可以将其用于开发参考体系结构和参考体系结构的实现（应用程序体系结构）。
可以采用多种方式使用原则。 在 IT 决策过程中，原则作为基础，可为结构良好切中要点的决策提供指南、约束、最佳实践和标准。
在决策的治理中，原则可以定义决策流程的控制属性。 此标准可用于评估体系结构遵从性。
对于产品选择，原则可建立用于选择支持 IT 体系结构的产品的相关评估标准。 也可将其用于基本原则中，重点说明体系结构对企业的价值或用途。
原则可用于说明不使用原则的影响，及其在完成组织的任务时增加的价值（例如，将会出现的操作问题类型或潜在的重用）。
原则用于为规划决策提供输入信息。 可以将其作为需求中介，以对冲突需求的使用进行平衡。 作为评估措施，原则用于基于公司的优先级确定是否可以通过现有的及建议的
IT 系统满足业务目标。 还可以将原则作为定义体系结构的概念需求的驱动元素使用。
模板可在定义体系结构原则时提供一致性。 通过使用模板指导原则，可得到各种人员都能理解的内容和形式。 每个原则应该采用有意义的名称和定义语句。
每个原则还应该具有相关的基本原则和影响声明，以促进原则的理解和接受，以及在说明和支持具体决策方面支持使用原则。 下面给出了其模板。
体系结构模板
| 名称 |
应该代表规则的本质，而且便于记忆。 此名称还必须对于担任不同的角色和承担不同的职责的人有意义。 |
| 语句 |
应该简洁而且明确地说明基本规则。 通常，不同的组织间关于管理信息的原则语句都是类似的。 原则语句必须明确，这一点至关重要。
避免含糊的词汇，如：支持、开放、考虑和避免。 关于“管理”之类的术语需要谨慎处理，找出不必要的形容词或副词或各种失误。 |
| 基本原则 |
应该使用业务术语突出说明遵循原则的业务好处。 描述与其他原则的关系，并从一致解释的角度对其目的进行说明。 描述在决策时应该优先考虑某个原则或比其他原则更重要的各种情况。 |
| 影响 |
应该从业务和 IT 的资源、成本和活动及任务的角度对实现原则的影响进行重点说明。 当前系统、标准或实践经常明显地与要采用的原则不一致。
读者应该很容易地确定此问题的答案： “这会如何影响我？”
务必不要将影响的特征过于简单化、琐碎化，也不要轻易下结论。 有些影响只是潜在的，而有些需要仔细分析而不是草草分析了事。 |
原则示例
开发原则的价值在于，他们可以对应该治理的内容进行规定。 因此，每个原则应该包含有些可测定的属性。 以下两个示例都使用了上面给出的模板。
示例 1 重点说明了可以如何使用可重用资产减少资产开发成本和开发新应用程序所需的时间。
示例 1. 测定成本和开发时间的减少
| 名称 |
重用 |
| 语句 |
构建应用程序和企业需求时，应该使用 IT 体系结构中的公共组件。 |
| 基本原则 |
业务单位具有共有需求和需要，不过每个业务单位已自行开发了实现这些共有任务的自有实现。 |
| 影响 |
- 开发共有资产将减少支持成本。
- 加速应用程序开发
- 如果未加以遵循的话，会限制将系统与新应用程序可以补充的功能集成或一起使用的能力。
|
示例 2 说明了可以根据系统可靠性需求测定系统可靠性。 在这两个示例中，都至少有一个属性能够应用治理。
示例 2. 根据系统需求测定系统可靠性
| 名称 |
业务连续性 |
| 语句 |
系统需要在系统中断的情况下保持企业操作。 |
| 基本原则 |
随着系统操作变得越来越普遍，我们将对其更加依赖。 我们必须在设计和使用过程中考虑系统的可靠性。 企业中的业务机体必须具有在不受外部事件影响的情况下继续执行其业务功能的能力。
硬件故障、自然灾害和数据破坏不应该中断或停止企业活动。 企业业务功能必须能够在后备信息交付机制上操作。 |
| 影响 |
- 由于依赖于共享系统应用程序，因此必须事先确定业务中断风险并加以管理。 管理包括（但不限于）定期检查、测试漏洞和公开情况或设计任务关键型服务来通过冗余或后备功能确保业务功能持续性。
- 应该在设计阶段考虑可恢复性、冗余和可维护性。
- 必须评估应用程序的临界点和对企业任务的影响，以确定需要何种级别的连续性以及必须提供哪些对应的恢复计划。
|
正如我们指出的，应该尝试限制原则的数量，以免让需要理解这些原则的人觉得数量过多了。 通常将其限制在 20 或更少的数目。
如果开发的是企业级的参考体系结构，则此数量将更高一些。
随着原则数量的增加，将会出现一些自然的分组方式。 大部分体系结构最终都采用以下原则分组方式：
- 通用体系结构
- 业务
- 技术
- 信息/数据
- 管理
- 行业趋势
- 安全性
- 测试
以下部分将简单讨论这些原则，可作为您下一个项目的参考。 其中反映的是上面列出的自然分组，可让人们更好地了解其侧重点以及对于各个角色的适用性。
通用体系结构原则
- 随需应变
- 企业的业务流程必须与主要合作伙伴、供应商和客户实现端到端集成。 业务必须对任何客户需求、市场机会或外部威胁作出快速响应。
- 易用
- IT 体系结构将促进构建和支持体系结构及基于体系结构的解决方案方面的易用性。
- 非功能需求与功能需求同样重要
- 将按照功能需求的严格要求设计、开发、测试和管理非功能需求。
- 单一视图
- IT 体系结构将支持提供业务一致的集成视图的解决方案，而不会受到访问点的影响。
- 购买还是构建
- 除非出于竞争原因而进行内部开发，否则将购买业务应用程序、系统组件和支持框架。
- 简单性
- IT 体系结构应该尽可能保持简单，但同时仍然要满足业务和企业需求。 在需要一定复杂性的地方，应该对其进行封装，以提高以体系结构为基础构建的解决方案的简单性。
业务原则
- 速度和质量
- 体系结构决策将在强调缩短解决方案的上市时间但同时保持高质量的情况下作出。
- 灵活性
- IT 体系结构将具有灵活性，以支持不断变化的业务需求，并支持体系结构及构建于其上的解决方案的发展。
- 技术风险
- 业务系统的稳定性将通过在整个生命周期中有控制地使用和管理技术来得以保持。
- 集成解决方案
- IT 体系结构将支持由集成应用程序和基础设施组件组成的业务解决方案的交付。
- IT 和业务的一致性
- IT 体系结构将与业务远景、目标和战略保持一致，为业务操作提供支持。
- 关系的战略使用
- IT 体系结构将利用与其他企业和提供商的战略关系来促进 IT 体系结构的构建和发展。
- 优化 IT 基础设施
- IT 基础设施将根据业务需求和技术功能进行优化。
技术原则
- 创新和敏捷性
- IT 体系结构将方便地支持将新技术包含进来，以支持业务和技术创新。
- 技术与供应商独立性
- IT 体系结构将设计为减少技术更改对业务的影响，并具有针对更改的弹性。
信息/数据原则
计算机环境的所有组件都必须保持用于开展业务的信息的保密性和完整性，而且决策都基于数据分类进行。
管理原则
- 通用治理
- 对体系结构的遵从及体系结构的发展将通过有控制的治理流程进行管理。
- 成本绩效
- 将对 IT 体系结构进行管理，以确保信息和技术环境的成本效益。
- 应用程序和基础设施组件
- 这些元素将以能促进监视和测定的方式设计和实现。
- 服务级别管理
- IT 体系结构将支持服务级别协议定义的业务流程操作。
行业趋势原则
- 开放标准
- IT 体系结构将使用开放行业标准。
- 利用行业知识
- IT 体系结构将利用行业最佳实践。
- 面向服务
- IT 体系结构和构建于其上的组件应该视为一组可进行组合来形成解决方案的独立服务。
- 分离关注点
- IT 体系结构将支持定义清楚、划分合理的松散耦合组件、流程和角色。
- 重用
- 对应用程序和企业需求进行平衡时，应该使用 IT 体系结构中的公共组件。
安全性原则
以下原则非常有价值，企业可使用其提供安全性（包括信任模型、资产概要）。
- 深度设计
- 可以通过分层防御提供更高的安全性。
- 风险管理
- 应该根据业务目标对风险和安全控制进行平衡——安全控制应该与风险成正比。
- 安全性设计
- 安全性不应是马后炮或附加项。 安全考虑应该从开发工作的需求阶段开始，作为总体系统设计不可或缺的一部分进行处理。
- 基于需求的访问
- 只应向用户（人员或计算机）提供执行指定的工作活动、功能或任务所需的任务足够的权限；不多也不少。
- 透明性
- 安全性应该对用户透明，不应让用户进行额外的不合理工作。 安全组件的管理和配置不应过于复杂和模糊。
- 响应弹性
- 恰当地设计和操作 IT 系统以限制漏洞，保持响应的弹性。
- 执行策略
- 实现可促进组织安全策略执行的流程、过程和系统。
测试原则
- 可测试性
- IT 体系结构的设计应该考虑可测试性。 测试环境将提供与测试的级别和类型相对应的生产环境的模拟。
IT 体系结构的设计不应该由于成本或复杂性妨碍生产环境的模拟。
IT 体系结构应支持能独立 进行的测试工作，而不用进行大量协调和计划。
体系结构原则侧重于两个主要区域。 它们用于治理以下方面的流程：
- 开发 体系结构。 需要使用体系结构原则指导企业体系结构的开发、维护和使用。
- 实现 体系结构。 这指要建立用于设计和开发 IT 系统的原则和相关指南。
图 2 显示了这些体系结构组件。
图 2. 体系结构组件
原则以业务目标和体系结构驱动因素（业务和设计）为基础创建，作为体系结构开发和实现的治理基础使用。 体系结构原则、所需的功能和需求全部用于进行体系结构决策之用，而此决策可反映所创建的体系结构。
体系结构既是艺术也是规程，处理的是 IT 系统的设计原则与构造及修饰。 体系结构的此定义表明结构或概念（可帮助提高体系结构可靠性和延长其寿命）是非常不错的东西。
定义体系结构原则对于开发可在整个生命周期中加以治理的成功体系结构至关重要。
每个体系结构都需要支持测定和控制属性的原则，以实现一致的使用。 如果缺少体系结构原则，则表明对什么驱动业务及其价值缺乏足够的认识，并且将会导致体系结构不完整，缺少长期价值所需的深度和广度。
学习
获得产品和技术
- 下载
IBM 产品评估版，获得来自 DB2®、Lotus®、Rational®、Tivoli®
和 WebSphere® 的应用程序开发工具和中间件产品。
讨论
