Understanding the Service Lifecycle within a SOA: Design Time
Enterprise Services
Enterprise services have horizontal influence and may include:
- Security needs either at the perimeter or some form of centralized entitlement, for example, compliance rules for an industry.
- Auditing of activities. Remember that auditing may be an aspect of a particular function such as foreign exchange trading but not the process of placing the trade.
- Generic exception handling.
- The service requires 24x7 reliability and must be governed accordingly.
- The service demands high volume and/or low latency throughput.
- The service, based on context of use, may require a higher level of customer service or response time. For example; if the customer profile denotes that they are a gold-class customer, a service's contract may require a different SLA.
- If the service requires interaction across lines of businesses, there may be enterprise infrastructure requirements that need to be adhered to.
- The service interacts with enterprise data. This aspect may mean that the canonical model is owned by the enterprise but the implementation to the specific user data store is owned by the line of business. Experience and reality has shown me that more often than not, a number of user data stores exist within organizations. Part of the SOA initiative may be to consolidate these aspects in the long term, but you need avoid a boil the ocean approach to your undertaking and leverage what is in place today while defining a plan for the future.
Line-of-Business Services
Such services have vertical influence and may include:
- Specific business functions such as purchase order (PO) or new hire processing.
- Presentation services with specific UI, look and feel, or wizards often used to provide visual representation for a specific business function.
- Information and access services to support CRUD (Create, Read, Update, Delete) activities for a line of business.
- Application services such as sales tracking or forecasting based on specific line-of-business data.
This categorization is by no means complete but should provide an indication of where an organization may begin their categorization efforts.
By examining the categories above you may be able to place some of your service candidates from the catalog of needs you defined previously into governable groupings and identify a number of canonical structures previously not apparent:
| Enterprise Service | Line-of-Business Service |
|---|---|
| Log into the Intranet (intranet infrastructure is typically owned by IT or a particular LOB) | |
| Update Profile (Canonical Profile) | Update Profile (Service) |
| Log into eCommerce site | |
| Seller Profile Canonical | Create Seller Profile |
| Inventory Item Canonical | Buy Movie |
| Inventory Item Canonical | Buy Book |
| View My Order Status | |
| Payment Canonical | Provide Payment Information |
| Inventory Item Canonical | Sell book |
| View Corporate News | |
| Inventory Canonical | Check Movie Inventory |
| Inventory Canonical | Check Book Inventory |
| Check All Inventories | |
| Consolidate Inventory System (long term are often planned initiatives vs. actual services) |
The point of the service lifecycle is to move towards solving business needs, and not get weighed down in a detailed taxonomy exercise. The evaluate phase of the SSLC is intended to support this reassessment based on actual usage and context. I like to think of the movie Field of Dreams with Kevin Costner in which he hears the voice repeatedly saying If you build it, they will come. This is not dissimilar to exposing services in the enterprise. Something defined for a certain usage level at a given point of time may be utilized in a completely different way in reality, often a way not considered at initial design time. Guidelines should assist in the recategorization phase.
At this stage in the process I am talking about the notion of service candidates versus service implementations. Erl (2004) suggests that candidates are potential services that may or may not be realized into the eventual design. The design process is intended to identify the inputs to future phases of design and development. It is important for the service engineering team to understanding what already exists within the enterprise verses what needs to be developed. Tooling that supports discovery of services, such as a UDDI-compliant registry, is an important component to promoting service reuse and understanding what already exists that may be leveraged.
Finally, during the modeling phase and with your understanding of the fact that you are attempting to define service candidates, the service engineering team should continue to design through the established methodology independent of realities of technical architecture and constraints of the physical environment. The intention of the service design and modeling phase is to define a desired future state. The build and compose phase of the SSLC will subject service candidates to organizational constraints in an effort to define final service implementations.
Build and compose
The build and compose phase of the service lifecycle focuses on the tasks required to develop new services and also leverage what already exists within the organization in an effort to develop new functionality more quickly and cheaply. This approach should translate into a reduction in time to market, one of the key financial benefits to SOA.
At this stage the service candidates that have been identified in the service modeling and design phase are rationalized into service operations with the infrastructure and environmental reality mapped to them. As mentioned in the modeling phase, it is important to identify the goals of the SOA initiative. Achieving these goals may not be feasible due to current restrictions or limitations in your environment but may promote some healthy discussion and potentially some form of cost benefit analysis to determine how to achieve that desired future state. For now, however, the organization needs to move ahead so your candidates must be realistic in your organizational ecosystem.
With an understanding of which service operations and implementations are realistic, you can build on any opportunities for reuse and composition identified in the previous phase. To fully leverage SOA, the notion of composition is very important to business agility. The development environment and service infrastructure tooling must facilitate design-time discovery of services and provide the ability to compose these services together to complete a business process.
Without such tooling, the success of your SOA initiative may be limited. As initial services become available to line-of-business teams and other engineering groups, opportunities for composition may be realized. In this case, while cataloging needs you identified initial dependencies. These dependencies should be interpreted as direct opportunities for building composable services and should provide the tangible benefit of reuse. I have hinted at composition throughout this article but the importance of such activities is directly relevant to the build and compose phase of the SSLC.
Consider the catalog of needs example: An initiative called Consolidate Inventory System has been identified in the long-term goals. At first review this task may be interpreted as physically retiring old inventory systems and consolidating the repository into one master source. Although this may indeed be the case, if a cost benefit analysis indicates it is more cost effective to retire old systems, the activity may also indicate a less obtrusive approach. The services engineering team may produce a series of logical data services hiding the physical end points to the consumer. Such an approach of building a ubiquitous data-access layer would directly leverage existing check inventory X services developed in the mid-term catalog of needs through composition. The consolidate inventory systems initiative may then require little more than decision logic based on a canonical representation of an inventory document to determine which end points need to be modified. This sort of distributed CRUD logic should be provided through the Service Infrastructure Tooling. An example of this may be the BEA AquaLogic Data Services Platform.
Very often services originate at the line-of-business level rather than through enterprise initiatives as typically this is where project funding and need is driven. As a result, the if you build it, they will come scenario may result in design-time discovered services that may not be good candidates for reuse. They may not provide adequate performance or consistent schemas. Although they are available in the enterprise, they should remain as application-level services. As a result, the organization must begin to establish a governance process to control enterprise visibility to services. Very often, service registries are leveraged to provide control mechanisms and processes to ensure service quality. Many of these aspects must be addressed in the publish and provision phase of the service lifecycle.
Finally, to provide rapid development, experience has shown that standardizing on tooling enables the organization to leverage learning and reuse across SOA initiatives. This is not to say everyone must use the same IDE or one specific tool; rather, any tool that is used must function in a similar fashion, must support standards, and must promote a reduction in the learning curve if a developer is required to support other projects with different tools. In addition, these tools must support the ability to easily capture metrics with regard to reuse and time-to-market for services developed. Capturing metrics through the service lifecycle provides invaluable information to the organization when demonstrating the success of a SOA initiative.
The BEA Domain Model
As with many methodologies, an underlying theme need to be established that unifies all other activities. In the case of BEA and SOA this is BEA's Domain Model (requires registration). A number of articles on Dev2Dev describe the importance of understanding each of the aspects of SOA (see Successfully Planning for SOA by David Groves for a great introduction). The Shared Service Lifecycle leverages this model and provides tangible control points along the way. In the case of the design time phases as identified in this article, the influence of the domain model is represented through the need to define projects and applications in alignment with the catalog of needs through an architectural approach.
This approach often begins with a vision and is initially implemented through foundation services or building blocks. Although not as critical in the design phase as it may be in the run-time aspects of the SSLC, governance begins to exhibit a degree of influence across the process, in particular when determining initial service realizations.
The second part of this article series will demonstrate the importance of measuring costs and benefits of deployed services and an increased focus on how services are governed at run-time. In addition, both the design-time and run-time phases of the SSLC require close alignment with the business strategies and processes. This was evident in the need to identify and design business processes that become our service candidates and may be composed into reusable services to achieve business agility.
Summary
By further understanding design time needs with regard to shared service lifecycle, organizations looking to SOA to promote reuse and increase business flexibility may recognize that establishing fundamentals early, such as methodology, categorization guidelines, and development tools, is crucial to early and continued success. By beginning to break the traditional application development paradigms and focus on business processes as the blueprint for moving forward, service engineering teams can provide closer alignment to business needs in a timely and efficient manner.
The second part of this article will focus on the run-time aspects of the shared service lifecycle.
References
- SOA Compass: Business Value, Planning and Enterprise Roadmap, Bieberstein et al (2005); available at Amazon.com or other retailers
- Business Benefits of Implementing SOA by Tom Dwyer (The Yankee Group, 2005)
- Service-Oriented Architecture: Concepts, Technology & Design, by Thomas Erl (2004); available at Amazon.com or other retailers
- W3C (2004) Web Service Management: Service Life Cycle
Quinton Wall is a Sr. Product Marketing Manager for Integration at BEA where he is responsible for articulating the strategic vision and direction of the products such as WebLogic Integration and AquaLogic Integration.