Related Topics: SOA & WOA Magazine

SOA & WOA: Article

SOA Book Excerpt: Service Oriented Modeling and Architecture - Part 2

An SOA Reference Architecture

The next step in this technique is called process decomposition. In process decomposition, we decompose business processes into their constituent subprocesses and further into more atomic activities or tasks. The resultant process model depicts both the business-level and IT-level flow of events that realize a business process. It also forms the basis of candidate service identification. A process is a group of logically related activities that use the resources of the organization to provide defined results in support of the organization's objectives. Process models describe the work that an organization is involved in and the behavior of systems the organization uses. Each business process in the scope of the business or IT transformation is decomposed into subprocesses and further into leaf-level subprocesses. Each activity in the resultant process model or process breakdown tree is considered a candidate for service exposure. Hence, each is added to a list called the service portfolio. At this point, the service portfolio consists of all the subprocesses, activities, and tasks from the process model definitions for every single process. The "Service Portfolio" section of the service model work product is the recipient of the list of candidate services that are identified in this step.

Decomposition of processes into its activities and tasks also assists in identifying commonalities and variations between multiple business processes. The common activities or subprocesses provide good candidates for services while the points of variability enable the design of the system in a way that fosters design resiliency and makes the system more adaptive to incorporate future changes. Variations in a system are usually identified across three aspects: structures, processes, and rules. Externalizing these variability points enables configurable injection of flexibility into system design. Variations may also suggest new services based on types, processes, and rules.

Existing Asset Analysis
Existing asset analysis is a bottom-up approach in which we examine assets such as existing custom applications, packaged applications, and industry models to determine what can be leveraged to realize service functionality. This analysis is also designed to uncover any services that may have been missed through process decomposition. While you are analyzing existing legacy and custom applications, we recommend performing a coarse-grained mapping in which you map business functionality in the portfolio of existing applications to the business processes and determine which step (as identified through domain decomposition) in the process can be potentially realized by some functionality in existing applications. We do not recommend performing a fine-grained mapping to specific transactions and batch processes within legacy application at this stage.

During the coarse-grained mapping activity, a detailed understanding of the application's state and quality is obtained that will allow the assessment of technical risks associated with the services that are going to be realized by the existing system functionality. For the applications that have such technical risks associated with their usage for service implementation, we recommend scoping some technical prototypes to test things like basic connectivity, protocol issues, data structures and formats. This prototyping will help mitigate the project risks that might otherwise crop up during the later stages, for example, during implementation.

With this technique, we can not only start thinking about service realizations using existing assets but also identify new services. These new services will be added to the service portfolio. At this point, the service portfolio consists of potential services derived from both a top-down and a bottom-up approach.

Goal Service Modeling
Goal service modeling (GSM) is the third of the three techniques and is used to validate and unearth other services not captured by either top-down or bottom-up service identification approaches. It ensures that key services have not been missed. GSM provides the key link between the business goals and IT through the traceability of services directly to a business goal. The attainment of the goal, through the supporting service, is measured through the KPIs and its metrics that were documented as a part of the input from the business. GSM also ensures that stakeholder involvement and accountability are maintained through their consent on the business goals that needs to be achieved. Services directly linked to the business goals would then have a higher probability of being prioritized and funded for subsequent design and implementation. It is worthwhile to point out that GSM may be used as a scoping mechanism that assists in defining the scope of a project by focusing deeper into the problem domain. A problem domain is often too large to be tackled in one iteration and hence narrowing down and identifying an area that provides the highest impact (by realizing one or more business goals) to the business in a reasonable and acceptable timeframe is a recommended way of scoping a project initiative. Once the scope is defined around a business goal, not only can services be identified through the GSM technique but also the top-down (domain decomposition) and bottom-up (existing asset analysis) techniques may be performed on the given scope of the project.

Identifying business goals is a nontrivial task. It is not uncommon for clients to be grappling for ways to articulate their real business goals. SOA architects are not the ideal consultants who can be of much help to the business people. The business analysts and SMEs are the ones who come to the rescue, helping the clients to clearly articulate their business goals.

The business goals are usually stated in a way that are too lofty and at a very high level. It is difficult and often impossible to try to identify and associate a service to these lofty goals. The recommended approach is to work closely with the business and domain SMEs to decompose the goals into subgoals, and keep decomposing until the point that a subgoal is actionable. Actionable here means the attainment of what I call as the "Aha!" factor - I can identify an IT function that I can use to realize this subgoal. Hence, each business goal is usually decomposed into subgoals, and then services are identified that can realize them. This approach differs radically from the top-down and bottom-up techniques, and therefore you have a high potential of discovering new services. These new services are added back to the service portfolio. Some of the discovered services can be found to be already present in the existing service portfolio. This is a good thing, a validation step that ascertains that more than one technique for service identification has identified the same service.

What do we achieve in the service identification phase?

  • We have taken a three-pronged approach to identify candidate services.
  • Each identified candidate service is added to the service portfolio.
  • FAA is performed or leveraged to provide a mechanism to group services - the service hierarchy.
  • The service grouping may be iteratively refactored to provide the best categorization of services.
  • For functionality in existing applications identified for use to realize service implementations, a technical assessment is performed to assess the viability of reusing the existing application for service implementation.

From a service model standpoint, what have we addressed?

  • We are able to provide a service portfolio of candidate services.
  • We categorized the services into a service hierarchy or grouping.

With this, we move on to the second phase in the method: specification of services, which will be discussed in Part 3.

Links to developerWorks Articles

Arsanjani, A. Service Oriented Modeling and Architecture, IBM developerWorks, November 2004.

Arsanjani A.; Zhang, LJ.; Ellis, M.; Allam, A.; Channabasavaiah, K. Design an SOA solution using a reference architecture, IBM developerWorks, March 2007.

Arsanjani, A.; Ghosh, S.; Allam, A.; Abdollah, T.; Ganapathy, S.; and Holley, K. SOMA: A method for developing service-oriented solutions, IBM Systems Journal 47, No. 3, p377-396,2008.

•   •   •

This chapter is an excerpt from the new book, Executing SOA: A Practical Guide for the Service-Oriented Architect authored by Norbert Bieberstein, Robert Laird, Keith Jones and Tilak Mitra, published by IBM Press, May 2008, ISBN 0132353741, Copyright 2008 by International Business Machines Corporation. All rights reserved.


More Stories By Tilak Mitra

Tilak Mitra is a Certified Senior IT Architect at IBM. He specializes in mid- to large-range enterprise and application architectures based on J2EE, MQ, and other EAI technologies. You can reach him at [email protected]

More Stories By Norbert Bieberstein

Norbert Bieberstein, solution architect for IBM's Enterprise Integration team, has extensive first-hand experience with customers migrating to SOA-based On-Demand solutions.

More Stories By Keith Jones

Keith Jones, PhD, IT architect at IBM Enterprise Integration Solutions, focuses on helping customers define and implement service-oriented architectures.

More Stories By Robert Laird

Robert Laird is an IT architect in IBM's SOA Advanced Technologies group.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.