某公司企业架构设计原则

1 范围

本原则是公司总体架构管控技术文档的核心文档之一，适用参与信息化规划、设计、建设和运维的业务部门、二级单位和研发单位。

2 规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

3 总体架构管控原则

3.1 架构管理原则

3.1.1　统一架构原则

描述	公司统一开展总体架构规划和管控。
理由	1.统一的总体架构有利于避免信息系统的分散、异构、难以管控等问题。 2.统一的总体架构有利于业务和信息化规划的实现和落地。 3.统一的总体架构有利于优化IT治理工作。
影响	1.研发单位应按公司总体架构维护相一致的技术架构体系。 2.根据公司业务和信息化战略，综合短期成果和长期影响，定期开展总体架构维护。 3.统筹安排、集中管理总体架构规划。

3.1.2　统一管控原则

描述	推动业务与信息化融合，实现柔性、完整的总体架构落地。
理由	1.推动总体架构在全公司的整体运用、决策制定、全面指导和质量保障。 2.推动跨业务领域的信息技术共享和应用。 3.强化业务部门与信息部门间的协作。 4.推动业务部门与信息部的互动，实现完整、迅速的总体架构落地。
影响	1.推动业务目标与系统架构设计相一致。 2.推动架构设计过程的有效沟通。 3.运用架构管控流程，规范化架构评审和资产维护过程。 4.明确架构管控组织的管理角色和职责。 5.制定架构评估指标，定期检查架构执行效率、遵从度和一致性。 6.构建架构资产，支撑架构决策和评审的执行。

3.1.3　架构遵从原则

描述	推动系统架构的分级评审，保证系统架构设计与总体架构规范相一致。
理由	1.对所有新建和在建项目进行系统架构评审，保证设计与总体架构一致。 2.对所有已建应用完善或重建项目进行系统架构评审，保证设计与总体架构一致。 3.提升系统架构的业务符合性、设计标准性、架构一致性和技术完备性。
影响	1.建立系统架构评审流程，保证系统建设与总体架构一致。 2.推动项目管控与架构评审的高效整合，提升系统架构设计质量。

3.1.4　架构收敛原则

描述	为保持技术方案的灵活性和健壮性，对同一类业务或技术场景，总体架构可提供多个备选技术方案。
理由	1.在总体架构中，减少支撑同一类场景的备选技术方案的数量至两个或一个，以降低架构管控的复杂性和技术多样性。 2.选择实施难度小、复杂性低、非功能性约束低的技术方案作为推荐技术方案。
影响	有效控制总体架构的灵活性，备选方案收敛性直接影响信息化成本的变化。

3.1.5　融合共享原则

描述	以业务和信息化发展战略为导向，推动业务应用的融合集成。
理由	1.避免冗余系统林立，降低信息化运维成本。 2.推动业务应用的深度集成，为智能分析决策奠定基础。 3.避免在信息化建设中新建数据或应用孤岛。 4.避免业务应用的重复建设。
影响	1.由公司全局着眼，考虑业务应用的融合集成。 2.形成一套公司标准化的应用集成设计方法。 3.建立配套的流程和数据管控机制，以降低由企业级应用集成而产生的流程和数据管理复杂性。 4.构建企业级的共享应用群和组件库。

3.1.6　服务架构原则

描述	利用SOA概念设计业务服务和IT服务。
原因	1.通过业界标准促进业务和IT的融合。 2.需要通过灵活、可重用和标准化的IT架构支撑业务的快速变化。 3.需要先进的设计理念。
影响	1.由公司全局着眼，考虑业务应用的融合集成。 2.形成一套公司标准化的应用集成设计方法。 3.建立配套的流程和数据管控机制，以降低由企业级应用集成而产生的流程和数据管理复杂性。 4.构建企业级的共享应用群和组件库。

3.2 业务架构原则

3.2.1　战略契合原则

描述	业务架构设计应与企业发展战略相契合
理由	1.业务架构涵盖的业务能力应有效推进企业战略发展。 2.避免与企业战略发展相悖的业务能力出现在业务架构中。
影响	1.业务架构指导了应用架构的建设，应确保信息化建设方向与企业战略目标一致。 2.信息化建设的优先级顺序收到企业战略发展影响，需要在业务架构中有所体现。

3.2.2　流程重构原则

描述	业务流程重构先行。
理由	1.不建议对陈旧、无效的业务流程进行信息化改造。 2.业务流程按效率最优的原则进行优化和重组。 3.业务流程重构以降低全面拥有成本为目标。
影响	1.业务部门与系统建设方应就优化后的业务流程达成共识。 2.业务流程重构与新技术应用并举。 3.业务流程重构应与业务目标保持一致。 4.组织架构变更将触发业务流程重组及业务架构调整。

