Business analysis and SOA part 4 of 6: SOA delivery lifecycle and the top-down approach [by Thomas Erl]

转载 2006年06月01日 15:27:00
 

Development projects for service-oriented solutions are, on the surface, much like any other custom development projects for distributed applications. Services are designed, developed, and deployed alongside the usual supporting cast of front and back-end technologies. Once you dig a bit deeper under the layers of service-orientation, though, you'll find that in order to properly construct and position services as part of a standardized SOA, traditional project cycles require some adjustments.

As we can see in Figure 1 (see below), common delivery lifecycles include processes specifically tailored to the creation of services in support of SOA. In the service-oriented analysis stage, for example, services are modeled as service candidates that comprise a preliminary SOA. These candidates then become the starting point for the service-oriented design phase, which transforms them into real world service contracts.

Service-oriented analysis (and a related sub-process known as service modeling) represent an important part of service delivery that requires the involvement of business analysts and very much demonstrates how business analysis in general is affected by SOA. We'll discuss these processes in more detail later in this series. For now, our focus is on the project lifecycle and its relationship to business analysis.

Figure 1: Common phases of an SOA delivery lifecycle.

Delivery strategies

The lifecycle stages displayed in Figure 1 represent a simple, sequential path to building individual services. Real world delivery, however, is rarely that simple. These stages generally need to be organized into a delivery cycle that can accommodate the goals and constraints associated with project requirements, schedules, and budgets.

The challenge often lies in balancing these considerations. The success of SOA within an enterprise is increasingly associated with the extent to which it is standardized when phased into business and application domains. However, the success of a project delivering a service-oriented solution is traditionally measured by the extent to which the solution fulfills expected requirements within a given budget and timeline.

To address this problem, we need a strategy. This strategy must be based on an organization's priorities in order to establish the correct balance between the delivery of long-term migration goals with the fulfillment of more immediate, tactical requirements.

In this article we contrast two common strategies used to build services known as bottom-up and top-down. Neither is perfect, but both provide us with insight as to how the SOA delivery lifecycle can be configured.

The bottom-up approach is currently the most common variety, where services are created on an "as need" basis to fulfill mostly tactical requirements. The top-down approach, on the other hand, is one of analysis, deep thought, and patience. Service-orientation is infused into business layers so that services can be modeled in alignment with business models. In other words, it is far more strategic.

Because the theme of this series is about how SOA relates to business analysis we are more interested in what lies behind the top-down process. The bottom-up approach is described primarily to provide contrast.

Bottom-up approach

The majority of organizations that are currently building services as Web services follow a process similar to the one shown in Figure 2. The primary reason being that many just add Web services to their existing application environments in order to leverage the open Web services technology set (primarily for integration purposes). Even though the resulting architecture is often referred to as SOA, it really is still more reminiscent of traditional distributed architectural models, as service-orientation is rarely taken into consideration.

Figure 2: Common bottom-up process steps.

Though bottom-up designs allows for the efficient creation of services they can introduce some heavy penalties down the road. Implementing a "proper SOA" after a wide spread implementation of tactical services can impose a great deal of retro-fitting.

Top-down approach

This is very much an "analysis first" approach that requires not only business processes to become service-oriented, it also promotes the creation (or realignment) of an organization's overall business models. This process is therefore closely tied to or derived from an organization's existing business logic, and it commonly results in the creation of numerous reusable business and application services.

The top-down approach will typically contain some or all of the steps illustrated in Figure 3.

Figure 3: Common top-down process steps.

The point of this strategy is to invest in the up-front analysis and planning work required to build a high quality service architecture. The boundary and parameters of each service are thoroughly analyzed to maximize reuse potential and opportunities for streamlined and sophisticated compositions. All of this lays the groundwork for a standardized and federated enterprise where services maintain a state of adaptability, while continuing to unify existing heterogeneity.

The obstacles to following a top-down approach are usually associated with time and money. Organizations are required to invest significantly in up-front analysis projects that can take a great deal of time to demonstrate tangible, ROI-type benefits. There are further risks associated with over planning, where by the time the analysis projects are completed, they can become outdated.

Top-down approach and enterprise models

Of particular interest to business analysts are the enterprise models referenced in Step 1 of Figure 3. These tend to vary across different organizations, each of which will have models that are unique to its business domains.

Common types of enterprise model documents include a formal ontology, an enterprise entity model, an enterprise-wide logical data model, a standardized data representation architecture (often realized through a collection of standardized XML Schemas), and other forms of models generally associated with enterprise information architecture.

