In the articles leading up to this final installment in our series, we established relevant business service models and service delivery strategies. These two important parts of an SOA project tie into the first of two processes responsible for producing the actual services. This process is called service-oriented analysis and it represents an important, initial lifecycle phase that requires the coordinated collaboration of business analysts and technology architects.
The service-oriented analysis process
Different organizations have adopted different approaches to analyzing business automation problems and developing corresponding solutions. Years of effort and documentation will often have been invested into well-established processes and modeling deliverables.
The process described here is not intended to supplant existing procedures. Instead, it proposes a set of supplementary steps that help shape the organizational automation logic in preparation for the service-oriented design processes. These steps raise issues that combine the use of service models, service-orientation principles and other key considerations into a preliminary definition of services.
It is important to note that this process is generic and high-level. It establishes a starting point from which an organization is expected to customize a variation that is most suitable to its goals and most compatible with its existing business analysis approaches. The primary questions addressed during the service-oriented analysis phase are:
- What services need to be built?
- What logic should be encapsulated by each service?
- The extent to which these questions are answered is directly related to the amount of effort invested in the analysis.
The overall goals of performing this analysis are as follows:
- Define a preliminary set of service operation candidates.
- Group service operation candidates into logical contexts. These contexts represent service candidates.
- Define preliminary service boundaries.
- Identify encapsulated logic with reuse potential.
- Ensure that the context of encapsulated logic is appropriate for its intended use.
- Identify preliminary issues that may challenge required service autonomy.
- Define any known preliminary composition models.
Figure 5 shows the three primary steps that comprise the service-oriented analysis process.
Step 1 requires us to establish the functional scope of what we are planning to deliver. Unlike traditional development projects, the scope of a service delivery project is not always tied to a business process requiring automation or to some extension or enhancement to an existing solution. Although service delivery projects can have a scope that is defined by a unit of business process logic, it is not uncommon to only deliver a single process-agnostic service that will establish itself as a part of the overall service portfolio for use by future automated business processes. In this case, the scope is not as much a specific business task as it is the delivery of a series of tasks (operations) associated with a generic service context.
As part of the second step we are asked to identify existing application logic that is already, to whatever extent, automating any of the requirements identified in Step 1. While a service-oriented analysis will not determine how exactly services will encapsulate or replace legacy application logic, it does assist us in scoping the potential systems affected in order to raise potential autonomy issues.
Finally, Step 3 introduces the concept of service modeling—a process by which service operation candidates are identified and then grouped into a logical context. These groups eventually take shape as service candidates that are then further assembled into tentative compositions. This step essentially represents the service modeling sub-process which we will explain shortly.
Service-oriented analysis can be applied at different levels, depending on which of the SOA delivery strategies is employed. As explained in Part 5 of this series, the chosen strategy also determines whether some form of enterprise service model is created and to what extent its detail is defined. It is with this perspective of an enterprise SOA that the service-oriented analysis process described here is commonly applied, using whatever has been established within the enterprise service model as its guide.
The service modeling process
Service modeling can be viewed as an exercise in organizing the information we gathered in Steps 1 and 2 of the parent service-oriented analysis process. Sources of the information required can be diverse, ranging from various existing business model documents to verbally interviewing key personnel that may have the required knowledge of a relevant business area. This process can therefore be structured in many different ways.
Figure 6 illustrates a sample process that provides us with an indication of the amount of effort required to properly organize granular actions or pieces of functionality (represented as operation candidates) into proposed or candidate services that are subsequently combined into candidate service compositions.
The primary goal of service modeling is to figure out how services are ideally defined on a logical level so that we know what to design and build in subsequent project phases. It is therefore helpful to continually remind ourselves that we are not actually implementing a design at this stage. We are only performing an analysis that results in a proposed separation of logic used as input for consideration when modeling the services. In other words, we are producing abstract candidates that may or may not be realized as part of the eventual concrete design.
The reason this distinction is so relevant is because once our candidates are submitted to the design process, they are subjected to the realities of the technical architecture in which they are expected to reside. Once constraints, requirements and limitations specific to the implementation environment are factored in, the end design of a service may be a significant departure from the corresponding original candidate. So, at this stage, we do not produce services; we create service candidates. Similarly, we do not define service operations; we propose service operation candidates.
The overall delivery strategy chosen by an organization generally determines the amount of time project teams have to spend on service-oriented analysis and service modeling. The service models that have been chosen determine the types of service and composition candidates that are defined during these processes. The quality and longevity of these service definitions can be greatly improved through the incorporation of an enterprise service model. Service-oriented computing provides us with the ultimate opportunity to unite and align the business and technology domains of an enterprise. Leveraging and properly positioning your in-house business analysis expertise is a critical success factor for achieving this goal. I hope this series has been helpful in moving your enterprise toward a more business-centric SOA.
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.
About the author
Thomas Erl is the world's top-selling SOA author and Series Editor of the "Prentice Hall Service-Oriented Computing Series from Thomas Erl" ( www.soabooks.com). Thomas is also the founder of SOA Systems Inc., a firm specializing in strategic SOA consulting, planning, and training services ( www.soatraining.com). Thomas has made significant contributions to the SOA industry in the areas of service-orientation research and the development of a mainstream SOA methodology. Thomas is involved with a number of technical committees and research efforts, and travels frequently for speaking, training and consulting engagements. To learn more, visit www.thomaserl.com.