Understanding the Service Lifecycle within a SOA: Design Time

Design-time Considerations in the SSLC

Let's now look at the design-time aspects of the shared service lifecycle. When I refer to design time I am focusing on the lifecycle of a service before it is put into production and made available for use. Many of the requirements of design-time modeling, such as developing a service modeling methodology, will not be covered within this article, but if there is enough interest I can write about this topic in future.

Identifying business processes

One of the core tenets of SOA is the alignment of business and IT and the establishment of the playing field. By identifying a business process that the organization feels will provide value through service orientation, the service engineering team (usually a mix of business, analysts, and IT personnel) can agree on a starting point for discussions.

Many organizations find it difficult to understand where to start with SOA and which business processes may be the most appropriate. A good approach is to start by defining a catalog of needs on a whiteboard. Divide the white board area into three swim lanes, each representing short-term needs (3 to 6 months – these are often more tactical in nature), medium-term needs (6 months – 18 months), and longer term needs (greater than 18 months – often strategic needs that may change as business demands change). After you have drawn your swim lanes, start adding needs for each of the areas. Try to avoid the tendency to think in terms of applications (for example, an e-commerce site); the farther out you look, the more likely it is you'll have only a high-level view of what you need to achieve. (For example, I need to consolidate my inventory systems.) At this stage of the lifecycle, you are looking at business processes that may become part of a business offering, such as the e-commerce site.

After completing this first run-through, the service engineering team may start looking for dependencies in an attempt to determine priority, expose opportunities for reuse, or identify dependencies between needs. Looking at the sample catalog of needs below, you can see that for this organization it makes sense to focus initially on the user registration process as it is depends on many other processes and can be reused across the e-commerce functions and the corporate intranet.

Figure 2: An example catalog of needs, which provides the service engineering team with a roadmap to achieve the to-be state of the organization

Depending on the maturity of the organization in relation to service design and development, choosing which services to develop first may naturally lead to building services that do not have many dependencies in an effort to gain experience. Although such thoughts are valid, it is important early in your organization's maturity to become familiar with service modeling techniques, such as strong contract and policy definition, that promote reuse. The service engineering team must be aware that the notion of reuse has been touted to business many times before, often with little success. Due to the shorter cycles of service development versus traditional application lifecycles, the service engineering team has the ability to demonstrate early success by focusing on building a series of foundation services from the short-term catalog that can be leveraged quickly across initiatives.

It is important to recognize, however, that the selection of initial services, in particular dependent services, should be balanced with the ability of the service engineering team. A new team will require time to become more experienced in the design phases of the SSLC. A dependent service identified through the services catalog may appear to be a good candidate due to the high level of reuse, but it may not be appropriate for a less mature team. If a service has upstream dependencies that span lines of business, provide enterprise quality functions, or are subject to strict quality of service regulations, it may not be an ideal initial candidate.

On the other hand, a service with a defined process and known end points that are controlled, mature, or small in scope and that is discrete enough to be built and rebuilt, if necessary, in a short amount time is a prime candidate for initial development. Such initial services should be able to be proofed out quickly to validate assumptions, methodologies, and processes. It takes experience and practice to get the design correct. Trial and error, especially in the formative stages of your SOA initiative, are an important mechanism to determine what works and what does not within your organization. Choosing stand-alone services without some dependencies early may limit the service engineering team's opportunity to learn important lessons in this formative stage.

Service design and modeling

The goal of the service design and modeling phase is to establish a consistent approach to defining service candidates based on the business process identified through the catalog of needs. This is where the "rubber hits the road," so to speak, with the service engineering team often white boarding the business process, decomposing the steps, and discussing current and future needs. In order for this to be effective, a consistent methodology for design should be established with common language defined that both business and IT understand.

A service design methodology provides the service engineering team a series of steps or activities that the team can use to decompose the business process to identify which aspects may make sense to be developed into a service based on service-oriented principles of design. This design methodology is something many organizations initially struggle with, especially in service granularity. Too fine-grained and you may get a proliferation of services that you cannot reuse; too coarse-grained and it may be difficult to get your hands around. Until the team feels comfortable with the modeling process, it should focus its activities on well-defined business processes that may not have large enterprise requirements, such as high throughput, long-running transactions.

Although technically not part of the modeling phase (but likely part of the modeling methodology), my experience has shown that it is important for organizations to invest time in defining service categorization guidelines. These guidelines should define what aspects of a service determine whether it may be a line-of-business (LOB) or application-level services versus an enterprise service with special needs. These guidelines may include throughput, quality of service (QoS), uptime, criticality to the business, and how many consumers are utilizing the service. In addition, these guidelines are very important to beginning to define organizational governance controls in relation to how services are funded, managed, and so on. Developing the guidelines can be a full-time job in itself but starting small and defining just what is required for current needs is a good approach. What's more, service categorization may assist in grouping similar functions and identifying business owners for these functions. Remember that you can revisit the guidelines later as the need arises.

Figure 3: Service categorization and its relation to SOA governance; this categorization may assist in the definition of organizational governance controls of SOA assets.

Building on the services catalog example, the organization may have established categories of enterprise services and line-of-business services. Let's look at these in a little more detail.