SOA:服务集成成熟度模型(Service Integration Maturity Model)

SOA:服务集成成熟度模型(Service Integration Maturity Model)
强烈推介IDEA2021.1.3破解激活,IntelliJ IDEA 注册码,2021.1.3IDEA 激活码 

大家好,我是架构君,一个会写代码吟诗的架构师。今天说一说SOA:服务集成成熟度模型(Service Integration Maturity Model),希望能够帮助大家进步!!!

    基本上每个方法框架都有成熟度之说,例如CMMI分级、企业架构 - 企业架构成熟度模型(EAMM),SOA出现的最明显的好处之一就是集成性, The Open Group发布了一个OSIMM模型(The Open Group Service Integration Maturity Model),本篇主要结合SOA Source这本书的内容来介绍一下OSIMM的相关内容。

OSIMM Maturity Matrix

20110307190132277.png

    OSIMM开始是由IBM提交的,后由The Open Group负责。这个模型定义了七个维度和七个成熟度级别。

如何使用OSIMM

  • 通过评估组织的每一个维度的成熟度来开发基线和目标模型
  • 做出基线到目标的差距分析
  • 生成组织提高目标成熟度级别的转换项目路标

维度:业务

  • 业务架构
    • 组织在业务架构上当前的实践和策略
    • 业务流程如何设计、组织、实现和执行
  • 企业完整的IT需要多少成本
  • IT能力如何支持业务灵活性、业务敏捷和业务服务级别business Service Level Agreement (SLA)
  • IT战略
  • 从一个成熟度级别转移到更高级别成熟度模型的价值决策依据

维度:组织和治理

  • 组织自身的结构和和设计,以及在SOA上下文和SOA治理当中的有效性
  • 关注组织结构、关系、面向服务战略
    • 包括扩充技能、训练、以及可以从组织中获得的培训
  • 治理与正式的管理流程结合起来,保证IT活动、服务能力和SOA方案与业务需要对齐
  • 治理之道其他成熟度维度方面,包括如何组织管理以及如何预算成本

维度:方法

  • 组织采用的方法和流程是为IT和业务转换服务的
  • 围绕软件开发周期的组织成熟度使用到:
    • 需求管理
    • 估算技术
    • 项目管理
    • 质量保证流程
    • 设计方法和技术
    • 设计方案工具

维度:应用

  • 应用样式
  • 应用结构和功能解耦
  • 重用
  • 灵活
  • 可靠
  • 扩展
  • 明白
  • 一致操作

维度:信息

  • 信息如何组织的
  • 信息如何建模的
  • 访问企业数据的方法
  • 从功能层面来看数据访问抽象
  • 数据规格
  • 数据转换能力
  • 服务和流程定义
  • 处理标识
  • 安全认证
  • 知识管理
  • 业务信息模型
  • 内容管理

维度:架构

  • 拓扑
  • 集成技术
  • 企业架构决策
  • 标准和策略
  • web services采用级别
  • SOA实现经验
  • SOA一致性
  • 产生的工件

维度:基础设施和管理

  • 组织基础设施能力
  • 服务管理
  • IT操作
  • IT管理和IT维护
  • 如何满足SLAs
  • 如何执行监控
  • 提供什么类型的集成平台

成熟度级别1: Silo

  • 组织每个独立部分都有自己独立的软件,没有数据、流程、标准或者技术集成
  • 限制了不同组织之间的业务流程协作,如果不通过人工干预(例如人工输入或者人工解释),IT系统不能支持集成

成熟度级别2: Integrated

  • 技术上考虑了在竖井之间的数据和交互集成
  • 不同部分之间IT集成变成可能,但是集成并没有扩充到数据或业务流程的通用标准,因此两个系统之间需要复杂的数据约定和协议来进行连接
  • 每个组件可能需要定制开发和适配,导致软件功能蔓延,以至于难以管理和编写代码,因为开发一个新的业务流程会比较难

成熟度级别3: Componentized

  • IT系统已经分析并拆分为组件,它们可以配置成一个新的系统
  • 从业务功能到组件仍然有一些分析限制
  • 虽然组件通过定义的接口进行交互,但是它们仍旧不是松耦合的,这也就限制了不同系统间的敏捷性和可交互性
  • 很能开发跨组织的业务流程

成熟度级别4: Service

  • 基于松散偶尔的业务流程来构建组合应用
    • 服务基于开放标准,与底层应用技术无关
    • IT基础设施支持多种协议、安全机制、数据转换和服务管理
    • 服务可以在组织内和跨组织中使用,符合SLAs
  • 业务功能经过详细的分析,并且拆分为服务,确保服务可以在业务级别进行交互
  • 能够通过规范的语言明确的定义每个服务的操作
  • 这个阶段,服务组合仍然靠开发人员定制代码来实现,以至于限制了开发新的业务流程

成熟度级别5: Composite Services

  • 通过组合语言来定义信息流来控制每一个独立的服务
  • 组合服务包括静态的、流畅的、基于活动的服务 ,这时候不需要定制代码就可以组合服务成为一个业务流程,可能是短期流程,也可能是长期流程 。因此,开发人员可以在业务分析师的指导下敏捷的进行服务的设计和开发。

成熟度级别6: Virtualized Services

  • 虽然虚拟化开始于非SOA领域,这个级别将虚拟化扩展到业务服务上,业务和IT服务间接地通过虚拟服务提供出来
  • 基础设施进行虚拟调用到实际物理服务调用的映射
  • 虚拟服务让组合服务变得更加松耦合

成熟度级别7: Dynamically Re-Configurable Services

  • 这个级别之前,业务流程可以通过开发人员在设计期通过合适的工具进行开发。而这个级别下,运行服务可以动态期执行。

评估问题和成熟度指示器

  • The OSIMM base model 包括一套评估问题和成熟度指示器
  • 能够基于The base OSIMM model 之上进行扩展,添加一些额外的成熟度指示器、评估问题

以下为业务维度的成熟度指示器示例,更多内容:http://www.docin.com/p-130316849.html

201103071901338051.png

这些概念初次接触比较抽象,如果写的有误,欢迎回复指正。

推荐:你可能需要的在线电子书201103071901332163.gif   

我的新浪围脖: http://t.sina.com.cn/openexpressapp   敏捷个人sina围裙:http://q.t.sina.com.cn/135484  

欢迎转载,转载请注明:转载自周金根 [ http://zhoujg.cnblogs.com/ ]

转载于:https://www.cnblogs.com/zhoujg/archive/2011/03/07/1975717.html

本文来源weixin_30595035,由架构君转载发布,观点不代表Java架构师必看的立场,转载请标明来源出处:https://javajgs.com/archives/29701

发表评论