「业务架构」业务服务:它们到底是什么?

简介: 「业务架构」业务服务:它们到底是什么?

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从业者。

相关文章
|
2月前
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
3月前
|
存储 Linux KVM
Proxmox VE (PVE) 主要架构和重要服务介绍
Proxmox VE (PVE) 是一款开源的虚拟化平台,它基于 KVM (Kernel-based Virtual Machine) 和 LXC (Linux Containers) 技术,支持虚拟机和容器的运行。PVE 还提供高可用集群管理、软件定义存储、备份和恢复以及网络管理等企业级功能。
1380 7
|
9天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
44 11
|
5月前
|
安全 前端开发 JavaScript
逆向海淘代购集运系统:sugargoo的技术架构与创新服务解读
逆向海淘代购集运系统整合中国电商资源,为海外用户提供便捷购物及物流服务,降低购物成本。sugargoo系统搭建攻略包括: - **需求分析与规划**: 深入了解目标市场需求,明确服务特色。 - **平台开发**: 选用合适技术栈,开发关键功能模块,集成电商数据。 - **物流合作**: 建立物流合作关系,集成物流API提升自动化。 - **支付解决方案**: 支持多种支付方式,保障支付安全。 - **客户服务**: 提供多语言支持,建设专业客服团队。 - **营销与推广**: 优化SEO,利用社交媒体扩大品牌影响。
|
1月前
|
Kubernetes Cloud Native Docker
云原生之旅:从传统架构到容器化服务的演变
随着技术的快速发展,云计算已经从简单的虚拟化服务演进到了更加灵活和高效的云原生时代。本文将带你了解云原生的概念、优势以及如何通过容器化技术实现应用的快速部署和扩展。我们将以一个简单的Python Web应用为例,展示如何利用Docker容器进行打包和部署,进而探索Kubernetes如何管理这些容器,确保服务的高可用性和弹性伸缩。
|
2月前
|
消息中间件 Kafka 数据库
微服务架构中,如何确保服务之间的数据一致性?
微服务架构中,如何确保服务之间的数据一致性?
|
2月前
|
存储 分布式计算 druid
大数据-155 Apache Druid 架构与原理详解 数据存储 索引服务 压缩机制
大数据-155 Apache Druid 架构与原理详解 数据存储 索引服务 压缩机制
72 3
|
3月前
|
消息中间件 Kafka 数据库
微服务架构中,如何确保服务之间的数据一致性
微服务架构中,如何确保服务之间的数据一致性
|
3月前
|
存储 搜索推荐 数据库
MarkLogic在微服务架构中的应用:提供服务间通信和数据共享的机制
随着微服务架构的发展,服务间通信和数据共享成为关键挑战。本文介绍MarkLogic数据库在微服务架构中的应用,阐述其多模型支持、索引搜索、事务处理及高可用性等优势,以及如何利用MarkLogic实现数据共享、服务间通信、事件驱动架构和数据分析,提升系统的可伸缩性和可靠性。
56 5
|
3月前
|
XML Java 数据库
在微服务架构中,请求常跨越多个服务,涉及多组件交互,问题定位因此变得复杂
【9月更文挑战第8天】在微服务架构中,请求常跨越多个服务,涉及多组件交互,问题定位因此变得复杂。日志作为系统行为的第一手资料,传统记录方式因缺乏全局视角而难以满足跨服务追踪需求。本文通过一个电商系统的案例,介绍如何在Spring Boot应用中手动实现日志链路追踪,提升调试效率。我们生成并传递唯一追踪ID,确保日志记录包含该ID,即使日志分散也能串联。示例代码展示了使用过滤器设置追踪ID,并在日志记录及配置中自动包含该ID。这种方法不仅简化了问题定位,还具有良好的扩展性,适用于各种基于Spring Boot的微服务架构。
59 3

热门文章

最新文章