企业架构的数字化转型

第5章企业IT架构 业务的开展依赖IT系统的支持，而IT系统的需求也来自业务。如何使业务与IT的关系协调一致一直是企业管理者关注的问题。业务与IT的关系是相互支持和相互促进的。IT架构（EITAXE"EITA"）是企业建立IT系统的基础，它会指导IT发展方向和项目的开展。企业的IT架构能够帮助企业解决以下问题：  IT如何支持业务发展？  IT项目开发的理由，如何实现IT的投资回报？  企业的技术如何发展？为什么采用某个技术/产品，谁决定和决定的依据是什么?  如何对股东和企业管理层展示IT的价值，并持续得到支持和投资？ 企业IT架构的组成部分如图5.1所示，每个部分详细的内容会在后续章节中介绍。 图5.1企业IT架构的组成部分 IT架构XE"IT架构"设计工作主要由IT架构师完成。IT架构师XE"IT架构师"的工作涉及解决业务问题的IT系统架构和方案，可以包括应用系统、接口、数据、软硬件平台等。架构师负责企业级的IT架构，在具体的项目中只在开始时参与方案审核，做出架构方面的*终决策。在系统开发过程中，架构师会指导开发队伍解决技术问题，但是不参与具体的开发工作。〖1〗〖2〗企业架构的数字化转型第5章企业IT架构〖2〗IT架构设计时需要明确设计对象所处的环境，也称为系统上下文XE"系统上下文"（system contextXE"SystemContext"）。如果是一个很小的系统，只要简单的架构和建模，简单的工具设计；反之则需要很多的工具、分析、设计和方法。常见的设计环境有系统中的某个组件、企业的某个系统、行业中的某个企业、经济体系中的某个行业等。 5.1应用架构 业务架构是企业架构的基础，描述企业战略、业务流程、组织、治理间的结构和交互关系，明确人员、资金、IT、服务等企业资源如何进行部署和分配。考虑到使用SOA风格落地企业架构，在业务架构中识别业务服务和得到业务服务规格说明后，需要将服务进行实现。业务服务通过应用架构中的应用服务组件实现，而应用服务组件进行逻辑组合后，就成了应用中的功能组件/模块。 简单来说，业务组件拆解以后是更细的业务能力；而业务流程拆解以后是更细的业务活动或子流程，这些活动或子流程被识别成服务。实际上，低层级活动是业务流程和业务组件共有的东西，即组件内部的业务活动就是组装流程的零件。这些“零件”的能力或活动*终是运行在应用系统的功能模块上的（当然，中间会通过将业务功能抽象成服务进行），各功能模块可以访问相关的底层数据源。一个功能模块可以对应多个流程/活动。 应用架构的主要内容是用于实现业务服务（如应用服务组件、模块、子系统等）的，还包括应用架构蓝图、子系统规划、应用开发框架等。SOA对业务服务和实现服务的应用系统进行了剥离。在完美情况下，任何组合应用的构建过程就是对服务进行编排和分组的过程，体现“厚平台、薄应用”。在现实中，企业很大一部分服务都要直接依靠现有应用系统提供支持，有些应用功能难以服务化。服务通过应用服务组件实现，应用服务组件可由原有应用直接支持，或对原有系统的功能组件进行封装，或者完全重新开发、购买等。 5.1.1应用架构设计 应用架构的设计需要考虑的输入有企业应用原则、行业*佳实践、业务用例、非功能性需求、系统范围（系统上下文XE"系统上下文"）、现有系统情况等。应用系统架构图是描述企业现有或者未来概念应用架构的主要方式，它展示了企业应用系统的组成部分和它们之间的关系，如子系统、组件、中间件、数据库、外部系统等，描述了企业应用系统高层次的原则。当系统现有和未来架构差距较大、改造的周期较长的时候，还会设计不同阶段的过渡方案应用架构图。 根据系统的范围和复杂程度不同，系统架构图的表现形式也不同。对于简单的系统或者部门级的系统，一张图就可以表达清楚全部系统。但是，对于企业级和功能复杂的系统，一般要分为概念架构图和逻辑架构图两个层次，才能清楚地描述众多的系统和组件。概念架构XE"概念架构"（conceptual architecute）是业务和IT人员都能理解的把所有系统同时展示出来的架构图；逻辑架构XE"逻辑架构"（logical architecute）使用图表和文字描述相结合，更加详细地说明子系统和组件的功能和使用情况。不同的业务线条之间、总部与分支机构之间，如果业务的差别很大，则需要分别设计应用架构，而无法在一张图上描述出来。图5.2是应用架构设计框架，包括应用层、应用系统层、应用开发层。 图5.2应用架构设计框架 应用架构（EAA）XE"应用架构"是企业IT系统的蓝图，可以指导具体解决方案的制订、系统的开发和部署。图5.3以银行业为例，分客户、表现层、应用层、集成层、数据层展示一个企业IT系统的各个组成部分。在一张图中定义了企业全部的系统和数据库，并说明了它们之间的关联关系。 应用架构的目的是建立企业的业务架构和数据架构与具体的IT应用系统之间的关联关系。应用架构不是某个系统的设计或者需求的分析，而是定义企业向业务部门提供的整体的IT应用系统和功能。简言之，应用系统的功能就是对企业数据的管理和使用，包括数据的录入、编辑修改、排序、汇总、分析等操作。应用系统的目的是提供随时随地的、方便的和低成本的数据的存储和使用，并且根据业务的发展提供更多的功能和处理能力。应用系统是指用户使用完成企业业务处理流程的系统；而操作系统等属于技术架构的范畴。应用架构在IT架构中起了核心的作用，它能够连接业务架构中的流程、组件、功能、人员，也能够连接数据架构中的数据的管理和使用，还能够提出对技术架构和IT基础设施的要求。所以，制定一个完整全面的应用架构对于IT系统建设很重要。 从另一个方面考虑，应用架构是一个全企业的单一视图，规划定义IT系统和它们之间的接口和集成方式，可以避免各个部门从自己角度出发，建立很多烟道式的、重复的、难于共享的应用系统。万物皆“服务”，以服务为中心的现代应用架构可以解决企业目前在开发和系统集成过程中面临的很多问题。 应用架构设计的时候，首先要考虑在企业内部通用的需求，设计具有广泛适用性的架构。建立企业跨部门通用的系统，可以*大限度地降低开发和运营成本，也有利于数据的共享，但是也难以避免不同业务线条之间的差异化需要，需要开发特殊的功能，或者数据独立存储。但是，如果应用架构设计的灵活性高，就会更大限度地支持不同部门的需求，从而提高共享的程度。图5.4展示了不同情况下系统功能和数据共享的4种程度。 图5.4应用架构的灵活性决定了在企业内的适用范围 应用架构规划这里存在大变化，即进一步强化平台+应用的构建思想。同时，对于应用层，又体现了一个关键的概念，即业务中台的构建。 应用设计原则举例  A1 应用分层原则  应用系统层次划分为接入渠道层、服务整合层、业务处理层、企业应用层、基础服务层  复杂的业务逻辑（核保、核赔）与业务处理分离，利用规则引擎实现业务规则的处理和管理 ……  A2 应用共享原则  ECIF是企业唯一的客户主数据源，各个应用系统通过ESB链接ECIF获得和存储客户信息  跨系统的业务流程（长流程）、以审批为主的系统等可以采用BPM流程开发平台建设，提供开发效率和系统灵活性 ……  A3 应用独立实现部署原则  A4 应用扩展原则  A5 应用标准化原则 设计和开发规范  应用架构设计规范  模块设计规范  服务设计规范  接口设计规范  组件设计规范  Java开发规范  界面开发规范  PLSQL开发规范  CSS开发规范  ESB开发相关规范  系统安全开发手册