3.2.3　业务连续原则

描述	公司的生产运行和经营管理不受信息系统建设影响。
理由	1.随着公司信息化的进一步普及，公司生产运行和经营管理活动对信息系统形成一定依赖。系统设计、建设和应用过程中必须全面考虑系统可靠性。 2.建立无信息系统干预的业务运行预案，确保极端情况下的公司业务连续性。 3.建立健壮的一体化信息平台，支撑业务活动的连续运行能力，避免系统硬件故障、自然灾害、数据损坏等问题的影响。
影响	1.建立信息化风险管理机制，预防和管理信息系统故障可能造成的业务中断。 2.系统架构设计应考虑并解决技术方案的可复原性、冗余性和可维护性等要求。

3.2.4　业务合规原则

描述	所有的业务规则和流程需要遵从公司和政府的相关政策、标准及法规。
理由	1.如果在应用系统中实施了有缺陷的业务规则及流程，会造成财务或实物资产的损失、及对公司声誉的伤害。 2.需要遵从政府的法规和行业标准。
影响	1.业务规则和流程的整体设计，需要法律及相关部门的审核和批准。 2业务规则和流程的变更，在应用到信息系统之前，需要法律及相关部门的审核和批准。

3.3　应用架构原则

3.3.1　统一设计原则

描述	业务应用采用统一设计，避免重复建设。
理由	1.企业级应用建设需保证科学重用。 2.架构设计中避免重复设计、冗余应用。 3.设计冗余将引致高昂的信息化成本。 4.设计冗余将带来数据冲突，增加集成复杂度。
影响	1.不建议对相似的企业级业务能力进行重复建设。 2.标准化企业级的数据和信息。

3.3.2　功能重用原则

描述	新建应用重用已有应用功能。
理由	1.深化套装软件方案的实用性和可用性。 2.选用已经验证或测试的应用方案。
影响	1.带来明显商业优势与成本节省。 2.需要经过评估来决定是新建还是购买新应用。

3.3.3　应用柔性原则

描述	应用设计具备充分柔性。
理由	1.通过业务应用系统升级，灵活适应业务需求以及合理的需求变更。 2.适应业务流程优化调整。 3.业务应用系统灵活适应信息技术变更。 4.在降低业务流程重建风险的同时，实现业务应用的便捷、快速集成。
影响	1.初期投入相对较大。 2.系统设计周期加长。 3.系统生命期延长。

3.3.4　应用安全性原则

描述	保证应用系统的完整性、保密性以及安全性。
理由	1.避免公司的财务资产,、实物资产、声誉以及客户关系, 因为应用系统或数据的不当使用, 而带来损失和伤害。 2.应用系统和数据的访问需要采取授权机制。
影响	1.需要制定统一的访问控制机制并取得共识。 2各种不同的应用系统，需要实施统一的管理和标准化的访问控制机制。 3.中标的成熟套装软件及相关功能模块也需要遵循已定义好的安全标准。

3.4　数据架构原则

3.4.1　数据资产化原则

描述	数据是公司的一类有价值的无形资产，需要对其进行统一的管理。
理由	1.数据是支撑公司业务正常运转以及战略决策科学制定的重要保障。 2.对数据的充分利用能够实现公司价值的提升。
影响	1.将数据上升为公司无形资产的高度，在全公司范围内统一认识。。 2.加强对公司数据的管理与管控，挖掘公司数据的潜在价值。

3.4.2　数据共享原则

描述	数据要能够被合理的访问，不能被私有化。
理由	1.数据共享能够支撑公司内部广泛的业务协同。 2.数据共享是提高决策质量和效率的基础。 3.明确数据唯一来源，减少数据冗余，能够有效降低运维成本。 4.公司数据的收集、生成、转换、汇总等处理速度取决于各部门数据的共享程度。
影响	1.基于短期和长期的考虑，建立数据共享的策略、机制、流程、标准等。 2.建立全局数据模型，梳理数据资产，加强元数据管理，构建数据共享环境。 3.限制对孤立的遗留系统投资，制定遗留系统的退役或迁移策略。 4.数据共享需要全公司认识上的转变。 5.数据共享要与数据安全相统一。

3.4.3　数据可用性原则

描述	数据对于有权访问和利用它的用户来说必须是可用的。可用性主要体现在可获取和可利用两个方面。
理由	易获取、高质量的数据能够支撑公司内部广泛的业务协同，是提高公司决策质量和效率的重要保障。
影响	1.数据的访问和展示方式要能够充分满足公司各级单位、部门的需求。 2.提高公司对数据质量的重视程度，开展有效的数据治理。

