SOA 治理的业务流程

IBM 的高级架构师 Prabhakar Mynampati ，上周发表了一篇详细说明 6 个 SOA 治理业务流程的文章。这篇文章给出了以下流程的类 BPMN 流程定义：

• 服务识别
• 服务创建
• 服务测试
• 服务版本控制与变更管理
• 服务管理
• 服务安全

这些场景是针对“在缺少 SOA 治理的情况下，SOA 开发生命周期可能会遇到的潜在挑战”而定义的：

• 疲于识别新服务和确定其优先级
• 服务创建和重用中的重要问题，如创建冗余且低效的服务
• 采用杂乱无章的测试策略和标准
• 粗糙且不完善的服务变更和版本的治理
• 没有系统地确保服务管理、服务质量（QoS）以及服务安全治理策略的施行。

Prabhakar 声称服务的识别过程是必要的，因为：

因识别业务服务和 IT 服务方式的不一致，带来了各种项目风险。服务可能不具有互操作性，并且在识别之后也可能出现大量冗余。甚至找不到负责服务识别和交付的人员。最终，所有这些风险将导致项目成本陡增，无法按时交付。

他建议采用以下的服务识别流程：

同样的，服务创建流程也是必要的，因为：

目前，组织正在饱受开发和部署那些冗余和低效的服务之苦，这些服务跨水平和垂直领域不同业务线构建，但又没有考虑其它仓储。部分服务实现时对系统功能的确认方式都不一致。维护相似或相同服务的多个副本使得维护成本陡增；由于对此服务缺少控制，更阻碍了进一步的开发。

在服务测试方面，Prabhakar 认为：

现状是，各小组正在用不同的工具和策略测试他们的服务。在组织内，针对服务实现，运用工具、插件以及测试策略的方式没有统一。这归咎于判断服务是否满足需求的测试是由垂直单位开发的，而且由于所实现的 IT 服务没能正确满足业务需求而暴露了一些问题。在紧迫的项目安排下，一些单位无法满足集成和系统测试的期限。当 IT 服务的系统实现遇到业务需求的变更时，一些项目团队遇到了困难。所有这些问题都给测试场景的治理带来了挑战。

他认为服务版本控制和变更管理流程是必要的：

在组织内没有建立管理中心来决定业务流程所需求的变更是否需要以 IT 实现，以及该变更是否应以现有服务实现还作为新版本发布实现。在企业里也没有一个公共团体来探究这些变更对于其它服务消费者的影响。同时也没有一个管理中心来决定服务版本控制的运行时策略。当变更服务版本时，由于服务中断，出现客户抱怨系统的不可用。

他同时还指出了服务管理流程领域的一些关键 SOA 治理活动：

在这个服务管理场景中，你会看到组织在对那些暴露给不同服务消费者的服务进行监控和管理时遇到了困难。……架构和开发团队并未意识到服务和资源需要基于服务水平协定（SLA）进行监控。没有使用统一的管理工具来覆盖业务应用的端到端视图，也没有使用统一的方式来提供关于各个资源性能和可用性度量指标的详细信息。

最后，他还发现了一些问题：

组织没有应对安全威胁和保护服务免受外界访问的公共策略。服务的多次认证和授权使操作者感到沮丧。针对策略的采用并从开端到实现对其进行跟踪，没有合适的安全策略管理框架；针对一个共同安全标准集合的维护，也没有一个责任团体与企业边界组织进行交互和沟通。与其它服务和数据的交互缺少公认的安全标准，并且没有定义策略管理的角色和责任。

在识别，实现，保护或管理服务时，SOA 治理需要讲究方法。在你的组织里也在使用类似的流程吗？如果没有，你遇到过一些作者在这里陈述的问题吗？你是否会考虑实现这些流程呢？

查看英文原文： Business Processes for SOA Governance