You are on page 1of 6

Whitepaper

Technology that Delivers with SOA-Based Process-Centric Design

Published on: August 2010 | Author: Sridharan S

© Hexaware Technologies. All rights reserved. www.hexaware.com


Whitepaper
Technology that Delivers with SOA-Based Process-Centric Design

Table of Contents
1. Introduction 03
2. SOA-Based Process-Centric Design 03
3. Guiding Design Principles 03
4. SOA in Action 04
5. Conclusion 05

© Hexaware Technologies. All rights reserved. 2 www.hexaware.com


Whitepaper
Technology that Delivers with SOA-Based Process-Centric Design

1. Introduction
A key step in application development is to capture end user needs accurately. Much of the reason systems fail to live up to their expectations
is because end users often don’t speak the same language as analysts and developers. As a result, the technology developed doesn’t
always address the right problems.

One of the most successful ways to deal with this issue is to adopt a process-centric approach. This involves defining and maintaining
business process flows that reflect the tasks performed by the users and using these process flows as the basis of communication between
end users and the development team. Taking a process-centric approach enables the organization to define the needs of the end users in a
language that is familiar.

In this paper, we will examine how Service Oriented Architecture (SOA)-based process-centric design can help to deliver significant business
benefits, tighter alignment between business and IT, and agility to respond faster to ever-changing market realities.

2. SOA-Based Process-Centric Design


In any new technology development, it is critical to identify business goals of the new system and set objectives in terms of the desired ipacts.
Typically these may include:
Reduced time to market
Improved business agility
Greater process harmonization
Reduced costs
Tighter alignment between business and IT

SOA-based process-centric design makes all these possible by linking computational resources, primarily applications and data, on demand
to achieve the desired results for service consumers, who can be end users or other service providers.

3. Guiding Design Principles


While SOA-based process-centric design offers tremendous advantages, there is a need to understand and define the ground rules for its
development, maintenance, and usage. This set of guiding principles listed below helps to influence the intrinsic behavior of a system and
the way it offers services:

Reuse is the ability to expose the functionality as shared business services.


Granularity is the extent to which a process or a service is broken down into smaller components.
Modularity is the technique used to build larger systems by combining smaller subsystems.
Componentization is the method used to expose business contracts via interfaces and thus enabling loose coupling.
Interoperability is the property which enables platform, language, location, and invocation independence.
Loose Coupling is the approach by which the implementation details are hidden from the caller, as a result, minimizing the changes
across the integration interfaces.
Service (identification, design and consumption) is the principle used in Service Oriented Analysis and Design (SOAD methodology
to identify, design and consume services.
Service compositability is the collection of services that can be coordinated and assembled to form composite services.
Process design is the means by which a process could be optimally designed for reuse by applying granularity.
Process metrics is the process of defining Key Performance Indicators (KPI) that are used to monitor and minimize bottlenecks.
Versioning is the capability to enable multiple versions of services or processes to co-exist in an SOA environment.

Having understood the guiding principles of SOA-based process-centric design, let’s now see it in action.

© Hexaware Technologies. All rights reserved. 3 www.hexaware.com


Whitepaper
Technology that Delivers with SOA-Based Process-Centric Design

4. SOA in Action
Consider a business scenario that involves a loyalty system linked with multiple airline operators. Typically, customers earn reward points for
the travel made and can redeem the reward points for air tickets when they have accumulated the requisite number of reward points.

Every participating airline that is part of the loyalty system has varying reward policies, which may change frequently depending on market
dynamics. In addition, the loyalty system needs to be able to interface with different systems for reward booking, payment, etc.

To stay ahead of the competition, the loyalty system needs to be able to:
Introduce new promotions and regulations to accelerate speed to market.
Support participating airlines’ dynamic reward policies to offer business agility and complement new processes faster.
Add new business partners and support changes to payment service providers with minimal development and ripple effect for increased
flexibility and decreased error rates.
Quickly deploy changes in business conditions to support business with improved IT capabilities.

FFM

Complete
Agent Reward
Online Booking Get Member’s Reward points
Entry & Enrollment details

Booking Rules

Business Determine member


Not Eligible
Rules Reward Eligibility

Error Page
Eligible

Member’s
Enrollment
Eligible
External System Choice?

Airline II
If Yes
Validate & Charge
Credit Card Purchase Shortage Miles Miles Shortage?
(If Any)
No

Airline II Airline I

Book Travel Book Travel

Reward Booking

Generate Reward
Certificate

Booking
Completion

© Hexaware Technologies. All rights reserved. 4 www.hexaware.com


Whitepaper
Are youProcess-Centric
Technology that Delivers with SOA-Based ready for ICD10?
Design

Some best practices that should be applied in such a scenario are listed below:
Apply the componentization principle: Avoid embedding business rules into the application so that a tightly coupled design doesn’t
constrain business.
Apply granularity, modularity, and reuse principle: Reduce time to market by enabling modifications to the business rules and process
flows quickly and independent of the application code.
Apply the loosely coupled invocation principle and interoperability along with service consumption pattern: Seamlessly
integrate other systems like payment services, booking etc. and also consume functionality from other systems as services.
Apply service identification, design, and consumption principle: Expose the repetitive business tasks as services.
For example, retrieving member information, generating reward certificates, etc.
Apply process design, granularity and composite-ability principle: Design the desired flight reward booking process and other
optimal sub-processes.
Apply process metrics, analyze the metrics and improve the business processes: Compute the number of reward booking made in
a day, loss of business due to not allowing purchase of shortage miles, etc.
Apply versioning principle: Define process and service validity and manage old and new versions of processes and services so that
they co-exist for a certain period of time before new processes and services fully take over.

5. Conclusion
As you have seen, the SOA paradigm provides compelling reasons to explore its benefits when applied as domain solutions in industries
such as travel. However, not every business case lends itself naturally to SOA-based process-centric design. It is important to assess if a
business fits the SOA solution by examining the projected business benefits. Having assessed and initiated an SOA design, if suitable, it is
important to see the implementation through to its logical end to discover the true advantages of SOA-based process-centric design.

© Hexaware Technologies. All rights reserved. 5 www.hexaware.com


Whitepaper
Technology that Delivers with SOA-Based Process-Centric Design

To learn more, visit http.//www.hexaware.com/wp-oracle.htm

Address
1095 Cranbury South River Road, Suite 10, Jamesburg, NJ 08831. Main: 609-409-6950 | Fax: 609-409-6910

Safe Harbor
Certain statements on this whitepaper concerning our future growth prospects are forward-looking statements, which involve a number of risks, and uncertainties that could cause
actual results to differ materially from those in such forward-looking statements. The risks and uncertainties relating to these statements include, but are not limited to, risks and
uncertainties regarding fluctuations in earnings, our ability to manage growth, intense competition in IT services including those factors which may affect our cost advantage, wage
increases in India, our ability to attract and retain highly skilled professionals, time and cost overruns on fixed-price, fixed-time frame contracts, client concentration, restrictions on
immigration, our ability to manage our international operations, reduced demand for technology in our key focus areas, disruptions in telecommunication networks, our ability to
successfully complete and integrate potential acquisitions, liability for damages on our service contracts, the success of the companies in which Hexaware has made strategic
investments, withdrawal of governmental fiscal incentives, political instability, legal restrictions on raising capital or acquiring companies outside India, and unauthorized use of our
intellectual property and general economic conditions affecting our industry.

© Hexaware Technologies. All rights reserved. 6 www.hexaware.com

You might also like