当前位置:智慧城市产业动态 → 正文

谈联邦企业架构对智慧城市顶层设计的借鉴意义

责任编辑:zsheng |来源:企业网D1Net  2018-06-20 20:19:34 本文摘自:人月神话博客

2002年2月,OMB成立了FEA项目管理办公室(FEA-PMO),开始着手开发一个综合的、业务驱动的政府蓝图,即联邦企业架构(FEA)。FEA是为了帮助政府管理层制定有效的决策,并允许他们在跨机构之间增加合作以及资源共享的机会。FEA由一套相互关联的参考模型组成,用来进行跨机构业务分析,识别机构内部或跨机构的重复投资、差距和机会。这些参考模型共同组成一个框架,用共同的和一致的方式来描述FEA的重要元素。在这里只谈些FEA架构本身的特性和可以借鉴和思考的一些关键点。

 

\

 

PRM-绩效参考模型

任何顶层设计都必须要先定目标和绩效度量框架,这是知道后续顶层架构设计和实施的基础,首先是目标和方向不能错。IT规划和建设的最终目标是为业务和绩效目标服务的,在后续的各个分解架构设计和模型中,都必须时刻的意识到和最终目标和绩效的匹配。随时考虑到我们当前有哪些输入?我们需要得到什么样的结果?我们最终规划和建设的内容是否能够满足当初的各项性能指标。

在TOGAF里面同样谈业务目标和架构愿景,但是在FEA架构中可以看到进一步对性能评估指标的量化,定量的分析和评估。首先是根据绩效目标细化和量化性能评估指标,然后是分析需要什么样的业务活动和功能来支撑这些绩效目标(BRM),再来考虑这些业务功能应该如何划分为高内聚的服务构建提供这种能力和服务(SRM),接着再考虑这些服务构建应该通过什么样的技术模型来实现和集成。这就是PRM驱动的简单完整思路。

BRM-业务参考模型

因为FEA本身就是联邦政府部门退出的企业架构模型,因此BRM对当前智慧城市顶层业务设计和业务架构有相当大的参考作用。其本身已经有初步的对于政府部门的业务参考架构。如分为4个业务领域(公民服务,交付模式,支持交付的服务,政府资源管理),39个对内对外业务线,153个业务子功能。

可以简单来理解下业务架构的分层,首先是需要对公众提供什么样的服务?其次是我需要构建哪些资源或如何筹资才能提供这个服务?再次是在这个过程中需要有哪些支撑配合的业务或规范流程?最终是作为政府部门的内勤应该如何更好的管理。从这个概念上可看到前两者是核心价值链,后两者是辅助作用。

前面在谈智慧城市核心业务的时候一般分为政务和公共管理,民生服务,智慧产业等几个部分。从BRM业务参考模型来看核心就是公民服务,其它都是围绕公民服务的支撑内容。

对于BRM有点类似于TOGAF中的业务架构,但是BRM更加强调了在构建业务架构中的分层,首先强调的是业务线和业务功能,而非业务部门或组织。这也是我们常说的业务架构建模的一个重点。在BRM中我们仍然只看到了静态的业务架构,没有看到动态的业务流程建模和分析,暂不清楚是否有这块的内容。

SRM-服务组件模型

 

\

 

首先可以看到这里谈的服务构件的概念,已经和SOA我们经常谈到的业务组件化,组件能力化的思路很类似了。上图可以清晰的看到我们整个分析思路就是先理顺业务目标和业务线,业务功能。再来考虑应该用什么样的服务构件来支撑相应的业务。

一个构件可以定义为“一个自包含的业务过程或服务;这个过程和服务具有预定的、可以通过一个业务或技术接口发挥作用的功能。业务构件代表一个自组织业务概念或过程的实现。它包括所有必要的技术元素(如,软件,硬件,数据)以表述、实现和部署一个给定的业务概念为一个大型信息系统的自组织、可重用的元素。这是整个开发生命周期和分布层次中统一的概念。

SRM分了7个服务域,每个服务域下还有具体的服务类型和详细的服务构建。在这里已经和我们在SOA规划分析中的SOA服务目录库的概念很类似了。启用SRM这一层一个核心就是真正实现BRM和TRM之间的一种松耦合。同时SRM对于服务的分层和分类并没有完全照搬BRM业务参考架构分离,而是进一步按照业务高内聚的思想识别和分解为不同的服务构件提供能力。最终再进行业务功能和服务构件之间的映射。

