在EA企业架构中我们经常谈到业务架构(流程视图),数据架构(信息视图),应用架构(应用视图)和技术架构。对于流程视图和信息视图是偏业务层面的内容,而对于应用架构,应用集成架构和技术架构则偏技术方面的内容。
在原有的EA企业架构和信息化规划中,我们比较少谈到服务视图的概念,而引入了SOA实施方法论和SOA集成后,服务视图的概念就显得越来越重要,服务视图本身是一个服务能力提供视图,是业务和IT能力提供中心。服务视图的构建目的就是能够更加清楚的展现业务和IT的可重用的能力。
构建服务视图包括两个方面的内容,一个是服务的识别和定义,一个是服务的展现。
对于服务的识别和定义,我们遵循一个基本的准则,即先通过业务流程,数据和应用驱动识别出候选服务,然后对候选服务进行多维度评分,得到最终选择的服务,然后再对服务进行详细的定义和设计。
对于服务识别的核心仍然要以流程,数据和应用三个角度进行分析和梳理。对于流程需要从端到端流程出发,然后进行二级,三级流程的分解,细化到具体的业务活动或操作单元。然后分析这些业务活动或操作哪些是可以复用的公共功能,具体包括:
流程公用性:业务活动单元在哪些流程里面都会使用到?活动和流程的对应关系是如何的?
应用公用性:业务活动单元在哪些应用里面会使用到?特别是是否存在多个业务系统使用?
而对于信息视图驱动,则常见的分析方法还是数据和业务功能间对应的CRUD分析。这个分析可以先在已经细化出具体的业务活动单元后再进行。有了业务活动或功能,然后由具体的信息视图中的数据模型,这两者之间可以进行CRUD分析,分析数据跨业务流程,跨系统,跨功能模块的使用情况。这个分析是我们后续识别数据服务的基础。
通过上面的方法基本可以得到候选服务清单,候选服务清单的识别来源于流程,数据和应用视图。识别的关键是候选服务具有在多个流程或应用使用的公共性和可复用性。
服务定义的重点是对候选服务进行去重和归并,并补充服务所需要的属性项。对于归并和去重后的服务再进行量化的结构化评估。这个评估可以从服务的可重用性,业务灵活性,服务可实现性,服务使用频率等多个方面进行。在量化评估完成后,服务最终可以入库到服务视图。
服务视图的呈现
对于流程视图展现的是企业所包含的所有业务和流程,而对于服务视图则展现的是企业在业务和流程协作中可以复用的服务能力,这是服务视图和流程视图的一个关键差异点。
服务视图本身有多个可以展现的维度,而我们前面所说的流程视图,数据视图,应用视图恰好都是服务视图可以展现的各个维度。高端的服务视图就是服务目录集或服务资产库,这是对服务视图的一个高端分类,这个分类可以按业务流程,数据分类,业务系统应用分类多个维度进行展开。这也可以理解为服务关系的核心逻辑,即服务和流程的关系,服务和数据的关系,服务和应用系统间的关系。
其次,服务视图需要体现服务的分层。对于服务的分层从业务层面来看,应该包括数据服务,业务服务,流程服务三个层面。从技术来看,则应该包括技术层服务,公共平台层服务。对于服务的调用应该基于一个从上到下的调用顺序,而不能进行逆向调用,即服务调用顺序为:
流程服务->业务服务->数据服务->公共平台服务->技术服务
另外服务视图构建,还需要考虑和服务工程域,服务全生命周期的融合。服务本身不能离开服务全生命周期而存在。服务全生命周期体现了服务从业务目标和需求开始,到服务识别和发现,服务定义,服务设计开发,服务测试,服务上线,服务使用的全过程。通过上面的分析,服务视图的呈现就比较清楚了,服务视图是一个涉及到服务生命周期,服务分类,服务关系等的一个多维度呈现模型。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
把软件架构演进体现在栈上
曾几何时,企业架构师要为了得到承认和支持而抗争,但这种时候正在过去。大多数企业现在已经意识到实现业务流程中敏捷性和效率需要业务目标、人力资源以及信息技术的结合。
-
架构安全模型开发方式探索
维护一个强大的安全模型,以及相关合规和管控的需求越来越重要,特别是在如今黑客和入侵几乎每天都会发生的情况下。
-
你了解应用集成架构吗?
业务流程越来越多得要求在很多任务,甚至很多应用之间共享更多的信息。应用集成架构是一种IT流程,确保数据或者某个功能能够从一个应用移动到另一个应用。
-
企业架构 请用好移动设施和云计算
虽然很多企业都实施了移动化,但是并没有改变其底层架构。其结果就是,他们最终会围绕手机这样一个集成点来开发一个轴辐型的架构。