架构设计原则王青国翻译.docx
《架构设计原则王青国翻译.docx》由会员分享，可在线阅读，更多相关《架构设计原则王青国翻译.docx（23页珍藏版）》请在冰点文库上搜索。
架构设计原则王青国翻译
第23章架构原则
本章描述在企业架构开发过程中使用的原则。
23.1简介
原则是基本规则和指南，它们被设计成持久的因而很少修改。
这些原则为企业制定完成其使命的方法提供信息和支持。
因而，原则可能只是一系列结构化想法中的一个元素，这些原则组合起来从价值观到行动和结果层面定义和指导企业。
依据不同的组织，原则可以在不同领域和层面上来建立。
以下两个领域的原则在架构开发和应用中比较多：
⏹企业原则为企业中的决策提供基础，指导组织如何开始完成它的使命。
这些原则经常被用来作为协调组织中决策的一种手段。
尤其在成功的架构管控战略中，他们往往是关键成功因素（参见第50章）。
在企业原则这个比较广泛的领域，在业务或组织单元中经常有子原则。
例如，IT、HR、国内运营、国际运营等。
这些子原则为这些子领域的决策提供基础，同时指导子领域的架构开发。
必须注意，一定要确保用来指导架构开发的原则与架构能力的组织环境相匹配。
⏹架构原则是一系列与架构工作相关的原则。
它们了组织范围内的一致意见，并且使企业原则的精神和想法具体化。
架构原则控制架构过程，影响架构的开发、维护和使用。
通常一系列的原则形成层次关系，在这个层次关系中分段原则被企业原则所指导并且把企业原则细化。
架构原则被企业原则所指导和限制。
架构原则可以重申其它相关的企业指南，这些相关指南可以有效地指导架构的开发。
本节的其余篇幅将只描述企业架构原则。
23.2架构原则的特点
架构原则定义整个企业中使用和开发所有IT资源和资产过程中潜在的一般规则和指南。
他们反映了企业中各种相关元素一定程度上的一致，形成将来进行IT相关决策的基础。
每个架构原则应该清晰地关联到业务目标和关键架构驱动因素。
23.3架构原则的组成
定义一个标准的描述原则的方法非常有用。
除了一个定义描述之外，每个原则应该有相关的原因和隐含意义说明，这样不但可以促进原则容易被理解和接受，而且可以解释和证明为什么做出这样的决定从而可以支持原则被应用。
推荐的原则模板见表23-1。
原则名称
原则名称应该表达原则的本质并且容易记忆，具体的技术平台不应该出现在原则名称和描述中，避免在名称和描述中出现支持、开放、考虑、避免等模糊的词语，当使用“管理”这个词时要格外小心，不要使用不必要的形容词和副词。
原则描述
原则描述应该简明、清晰地传达基本原则，大多数情况下不同企业关于信息管理的原则描述是非常类似的。
最重要的是原则描述必须无歧义。
原则理由
架构理由必须强调遵守原则能够给企业带来的业务利益，而且必须用业务语言进行表达，指明信息架构原则、技术架构原则、业务架构原则的共同点。
描述清楚这个原则与其它原则的关系，描述在哪些情况下、哪些原则有更高的优先级和权重，以便于决策。
隐含意义
隐含意义必须从业务和IT两个角度强调执行原则的需求，例如，资源、成本、活动等。
如果采用了原则，现有的系统、标准、实践将会明显与原则不一致，采用一个原则对业务的影响和后果一定要描述清楚。
读者应该很容易地辨别出以下问题的答案,“原则将如何影响我？
”。
千万不要过分简化、轻视原则的影响。
有些隐含的影响仅仅是识别的可能影响，应该进行推测而不是完整的分析。
表23-1推荐的定义原则的格式
符合此模板的一系列架构原则在章节23.6中给出。
23.4开发架构原则
一般架构原则由企业架构师与关键涉众一起开发，由架构管理委员会批准。
如果在企业级存在更普遍的原则，那么架构原则应该参考这些原则中的信息。
架构原则必须具有很好的可追溯性、被清晰地描述，以用来指导相关决策。
架构原则用来使架构及目标架构的实现与业务战略和远景对齐。
特别地，架构原则的开发一般受到以下因素的影响：
■企业使命和规划：
企业的使命、规划和组织架构。
■企业战略动因：
企业的特点，包括优势、弱势、机会、威胁，当前企业的变更驱动因素（例如，业务流程优化、质量管理）。
■外部约束：
市场因素（上市时间规律、客户期望）；现存及潜在的法律法规。
■现有系统和技术：
企业已经部署的一系列信息系统资源，包括系统文档、设备清单、网络配置图、策略、流程等。
■暂露头角的行业趋势：
影响企业架构的关于经济、政策、技术、市场等方面的预测。
23.4.1原则的质量
仅仅有一个称为原则的书面原则描述并不意味着是好的原则，即使所有的人都认可这些描述。
一系列好的原则应该是基于组织的信仰和价值观而建立，利用业务容易理解和使用的语言进行描述。
架构原则数量不能太多，未来导向，被高层管理者赞同和支持。
架构原则为做出架构的决策和规划、制定政策框架、过程、标准提供坚实的基础，能够支撑解决相互冲突的情况。
质量较差的架构原则很快成为争论的焦点，由这些原则而形成的架构、策略、标准将呈现随意性、自我服务性，因此缺乏可信度。
从本质上讲，原则驱动行为。
鉴别好的架构原则有以下五个标准：
■易理解性：
潜在的含义能够被组织中的任何人很容易地掌握和理解。
原则的意图清新而没有二义性，因此有意和无意的违反原则的情况被最小化。
■健壮性：
促使做出关于架构的良好决策和规划，制定出可行的策略和标准。
每个原则应该足够清晰和准确，支持在复杂、有争议的情况下做出决策。
■完整性：
组织范围内每一个控制信息管理和技术的重要潜在原则都被定义。
这些原则覆盖每一种意识到可能情况。
■一致性：
严格遵守一个原则都可能需要对另一个原则的弱化。
一系列的原则必须采用可以平衡解读的方式来描述。
原则不应该相互矛盾而造成遵循一个原则会违反另一个原则的精神。
原则中的每个词都应该精心挑选从而允许一致而又灵活的解读。
■稳定性：
原则应该持久而又适应变化。
架构原则被初次批准后，应该准对增加、删除、修改制定修订流程。
23.5架构原则的应用
架构原则用来捕获关于企业如何使用和部署IT资源和资产的基本真谛。
架构原则可以有很多不同的适用方法：
1.在企业范围内提供一个开始做出关于企业架构和实现目标架构的项目的有意识的决策的框架。
2.指导建立相关的评估标准，因而可以在后期的架构遵从管理中对产品、解决方案、解决方案架构的选择产生有力影响。
3.作为定义架构功能需求的驱动因素。
4.作为评估已有实现和战略组合与已定义架构符合性的输入；这些评估将为实现架构的转换活动提供有价值的洞察力，从而支持业务目标和优先级。
5.架构原则的原因描述突出了实现符合原则的业务价值，为处理相互冲突的驱动因素和目标提供指导。
6.架构原则的隐含意义描述提供遵循原则的主要任务、资源、潜在成本的轮廓；还为将来转换驱动因素和计划行动提供有意义的输入。
7.支持架构管控活动
----为标准的架构遵从评估提供退路，这时需要对原则做出一定的解释。
----支持决定做出一个例外请求，这时某个架构修正案的隐含意义在局部的运作流程只能够无法得到解决。
架构原则是相互关联的，应该作为一个整体来应用。
架构原则有时是竞争的；例如，“可用性”、“安全”趋向于做出相互矛盾的决定。
每个原则必须在“所有其它事情同等重要”的环境下来进行考虑。
有时在特定的情况下必须做出哪个原则优先的决定。
做出这个决定的理由必须文档化进行记录。
阅读一个原则的第一反应往往是“这时明显的，不需要文档化描述”。
一个原则看起来不言而喻的实时并不意味着原则所包含的指导原则能够被遵循。
拥有看起来很明显的原则帮助确保决定实际上遵循期望的结果。
虽然在原则的定义中没有关于违反原则害处的说明，违反原则通常会造成企业运作问题并且阻碍企业实现它的使命。
23.6架构原则的例子
太多的架构原则容易削弱架构的灵活性。
很多组织选择仅仅定义高层原则，限制原则的数量在10个到20个之间。
下边的例子示例架构原则的典型内容，同时示例推荐的定义原则的格式。
23.6.1业务架构原则
原则1：
原则第一
原则描述
信息管理的这些原则适用于企业的所有组织单元（单位、部门等）。
原则理由
我们向决策者提供一致、可预测的高质量信息的唯一方法是所有组织单元都遵守这些原则。
隐含意义
■如果没有这个原则，排外主义、个人喜好、不一致等现象将迅速削弱信息管理。
■信息管理的任何提议在经过检查遵从架构原则之前都不会开始。
■信息管理提议与架构原则的冲突将通过改变提议的框架来解决。
原则2：
企业利益最大化
原则描述
信息管理的有关决定必须保证企业利益在整体上最大化。
原则理由
这个原则的含义是“服务高于自我”。
从企业层面做出的决策与在特定组织单元层面做出的决策相比具有更长远的价值。
投资收益最大化要求信息管理的决定服从企业级的驱动因素和优先级。
没有任何少数团体能够损害企业的整体利益。
然而，这个原则并不阻碍任何少数团体完成它的任务。
隐含意义
■获得企业级的最大利益需要改变我们策划和管理信息的方法。
仅靠技术并不能带了这个改变。
■有些组织可能必须牺牲他们自己的喜好换来整个企业更大的利益。
■应用系统开发的优先级必须由企业在整个企业层面来确定。
■应用组件应该跨越组织边界进行共享。
■信息管理的发起行动必须根据企业规划来实施。
每个组织应该按照企业已经建立的蓝图和优先级来实施它的信息管理发起行动。
需要时我们必须变更规划。
■当有需要的时候，我们必须调整优先级。
通过有广泛代表参加的专题研讨会来做出这些决定。
原则3：
信息管理是每个人的事情
原则描述
企业中所有需要达到业务目标的组织都应该参加信息管理决策。
原则理由
在应用技术解决业务需要的过程中，信息的用户是关键涉众或客户。
为了保证信息管理与业务对齐，企业中的所有组织必须在信息环境的各个方面积极参与。
来自企业各个组织的业务专家和负责开发和维护信息系统环境的技术员工必须组成小组一起来定义IT的目标和目的。
隐含意义
■作为一个小组的每个涉众和客户都应该在开发信息系统环境的过程中承担责任。
■为了实现这个原则必须承诺足够的资源。
原则4：
业务连续性
原则描述
即使在信息系统中断的情况下，公司的生产运行和经营管理也应该能够继续进行。
原则理由
随着信息系统的普及，公司生产运行和经营管理活动对信息系统形成一定依赖;因此，我们在系统设计、建设和应用过程中必须全面考虑系统的可靠性。
企业的工作场所必须能够保证不管发生什么意外事件，企业的业务功能都能继续运转。
硬件故障、自热灾害、数据损坏等事件都不应该扰乱企业的生产运行和经营管理活动，更不能造成这些活动中断。
企业必须建立应急信息交付机制，保证业务功能的连续性。
隐含意义
■对于依赖共享应用系统的业务，必须事先建立业务中断风险的预案并得到管理，管理措施包括但不限于定期评审、检测攻击和泄露、通过冗余或备份建立任务关键型服务来保证业务连续性。
■可恢复性、冗余性、可维护性等特性应该在设计的时候加以考虑。
■必须对应用系统的重要性和对业务的影响加以评估，进而决定需要什么样的业务连续性，需要什么样的恢复计划。
原则5：
共享应用系统
原则描述
应该开发在整个企业范围内使用的应用系统，而不是开发多个功能相似或功能重复的应用系统给特定的组织单元使用。
原则理由
重复的功能是昂贵的，并且会造成自相矛盾的、冗余的数据急剧增加。
隐含意义
■那些依赖于不是服务于整个企业的应用系统的组织单元必须改为使用服务于整个企业的应用系统。
这需要建立并坚持一定的原则。
■任何业务单元都不允许开发仅供他们自己使用的应用系统，而这些应用系统的功能与企业应用系统的功能类似或重复。
这样，花费在开发本来功能相同的应用系统上的稀缺资源消耗将大大减少。
■用来支撑企业决策的数据和信息将比以前更大程度上实现标准化。
这是因为那些产生不同数据的小规模、部门级的应用系统将被企业级应用系统所取代。
增加企业应用系统功能的动力可能来源于某个组织单元，但是由此产生的功能将变为整个企业的功能，产生的数据也将变为企业共享数据。
原则6：
面向服务
原则描述
架构基于对反映现实世界的业务活动的设计，而这些业务活动构成企业内部或跨企业的流程。
原则理由
面向服务的架构可以交付企业敏捷性，实现无边界的信息流。
隐含意义
■利用业务描述为服务定义提供背景（例如，业务流程、目标、规则、策略、服务接口、服务组件），通过服务编排实现服务。
■面向服务的架构对基础设施提出了独特的需求，其实现必须使用开放的标准来实现互操作性和位置透明性。
■服务实现是与环境密切相关的，受到环境的限制或通过环境成为可能，所以必须在特定的环境下进行描述。
■必须加强对服务定义和服务实现的管控。
■必须有检验服务是否是一个好服务的方法。
原则7：
符合法律法规
原则描述
企业的信息管理过程要符合相关的法律、法规、政策。
原则理由
企业的政策要遵守国家的法律、法规、政策，同时也要遵守国家电网公司的相关政策、规定、标准。
但是并不排除对业务流程进行改进，而这些改进可以引起政策、规定、标准的变化。
隐含意义
■企业必须牢记有关数据收集、保存、管理的法律、法规和外部的政策、规定、标准。
■在教育和规则使用方面，效率、责任、常识并不是唯一驱动力，法律、法规的变化常常引起业务流程和应用系统的变更。
原则8：
IT负责制
原则描述
IT组织负责拥有和实现IT流程和基础设施以使解决方案满足用户定义的需求，包括功能、服务水平、成本、交付时间等。
原则理由
有效地平衡期望和能力及成本，保证所有的项目都是有成本效益的。
有效且高效的解决方案有合理的费用和清晰的利益。
隐含意义
■必须建立一个确定项目优先级的流程。
■IT职能部门必须定义一个管理业务单元期望的流程。
■必须建立数据、应用、技术模型以创建高度整合而有质量的解决方案，使结果最大化。
原则9：
保护知识产权
原则描述
企业的知识产权必须得到保护。
这种保护必须在IT架构、实现和管控过程中得到体现。
原则理由
企业的大部分知识产权都驻留在IT领域。
隐含意义
■虽然知识产权保护是每个人的事情，实际上大部分知识产权保护都是在IT领域实现的。
甚至有理由相信非IT流程也能够用IT流程进行管理（电子邮件、委托日记等）。
■必须有一个管控人员和IT参与者的安全策略，以充分地改进知识产权保护。
这个策略必须能够避免折中和逃脱责任。
23.6.2数据架构原则
原则10：
数据就是资产
原则描述
数据是公司的一类有价值的无形资产，需要对其进行管理。
原则理由
数据是公司的有价值的资产，数据有真正的、可度量的价值，简单来讲数据的目的是辅助决策。
准确和及时的数据对于准确和及时的决策非常重要，数据应该像其它资产一样得到细致的管理。
因为数据是决策的基础，所以我们必须仔细地对数据进行管理，确保我们知道数据在哪里、确保数据准确、当需要的时候可以得到。
隐含意义
■数据资产化、数据共享、数据可用性是三个密切相关的数据架构原则，必须进行培训使公司范围内的所有组织单元理解它们之间的关系。
■数据管家必须有管理他们所负责数据的权利和手段。
■我们必须从“数据主人”的思维向“数据管家”的思维转变。
■数据管家的角色非常重要，因为过时的、错误的、不一致的数据可能被传递到企业的员工，从而对企业范围内的决策起到反作用。
■数据管家的重要职责之一就是管理数据以确保数据质量。
必须制定相应的程序来避免和纠正数据错误，同时还要改进那些造成数据错误的流程。
数据质量需要被测量，进而采取措施改进数据质量，也要为这些制定规程。
■应该有一个具有企业范围内广泛代表性的团体来就数据管家提议的流程变更做出决定。
■既然数据是一个有价值的资产，那么负责管理数据的数据管家必须在企业层面上进行任命。
原则11：
数据共享
原则描述
数据要能够被合理的共享访问，不能被私有化。
任何员工有权访问履行他们指责所需要的数据，因而数据应在企业中的各个组织、各个业务线上进行共享。
原则理由
及时获得准确的数据是提高企业决策的效率和质量的最基本要求。
在一个企业范围内公用的应用程序中维护及时、准确的数据并且进行共享，比在多个应用程序中维护重复的数据更节省资源和资金。
企业拥有大量的数据，但是这些数据往往存储在上百个互不兼容的烟囱数据库中，收据、创建、转换、清洗数据的速度往往是由在企业范围内高效共享这些数据的能力所驱动的。
共享的数据将提高决策水平，因为所有的决策将基于更少（最终应该是一个）的数据源，而这些数据源中的数据是更准确及时。
从计算机处理的角度来说，共享的数据将提高数据处理效率，因为已经存在的数据能够被利用而不需要重新创建实体或对数据进行重新处理。
隐含意义
■数据资产化、数据共享、数据可用性是三个密切相关的数据架构原则之一，必须进行培训使公司范围内的所有组织单元理解它们之间的关系。
■数据为了能够进行数据共享，我们必须建立和遵守关于数据管理和访问的一系列数据治理的策略、规程和标准，包括短期的和长期的。
■数据短期来讲，为了保护在遗留应用系统上的巨大投资，我们必须在那些能够迁移遗留系统中数据到共享环境的软件方面进行投资。
■数据我们必须开发标准数据模型、标准数据元素和其它定义共享环境的元数据，同时开发一个存储系统来保存这些元数据并容易被访问。
■数据从长期来讲，在遗留系统被替换掉以后，我们必须采取和执行公共数据访问策略和指南，确保新应用系统的数据能够被共享环境访问，进而共享环境的数据能够被新开发的应用系统所使用。
■数据不管是长期还是短期，我都应该采取公共的方法和工具来创建、维护、访问企业的共享数据。
■数据数据共享需要在企业文化上进行很大的变革。
■数据这个数据共享的原则将持续对数据安全的原则提出挑战，在任何情况下都不能因为共享而造成机密数据泄露或破坏。
■数据共享数据必须被所有用户使用来执行他们的日常任务，这样才能确保唯一的、准确的、及时的数据被决策所使用，共享数据将成为企业范围内的虚拟唯一数据源。
原则12：
数据是可访问的
原则描述
数据对于有权访问和利用它的用户来说必须是可用的，以便用户利用数据来执行他们的工作。
原则理由
广泛的数据访问将有助于高效的决策并提高决策的效果，同时对信息的请求进行快速响应，快速交付服务。
数据使用必须从企业全局的角度进行考虑，允许企业范围内广泛的用户访问数据，这样即可节省员工的时间又可提高数据的一致性。
隐含意义
■数据资产化、数据共享、数据可用性是三个密切相关的数据架构原则之一，必须进行培训使公司范围内的所有组织单元理解它们之间的关系。
■可访问性是指用户获得信息的容易程度。
■访问数据和展示数据的方法必须具有很强的适应性，以便满足企业范围内广大用户和他们访问方法的需求。
■数据访问不包括对数据的理解，员工必须当心不要错误地理解数据。
■数据访问不一定授权用户修改或暴露数据，需要在企业文化层次上做出改变，消除目前普遍存在的数据被业务组织拥有的观念。
原则13：
数据责任人
原则描述
每个数据元素都应该有一个责任人（受托人）对数据的质量负责。
原则理由
随着数据共享程度的提高和业务单元对共享数据的依赖，有必要让唯一的数据负责人对数据的内容做出决定。
如果数据被录入多次那么数据就会失去其完整性，数据责任人具有唯一的数据录入责任，这样就可以减少多余的人工劳动和存储资源。
注意:
数据责任者与数据管家不同—数据责任人对数据的准确性和实时性负责，而数据管家的职责更为广泛，包括数据的标准化和数据定义等任务。
隐含意义
■真正的数据责任人使数据主人的问题得以解决，使得数据对所有需要数据的人都可访问。
这就要求企业文化方面要从数据主人向数据责任人转变。
■这就要求数据责任人满足施加在数据上的质量要求。
这就要求数据责任人具备基于数据的属性使数据用户对数据质量充满信心的能力。
■必须识别数据的真正数据源以便把数据授权给数据责任人，但这并不意味着分类的数据源信息被暴露，也不意味着数据源就是数据责任人。
■从计算机信息处理角度来说，数据应该被捕获一次并且在离数据源最近处进行验证，必须应用质量控制措施来确保数据的完整性。
■随着数据在企业范围内的共享，数据责任人必须对数据的准确性、实时性负责，必须意识到数据责任人职责的重要性。
原则14：
一致的术语和数据定义
原则描述
数据要在全公司范围内有一致的定义，并且数据定义能够被所有用户获取和理解。
原则理由
应用系统开发过程中使用的数据必须在企业范围内有一致的定义，这样才能使数据能够共享。
一个统一的术语表将促进沟通和交流更加高效。
另外，还需要集成不同的应用系统以共享数据。
隐含意义
■我们很容易误认为这个问题已经得到了很好的处理，因为往往有被冠以“数据管理员”头衔的人和具有一定章程的团体。
然而，必须投入更多的精力和资源到这项任务上来，改善数据环境是成功的关键。
这个任务与数据元素定义既相关又不同，数据元素定义往往有更广泛的组织负责，这里仅指一个统一的术语表和定义。
■企业必须为业务建立一个初始的统一的术语表，这些定义将在企业范围内被一致地使用。
■当需要定义一个新的数据时，数据定义活动必须与企业的术语表定义活动相协调，一般由数据管理员进行协调。
■多个局部术语定义引起的模糊不清必须给一个企业范围内被接受和理解的统一术语定义让步。
■多个数据标准化的活动必须被协调一致。
■数据管理的职责必须被正式分配。
原则15：
数据安全
原则描述
数据要在安全等级要求下，被合理的访问、共享和发布。
数据必须被保护，避免未授权的使用和泄露。
除了按照国家的安全等级对数据保护外，还包括但不限于对未决定数据、敏感数据、数据源敏感数据、专有数据的保护。
原则理由
公司数据涉及国家安全的，要满足国家监管单位对数据安全的要求。
公司数据涉及商业机密的，要满足公司自身发展对数据安全的要求。
在开放地共享数据和根据相关规定分发数据之间必须进行平衡，限制等级保护数据、敏感数据、专有数据的访问。
为决定数据（处于工作过程中，但未授权发布）必须受到保护，防止未授权的推测、错误理解、不恰当使用。
隐含意义
■安全等级保护数据和非安全等级保护数据的聚合，都可能产生大量新的目标数据，需要对目标数据进行评审和去等级保护，以便进行适当的控制。
数据主人或业务用户必须决定数据聚集是否产生安全防护等级更高的数据，我们需要适当的策略和规程来处理这些评审和去等级保护活动。
基于应该知道的策略访问信息是有其需要进行经常进行信息内容的评审。
■目前由不同系统那个各自包含自己的数据分类的做法需要重新思考。
是否存在一个对数据进行等级保护和去等级保护的软件解决方案？
目前硬件解决方案往往是笨重、低效、昂贵的。
利用等级保护的系统来管理非等级保护的数据是非常昂贵的。
目前，合并二者的唯一方法是把非等级保护的数据存储在等级保护的系统中。
■为了更好的提供公开数据访问和保护安全数据，安全需求必须在数据层面进行识别和开发而不是仅在应用层面进行考虑。
■数据安全防护措施可以用来保护仅供查询和不许查询数据，对那些未决定数据、敏感数据、专用数据必须进行敏感性标记。
■数据安全性必须在开始的时候就设计到数据元素中，因为无法在后期进行增加。
系统、数据、技术必须进行保护，避免未授权访问和控制。
总部的数据必须进行安全防护，避免不经意的或未授权的修改、蓄意破坏、灾害、暴露。
■对于未决定数据和其它过程数据需要新的策略来管理保护期限，这是必须考虑内容的新旧程度。
23.6.3应用架构原则
原则16：
技术无关性
原则描述
应用系统应该与具体的技术选择无关，因此能够在各种技术平台上运行。
原则理由
将应用系统与底层技术相互独立，允许应用系统以更低的成本、更快的速度进行开发、升级、运行。
否则，那些不断过时、依赖厂商的技术而不是用户的需求将驱动应用系统的开发。
要认识到关于IT的任何决定
升级会员 