构件的有效识别、集成和使用,使得集成服务在部门和政府间共享。这些服务提供业务过程的功能和执行,它们支撑着BRM的子功能。服务构件的聚集可以快速构造和实现构件以支持一个给定的启动项目或投资。(这段也可以看到完全的SOA思想体现)

再次强调,在BRM清楚后,应该分解为哪些服务构件,每个服务构件应该提供哪些能力和服务,才能够满足业务目标和跨构件的业务协同,这是业务架构层面必须要重点考虑的问题质之一。

TRM-技术参考模型

 

\

 

很好的一个图,再次体现了服务构建的承上启下的作用。对内来说收集和聚合能力,对外来说提供粗粒度的服务。对外是服务访问和交付,对内是服务接口和集成。内部是服务平台,技术架构和框架。内部的能力必须要通过服务构件进行访问或聚合。既实现内部和外部的松耦合,也实现内部和外部的隔离。

在这里的服务平台要注意到两个层次的含义。一个是服务构件的开发平台,一个是服务构件提供的服务接口的统一管理和集成平台。前者和标准的应用开发技术架构相关,后者与集成平台或ESB相关。在FEA的技术参考架构里面强调的是数据交换和数据集成,强调是接口。在SOA参考架构下可以转换为服务共享和能力开放,同时提供数据,业务,技术各个维度的开放能力。

DRM-数据和信息参考模型

同传统的数据架构的分析和方法类似,同时也看到在FEA里面也强调的是在数据模型和元数据定义清楚后,重点分析的是数据交换和接口。这个我们我们现在建立数据开放能力平台的思路已经不吻合。在新的智慧城市顶层架构设计下要意识到,对于数据,特别是基础MDM主数据和共享数据,需要建立的是共享数据中心并提供数据开放能力和服务。

关键字:设计智慧城市架构企业

本文摘自:人月神话博客

x 谈联邦企业架构对智慧城市顶层设计的借鉴意义 扫一扫
分享本文到朋友圈
当前位置:智慧城市产业动态 → 正文

谈联邦企业架构对智慧城市顶层设计的借鉴意义

责任编辑:zsheng |来源:企业网D1Net  2018-06-20 20:19:34 本文摘自:人月神话博客

2002年2月,OMB成立了FEA项目管理办公室(FEA-PMO),开始着手开发一个综合的、业务驱动的政府蓝图,即联邦企业架构(FEA)。FEA是为了帮助政府管理层制定有效的决策,并允许他们在跨机构之间增加合作以及资源共享的机会。FEA由一套相互关联的参考模型组成,用来进行跨机构业务分析,识别机构内部或跨机构的重复投资、差距和机会。这些参考模型共同组成一个框架,用共同的和一致的方式来描述FEA的重要元素。在这里只谈些FEA架构本身的特性和可以借鉴和思考的一些关键点。

 

\

 

PRM-绩效参考模型

任何顶层设计都必须要先定目标和绩效度量框架,这是知道后续顶层架构设计和实施的基础,首先是目标和方向不能错。IT规划和建设的最终目标是为业务和绩效目标服务的,在后续的各个分解架构设计和模型中,都必须时刻的意识到和最终目标和绩效的匹配。随时考虑到我们当前有哪些输入?我们需要得到什么样的结果?我们最终规划和建设的内容是否能够满足当初的各项性能指标。

在TOGAF里面同样谈业务目标和架构愿景,但是在FEA架构中可以看到进一步对性能评估指标的量化,定量的分析和评估。首先是根据绩效目标细化和量化性能评估指标,然后是分析需要什么样的业务活动和功能来支撑这些绩效目标(BRM),再来考虑这些业务功能应该如何划分为高内聚的服务构建提供这种能力和服务(SRM),接着再考虑这些服务构建应该通过什么样的技术模型来实现和集成。这就是PRM驱动的简单完整思路。

BRM-业务参考模型

