Fastening the SOA/SOMA Service identification approaches with project environments

Gandhi Sivakumar (gandhis@au1.ibm.com), Senior IT Architect, IBM Australia

Summary: 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.

Date: 01 Mar 2010

Level: Intermediate
PDF: A4 and Letter (32KB | 7 pages)Get Adobe® Reader®
Also available in: Spanish

Activity: 2278 views

Comments: 0 (Add comments)

Average rating (based on 0 votes)

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 G

" oal 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.

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
Fastening the SOA/SOMA Service identification approaches with project environments

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.

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 application mapping Remarks
1 CustomerDetails Mapped- Legacy1 CICS Transaction
2 AddressDetails Not Mapped Gap identified
3 CustomerContactDetails Mapped- Legacy1 Application programming interface
4 ProductOrderDetails Mapped- Legacy2 Access to packaged application interface
5 ProductOrderItemDetails Mapped- Legacy2 Access to 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.

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.
Fastening the SOA/SOMA Service identification approaches with project environments

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

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.

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.
Fastening the SOA/SOMA Service identification approaches with project environments

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.

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 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.

Trademarks | My developerWorks terms and conditions