在EA企业架构中我们经常谈到业务架构（流程视图），数据架构（信息视图），应用架构（应用视图）和技术架构。对于流程视图和信息视图是偏业务层面的内容，而对于应用架构，应用集成架构和技术架构则偏技术方面的内容。

    在原有的EA企业架构和信息化规划中，我们比较少谈到服务视图的概念，而引入了SOA实施方法论和SOA集成后，服务视图的概念就显得越来越重要，服务视图本身是一个服务能力提供视图，是业务和IT能力提供中心。服务视图的构建目的就是能够更加清楚的展现业务和IT的可重用的能力。

    构建服务视图包括两个方面的内容，一个是服务的识别和定义，一个是服务的展现。
 

    服务识别和定义

    对于服务的识别和定义，我们遵循一个基本的准则，即先通过业务流程，数据和应用驱动识别出候选服务，然后对候选服务进行多维度评分，得到最终选择的服务，然后再对服务进行详细的定义和设计。

    对于服务识别的核心仍然要以流程，数据和应用三个角度进行分析和梳理。对于流程需要从端到端流程出发，然后进行二级，三级流程的分解，细化到具体的业务活动或操作单元。然后分析这些业务活动或操作哪些是可以复用的公共功能，具体包括：[page]
    流程公用性：业务活动单元在哪些流程里面都会使用到？活动和流程的对应关系是如何的？

    应用公用性：业务活动单元在哪些应用里面会使用到？特别是是否存在多个业务系统使用？

    而对于信息视图驱动，则常见的分析方法还是数据和业务功能间对应的CRUD分析。这个分析可以先在已经细化出具体的业务活动单元后再进行。有了业务活动或功能，然后由具体的信息视图中的数据模型，这两者之间可以进行CRUD分析，分析数据跨业务流程，跨系统，跨功能模块的使用情况。这个分析是我们后续识别数据服务的基础。

    通过上面的方法基本可以得到候选服务清单，候选服务清单的识别来源于流程，数据和应用视图。识别的关键是候选服务具有在多个流程或应用使用的公共性和可复用性。

    服务定义的重点是对候选服务进行去重和归并，并补充服务所需要的属性项。对于归并和去重后的服务再进行量化的结构化评估。这个评估可以从服务的可重用性，业务灵活性，服务可实现性，服务使用频率等多个方面进行。在量化评估完成后，服务最终可以入库到服务视图。

    服务视图的呈现

    对于流程视图展现的是企业所包含的所有业务和流程，而对于服务视图则展现的是企业在业务和流程协作中可以复用的服务能力，这是服务视图和流程视图的一个关键差异点。

    服务视图本身有多个可以展现的维度，而我们前面所说的流程视图，数据视图，应用视图恰好都是服务视图可以展现的各个维度。高端的服务视图就是服务目录集或服务资产库，这是对服务视图的一个高端分类，这个分类可以按业务流程，数据分类，业务系统应用分类多个维度进行展开。这也可以理解为服务关系的核心逻辑，即服务和流程的关系，服务和数据的关系，服务和应用系统间的关系。

    其次，服务视图需要体现服务的分层。对于服务的分层从业务层面来看，应该包括数据服务，业务服务，流程服务三个层面。从技术来看，则应该包括技术层服务，公共平台层服务。对于服务的调用应该基于一个从上到下的调用顺序，而不能进行逆向调用，即服务调用顺序为：

    流程服务->业务服务->数据服务->公共平台服务->技术服务

    另外服务视图构建，还需要考虑和服务工程域，服务全生命周期的融合。服务本身不能离开服务全生命周期而存在。服务全生命周期体现了服务从业务目标和需求开始，到服务识别和发现，服务定义，服务设计开发，服务测试，服务上线，服务使用的全过程。通过上面的分析，服务视图的呈现就比较清楚了，服务视图是一个涉及到服务生命周期，服务分类，服务关系等的一个多维度呈现模型。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。