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.
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