因为FEA本身就是联邦政府部门退出的企业架构模型,因此BRM对当前智慧城市顶层业务设计和业务架构有相当大的参考作用。其本身已经有初步的对于政府部门的业务参考架构。如分为4个业务领域(公民服务,交付模式,支持交付的服务,政府资源管理),39个对内对外业务线,153个业务子功能。

可以简单来理解下业务架构的分层,首先是需要对公众提供什么样的服务?其次是我需要构建哪些资源或如何筹资才能提供这个服务?再次是在这个过程中需要有哪些支撑配合的业务或规范流程?最终是作为政府部门的内勤应该如何更好的管理。从这个概念上可看到前两者是核心价值链,后两者是辅助作用。

前面在谈智慧城市核心业务的时候一般分为政务和公共管理,民生服务,智慧产业等几个部分。从BRM业务参考模型来看核心就是公民服务,其它都是围绕公民服务的支撑内容。

对于BRM有点类似于TOGAF中的业务架构,但是BRM更加强调了在构建业务架构中的分层,首先强调的是业务线和业务功能,而非业务部门或组织。这也是我们常说的业务架构建模的一个重点。在BRM中我们仍然只看到了静态的业务架构,没有看到动态的业务流程建模和分析,暂不清楚是否有这块的内容。

SRM-服务组件模型

 

\

 

首先可以看到这里谈的服务构件的概念,已经和SOA我们经常谈到的业务组件化,组件能力化的思路很类似了。上图可以清晰的看到我们整个分析思路就是先理顺业务目标和业务线,业务功能。再来考虑应该用什么样的服务构件来支撑相应的业务。

一个构件可以定义为“一个自包含的业务过程或服务;这个过程和服务具有预定的、可以通过一个业务或技术接口发挥作用的功能。业务构件代表一个自组织业务概念或过程的实现。它包括所有必要的技术元素(如,软件,硬件,数据)以表述、实现和部署一个给定的业务概念为一个大型信息系统的自组织、可重用的元素。这是整个开发生命周期和分布层次中统一的概念。

SRM分了7个服务域,每个服务域下还有具体的服务类型和详细的服务构建。在这里已经和我们在SOA规划分析中的SOA服务目录库的概念很类似了。启用SRM这一层一个核心就是真正实现BRM和TRM之间的一种松耦合。同时SRM对于服务的分层和分类并没有完全照搬BRM业务参考架构分离,而是进一步按照业务高内聚的思想识别和分解为不同的服务构件提供能力。最终再进行业务功能和服务构件之间的映射。

构件的有效识别、集成和使用,使得集成服务在部门和政府间共享。这些服务提供业务过程的功能和执行,它们支撑着BRM的子功能。服务构件的聚集可以快速构造和实现构件以支持一个给定的启动项目或投资。(这段也可以看到完全的SOA思想体现)

再次强调,在BRM清楚后,应该分解为哪些服务构件,每个服务构件应该提供哪些能力和服务,才能够满足业务目标和跨构件的业务协同,这是业务架构层面必须要重点考虑的问题质之一。

TRM-技术参考模型

 

\

 

很好的一个图,再次体现了服务构建的承上启下的作用。对内来说收集和聚合能力,对外来说提供粗粒度的服务。对外是服务访问和交付,对内是服务接口和集成。内部是服务平台,技术架构和框架。内部的能力必须要通过服务构件进行访问或聚合。既实现内部和外部的松耦合,也实现内部和外部的隔离。

在这里的服务平台要注意到两个层次的含义。一个是服务构件的开发平台,一个是服务构件提供的服务接口的统一管理和集成平台。前者和标准的应用开发技术架构相关,后者与集成平台或ESB相关。在FEA的技术参考架构里面强调的是数据交换和数据集成,强调是接口。在SOA参考架构下可以转换为服务共享和能力开放,同时提供数据,业务,技术各个维度的开放能力。

DRM-数据和信息参考模型

同传统的数据架构的分析和方法类似,同时也看到在FEA里面也强调的是在数据模型和元数据定义清楚后,重点分析的是数据交换和接口。这个我们我们现在建立数据开放能力平台的思路已经不吻合。在新的智慧城市顶层架构设计下要意识到,对于数据,特别是基础MDM主数据和共享数据,需要建立的是共享数据中心并提供数据开放能力和服务。

关键字:设计智慧城市架构企业

本文摘自:人月神话博客

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^