企业架构研究总结(7)——联邦企业架构之FEAF的出现和构成(下)
基于前述关于FEAF第一粒度层次的描述,在第二粒度层次中原来模型中的架构驱动力、当前架构、目标架构以及架构模型的内容被进一步从业务和设计两个方面进行了细化:
FEAF第二层粒度示意图
在第二粒度层次的细化中,业务方面代表着企业业务能力方面的内容,而设计方面则代表用于实现企业业务能力的技术方面的内容:
- 架构驱动力细化为业务驱动力和设计驱动力两个方面:
- 业务驱动力代表着联邦政府的核心业务需求,例如公众访问需求、Clinger-Cohen法案对架构开发的要求、其他新法案要求电子化访问或者电子签名的使用,以及关于政府行为的各种创新。
- 设计驱动力代表用于实现联邦政府业务需求的各种革新方法,例如使用Internet。
- 当前架构的内容也被从业务和设计两个层面进行了划分:
- 当前架构的业务层面代表了在当前技术能力支持下企业目前的业务需求。
- 当前架构的设计层面代表了用于实现当前业务需求的数据、应用和技术方面的内容。
- 目标架构的内容也被从业务和设计两个层面进行了划分:
- 目标架构的业务层面代表了在未来技术能力支持下的企业未来的业务需求。
- 目标架构的设计层面代表了用于支持未来业务需求的数据、应用和技术方面的内容。
- 架构模型包含了用于描述架构内容的各种架构制品。在第二粒度层次的细化中,架构模型的内容也被分为业务模型和设计模型:
- 业务模型为在架构驱动力推动下出现的各种业务需求进行建模。
- 设计模型为支持业务需求而必须的数据、应用和技术进行建模。
接下来,FEAF采用了第三粒度层次对企业架构的开发和维护过程模型进行了最后一个层次的细化。经过这个层次的细化,FEAF表现如下:
FEAF第三层粒度示意图
在第三粒度层次的细化中,组成FEAF模型的各个组件作了如下的扩展:
- 在上个层次中的当前设计架构被细化为当前的数据架构、应用架构以及技术架构。
- 数据架构定义了用来支持业务各种数据,以及他们之间的关系。
- 应用架构定义了用来管理数据并支持业务功能的各个应用。
- 技术架构定义了用于为管理数据和支持业务功能的各个应用提供支持的各种技术。
- 与当前设计架构的细化类似,目标设计架构也被细化为数据架构、应用架构以及技术架构。
- 在上个层次中的架构设计模型被细化为数据模型、应用模型和技术模型,他们分别为数据、应用和技术架构的描述提供了更加详细的描述方式。
- 在这个层次中每个架构片段对应联邦政府中的一个主要业务领域。一个架构片段的选择和定义需要与框架以及加载到联邦企业架构资源库中的模型、架构信息相符合。一个架构片段也可以看作为一个事件驱动的流程,它贯穿联邦组织机构,并拥有足以使其被纳入到联邦企业架构中的投资回报率(ROI,return-on-investment)。
- 过渡过程的内容也被进一步细化和明确,包括且不限于如下几个过程:
- 资金IT投资规划和决策制定(Capital IT Investment Planning and Decision Making):根据筹资预测、投资回报率和成本效益等判定条件来评估投资是否值得为其编制预算。
- 投资管理审查(Investment Management Review):为投资审查决策过程提供架构信息。
- 片段协调(Segment Coordination):协调片段架构与联邦企业架构的整合,同时配置管理和工程变更控制过程也必须到位。
- 市场调研(Market Research):执行一个周期性的市场搜索和分析,用以寻找先进的且具有潜在收益的技术。
- 资产管理(Asset Management):管理所有基于联邦企业架构的基础设施资产。
- 采购实践(Procurement Practices):使采购活动与架构以及其他过渡过程相同步。
- 架构治理(Architecture Governance):协调架构建设和维护过程中的种种活动,从而避免工作的混乱、误解和返工。
- 标准的内容也被进一步细化和明确,包括且不限于如下几种标准:
- 安全标准(Security Standards):包括所有方面都必须遵循的各种安全准则。这不仅包括信息技术方面的各种安全方针,还包括在业务领域也需要遵循的各种安全准则。
- 数据标准(Data Standard):用于描述数据、元数据以及他们之间关系的各项准则。
- 应用标准(Applications Standards):应用于各种应用软件上的各项原则和标准。
- 技术标准(Technology Standards):应用于各种操作系统、平台以及硬件系统等信息技术基础设施上的各项标准。
与上面的三个细化粒度不同,FEAF在最后一个粒度层次的细化中仅是针对架构模型的内容来进行的。在这个细化层次中,FEAF通过借鉴Zachman框架的内容将架构模型的内容进一步细分如下:
视角 |
数据架构 |
应用架构 |
技术架构 |
|
|
规划者 (目标和范围) |
业务对象列表 |
业务流程列表 |
业务地点列表 |
业务架构模型 |
|
拥有者 (企业模型) |
语义模型 |
业务流程模型 |
业务物流系统 |
||
设计师 (信息系统模型) |
逻辑数据模型 |
应用架构 |
系统空间部署架构 |
设计架构模型 |
|
建造者 (技术模型) |
物理数据模型 |
系统设计 |
技术架构 |
||
分包商 (详细规范说明) |
数据定义、字典 |
执行方案 |
网络架构 |
||
|
数据架构模型 |
应用架构模型 |
技术架构模型 |
与Zachman框架不太一样,FEAF只采用了Zachman框架中的前三列的内容,将在第三个层次中细化出来的业务架构模型、数据架构模型、应用架构模型和技术架构模型分别按照不同参与者的视角进行了更加详细定义。在上面的架构模型定义表格中:
- 业务架构模型被进一步细化,包括了规划者视角下的业务对象列表、业务流程列表、业务地点列表,以及拥有者视角下的语义模型、业务流程模型和业务物流系统。
- 数据架构模型的内容被细化为逻辑数据模型、物理数据模型,以及数据定义和字典。
- 应用架构模型的内容被细化为应用架构、系统设计和执行方案。
- 技术架构模型的内容被细化为系统空间部署架构、技术架构和网络架构。
由此可见,作为用于描述组织核心任务的业务架构模型,其主要关注者就是承担规划者和业务拥有者角色各个干系人,他们所关注的范围包含了数据、应用和技术等所有方面,只不过相对于下面用于支持业务的参与者来说,他们对于这三方面的描述角度是站在业务相关的立场上的,因而业务架构模型与从属于设计架构模型的数据、应用和技术架构模型并不是一个平行的层次关系,而是不同角色的干系人针对相同事物在不同角度的所看到的不同视图。相对于业务架构模型与设计架构模型这两者根据视角的不同而采取的水平划分方法,对于设计架构模型的细化采取的就是垂直划分了,即从数据、应用和技术这三个方面对设计架构模型进行划分,并且在每个划分出来的模型区域中又根据设计师、建造者以及分包商所具备的视角分别制定更加详细的模型制品。
除了对架构模型内容的细化,FEAF还通过借鉴企业架构规划技术(EAP,Enterprise Architecture Planning)为业务架构模型的建立提供了方法。企业架构规划是指为利用信息支持业务而定义架构的过程,以及用来实现这些架构的规划。(原文:EAP is the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures)。EAP可以看作是关于数据、应用和技术的一张高层次(业务和管理视角)蓝图,并借此保证他们之间的协调发展(alignment)。具体到FEAF,EAP为上面的FEAF架构模型中的业务架构模型(第一和第二行内容)提供了一套实现方法。在CIO委员会的FEAF文档中,EAP的作用表现如下:
EAP在架构模型中的作用
与Zachman框架将关注点放在架构内容描述上不一样,EAP所关心的是对信息技术与业务的相互校准过程进行规划和管理,因而EAP所采用的是不同于具体设计和实现的高层次的视角。