Fastening the SOA/SOMA Service identification

approaches with Project environments

Skill Level: Intermediate

Gandhi Sivakumar (gandhis@au1.ibm.com)

Senior IT Architect
IBM

25 Feb 2010

The motivation towards Service Oriented Architecture (SOA) is reuse. An entity

developed to fulfill a particular business functionality should possess the capability of
being used again to cater to the changing business needs. The IBM developed SOA
paradigm termed SOMA (Service Oriented Modeling and Architecture) provides
techniques at various dimensions to adopt SOA. In projects leveraging SOA/SOMA,
services are identified, designed and implemented. Various approaches exist for the
service identification process and each one is best suited for a particular project
environment. This article is aimed to analyze the existing approaches, project
environments and recommend the best fit approach for each environment.

SOA/SOMA service identification

In SOA based projects, services are identified using the following approaches:

• Top down approach

• Bottom up approach
• Meet in the middle approach
(Note: An extension to all the above approaches exists which is termed as "Goal
Service Model" detailed later).

IBM's SOMA Method has the capability to handle the above approaches. It provides
best practices and prescriptive guidance to support such activities.

Fastening the SOA/SOMA Service identification approaches with Project environments

© Copyright IBM Corporation 2010. All rights reserved. Page 1 of 7
developerWorks® ibm.com/developerWorks

Top down approach

Various methods exist to perform top-down decomposition in which the business
requirement is decomposed into elements of the lowest level of granularity.
Following are such genre of methods:

• Information based method

• Process Modeling based method
• Requirements based method
Eventually, based upon the anticipated business forecast, the resulting elements are
refactored/ or as is selected as a service. For example consider a business
requirement to manage an order from the front end Customer Relation Management
system. Using an information based top down approach, the Order can be broken up
into the following elements:

• CustomerDetails
• AddressDetails
• CustomerContactDetails
• ProductOrderDetails
• ProductOrderItemDetails
Depending upon the future business need, elements like ProductOrder and
ProductOrderItem can be refactored as "ManageProductOrder" which is a service
and other three can be decided to exist as separate services. Such identified
services can be consumed by external or internal services and will be plugged into
multiple back end applications to fulfill the business need.

Bottom up Approach
Bottom up approach is targeted to exposing the existing application as services.
Services served by legacy applications can be re-factored to build up composite
services based upon the business need. (Note: Exposing legacy applications as
services can be done by using off the shelf available adapters). Such a composite
service eventually can use multiple legacy applications to fulfill the intended
business need. The SOMA method defines this approach as "Existing Asset
Analysis" where the term Asset refers not only to legacy systems, but to industry
frameworks and standards as well as packaged applications that may be used in this
context.

Fastening the SOA/SOMA Service identification approaches with Project environments

Page 2 of 7 © Copyright IBM Corporation 2010. All rights reserved.
ibm.com/developerWorks developerWorks®

Meet in the Middle Approach

Meet in the middle approach focuses on accounting both decomposition of the
business process into granular elements and mapping them to the existing
applications. Wherever a gap is observed i.e an element not fitting into the
functionality of the existing applications, it becomes eligible to be a potential
candidate for a new service requiring upgrading of the existing legacy application to
execute the business need. Table 1 re-iterates the example discussed in Top down
approach for this case:

Table 1. Top-down approach

S1 No Elements Legacy Remarks
application
mapping
1 CustomerDetails Mapped- CICS
Legacy1 Transaction
2 AddressDetails Not Mapped Gap identified
3 CustomerContactDetails
Mapped- Application
Legacy1 programming
interface
4 ProductOrderDetails
Mapped- Access to
Legacy2 packaged
application
interface
5 ProductOrderItemDetails
Mapped- Access to
Legacy2 packaged
application
interface

In the above example the element AddressDetails is not mapped to any of the
existing legacy application. In order to fulfill the business need i.e
ManageCustomerOrder this functionality has to be augmented in legacy
applications. In cases where the client is not willing to invest in spending on the
legacy applications (reason could be that the legacy applications might need to be
worn out in the transformation), this functionality can be built in the middleware. In
this case the service could be made flexible to receive complete address details
from the consumer or just the AddressIdentifier. Say consumer 1 does not have the
capability to send the address structure (as we discussed earlier the reason could be
that this consumer is expected to be torn out during subsequent releases or the
client does not own the privilege to make changes to the consumer application) then
it can just pass the AddressIdentifier. The service component will perform the
functionality of translating the Address identifier to Address structure.

Fastening the SOA/SOMA Service identification approaches with Project environments

© Copyright IBM Corporation 2010. All rights reserved. Page 3 of 7
developerWorks® ibm.com/developerWorks

Goal Service Modeling

SOMA introduces an extension to the Meet in the middle approach termed as "Goal
Service modeling (GSM)" where the Services identified using any of the above
approaches in a tactical environment is ensured to be aligned to the strategic vision
of the business. (Note: Logically GSM can be applied for other approaches as well).
In addition, GSM proposes tagging each service with KPIs (Key Performance
Indicators) to gauge the performance of each service. The KPIs are initially used to
track the extent of success in achieving the designated business goal. Note that
services provide a mechanism to fulfill goals.

In the next section we discuss the project environments and map the approaches to
each environment.

Project environments
In reality, three different project environments exist:

1. Green field based environments

2. Weaker brown field environment (normally termed as brown field

environment)

3. Stronger brown field environment (normally termed as brown field

environment)

Figure1 shows the various SOA service identification approaches and the best fit to
project environments.

Figure 1. SOA service identification approaches

Fastening the SOA/SOMA Service identification approaches with Project environments

Page 4 of 7 © Copyright IBM Corporation 2010. All rights reserved.
ibm.com/developerWorks developerWorks®

Green field based environments

In this environment the product or solution is developed from the scratch. Most times
this environment is applicable to the development of product against solutions
focused on Integration. In such an environment, the designer has no clue about the
consumers or target applications which have to be used.

The designer might have to rely on industry process models like the e-TOM
(enhanced Telecommunications Operations Map) for Telecom industry specific
products or IFW-APM (IBM Financial Services Industry Model- Analysis Process
Model) for banking industry specific products. The best approach for identifying
services in such scenarios is the "Top-Down approach". Once services are identified
the designer can apply GSM concepts, by analyzing the long term business goals
and augment new services in case, tag with key KPIs to take the services forward to
the subsequent stages in the life cycle.

Brown field based environment

For simplicity we dichotomize brown field based environments into two categories:

Weaker brown field based environments: In this category the aim is to just
expose the existing legacy application as a service. In such cases the designer need
not care for the business process/consumer which eventually will consume the
service. In case of exposing a legacy application as a service, the designer can wrap
up the interfaces using an adapter. It is the responsibility of the consuming
applications or the intermediary to comply with the requirements of such services. At
this stage the GSM technique can be applied: The identified service(s) can be
analyzed for future need and tagged with KPIs.

So pure "bottom up approach" would be the best approach for carrying out the
service identification process in weaker brown field based environments.

Fastening the SOA/SOMA Service identification approaches with Project environments

© Copyright IBM Corporation 2010. All rights reserved. Page 5 of 7
developerWorks® ibm.com/developerWorks

Stronger brown field based environments: Solution scenarios requiring

integration of the existing applications/ enhancements to the existing applications fall
into this category. In the integration environment this requires identifying the
processes, mapping these processes to the functionality of the existing
applications/services, identifying the gaps and deciding to position the enhanced
functionality at the appropriate layers. In such scenarios it is suggested to use Meet
in the middle approach. This is because identifying services requires twining the
business processes as well as analyzing and accounting the existing legacy
applications. Similar to the other approaches this can be augmented with GSM.

Conclusion
Various general approaches to service identification exist and relevant ones should
be adopted for the appropriate project environments. This article provided analysis
of such service identification processes and fitted them to the appropriate project
environment.

Acknowledgements
The author renders her thanks to Ahamed Jalaldeen, Lead Architect SOMA
automation and Ali Arsanjani, Distinguished Engineer & CTO, Emerging
technologies, SOMA for their guidance and support in this article.

Fastening the SOA/SOMA Service identification approaches with Project environments

Page 6 of 7 © Copyright IBM Corporation 2010. All rights reserved.
ibm.com/developerWorks developerWorks®

Resources
Learn
• "Service-oriented modeling and architecture" (developerWorks, Nov 2004)
discusses the highlights of service-oriented modeling and architecture.
• Access the IBM Journal of Research and Development for a full list of the
various techniques within SOMA refer.
• In the SOA and Web services area on developerWorks, get the resources you
need to advance your skills.
• Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
• Download IBM product evaluation versions or explore the online trials in the
IBM SOA Sandbox and get your hands on application development tools and
middleware products from DB2®, Lotus®, Rational®, Tivoli®, and
WebSphere®.
Discuss
• Check out developerWorks blogs and get involved in the developerWorks
community.

About the author

Gandhi Sivakumar
Gandhi Sivakumar is an IBM Certified Senior IT Architect/ IBM Certified SOA solution
designer and works in the Architecture practice team of IBM Australia. She has been
a key towards the success of complex First of its kind projects in the business. She
has published numerous papers and filed many patents in the SOA domain. Besides
she is a member of the IBM Academy of Technology.

Fastening the SOA/SOMA Service identification approaches with Project environments

© Copyright IBM Corporation 2010. All rights reserved. Page 7 of 7