Some of these provide business-centric perspectives of an organization that prove extremely valuable sources for deriving business services. Business entity models especially tie directly into the subsequent definition of entity-centric business services.

Although listed as just a single step in the overall process, the requirements to properly define enterprise models can easily result in the need for one or more separate processes, each of which may require its own project and working group. On the other hand, if the required enterprise business models already exist, then this step may simply consist of their identification.

What's next

The choice of delivery strategy will determine the extent to which business analysts can help shape a service portfolio conceptually, before services are physically implemented. It is therefore worthwhile to give serious consideration to the pros and cons associated with each approach.

The next article in this series continues this exploration by explaining a common deliverable of the top-down analysis effort known as the enterprise service model. We will also then describe how the both tactical and strategic requirements can be addressed in an alternative strategy known as "agile" or "meet-in-the-middle."

This article contains excerpts from "Service-Oriented Architecture: Concepts, Technology, and Design" by Thomas Erl (792 pages, Hardcover, ISBN: 0131858580, Prentice Hall/Pearson PTR, Copyright 2006). For more information, visit www.soabooks.com.

Business analysis and SOA part 2 of 6: Business service models and the entity-centric business service [by Thomas Erl]

 As part of the design of service-oriented solutions it is common to label individual services accor...
  • Xalloy
  • Xalloy
  • 2006年06月01日 15:23
  • 1243

Business analysis and SOA part 3 of 6: Process-centric business services [by Thomas Erl]

 In the previous article we described the role of service models and explored the design standards f...
  • Xalloy
  • Xalloy
  • 2006年06月01日 15:24
  • 1505

Business analysis and SOA part 1 of 6: The benefits of business services [by Thomas Erl]

 This is the first article in a six-part series dedicated to exploring how SOA and service-orientati...
  • Xalloy
  • Xalloy
  • 2006年06月01日 15:20
  • 1229

Interactive Computer Graphics - A Top-Down Approach with Shader-Based OpenGL

2015-09-30    我很早之前就关注这本书了。在刚开始学习计算机图形学的时候,我首先购买的是另外一本,名叫 Computer Graphics with OpenGL,说到这本书,到手的...
  • cloudqiu
  • cloudqiu
  • 2017年02月10日 13:59
  • 428

Computer Networking A Top-Down Approach 总结

引言在这篇文章中,我主要对 Computer Networking: A Top-Down Approach (6th Edition) 一书进行总结,并把一些好的问题与 labs 记录下来,方便我日...
  • u013803076
  • u013803076
  • 2017年06月18日 15:13
  • 1030

SOA方法的一个简单例子

看了网上给的一些资料,写了一个SOA的服务端和客户端,传递的是javabean对象,用的是Axis不用手动生成stub文件,感觉比较简单点。   1、服务端代码,很简单,很普通 package cn....
  • zhxue123
  • zhxue123
  • 2009年06月04日 17:47
  • 6212

Spring与SOA

1.引言SOA是一种构造分布式系统的方法,它将业务应用功能以服务的形式提供出来,以便更好的复用、组装和与外部系统集成,从而降低开发成本,提高开发效率。SOA的目标是为企业构建一个灵活,可扩展的IT基础...
  • ruixj
  • ruixj
  • 2006年04月26日 15:41
  • 9063

RESTful架构及SOA架构简单解析

1.RESTful架构 本人也是刚接触ASP.Net开发,以下为自己简单的理解,并做了一些记录,表述不当或者错误之处还请指正,在此谢过。 首先,REST(REpresentational ...
  • u012384285
  • u012384285
  • 2014年06月21日 19:26
  • 3103

soa-面向服务项目搭建

1.创建新的工作空间,指定maven 工厂配置 1.1指定tomcat 1.2选择你自己本地拥有的对应的tomcat版本 1.3选择对应的目录和jdk版本 2.新建ma...
  • LYX082912
  • LYX082912
  • 2017年03月17日 09:58
  • 9222

论SOA架构的几种主要开发方式

面向服务架构soa以其独特的优势越来越受到企业的重视,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理...
  • chenleixing
  • chenleixing
  • 2015年04月07日 22:29
  • 54561
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Business analysis and SOA part 4 of 6: SOA delivery lifecycle and the top-down approach [by Thomas Erl]
举报原因:
原因补充:

(最多只允许输入30个字)