3.4.4　数据认责原则

描述	对数据要指定权威的数据拥有者、质量责任者、日常管理维护者等角色。
理由	1.数据认责机制是数据资产有效管理的基础。 2.通过数据认责能够提高公司各部门对数据管理的参与度，更好的满足各部门对数据的需求。
影响	1.数据认责需要公司各部门的共同参与，并在公司各部门间达成一致。 2.要建立数据质量的度量方法，形成科学的考核体系，推进数据认责的有效落实。

3.4.5　数据标准化原则

描述	数据要在全公司范围内有一致的定义，并且数据定义能够被所有用户获取和理解。
理由	1.数据的标准化是数据共享的基础。 2.一些项目的解决方案需要有统一的数据定义。 3.通用的数据定义能够实现有效的沟通和对话。 4.统一的数据定义是快速改善公司数据环境的有效途径。
影响	1.建立通用的业务术语表，业务定义要在全公司范围内一致。 2.在数据定义过程中，要引用术语表中的术语，以保证数据含义在全公司被有效的理解，不产生歧义。 3.建立数据定义的仲裁机制，以协调不同部门对数据理解的差异和冲突。 4.建立数据标准体系，对多种数据标准进行协调和统一。 5.指定数据标准的责任者。

3.4.6　数据安全性原则

描述	数据要在安全等级要求下，被合理的访问、共享和发布。
理由	1.公司数据涉及国家安全，要满足国家监管单位对数据安全的要求。 2.公司数据涉及商业机密，要求满足公司自身发展对数据安全的要求。 3.数据安全是公司信息安全的重要组成部分，应统一管理。
影响	1.制定数据安全管理策略，划分数据安全等级，不同安全等级应采用不同的安全访问策略及授权访问机制。 2.在数据定义阶段就要明确对数据安全级别的限定。

3.5　技术架构原则

3.5.1　标准化原则

描述	将技术多样性降低到最小化，降低建设和运维成本。
理由	1.技术多样性往往需要不同的基础架构，从而导致更高的建设和运维费用。通过公司整体范围内的技术统一能够有效降低整体建设成本和运行管理成本。 2.限制技术多样性带来的业务优势主要有：标准化应用组合；更好预测新技术带来的风险和影响，以适应技术进步。
影响	1.需要据此制定信息化建设策略、标准规范。 2.执行统一的技术生命周期管理，统一技术选型和采购。 3.建立技术架构蓝图，适时保持更新。 4.只在新技术能够明显证明有利于提升业务价值和改善运营效率的情况下才决定引入。

3.5.2　互操作原则

描述	推动硬件、软件的标准化，提升数据、应用、技术的互操作能力。
理由	1.有助于保持一致性，改善运行效率，提高用户满意度，保护现有IT投资。 2.有利于选择信息化供应商，促进供应链整合。
影响	1.建立目标架构设计规范，并保持适时更新。 2.建立集成设计规范，并保持适时更新。 3.建设统一的集成平台、开发平台等应用支撑平台。

3.5.3　快速响应原则

描述	技术架构的设计应能快速支持业务规则及流程变革。
理由	1.提高响应业务需求变化的灵活性。 2.减少应用系统变更的成本。 3.通过实施参数化的可灵活配置的业务规则及流程，降低开发成本。
影响	1.设计应用系统时，应支持业务规则及流程的外部配置参数化。 2.需要定义参数化的可灵活配置的业务规则及访问方式。 3.可灵活配置的业务规则及可重用的基本服务将增加应用系统的前期开发成本。 4.根据附加的非功能性需求来选择成熟解决方案。

3.5.4　服务等级原则

描述	技术架构应能根据服务等级协议提供各种服务，满足业务需求。
理由	提供可靠的、可重用的，以及可灵活配置的各项服务，能够实现最佳客户服务的业务目标。
影响	1.需要与相关部门一起，根据客户确定的系统性能指标，确定服务等级协议的范围并取得认可。 2.需要根据各种业务需求制定并认可各种非功能性需求。 3.应用系统和支撑体系架构在设计时必须要满足非功能性需求。 4.满足特定的服务等级协议可能需要特定的硬件，软件及设计费用。 5.对不支持性能升级的第三方产品要谨慎采用。

3.5.5　灾备原则

描述	技术架构设计时要充分考虑业务连续性需求。
原因	当灾难发生时，信息技术要支持业务的持续运作。
影响	制定灾备策略、计划和预案。