TOGAF 9.1元模型在图的中心有一个称为“业务服务”的框。经常有人问我:我们所说的“业务服务”是什么意思?查看规范和定义，我们发现以下定义:“通过显式定义的接口支持业务能力，并由组织显式治理。”
是的，我们知道业务能力可以帮助我们确定业务在一定粒度级别上需要哪些服务，以实现业务敏捷性，并由IT实现，但它并没有真正解释它的真正含义以及如何识别它们。业务能力完全符合这样一种概念:在面向服务体系结构(SOA)的意义上，服务是一个黑盒，其实现被封装在标准接口之后。
在规范的SOA部分，您还可以发现:
服务是具有指定产出的可重复业务活动的逻辑表示(例如，核对客户信用、提供天气数据、合并钻井报告等)，以及:
- 是独立的
- 可由其他业务服务组成
- 是服务消费者的“黑箱”
问题仍然存在……这些业务服务到底是什么，我们如何识别它们，正确的粒度级别是什么?
在ArchiMate 2.1中，我们也有一个可能更详细的定义:“业务流程、业务功能或业务交互可能用于实现业务服务”，但这并没有回答我们的问题:业务服务到底是什么?
潜在客户管理系统可能会实现许多业务服务(例如线索识别服务、潜在客户识别服务等)，这些业务服务将由销售人员访问(作为销售流程的一部分)。要访问面向服务的体系结构中的功能，只需要知道服务集(而不是底层应用程序/系统)。
业务服务的表示方式也更有利于业务。业务服务以“业务活动”的形式表征了独特的“业务行为元素”，由“特定角色”承担，共同支持特定的“业务目标”。
现在，TOGAF中的业务服务与ArchiMate和SOA服务中的业务服务相似吗?
从业务流程开始
作为起点，我们可以从由核心和非核心功能组成的流程景观来关注业务流程。这些流程通常可以在流程模型中称为流程级别的各种抽象级别上表示(例如，描述性、分析性/操作性和可执行性)。
然后可以使用自顶向下的方法从这些级别识别和提取业务服务。较高的抽象级别为组合业务服务提供输入，而较低的级别为细粒度的候选服务提供输入。这种对流程和业务服务候选者的关注还将有助于确定整个企业的功能冗余。
然而，这种方法的结果可能因组织的不同而有所不同。
业务服务以“业务活动”中独特的“业务行为元素”为特征，由“特定角色”承担，共同支持特定的“业务目标”。下面是一些业务服务的示例。两个是保险公司的，一个是银行的:
示例1保险
- ►业务能力客户合同管理
- ►业务目标确保优质客户合同
- ►业务活动创建客户契约
- ►业务功能合同管理
- ►业务流程合同管理流程
- ►业务角色合同专家
- ►业务服务客户合同创建
所有这些概念都可以链接到TOGAF元模型中描述的单个实体(方框)。
业务服务“客户契约创建”支持业务功能“契约管理”(并且是业务功能“客户契约管理”的一个组成部分，图中没有显示)。
在本例中，客户是内部的，因为“合同管理”功能是一个支持业务功能，它可能向保险公司的几个业务部门提供“客户合同创建”业务服务。有时，业务功能的客户可能是内部和外部的;它们可以被认为是共享的业务服务。业务服务与流程、信息、功能和人员相关。
例2保险公司
- ►业务能力
- 保险索赔管理
- ►业务目标
- 遵守保险单
- ►业务活动
- 接受保险索赔
- ►业务功能
- 索赔管理
- ►业务流程
- 索赔管理过程
- ►作用
- 保险索赔受体
- ►业务服务
- 保险索赔接受
与示例1一样，业务服务“保险索赔接受”支持业务功能“索赔管理”
示例3银行业务服务(与银行产品关联)
- ►银行产品
- 经常账户
- ■储蓄账户
- 透支账户
- ■信用卡账户
- 使用:
- ►业务服务
- 现金支取/存款
根据客户使用的银行通道，可能需要多个应用程序/系统组件:自动柜员机、Kiosk、网上银行、移动银行、分行银行
我在这三个示例中标识了以下业务服务:
客户合同创建
保险索赔接受
现金支取/存款
然而，这些合适吗?他们是正确的吗?这是正确的粒度级别吗?
服务模型
即使您选择的体系结构样式不是SOA，如果不考虑服务模型，您也无法真正地面对正确识别正确级别的业务服务的挑战。在过去的几年里，我们看到越来越多的业务服务实现为SOA服务，它们与软件功能直接相关。必须指出的是，其他社区，比如那些关注It服务管理(ITIL)的社区，也在寻求额外的清晰度。
该服务模型应该将业务服务与TOGAF的应用程序体系结构中的信息系统服务联系起来，然后与SOA和ITIL服务联系起来。
业务服务和SOA-ITIL服务是相关的，但是间接的。
SOA服务并不完全是业务服务，因为它通常是开发人员编写的一系列软件模式，用于提供信息、转换数据或进行一些计算。它是一个提供服务的组件，该服务公开隐藏内部实现技术的接口。它由三部分组成;实现要提供的服务的服务类、承载服务的主机环境以及客户机将连接到的一个或多个端点。
TOGAF定义的信息系统(IS)服务的解释是:“业务服务的自动化元素。信息系统服务可以交付或支持一个或多个业务服务的部分或全部“。一种可能的解释是，SOA服务继承自IS服务，SOA服务可以被归类为提供一个或多个结果(流程、访问、应用、信息、服务等等)。SOA参考体系结构可能是有益的，也应该加以考虑。
另一个要考虑的方面是ITIL服务;“IT服务是由信息技术、人员和流程组合而成的。面向客户的IT服务直接支持一个或多个客户的业务流程，应该在服务水平协议中定义其服务水平目标。其他IT服务(称为支持服务)不是由业务直接使用的，而是由服务提供者交付面向客户的服务所必需的”。我们还可以想象ITIL IT服务从相同的IS服务继承而来。
下面的模型说明了一种扩展TOGAF元模型的方法，以显示功能、流程、产品、业务服务、IS服务、SOA和ITIL服务之间的依赖关系。业务服务为特定流程组合人员、产品以及流程和技术资源。
SOA服务由部署的软件提供。ITIL(或IT)服务也由软件提供，这就是为什么我们还可以在不同级别的服务之下添加TOGAF体系结构域。
回到例1
- ►业务服务客户合同创建
我现在可以想象一个更完整的描述，包括:
- ►ITIL服务服务名称:合同管理服务(包括合同创建)服务描述:该服务向供应商(如承运人、港口、仓库等)提供报价和协议条件;管理采购和销售合同、知识产权许可证、内部协议等;自动化并加速整个契约生命周期，等等……支持时间：一至周五07:00 - 19:00可用性目标:99%备份服务所有者服务代表服务的重要程度等。
- ►SOA服务合同创建服务
SOA服务将是一个基于数据-应用-技术体系结构(最终)的软件，使用参考体系结构。这就是TOGAF架构域被添加到服务层次结构之下的原因。
ITIL IT服务属于一般类型，而不是SOA类型的服务。在IT服务和过多的SOA服务之间也可能存在关系。
从企业架构或ITSM的角度来看，业务服务被交付给客户，支持他们的需求，有时通过支持业务流程或直接支持交付给最终客户的服务或产品。
业务功能可以交付由一个或多个ITIL IT服务支持的业务服务，这些服务本身可能由SOA服务实现，也可能不实现(取决于对SOA体系结构的选择)。
这是一种有助于阐明如何集成这些不同类型的服务的方法(当然还有其他方法)，特别是对于TOGAF从业者。
