在EA企业架构中我们经常谈到业务架构(流程视图),数据架构(信息视图),应用架构(应用视图)和技术架构。对于流程视图和信息视图是偏业务层面的内容,而对于应用架构,应用集成架构和技术架构则偏技术方面的内容。
在原有的EA企业架构和信息化规划中,我们比较少谈到服务视图的概念,而引入了SOA实施方法论和SOA集成后,服务视图的概念就显得越来越重要,服务视图本身是一个服务能力提供视图,是业务和IT能力提供中心。服务视图的构建目的就是能够更加清楚的展现业务和IT的可重用的能力。
构建服务视图包括两个方面的内容,一个是服务的识别和定义,一个是服务的展现。
服务识别和定义
对于服务的识别和定义,我们遵循一个基本的准则,即先通过业务流程,数据和应用驱动识别出候选服务,然后对候选服务进行多维度评分,得到最终选择的服务,然后再对服务进行详细的定义和设计。
对于服务识别的核心仍然要以流程,数据和应用三个角度进行分析和梳理。对于流程需要从端到端流程出发,然后进行二级,三级流程的分解,细化到具体的业务活动或操作单元。然后分析这些业务活动或操作哪些是可以复用的公共功能,具体包括:
流程公用性:业务活动单元在哪些流程里面都会使用到?活动和流程的对应关系是如何的?
应用公用性:业务活动单元在哪些应用里面会使用到?特别是是否存在多个业务系统使用?
而对于信息视图驱动,则常见的分析方法还是数据和业务功能间对应的CRUD分析。这个分析可以先在已经细化出具体的业务活动单元后再进行。有了业务活动或功能,然后由具体的信息视图中的数据模型,这两者之间可以进行CRUD分析,分析数据跨业务流程,跨系统,跨功能模块的使用情况。这个分析是我们后续识别数据服务的基础。
通过上面的方法基本可以得到候选服务清单,候选服务清单的识别来源于流程,数据和应用视图。识别的关键是候选服务具有在多个流程或应用使用的公共性和可复用性。
服务定义的重点是对候选服务进行去重和归并,并补充服务所需要的属性项。对于归并和去重后的服务再进行量化的结构化评估。这个评估可以从服务的可重用性,业务灵活性,服务可实现性,服务使用频率等多个方面进行。在量化评估完成后,服务最终可以入库到服务视图。
服务视图的呈现
对于流程视图展现的是企业所包含的所有业务和流程,而对于服务视图则展现的是企业在业务和流程协作中可以复用的服务能力,这是服务视图和流程视图的一个关键差异点。
服务视图本身有多个可以展现的维度,而我们前面所说的流程视图,数据视图,应用视图恰好都是服务视图可以展现的各个维度。高端的服务视图就是服务目录集或服务资产库,这是对服务视图的一个高端分类,这个分类可以按业务流程,数据分类,业务系统应用分类多个维度进行展开。这也可以理解为服务关系的核心逻辑,即服务和流程的关系,服务和数据的关系,服务和应用系统间的关系。
其次,服务视图需要体现服务的分层。对于服务的分层从业务层面来看,应该包括数据服务,业务服务,流程服务三个层面。从技术来看,则应该包括技术层服务,公共平台层服务。对于服务的调用应该基于一个从上到下的调用顺序,而不能进行逆向调用,即服务调用顺序为:
流程服务->业务服务->数据服务->公共平台服务->技术服务
另外服务视图构建,还需要考虑和服务工程域,服务全生命周期的融合。服务本身不能离开服务全生命周期而存在。服务全生命周期体现了服务从业务目标和需求开始,到服务识别和发现,服务定义,服务设计开发,服务测试,服务上线,服务使用的全过程。通过上面的分析,服务视图的呈现就比较清楚了,服务视图是一个涉及到服务生命周期,服务分类,服务关系等的一个多维度呈现模型。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
如何避免云计算与SOA冲突