Apr - Jun 2007libvolume3.xyz/computers/btech/semester8/servicesorientedarchitec… · Enterprise...

SETLabs BriefingsAdvisory Board

Aveejeet PalitPrincipal Solutions Manager,System Integration Practice

Deependra MoitraAssociate Vice President,Software Engineering &

Technology Labs

Gaurav RastogiAssociate Vice President, Global Sales Effectiveness

George Eby MathewPrincipal Researcher,

Software Engineering & Technology Labs

Kochikar V PAssociate Vice President,

Education & Research Unit

Raj Joshi Managing Director,

Infosys Consulting Inc.

Ranganath MVice President & Head,

Domain Competency Group

Srinivas UppaluriAssociate Vice President & Head,

Global Marketing

Subu GoparajuVice President & Head,Software Engineering &

Technology Labs

Wiring the SOA enterprise

Service-oriented architectures being complex, lack of sheer clarity on when, where and how to begin can itself become a show stopper for SOA implementations. The complexity arises from enormous impact SOA has on the way firms undertake application development, deploy-ment, integration, IT processes, organizational structure and governance. It is not uncommon for organizations to delay SOA-related initiatives for these reasons.

There are few established best practices that have helped firms in this dilemma. For example, firms that are able to sign up IT and business commitments upfront are able to

traverse the journey with a certain degree of ease. Firms are able to minimize the risks of uncertainty and enhance the scope for sustainability by taking up small projects that are strongly linked to business and technology value based metrics upfront. Measuring success against the success criterion in a structured, well understood and documented manner has helped in the way organizations have learnt from their SOA journeys and have enhanced the repeatability of SOA deployment processes.

Since the lines between infrastructure and application, and application and business process model are bound to blur in SOA implementations, sufficient orientation to move away from mindsets that catered to a pre-defined, largely static, one-to-one environment into one that assumes almost continuous functional change is critical. These SOA champions will also need a different set of skills, processes and tools for IT operations and application management and a favorable governance framework. With these, most firms will do a good job in this journey.

In this issue of SETLabs Briefings, which is sequel to last quarter’s SOA volume, we evaluate deployment architectures such as those governed by standards like JBI,SCA, and MQM. We look at Web 2.0 and SOA as two complementary trends that empower the service consumer. For firms that are exploring business transformation we look at service-oriented and process-oriented approaches as key to building peo-ple-oriented enterprises. One of our articles help establish the relationship between Enterprise Architecture, Service Oriented Architecture, and Solution Architecture. The issue is not complete without looking at implications of SOA in the context of industry verticals. We examine five verticals: communications service providers, pharma, automotive retail, healthcare and banking.

I hope you enjoy the rich coverage of SOA issues that we provided in two separate volumes which are truly a treat to the IT leadership of any firm. As always we wel-come your feedback. My thanks to our editors, authors and contributors for making this and the previous issue special to SOA enthusiasts and those on their way to becoming one.

George Eby Mathew [email protected]

Tutorial: Evaluating Enterprise Service Bus architectures By Bijoy Majumdar, Terance Dias, Ujval Mysore and Varun PoddarESB is a new architecture, based on SOA principles, often talked about as the backbone of SOA enablement. In this tutorial, the authors explore the ESB deployment architectures governed by standards such as JBI, SCA and MQM.

Spotlight: Exploring complementarities between Web 2.0 and SOABy Shaurabh Bharti, Abhishek Chatterjee and Geo Phillips Web 2.0 can be conceptualized as a key enterprise computing trend, complementing SOA. It is now possible to envisage a rich ecosystem of interoperable business services, connected through common interfaces.

Viewpoint: Service and Process Orientation - Catalyzing Business Transformation By Manish SrivastavaPeople oriented organizations are better positioned to leverage their IT systems as a change agent. The author builds a case for building people oriented enterprises through service and process orientation.

Perspective: Service Oriented Architectural approach to building Healthcare solutions By Jai Ganesh, PhD and Vijaya Bhaskar Peddinti In the healthcare domain, SOA is essential to realizing real-time access to patient data from diverse systems, owned by different stakeholders. The authors propose a reference SOA based architecture, leveraging web services for healthcare service providers.

Framework: SOA implementation in Transaction Banking domain By Jayakumar Venkataraman and Siddhartha Vijay Joshi SOA is ideally positioned to infuse flexibility and interoperability in the IT architecture, while addressing key business concerns. The authors discuss the role of SOA in the transaction banking space, with a focus on cash management.

Practitioner’s View: Recasting Enterprise Integration in SOA mould By Rakesh Mishra and Yale Yu The roadmap ahead for leading integration products, would most probably involve recasting them with aflavor of SOA. The authors articulate the concept of SOA ‘empowered” integration architecture.

Perspective: SOA-based Enterprise Architecture for Communication Service Providers By Gnanapriya C and Binildas C A The SOA payoff for communication service providers is immense - it can help them to become total solution providers, for instance. In this perspective, the authors emphasize that SOA helps CSPs to work around issues and fill gaps to provide next generation services.

Framework: Chemistry Workbench – A composite services approach to transform drug researchBy Anirban Ghosh, PhDSOA-based Chemistry Workbench remediates in the Lead Optimization Phase of Research to align to the compelling pressures of dynamic drug discovery research.

Perspective: SOA: The missing link between Enterprise Architecture and Solution ArchitectureBy Jaidip Banerjee and Sohel Aziz Though the objectives of both EA and SOA are somewhat similar, EA is a framework that covers all dimensions of enterprise IT architecture. This article explores the role of the service portfolio and repository in bridging the gap between the solution architecture and SOA.

Implementation: Addressing OEM integration through a SOA based integration layerBy Mani Krishnamurthi, Anandh Rajappa and Shashikiran Suvarna Is there a business need for retail integration in the automotive industry ? What are the business and technology challenges for such an integration exercise ? This implementation guide delineates an auto retail integration solution.

Index

SETLabs BriefingsVOL 5 NO 2

Apr - Jun 2007

3

13

37

43

49

89

59

69

21

31

81

4

“SOA will enable bringing rigid engineering principles to building business solutions. On the same note, it will enable

availability of business modules which can be assembled on the fly.”

“Enterprises with intense focus on people-orientation are future proof and continue to thrive in the world of

shifting priorities.”

Manish Srivastava Principal ResearcherMTC Centre of ExcellenceInfosys Technologies Limited

Dr. Srinivas PadmanabhuniPrincipal ResearcherWeb Services/SOA Centre of ExcellenceSETLabs, Infosys Technologies Limited

3

SETLabs BriefingsVOL 5 NO 2Apr - Jun 2007

Evaluating Enterprise Service Bus architecturesBy Bijoy Majumdar, Terance Dias, Ujval Mysore and Varun Poddar

A one-size-fits-all ESB product strategy does not work

An Enterprise Service Bus (ESB) is an integration platform containing

synchronous/asynchronous messaging that provides secure and reliable interoperability between enterprise services though open standards, rules-based transformation and routing. Different vendors have tweaked this basic definition of the ESB to fit their products. Irrespective of the architecture that the product follows, an ESB is very helpful in realizing Service Oriented Architecture (SOA). In this article we provide an overview of different ESB architectures while specifying how they fulfill the different criteria for being an ESB.

AGILE ENTERPRISE ARCHITECTUREEnterprises require flexible business processes to easily adapt to the changing business requirements. This is the major driving force behind the upsurge of SOA. SOA envisages the enterprise as a collection of reusable services that can be dynamically discovered and used. The services are defined using standards-based

contracts that abstract business functions from their implementations. The result is a loosely coupled environment of self-contained services that can interact with each other to provide flexible business solutions. Many organizations have come up with an SOA roadmap to adopt SOA in a phased manner. Globally, independent vendors have come out with products to facilitate the roll out of SOA in an enterprise.

SOA REALIZATION THROUGH ESBAn ideal SOA enablement of an enterprise requires identification of loosely coupled services - granular or coarse-grained -- along with a middleware to support integration of these services. ESB which is based on the principles of service orientation is seen as an important enabler for SOA and is aptly mentioned as the backbone of SOA. ESB is a new architecture that exploits Web services, messaging middleware, intelligent routing and transformation [1]. Though ESB is defined differently by different vendors, the least

4

common denominator of an ESB is considered to have the following features:

It must provide location transparency It must provide standards based

messaging platform for enterprise integration

It must provide loose coupling in communication by abstracting protocols, data formats, and implementation platforms

It must support for intelligent content-based routing and transformation

It must be light weight with a pluggable architecture

It should have a single point of administration similar to hub-spoke model of earlier EAI tools

It may have the capability of being deployed in a distributed environment

It may support lookup/dynamic binding of services (integration with registries) and versioning of services.

BENCHMARK PARAMETERSAn ESB provides its functionalities in the form of services. These services are themselves configurable and additional services can easily be added. The extensibility of an ESB also allows adding third party services to interoperate with the existing set of services. These services enable the integration of enterprise-wide applications by allowing messages to mediate through them across different departments and components. The connectivity between application and ESB is in coherence with the standards-based approach of SOA and is not proprietary. The services offered by the ESB can be extended to provide security, transactional support and such other things to increase the robustness of the platform. Also, it can include

other business specific services like service registry, business process choreographer etc., which will result in a platform with multiple dimensions. An ESB can be benchmarked based on few essential characteristics of ESB architecture viz., Support for open standards Loose coupling Light weight pluggable architecture Management and Monitoring capabilities Security Deployment ease.

One of the key selling points of ESB is its cost effectiveness. The “incremental integration” model is well known to the enterprise architects to provide a short term return on investment with a vision of large scale integration. ESB’s service oriented features inherently make it suitable for such integration. Once the backbone is laid, the newer applications can be integrated easily to collaborate with others in an enterprise-wide distributed application.

CATEGORIES OF ESBDifferent ESB vendors have different strategies. This has led to many definitions of ESB which in turn has led to the emergence of ESB products that are very different from each other. The ESB products in market can be categorized into one of the following:

1. EAI-based products- These kind of ESBs are built on EAI products. Many EAI vendors position their products as ESBs by adding many open standards in addition to the already existing proprietary formats of communication.

2. Service-based architecture- These are products built on architecture

5

standards and specifications that support service based integration. Java Business Integration (JBI) is an ESB architecture specification. It was developed for building ESBs. Though Service Component Architecture (SCA) specification is not developed specifically for an ESB, the products based on it can be considered to fall into this category. Message Queue Middleware (MQM) is a standard architecture and ESBs based on it also fall into this category.

3. WS Standards Compliant Solution- These are products that are just implementations of a collection of WS Standards.

An overview and comparison of the three service-based architectures viz., JBI, SCA and MQM is detailed in the following sections.

JBI ARCHITECTUREJBI is a set of specifications aimed at creating a standard based architecture for integration solutions. It is aimed at removing the vendor lock-in that arises by using proprietary integration solutions such as EAI tools. It provides an architecture that allows different applications to integrate with each other using XML messages and WSDL interfaces. The JBI Architecture has the following high level components:

Component Framework Normalized Message Router Management.

The Component Framework provides the environment for deploying, monitoring and managing components like service engines and binding components.

Installcomponents,

Deploy artifactsand manage

service lifecycle

JMX basedAdministration

ServiceEngine1

ServiceEngine2

Delivery ChannelDelivery Channel

Normalized Message Router

Binding Components Binding Components

Delivery ChannelDelivery Channel

ExternalService1

ExternalService2

Figure 1: Architecture of JBI Source: Infosys experience

6

Service engines are components that contain some business logic such as XSLT-based transformation or BPEL-based process execution. Binding components, on the other hand, are components that allow external services provided by different vendors to plug in to the JBI environment. Service engines and binding components act as service providers and consumers. The providers need to describe their interfaces using a WSDL document. Normalized Message Router is responsible for transmitting the message to the appropriate component. It receives JBI specific Message Exchanges created by the consumer component and passes the message on to the provider component depending on the metadata provided by the consumer. Similarly, it also transmits the response/fault/status message back to the consumer. The components communicate with the Normalized Message Router using their delivery channel. The JMX-based management provides features like: Installing JBI Components like service

engines, binding components and shared libraries

Deploying artifacts (e.g., xsl file to XSLT service engine) to installed components

Starting and stopping components Starting and stopping group of related

services.

Message Flow – 1. An external service sends a message in

its own data format and protocol to the binding component.

2. The binding component (BC) converts the message in a normalized form as specified in the WSDL that describes the service exposed by the binding component to the consumer.

3. The BC then creates a Message Exchange containing the normalized message and sets properties on it, such as the desired service and the operation to be performed. It then sends it to the NMR through the Delivery Channel.

4. The NMR delivers the message to the Delivery Channel of the appropriate service. The service then pulls the message from its Delivery Channel.

5. The service (SE/BC) creates a normalized message out of the response according to its WSDL and puts it in a new Message Exchange. The message exchange is addressed by a Service Endpoint (SE); the SE deselects components that are used to perform the service. The message is then sent to the NMR through the delivery channel.

6. The NMR delivers the message to the Delivery Channel of the requestor BC.

7. The BC then converts the message into a data format and protocol that is required by the external service and sends it.

Loose Coupled CommunicationIn JBI the consumer does not know about the implementation of the provider. It only knows its interface through the WSDL document. So the consumer is completely decoupled from the provider. The consumer refers to the provider by providing the interface name, service name or the service endpoint. If the service endpoint is not provided, the JBI implementation decides on who the provider can be. This gives an even higher degree of decoupling.

Interoperability of Data Format and protocol abstractionThe JBI Components communicate using a Message Exchange which contains a

7

Normalized Message. This Normalized Message is nothing but an XML which is created by the BC according to the schema contained in its WSDL (normalizing). The Normalized Message Exchange contains this XML content, some properties and attachments. Binding Components do the normalizing and de-normalizing of data so that external services can communicate with other components.

Lightweight and pluggable architectureJBI just provides the basic framework. Components that provide and consume service can be plugged into the framework. These components can be provided by external parties. JBI allows external services to plug into its environment through the Binding Components. Due to this the basic architecture is very lightweight. Also, it provides management features so that only the services that are needed can be installed. New services can be added as and when required using JMX Management features.

Centralized Administration, Management and MonitoringJBI provides JMX administration tools that provide features such as service installation and artifact deployment. The lifecycle of the components can also be managed centrally. It allows one to start/stop individual components as well as a group of components (composite services). Monitoring features can be added so that the health of all components can be monitored.

SERVICE COMPONENT ARCHITECTURE (SCA)SCA is an architecture model aimed at creating and deploying standardized services. It separates the business logic from the implementation

details. SCA provides consistent interfaces for describing the business logic codes’ encapsulation and flow, thus making them accessible as a service. It also provides mechanism for its lookup and invocation. An SCA system represents set of services. Different services are represented as different SCA subsystems within the SCA system. SCA subsystems group module components, entry points and external services of a system plus the Wires that interconnect them. An SCA Module is a composition of components that are developed and deployed together [Fig. 2]. The external service, entry points and properties specified in the SCA Module can be overridden by the SCA subsystem. Module Components are configured instances of a service interface implementation. The implementation contains business logic. The same implementation can be used with different configurations to create different components. Components provide and consume services. Implementation may be in plain java classes, BPEL, XSLT, C++, etc. New implementation types can be introduced by using the extensibility mechanism of SCA. Interfaces are declarations of functions that are provided by a service. These services are used by components through references. SCA supports two interface type systems: Java Interfaces and WSDL PortTypes/Interface. Reference represents the dependency of one service on another. This is done by mapping a service’s reference to the other service’s interface. SCA Entry Points are used to declare the externally accessible services of a module. Messages from external services enter the module through entry points. An entry point may provide services using SCA, Web Service,

8

Stateless Session Bean (SSB), Enterprise Information System (EIS) and Stored Procedure. These are known as bindings. New binding types can be added using the extensibility mechanism of SCA. SCA External Services are remote services that are external to an SCA Module. They can be accessed from a component within a module. Wires are used to connect service references to services. The connectivity conditions like method name, number of parameters, type of parameters, order of parameters, exception throws, etc., have to be satisfied before they are wired. For data access and manipulation it uses Service Data Objects (SDO). Using SDOs data from different data sources can be accessed using a common interface.Message Flow –

1. An external service uses the entry point of the SCA module to send a message to it. The entry point specifies the interface and the binding to use to call the SCA module.

2. The entry point of the SCA module has a reference element that specifies the component that should be called next.

3. Every component can have a reference to another component or an external service

4. The service external to the module also specifies an interface and a binding. The component in the module uses this interface and binding to call an external service.

5. The response message follows the flow through the components in the reverse direction. For asynchronous calls, the interface element has a callback interface attribute that can be used.

Service Java Interface

WSDL PortType/Interface

ReferenceJava Interface

WSDL PortType/Interface

Module A

Wire Wire Wire

BindingWeb Service

SCAJMSJCA

ImplementationWeb Service

JavaBPELC++

BindingWeb Service

SCAJMSJCA

ExternalService

ComponentB

ComponentA

Entry Point


9

Loose Coupled Communication In SCA, each SCA Module is loosely coupled. Components in one module interact with components in another module by using entry points. The entry point exposes the module as a service using one of the bindings. It specifies the interface of the module by using a Java interface file or a WSDL file. The module component which needs to invoke this service has to create a reference using a compatible interface and binding. Since the calling component knows only the interface, the implementation of the interface can change – for example, from Java to BPEL -- without affecting the calling component. Also the invocation of modules is such that the binding – for example from WS to JMS -- can change without affecting the calling components code. The SCA system takes care of making a call using the specified binding. This decouples each SCA Module from the other.

Interoperability of Data Format and protocol abstractionIn SCA the service components process data in the form of SDO. The SDO framework provides the developer a common set of API’s to work with data from different data sources. Thus, the data access and data format complexities are hidden from the user. The binding takes care of converting specific data in SDO formats and vice-versa. One can write one’s own custom binding for this conversion. Also, since the code is independent of the binding used to communicate between modules, it provides protocol abstraction.

Lightweight and pluggable architectureSCA provides a set of reusable modules that can be used to create services. It provides one level of abstraction over the services. They form building

blocks for creating reusable, loosely-coupled services. These services can be a local service or a remote service. This makes the architecture very lightweight and pluggable.

Centralized Administration, Management and MonitoringThere is no specification for Administration, Monitoring and Management in SCA.

MEDIATION BASED MQMMessage Queue Middleware (MQM) is an architecture based on queues which provides a communication infrastructure for distributed applications [Fig. 3]. MQM provides a flexible architecture by enabling applications to exchange messages agnostic of the underlying platform. Messages are transferred between the applications using queues that ensure reliable message delivery. The advantage of this type of architecture is that the destination application might not be ready to receive when the message is sent; instead, it can retrieve the message at any time. Once messages are sent to a queue, they remain there until they are retrieved by the destination application. Thus the source and destination applications need not synchronize with each other and hence the system becomes loosely coupled. Services like security, directory and administrative services to support messaging can also be built into MQM. ESB provides the connectivity with routing between services termed as mediation. Mediation adds the dimension of interoperability to the MQM architecture to build the bridge between services across the system. Mediation provides a pattern to the enterprise architecture with which it plugs the different services, whether it is an internal transformation or aggregation service or an

10

external business-aided service, using the underlying robust and reliable technology – Message queues. This kind of architecture makes it more federated and provides distributed process execution and reliability in high end deployment systems.

Message Flow –1. An external service sends a message to

the ESB. The ESB exposes its queue by using the internal interface service. This service may be exposed using its native messaging APIs or by using standard bindings like web services, JCA, EJB. The internal interface service receives the message and drops the message in the inbound message queue.

2. The message is then picked up by a mediation component which may perform operations like transforming the message format. It then places the message in another queue for it to be acted upon by another mediation component and so on. Finally the message is placed in the outbound message queue.

3. The message is then picked by the external interface service which delivers it to the destination service.

4. The response messages may follow a different path back to the calling external service.

Loose Coupled CommunicationThe source service just needs to drop the message in the queue from where the destination service picks it up. Thus the call to the destination service becomes asynchronous. Any change in the destination service will not affect the source service. Hence it is loosely coupled.

Interoperability of Data Format and Protocol abstractionInteroperability between different data formats and protocols is achieved using mediation services. For example, we can have an XML transformation service that transforms the source XML format to the destination format. Users can also implement mediation function to transform data other than XML format.

Mediationservice

Destinationservice

External interfaceservice

Internalinterfaceservice

Queue Queue

Sourceservice


11

Protocol abstraction can be achieved using adaptors to the underlying protocol of the target service.

Lightweight and pluggable architectureComponents that provide and consume service can be plugged into the ESB container. These components can be provided by external parties. It allows external services to plug into its environment through the adaptors. Because of this, the basic architecture is not lightweight.

Centralized Administration, Management and MonitoringSince the messages in the ESB are propagated through queues, the flow of messages can be traced by monitoring these queues. Also, there are tools that help in administration, management and monitoring of queues, but since MQM does not have a specification, its implementation is largely dependent on the vendor.

Governing Body

Loose coupling

Light weight

Pluggablearchitecture

Management And Monitoring

Security

Deployment ease

Products

Sun

Yes - Binding component facilitates loose coupling

Yes - On-demandcomponents instantiationand remote service invocation

Yes - Binding component

Yes - JMX-based management and monitoring component

No - It does not include any specification for security

Configurable choreography

ServiceMix, Mule and OpenESB

IBM, BEA, Oracle,IONA, SAP, Sybase

Yes - Using different bindings

Yes - Using wires and bindings

Yes - Using wires and bindings

No - It does not include any specification for management and monitoring

Yes - The standard includes specification for high level security constraints using policy language

Deploys EARs which contains the configuration files

WebSphere ESB

NA

Yes - Messagingbased infrastructure

No - Adapter-based components connections

Yes - Using mediation queues

Partial - Proprietary queue management and monitoring, but no mediation supported management

Depends on the implementation

-NA- Depends on the implementation

Sonic ESB, Fiorano ESB

JBI SCA Mediation based MQM

Table 1: Comparison of ESB architectures Source: Infosys experience

12

EVALUATION MATRIX There have been many products in the market which are based on these architectures. For example ServiceMix, Mule and OpenESB are based on JBI; WebSphere ESB is based on SCA, and Sonic and Fiorano ESBs are based on Mediation based MQM. The general point of view for the MQM based architecture is that it depends on its own messaging implementation. On the other hand, JBI and SCA are building standards for component-based architecture providing accessibility to remote services. JBI is a framework (specification driven) based on concepts of binding components and NMR, while SCA is more of specification to construct the components from mere services. MQM-based ESB has been in existence for years and is a heavy robust reliable architecture. JBI configures its service orchestration by setting the subsequent service in the message passed to the normalized message router. Unlike JBI, SCA provides the orchestration details in the configuration files for linking the services while MQM-based ESB decides its orchestration through mediation. In Table 1 we compare the architectures on the basic ESB features.

CONCLUSIONIt is difficult to pick one ESB product over the other based on its architecture as SOA takes its own form in a specific industry. The selection of the underlying architecture is more tied to the existing system and its design. The same ESB product may not fit all the requirements

of different analysts. We have provided an overview and comparison of different ESB architectures. Architects need to validate and weigh the pros and cons of different ESB architectures based on the requirements to select the most appropriate ESB for networking the enterprise.

REFERENCES1. Roy Schultze, Predicts 2003: Enterprise

Service Buses Emerge, Gartner report, December 2002.

2. Service Oriented Architecture: http://www-306.ibm.com/software/solutions/soa/literature.html.

3. Event Driven Architecture: http://e l e m e n t a l l i n k s . t y p e p a d . c o m /bmichelson/2006/02/eventdriven_arc.html.

4. JBI Specification: http://jcp.org/en/jsr/detail?id=208.

5. ServiceMix Overview: http://servicemix.org.

6. SCA Specification: http://www-128.ibm.com/developerworks/library/specification/ws-sca.

7. WebSphere ESB Overview: http://www- 306.ibm.com/software/integration/wsesb.

8. Message-Oriented Middleware : http://www2.sims.berkeley.edu/courses/is206/f97/GroupB/mom.

9. Message Oriented Middleware (MOM):http://www.tml.tkk.fi/Opinnot/Tik-110.551/1997/mqs.htm.

10. Sonic ESB Overview: http://www.sonicsoftware.com/products/sonic_esb/index.ssp.

13


By Shaurabh Bharti, Abhishek Chatterjee and Geo Phillips

Dynamic, collaborative service networks are now a reality

The term Web 2. 0 was coined by O’Reilly in 2005 [1]. Since then, it has attracted a

lot of attention. Referred to as a new set of web technologies, Web 2.0 has resulted in the emergence of start-ups like Flickr.com (now acquired by Yahoo!), Youtube.com (now acquired by Google Inc.) and many others [2, 3]. Web 2.0 refers to the adoption of open technologies and architectural frameworks to facilitate participative computing thereby creating enhanced customer experience, collaboration and co-creation of value. Web 2.0 has taken collaboration and personalisation over web to the next level. It has transformed the way people create and consume information over web. More so, as internet is becoming more and more accessible to developing countries via cheap and fast broadband connections, it has become possible to form internet-based distributed collaborative networks thereby leveraging collective intelligence. Moreover the rich internet applications make the whole experience much more user friendly as well as intuitive. Analyst

firms such as Gartner have rated Web 2.0 as the hottest emerging technology [4].

WEB 2.0: ENABLING TECHNOLOGIESIt is important to differentiate between Web 2.0 concepts and the technologies which enable them. The most common Web 2.0 concepts around the internet include Rich Internet Applications (RIAs), RSS Feeds Services and their online aggregators. RIAs make internet pages look like desktop and hence are friendlier, while RSS feeds have helped increase accessibility of new content to a larger mass. Personalized Web Portals provide lot of services like search, emails, RSS aggregators etc., at one place [5]. Product services like Office, Folksonomy services like Del.icio.us, online collaboration services like browser-based video/audio chat and whiteboard facilities, calendaring, web conferencing for sharing presentations, audio/video conferencing, blogs, wikis, social networking websites like Orkut.com, mashups like Housingmaps.com are among many examples which are taken under Web2.0 umbrella [1].

Exploring complementarities between Web 2.0 and SOA

14

Though the list for Web 2.0 concepts are growing day by day, most of the enabling technologies are open technologies and not proprietary. This is one of the reasons why Web 2.0 has been receiving top ratings. This also stresses the fact that the innovation in Web 2.0 has not been in the technology per se, but the way it is used. Web technologies that are popularly used in the Web 2.0 context include JavaScript (includes AJAX), Flash, Web Services (SOAP and REST), RSS Feeds, Metadata Technologies, Ruby on Rails (RoR) etc.

SERVICE-ORIENTED ARCHITECTUREService-Oriented Architecture (SOA) is an approach to distributed computing, which

has of late received wide acceptance amongst enterprises. It speaks of a loosely-coupled system composed of services. These services are protocol/platform independent and are based on standards. These services provide contractually defined behaviors which are coarser than a component but finer than an application. In the current scenario where IT systems are developed on disparate platforms and are hugely complex, SOA comes as a winner. It provides a business-centric view of IT implementations which facilitates reuse of services, making it adaptable and extensible to future needs. It also preserves investment in legacy and existing applications and high interoperability among the services implemented on heterogeneous platforms.

WEB 2.0 AND SOAAs already discussed, SOA has primarily benefited large enterprises. The benefits of SOA – such as standardized patterns, interoperability, and centralized governance – have been tangibly realized in such enterprises. Almost all industry domains have benefited from SOA strategy in order to build more flexible and malleable IT architecture involving re-usable services. On the other hand, Web 2.0 practices like communities and folksonomy are very end-user-centric. They involve frequent communication among large consumers dispersed all around the world over the internet. They have become extremely popular among internet users. This calls for the melding of enterprise products and services and

consumer-savvy applications from Web 2.0. This would not only bring producers and consumers closer but also would take supply-demand relationship of the economy to the next level. By now, many companies have already adopted the integration-view of SOA for their own legacy applications. However, there is also a wave of exposing web applications as services to consumers such as the ones implemented by companies such as Amazon, Google etc. Both, Amazon and Google have exposed their search capabilities as free services to internet users. Web 2.0 has the right capabilities to take these services-based enterprises to consumers. Following are some

The key challenge is to successfully integrate Web 2.0 with high value services – the returns would follow

15

scenarios when services can be directly used for consumption.

Simple Web ServicesSimplest way is to consume a small web service by using AJAX, Flash, RoR etc. Common examples of such services could be sports score updates, calendar activities, regular weather information etc. They are highly modular and generally third party services that can be used to access information through message-based web services like SOAP or REST. Web Services composed in processesAs mentioned earlier, consuming a single web service is quite simple. However, it is not the same while consuming a set of web services that in general would constitute a business process. Web 2.0 provides certain advantages over consuming a process on a web page. Web 2.0 can tie up all the steps involved in a process on single UI page. Take a simple case - “booking a flight ticket,” may become tedious when financial and time constraints are tight. Various steps involved are providing journey details, passenger details, class of travel, routes and finally providing credit cards (or other monetary transaction modes) to purchase the ticket. Web 2.0 has capabilities to enable all these steps to happen on a single page. This not only makes it an easy process but also relieves consumers from regular back-and-forth navigation due to constantly changing flight details. Secondly, they can keep certain functionalities like simple data processing so that services may contain core functionalities enabling higher re-use of these services. However, they have certain challenges too. Data synchronization between services while running a process and transaction failure recovery are some of them.

Service Orchestration enabled on webWeb 2.0 can not only enable consumption of processes but also create them. Automated service orchestration in a typical enterprise scenario is still not achieved due to several reasons including lack of semantic interoperability and lack of standards to embed intelligence in the form of semantically annotated sentences. On the other hand, Web 2.0 techniques can provide sufficient assistance for complex orchestration of services. It can provide rich interfaces to easily involve experts at enterprises who can mix-and-match with services and orchestrate their processes based on their requirements.

Enabling dynamic collaborative service networksIt is now possible to envisage a rich ecosystem of interoperable business services, connected through common interfaces. Enterprises can now build a standalone application around web services from Amazon, Google and others. Such networks will be inherently dynamic, orchestrating these services to provide functionality on a per need basis. They will potentially also have various providers for the same functionality, giving clients a wider variety of choices and thereby, simulating a marketplace of services. Companies like Salesforce.com are a step in this direction and the future will see further refinement of this model. Web 2.0, as of now, will not turn productive and monetizable unless they are integrated with high value services. There are already significant attempts from Google, Amazon and others to expose their web applications as pure services to consumers and enterprises. Most of them are available in three common versions of service consumption: SOAP services, REST services and RSS-based services. Many commercial websites which are not very

16

interactive are rapidly moving towards adopting Web 2.0 practices like blogs, communities, web chat etc. This is not to suggest that SOA and Web 2.0 are natural fits for each other, and the integration suggested above will be painless and hassle free. As enterprises port SOA applications into the Web 2.0 sphere, they will face issues primarily dealing with governance and accountability. SOA is built on the assumption of a centralized governance model, whereas Web 2.0 is more democratic and moves accountability towards the edges. Having significant amounts of business logic and service orchestration on

the client side will also require investment in new methodologies to test and debug such rich clients.

SOA AND WEB 2.0: THE DIFFERENCEService Oriented Architecture is mostly inside an organization’s limits or virtual networks while Web 2.0 talks about a collective and a collaborative kind of vision. SOA and Web 2.0 present a shift enabling a user-centric approach rather than an approach that is more technology centric [6]. However both of them allow the usage of the underlying systems to be exposed using open technologies that can be used by other systems. Web 2.0 uses Web Services extensively due to its flexible and open nature of creation and access and its basic ability to leverage the principles of SOA that in turn helps

build the architecture for a Web 2.0 design. This can then be used to create real business value. Blogs, Wikis, Mashups can be used to publish data in a much more useful and intuitive form. Users can capture and share information in Wikis and blogs can be generated to keep the users up-to-date with the current happenings. Technologies like RSS and ATOM can be used to push information about the products and about the company onto the user’s desktops. But from where does this data come? Communities and other collaborative efforts contain people who try to combine their thought process and share the information they carry with them.

The underlying motive for this is to basically solve a common problem. Web 2.0 provides us a plethora of technologies and methods to create such an ecosystem. However what Web 2.0 has as a major part of it is the user interface or the presentation layer. It talks about how things will look to the end user. However SOA does not focus much on the presentation layer. SOA can be looked upon as the first step in which the whole enterprise is given a services approach [7]. The next step is how to make these services available outside the enterprise i.e., to partners as well. Web 2.0, propelled by standards like AJAX, RSS 2.0 etc., helps achieving this goal. For example Microsoft’s Virtual Earth can be used to build a logistics company’s delivery system. The company can track exact location of the trucks using GPRS systems and then plot them

An ecosystem of interoperable business services connected through common interfaces is now a reality – organizations like salesforce.com are taking the lead

17

on the map to give more detailed and accurate details about a customer’s delivery details. The complex tracking mechanism and other details can come from the internal services. This data can be mapped on a map which is a third party product/service. Merging these two systems or services gives us a completely new and useful representation. ILLUSTRATIONSWeb Services and RoRRuby on Rails is an open source Web application framework written in Ruby that closely follows the Model View Controller (MVC) architecture. It strives for simplicity, allowing real-world applications to be developed with minimum coding and minimum configuration as compared to other frameworks. Rails is a full-stack, open source web development framework that requires comparatively less time and effort to code XML interfaces than most other frameworks. Mashups which is an integral part in Web 2.0 can be easily created with Ruby on Rails. The seamless manner in which Rails can bind to databases and other enterprise data sources and work on that data gives it a much appreciated advantage over other frameworks in the market for such kind of development. This when combined with third party resources such as Google Maps can give rise to endless number of possibilities to leverage the information. Web Services plays an integral part in this case as much of the raw data is present inside the enterprise or outside as services. Ruby on Rails has a pack called Action Web Services which allows easy creation and deployment of Web Services (mainly REST Web Services), and automatic generation of WSDL files [8]. Consuming Web Services built on other platforms is also easy. Rails also gives the

flexibility for other technologies to ride on it. AJAX on Rails is one such example.

REST Web ServicesREST is an acronym for Representational State Transfer. REST is an architectural style, referring to a set of design principles rather than the implementation strategy (unlike SOAP) Fielding utilized the design rationale behind the Web (Internet) to come up with his definition of REST [9].

By retrospectively examining the architecture of the World Wide Web, it is seen that scalability and robustness of the Internet is basically due to the following factors:

The division of states and functionality into well-defined resources. A web page is a resource, as is an image on that page. Both of these are independent, reusable entities. A transition from one page to another on a site can be an example of a state change.

Every resource is universally and uniformly addressable by a hyperlink defined in a proper syntax. On the Web, these are called Uniform Resource Identifiers (URIs). URLs are an example of these. For example, the home page of Infosys is found at www.Infosys.com. This URL is understood by any web browser, and clicking on it always leads to the same page.

State transfer between resources and the client (web browser) happen through a common interface. This interface has a set of constraints, with relation to the operations and content types supported. HTTP is the interface used on the Web. It only supports the four operations POST, GET, PUT and DELETE. The content

18

types usable over a HTTP connection are also limited, such as text, xml, image formats like JPEG and GIF and so on.

A client-server based protocol which is also stateless, layered and supports caching on the client side.

Thus, any architecture which follows the above principles can be called RESTful. Obviously, the World Wide Web is one such example. REST is hence, not a standard like SOAP or HTTP. However, it prescribes the use of the standards : HTTP, XML and URIs. It will not be an overstatement to say that Web Service uptake has not been as rapid or far reaching as initially proposed. REST offers a viable alternative to the now common

SOAP-XML-HTTP paradigm. It can be seen that a RESTful architecture does not call for a separate messaging protocol. Thus, SOAP is no longer required. This is a fundamental differentiator for REST web services. The utilization of standard URIs also eliminates the need for separate WSDL files to find these services. In REST web services, all operations are mapped to the four HTTP commands: POST, PUT, GET, DELETE which are in general mapped to Create, Update, Read, Write operations in web services respectively.

While the scope of the aforementioned operations seems limited, a proper examination of any web service reveals that all operations fall into one of the above categories. Multiple operations falling under the same category can be appropriately chained using a data-validation framework. Data in REST web services is typically in the form of XML input i.e., an XML payload is given to the HTTP command. Output data can be returned in a variety of formats as required, though again, XML is usually seen to be the preferred choice. REST is gaining a tremendous amount of mindshare now as a viable architectural style. Major enterprises and companies such as Amazon have already delivered comprehensive

RESTful web services. REST is an ideal candidate for web services intended for Web 2.0, and is naturally complemented by other frameworks such as AJAX and RSS/ATOM.

AJAX and Web ServicesAJAX or Asynchronous JavaScript and XML is a technique to create interactive web applications. They have created a lot of hype as they can enable desktop-like features in the browser. Using AJAX in-house web services can be easily consumed even at the client-

AJAX leverages a diverse mix of technologies ranging from standard-based presentation, document object model

(DOM) to data interchange and manipulation using XML and XSLT

19

sides. AJAX is a mix of technologies and has the following constituents [10]:

The standard-based presentation that is done using XHTML and CSS. Standard-based presentation helps to increase the speed of development, simplify maintenance, open up bandwidth cost and improve the user experience.

Dynamic display and interacting using Document Object Model (DOM). The DOM scripting method helps to create documents on the fly. DOM also helps to modify the documents, for example, moving parts of the document around.

Data interchange and manipulation using XML and XSLT. XML – Extensible Markup Language – is similar to HTML, but differs in a way that the user can create his or her own tag. XML was designed to describe data. XSLT – Extensible Stylesheet Language – is based on XML and it transforms XML documents.

Asynchronous data retrieval using XmlHttpRequest. XmlHttpRequest Object enables JavaScript to make HTTP requests to a remote server without reloading the page. In essence, HTTP requests can be made and responses received, completely in the background and without the user experiencing any visual interruptions.

Java Script helps in binding everything together. Java Script is a client-level scripting language that helps validate the user interaction and many more functionalities.

As communications in web services scenario are based on xml, XmlHttpRequest object helps in sending request as well as receiving responses

to and from web services respectively. First, WSDL of the respective web service is invoked and parsed using XPath techniques for message schemas and endpoints. Based on that, SOAP messages are composed and sent to web service using XmlHttpRequest. Once SOAP response is received, it is parsed and information is published on web page. Hence, in this manner, it is quite simple to consume services in the enterprises even at the client side of web application.

CONCLUSIONSOA and Web 2.0, both have been widely accepted in the industry. However, SOA is seen more in the supply or enterprise side, while Web 2.0 is popular among end consumers. We have identified a few complementarity scenarios for these two trends with specific technology linkages. For enterprises that consume their own services Web 2.0 provides immense value. This is primarily the reason for the existence of communities, blogs and Wikis within enterprises. Concepts like business networks (like Amazon’s ECS) are more meaningful in such scenarios. All these practices will finally make the web as an ultimate platform of consuming services via Web 2.0 techniques.

REFERENCES1. Tim O’Reilly , What Is Web 2.0, Available

on http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html.

2. Flickr.com - http://www.flickr.com/3. Youtube.com - http://www.youtube.com.4. Ray Valdes and David Mitchell Smith,

Web 2.0: Get Ready for the Next Old Thing, Gartner Research, December 2005.

5. Netvibes.com – http:/www.netvibes.com.

20

6. Peter Evans Greenwood, SOA and Web 2.0: Cage Match. Available on http://www.capgemini.com/ctoblog/2006/10/soa_web_20_cage_match.php.

7. Dave Linthicum, SOA and Web 2.0 Convergence Continues...Thus I’m on Too Many Planes, February 2006. Available on http://weblog.infoworld.com/realworldsoa/archives/2006/02/soa_and_web_20.html.

8. Dion Hinchcliffe - Ruby on Rails 1.1: Web

2.0 on Rocket Fuel. Available on http://ajax.sys-con.com/read/200446.htm.

9. Roy Fielding, Architectural Style and the Design of Network-based Software Architectures, Available on http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.

10. Manivannan Gopalan and Mohit Chawla, Bringing Interactivity to Web Services Using AJAX, Web Services Journal, July 2006.

21


Service and Process Orientation- Catalyzing business transformation

By Manish Srivastava

People oriented enterprises are better clued in to the business ecosystem

Chief executives are on the move connecting with people across the globe, sensing the

changes that are happening and contemplating how these will impact their businesses. These changes could be shifts of customer demands, emergence of new markets, new talent pools, impending regulatory changes, movements in employee motivation levels, new technology innovations and several others. Most CXOs know that sensing such changes ahead of time will give them the competitive edge and sometimes even provide them “game changing” opportunities. They realize that enterprises which have a habit of sensing the changes and rapidly realigning to them continue to be relevant for several decades. Those who do not sense these shifts or resist the change render themselves less relevant and slowly fade away. Sensing shifts require an enterprise to be well connected with its people i.e., its customers, employees, shareholders, partners, regulators, and society. Also it requires it to

be agile to change itself, in time to serve the changing needs of its people. Such enterprises with intense focus on people are People Oriented Enterprises. They are future proof and continue to thrive in the world of shifting priorities.

OPERATING MODEL – “THE REAL ENTERPRISE”As the world is becoming connected, a complex interplay of environment, culture, regulation, business and technology is accelerating the pace of innovation. This is fueling the rate at which the business priorities are shifting. The situation requires organizations to realign their operating model more frequently than before. Operating model defines how an organization structures and links its people, process and ICT systems to deliver products/services to its customer and value to its stakeholders. The constituents of the operating model are illustrated in Figure 1. Organizations change their operating models by introducing new services,

22

repositioning existing products\services, redefining customer segments, consolidating products/services, replicating business in other regions, integrating diversified businesses, diversifying existing business, engaging in mergers and acquisitions, outsourcing, establishing new partnerships – to name a few. The ability of an organization to change its operating model rapidly is becoming critical in the emerging business scenario. This ability is often referred to as enterprise agility

or enterprise flexibility. It determines the ability of the organization and its functional units to enhance quality of existing services they deliver or completely repurpose themselves by adding new services to cater to the shifts in the business environment. This is dependent closely on complexity of interdependencies of the functional units themselves and the ability of the people, process and systems that constitute the functional unit to acquire new skills and rapidly realign to the new goals set for them.

Customer Segments

Products and Services

Value Chain

Organization Model

Key Stakeholders Key Systems

Figure 1: Operating Model Source: Infosys experience

23

Senior executives in the enterprise are focused on managing this real enterprise as defined by the operating model. They are driving strategic initiatives like inorganic growth, emerging markets and strategic alliances that impact the operating model to bring about significant changes in quality of existing products/services delivered by the enterprise and its functional units or create new ones to cater to the shifting demands of its people. They are often unaware that the complex interdependencies between external partners, functional units and sub-units are getting encoded into a parallel version of the operating model in a manner that can be difficult to change and can impact the success of these initiatives.

IMPACT OF THE “IMAGINARY ENTERPRISE” Processes define how an enterprise interacts with its partners, functional units interact with each other and people and systems interact with each other to serve their purpose. Some process-flows are dynamic and undefined. They require people involvement for orchestration. But for most mature processes, the primary workflows and the exception flows are defined and encoded into IT systems. The interactions between teams, departments and partners are also realized into IT systems as cross program interactions. As a result, a reflection of the operating model gets etched into the IT system landscape. This reflection could be referred to as the virtual or the imaginary enterprise. Most processes are encoded into systems with the premise that current processes will serve the enterprise for the next 3-5 years or so. The ROI calculations in the business case document for such large system implementation explicitly state this assumption. IT architects and developers then encode the process into systems

as described during the time of its creation, using prevalent architecture guidelines and platforms. As more processes are encoded into systems, the systems become more important to business. They are especially important to the functional units, which are dependent on these systems to perform their day to day activities and meet their deadlines and targets. As time progresses, the interdependencies between enterprise and its partners, cross functional units and cross sub-units increase. Many of these interdependencies get encoded into the IT systems. At the same time, the diversity of the platform components and the architectural ideologies that stitch them together also increases. Randomness of interdependencies and diversity of platforms makes the systems difficult to interoperate, difficult to change and expensive to maintain. IT systems are often, harsh but true reflection of the enterprise’s current state and operating model. The complex interdependencies that make IT systems difficult to change are only but reflections of the random interactions happening between partners, functional units and sub-units. Unfortunately, once encoded, IT systems resist the changes in the operating model, making the organization inflexible. A famous philosopher once said, “One’s behavior is determined by what one does repeatedly.” Processes define what organizations do repeatedly. Processes are encoded into IT systems which govern what large number of people in the enterprise do on a day to day basis. As the IT systems across the enterprise become inflexible, the characteristics cascade exponentially and can be observed at the process level, functional unit level , the operational level and also at the enterprise level to external customers, partners and shareholders. Like the DNA, the IT systems

24

though seemingly minute and inconsequential in the big picture view of the enterprise, have a significant impact on the enterprise behavior. Top business executives preoccupied in managing the real enterprise often underestimate the power of their IT systems. They delegate responsibilities of defining and managing the systems’ so called IT responsibilities to their subordinates without adequate guidance, directions and review. As a result, the operating model of their enterprise gets slowly encoded into architectures incompatible with the future views of operating models. This impacts the organization’s ability to realign to the fast changing business priorities. IT executives then have to wage a lonely battle with their systems. Often a battle, the systems wins - resulting in business being forced to shell out large sums of money to rip and replace IT systems. This can be quite a risky and expensive proposition with little guarantee of success. Here is an illustrative example of how this unfolds in the real world. Mike Johnson, a smart business executive of a large financial services company senses that the young generation today has a lot of disposable income. He formulates a strategy focused on targeting this customer base using some existing products and by creating some new products. His presentation is well received by the board. He is given a go-ahead, the dollars and the mandate to execute this strategy. Enthusiastically, he puts together a team to execute this strategy. Among others, his team advices that the young customers they are targeting expect these services be available to them anytime, anywhere via the internet. They also inform him the current online IT infrastructure is outdated as it is capable of providing only information to consumers and that it is not interactive enough

to deliver services to a generation very particular about the experience. A little disappointed he asks them to initiate discussions with the IT folks to identify what would be required to upgrade the infrastructure. The IT folks come well prepared for the discussion. Using detailed diagrams representing process and system flows they articulate why the current infrastructure is not good enough and why more needs to be procured. They explain why current systems may not scale up and will need to re-architected to meet the needs of the online strategy. When asked to provide a dollar figure and timelines required to put this in place, they indicate that the available information was not sufficient to provide reliable numbers. A suggestion was also made to initiate a discovery exercise for analyzing the impact and formulating the exact dollar figures and timelines. In the meanwhile, a key member of the strategy team cited unsatisfactory work environment reasons and quit. Soon, the team learned that their closest competitor was pursuing a similar strategy and were moving very fast. Mike approves the budget for the discovery exercise. After a 2 month discovery exercise, the report submitted to Mike presents a figure which is four times what he had originally estimated. After several rounds of tough negotiation with IT and their vendors, the team managed to reduce the cost to two and a half times its estimated value. Mike approached the board and passionately argued as to why they should approve the increase in budget. Some board members not completely sold on the idea raised some tough questions but, eventually the board approved the hike. Having got a renewed mandate, Mike and his team pressed the accelerator on all

25

fronts. The product design was initiated, new people were brought on board, new processes were designed to support the new products and services, discussions with existing groups were initiated to ensure they supported the new products and services, changes required by IT systems were being rolled out one by one. Everything was going smoothly, with no major show stoppers. One day, it was brought to the notice of the chief financial officer that the finance department was regularly failing to deliver the certain key reports to decision makers leading to increase in the risk profile of the company. On initial investigation it was found that some

recent changes in the IT system had caused their batch processing to slow down due to which they are unable to deliver the reports on time. On querying the IT department representatives, it was found that the new changes being rolled out for the new online initiative were impacting the financial systems, causing delay in report generation. Fearing huge impact on risk profile of the organization, the CFO issued orders for reversal of the changes and puts an immediate ban on any changes to the system. Mike was alerted. He was completely perplexed as to why such a thing should happen. None of the changes he had asked for impacted the finance systems. He immediately called a meeting with the finance and the IT team.

After long deliberations and analysis, it was found that some of the systems earlier thought to have no connections were actually closely interlinked. It became clear that Mike’s team will have to reformulate a portion of their implementation. And soon it was also known that this new found information would again, impact the estimated costs significantly. As Mike sat in his office, pulling himself together, preparing to fight another battle in the boardroom, the dark forces residing within the imaginary enterprise smiled, planning a final blow. It is therefore, important that senior executives learn to feel and sense the pulse of this imaginary enterprise and take steps to ensure

that not only is the encoded operating model in synch with the current operating model but is evolving to support their future vision of the operating model. With information and communication technology impacting almost all facets of our daily life, the influence of IT systems will continue to increase in the future. Enterprises that do not take control of how their operating model gets encoded into the imaginary enterprise often find dynamic executives like Mike failing to drive changes in the operating model. Those who do take control are able to leverage the IT systems as a catalyst in assisting and driving business change across the enterprise.

The influence of IT systems are poised to increase manifold – the all pervading impact of information and

communication technology being the primary driver

26

TAKING CONTROL THROUGH SERVICE AND PROCESS ORIENTATIONWhen processes are encoded into IT systems, they are hardwired into several programs and configuration files. Any changes in processes require changes to several programs, that are often linked with other programs. These programs also need to be analyzed for impact though they are not directly related with the original change request. In large enterprises, programs become interdependent over the years and probability of a change triggering a corresponding change in the dependent programs is quite high. These cascading changes result in increased time and cost for delivering the change. This situation is further aggravated by the multitude of platforms and runtime finding their way into the enterprise. Along with each comes an endless suite of middleware components, data and content management components, presentation and collaboration components, etc. These components are then stitched together by architects using architectural

ideologies fabricated using a concoction of the prevalent best practices of the times. Large enterprises today have realized that random diversity of platforms is unacceptable. They have established focused technology architecture groups coordinating initiatives across the enterprise to ensure standardizing to a few carefully chosen platform components. Benefits of such initiatives though varied, have been mostly positive. However, few realize that their needs will continue to change rapidly. And technologies will continue to evolve to address those needs. Organizations will be forced to adopt technologies that have significant implications in the future. Enterprise architecture groups set up to standardize platforms will only be able to facilitate the adoption of the chosen technology, effectively and uniformly across the enterprise. In short, they will be able to control random diversity to managed diversity. They will not be able to eliminate diversity of platforms entirely. While this does address some aspects of the inflexibility, it is often not enough. More needs to be done.

Figure 2: Process Oriented View of the Enterprise Source: Infosys Research

27

There are two schools of thought that are trying to do more to address the issues of inflexibility. The BPM school views the enterprise as a set of processes, orchestrations and workflows. They deem inflexibility as a result of hardwiring the processes into the systems. They believe for systems to be amenable to change requires them to be modeled as the processes they enact. The process models, thus created, should be executed as they are using orchestration and workflow engines. This will result in separately managed process definitions that can be changed and replaced in a localized manner. This, they say, makes the systems and hence the enterprise flexible by localizing process changes. Terms like Business Process Management or Process Oriented Systems are often used to describe this approach. Proponents of this approach cite additional benefits like BPM platforms providing information about current state of the process, activity-based timing and other

information that if analyzed can help identify further refinement of process. This, they claim, will help organizations achieve a business aligned IT systems architecture and make the organization process oriented, resulting in continuous process improvement. The SOA school of thought views the organization as a set of services. They see the organization and its functional units delivering services to its people. This school believes that the main reason for inflexibility is the complex interdependencies across functional units and its resultant reflection on the IT systems. To rectify this, they prescribe organizations to adopt and follow principles of service orientation. Service orientation mandates explicit definition of service interface and separation of the interface from the implementation. Explicit interface definitions ensure that all consumers know explicitly what the service has to offer. It further ensures that consumers of the service are linked with it at defined and known points.

SLA

SLASLA

SLA SLA SLA SLA SLA SLA

SLASLASLASLASLASLASLASLA

Figure 3: Service Oriented View of the Enterprise Source: Infosys Research

BusinessService

28

Unlike unknown interactions, known points of interactions can be managed and monitored to ensure predictable quality of services. Further, the separation of the interface and the implementation ensures loose-coupling --- the consumer and service provider are shielded completely or significantly from changes within each other. This loose-coupling allows each part and their systems to evolve independently due to changes in operating model- making enterprises flexible. The service orientation club also cites additional benefits of this approach. They claim, service orientation will enable organizations to manage services using service management tools. This will provide real time information on how the services are performing with respect to their SLAs. Adopting SOA principles enterprise-wide at all levels will ensure that there are back to back SLAs for all services. Transforming the organization to adopt service orientation will make it more flexible, predictable and future-proof. Clearly both the schools of thought seem to articulate the benefits organizations want. The approaches they prescribe – process oriented and service-oriented, seem orthogonal and often contradictory to each other. Let’s find out if they really are that way. Mike, the business executive, we met in the previous section was on a long drive with his family in a rented car. Suddenly the tire of the car burst and Mike had to pull up. Having dealt with similar situations before, he confidently took out the spare tire and the jack from the back of his car. To his surprise, he found out a complex mesh of bars and wires between the wheel and the car. It looked almost impossible to replace the tire without unwiring this mesh. With just a few options available, Mike pulled out the manual to understand how to untangle

this mesh and replace the flat tire. The manual described in excruciating details how the car works and how each wire connecting to tire was important for the overall functioning of the car. While interesting to read, it was still not giving him a good picture of how to replace the tire. As he unraveled the lengthy manual, time passed by and his frustration grew. He started wishing he had a car which had simple, standard and well-defined mechanism to replace the tire like we have in most cars today. And he wished it had an easy to understand process to achieve what he wanted ---- which probably read as Step 1: use the jack to lift the car; Step 2: unscrew the nuts one by one; Step 3: replace the tires; Step 4: replace the nuts one by one --- a process so easy that it was almost general knowledge or common sense and did not require going through elaborate manuals to use it. Suddenly, it all started making sense to Mike. No service consumers of the enterprise, its functional units or of its IT systems are interested in going through the excruciating pain of understanding elaborate internal processes to use the service, like he had to when dealing with the elaborate manual of the car or the elaborate process and system diagrams his IT team was sharing with his team. They expect services they consume should have well defined interfaces, should be easy to understand and simple to use. These characteristics are referred to as service orientation. True service orientation is really about being customer oriented. Defined interfaces are essential for service orientation but are not sufficient. It is possible to have providers that have defined interfaces which are difficult to use. By just exposing a provider and documenting its interface, a provider cannot become service oriented. Such providers are interface oriented. Service orientation

29

mandates interfaces that are easy to consume and simple to use. Service orientation makes it easy for a consumer to start using the services offered by the provider in a loosely coupled manner. Conceptually, service orientation is same as customer orientation. Service orientation makes it easy for organization to replicate, replace, integrate, extend, and relocate the provider - the providers being IT systems, functional units or the enterprise itself. Interestingly enough, service orientation also makes it easy for the consumer of a service to switch to other service providers as they are loosely coupled. Consumers of services switch because their existing provider is not delivering predictable quality and continuous improvement. And that the benefit of switching to other providers far outweighs the cost of switching. This ensures that providers with consistent poor quality of service will be doomed, irrespective of whether they are service oriented or not. Hence it is important for providers at all levels – enterprise, functional units or IT services to continuously improve the quality of services that they deliver. Service quality can be improved by continuously improving service implementation. Service implementation is internal workings of the service. It is the process, workflow or the orchestration required to deliver the service. In order for the processes to be improved continuously, they need to be defined explicitly, measured, analyzed regularly and changed continuously. The BPM school of thought recommends similar process oriented principles to ensure flexibility and continuous improvement. However, we also know that if internal processes are exposed as they are, it

becomes difficult for consumers to use them. They need simple interfaces as prescribed by the SOA principles. A good example of service oriented and process oriented systems is the human body itself. Simple external interfaces like hand, eyes, ears, mouth allow us to interact with other systems in a loosely coupled manner. These interfaces abstract a complex network of bones, muscles, blood vessels and internal organs that actually enable us to execute those interactions. Efficient internal processes and simple external interfaces are important for us as human beings as they are to IT systems, functional units and any business enterprise. It is important for all providers to be process oriented as well as service oriented, in order to be people oriented.

CONCLUSIONAs people across the world are getting connected, their demands are rapidly changing. People-orientated organizations can sense the shifts in demands from customers, partners, employees, shareholders and society. They can realign to these shifts in a timely fashion by bringing about appropriate changes in their operating model. The internal providers of such organizations are able to rapidly realign with the changes in the operating model, in a continuous manner, having adopted service oriented and process oriented principles. In fact, several of these organizations are able to leverage their IT systems as a change agent or a catalyst in driving the business change. People-oriented enterprises that are intensely focused on their people will continue to be relevant in an increasingly unpredictable world of constant change.

30

REFERENCES1. Jeanne W. Ross, Peter Weill and David

C. Robertson, Enterprise Architecture as Strategy: Creating a foundation for business execution, Harvard Business School Press, August 2006.

2. Thomas H. Davenport, Saving IT’s soul: Human-centered Information

Management, Harvard Business Review, March 1994.

3. Ulrich Homan, A Business-oriented Foundation for Service Orientation, MSDN Technical Article, February 2006. Available on http://msdn2.m i c r o s o f t . c o m / e n - u s / l i b r a r y /aa479368.aspx.

31


Service Oriented Architectural approach to building Healthcare

solutions By Jai Ganesh, PhD and Vijaya Bhaskar Peddinti

SOA is required to enable real-time access to information about patient data from diverse

systems spread across stakeholders

The highly fragmented and dynamic nature of the global healthcare market

has resulted in multiple entities providing healthcare services in isolation. Consolidation and collaboration among various players in the healthcare value chain such as medical devices manufacturers, hospitals, physicians, employers, insurance companies etc., is on the rise with the end consumers being the ultimate beneficiaries. This is driven by the use of internet and communication technologies. Adding to the pressures for seamless collaboration among partners is the need for real-time access to information about patient data across the various entities. Increasing competition in the healthcare space is resulting in competition between different healthcare value chains rather than one entity competing with another. Such competition puts pressure on the revenues and margins of healthcare providers, underlining the

need for cost minimization by way of reducing the cycle time of profit margin metrics. Globally, driven by the advancements in medicine as well as improved living conditions, the average life expectancy of population is increasing, which is expected to translate into increased demand for healthcare. This in turn indicates at a larger market opportunity for healthcare service providers.

BUSINESS DRIVERS FOR INTEROPERABILITYThe healthcare delivery business model is rapidly changing from a one doctor-one patient scenario to a multiple healthcare entities–one patient one, meaning a team of healthcare professionals belonging to different medical domains and entities are responsible for patient healthcare. Therefore, data in various formats is generated, modified, updated and consumed across

32

multiple entities that requires a high degree of interoperability across supporting medical systems and applications. Hospitals have electronic healthcare records (EHR) which store patient data. However many of these systems are proprietary in nature, with a limited scope, often catering to one specific department. Large and medium-sized hospitals have a multitude of systems such as patient care, observation reporting, patient administration, lab reporting, preventive medicine, exceptions etc. In addition there are systems that store unstructured data in multiple formats such as text, sound, images and video. In order to provide effective service to patients, interoperability across these disparate systems is a key requirement, the absence of which, could result in redundancy of efforts, lack of access of patient history as well as other life saving information about patients. Healthcare service providers have a number of redundant processes as well as a numerous manual hand-off points that result in reduced patient satisfaction and rise in the scope for errors. Mentioned below is a select projection of fatalities due to improper as well as non-real time access to critical patient data and information [1]:

44,000 to 98,000 people die in hospitals each year as a result of medical errors that could be prevented. This makes medical errors the eighth leading cause of death in the U.S.

Medication errors caused 7,000 deaths Medical errors cost US $37.6 billion each

year– $17 billion are associated with

preventable errors– About half the expenditure for

preventable medical errors are for direct healthcare cost ($ 8.5 billion)

Added to these are diagnostic errors. Faulty diagnosis may mean that the patient does not get the right kind of therapy or treatment as test results could be misinterpreted and the patient may fail to receive an indicated diagnostic test. Diagnostic errors could emanate from equipment failure, infections, blood transfusion-related injuries and misinterpreted medical orders. To mitigate such losses, interoperability in healthcare systems is a must. Listed below are the technological and business drivers for such interoperability.

Healthcare providers need access to information to support delivery of patient care. This could be in varying data formats such as text, video and audio

Extracting the right information becomes critical

Need to maximise physician productivity by making information easily accessible

Multiple entities accessing the medical record such as physicians, paramedical personnel etc.

Changing healthcare workflows Need for HIPAA (Health Insurance

Portability & Accountability Act) compliance

Data capture from various channels such as point of care

Collaboration with other healthcare providers, partners (e.g., insurance firms)

Mergers and Acquisition scenarios Managing increasing medical costs and

balancing customer satisfaction Heterogeneous healthcare information

systems that support delivery of patient care – Many of these are standalone systems

and are incompatible with one another

33

– Lack of interoperability is a key problem in data transfer across systems

Need for customisable XML interfaces that support hospital processes – need for open standard interfaces

reduce the cost and lock-in– incremental investment– ability to absorb new technologies– lower maintenance costs– easily adaptable and flexible software

architecture.

STANDARDS BASED SOA TO THE RESCUEThe key requirements of the IT architecture supporting a healthcare service network include ability to -- provide interoperability between internal systems; provide interoperability with external systems of partners (e.g., insurance, diagnostics, payment etc); comply with legal requirements such as HIPAA; configure/reconfigure services and reduce redundancy and enhance re-use. Given the nature of the scenario and the number of stakeholders involved, a web services based SOA would be the ideal solution to the problem. Due to the loosely-coupled nature of web services, healthcare service providers do not need to have hardwired connections with internal as well as external systems. This allows the entities to adopt flexible workflows offering more options to their customers. This would not only address the current needs but also address future needs like when the entities need to make faster business connections with partners without going through the conventional pattern of making large scale changes to the system. SOA based on web services would enable the healthcare providers to isolate the business logic from integration. Most conventional integration solutions embed part of the business logic in the

integration layer thereby requiring considerable efforts in making modifications. Architectural requirements for a healthcare service network include application functionality, interoperability, performance and scalability, flexibility and manageability. The physical architecture consists of databases, servers, software applications, web servers, and networking and Application Protocol Interfaces (API’s) to link them all together. Further a key requirement is to be able to interoperate with the multiple data representation formats of various systems. Overall, a flexible and interoperable architecture is needed to keep up with the pace of changes in the industry. The architecture should support appropriate open standards-based messaging infrastructure and must support a flexible way of incorporation of workflows or orchestration so as to enable typical transactions. In addition, the architecture should streamline services including capability for e-mail notification, mobile alerts for patients and customization capabilities. Additionally, partners will expect security, fraud prevention and other ancillary services like insurance claims. All these services and applications must be part of the application architecture or be integrated with the healthcare service provider via standard API’s over standard messaging standards. Given the above requirements, a SOA based on web services, drawing upon the benefits of HL7 V3 standards is proposed due to the following reasons:

SOA based on web services enables healthcare organizations to become technology and data-independent

The loosely coupled nature of web services facilitates healthcare information systems integration rapidly and cost-effectively

34

SOA enables re-use of applications Web services coupled with HL7 mitigates

confusion among data standards in healthcare organisations

Web services enables universal access be it wireless laptops, PDA etc., which are increasingly being used by physicians and paramedics

EHR based standards such as HL7 aim to enhance interoperability and data exchange across healthcare applications

HL7 provides the conceptual building blocks and hence we can adopt them for uniform service messaging

The service requestor invoking the web service and the service provider providing the web service must be HL7 compliant

An HL7 message consists of data from the underlying systems

The healthcare applications are exposed as web services which have standard interfaces.

PROPOSED TECHNICAL ARCHITECTURE FOR SOA BASED SOLUTIONS IN HEALTHCAREThe proposed architecture for the healthcare service provider is given in Figure 1. Some of the business processes identified under different categories of the proposed architecture are:

Patient CareRegistration: This captures the following details like patient type - in/out patient, address, allocation and appointment details, admission and discharge details, patient’s movements within the hospital.Medical Store: Generating invoice and issue, purchase returns, inventory, query and report services.

Billing: The patient is billed based on the services consumed like consulting fees, rooms, medicines, tests etc.In/Out Patient Management: If the enrolled patient is an in-patient then allocation of rooms and beds, allocation of attendants/nurses for daily routines like observations and drugs issues etc. If she is an out-patient then this captures the details like appointment scheduling for consulting/ diagnostic tests and provides the same for billing.

AdministrationResource Allocation: It captures the data pertaining to the allocation of resources like employees, room and beds.Payroll: This provides employees’ and consultants’ details pertaining to attendance, pay slip generation, pay details, provident fund, income tax related information. Purchases and Inventory: Purchase order placing, orders procurement and verification, issuance and maintenance of stock and general reporting related information is captured here.Accounts: This provides the details of the system related to items like accounts payable, accounts receivables, general ledger and reports to be submitted to the government agencies and stake holders.

Querying ServicesThese provide the information related to internal and external entities of the system. These provide querying of details with regards to patient, doctors, scheduling, facilities provided by the hospital, packages related information, etc. External entities like insurance agencies, and other hospitals, can access the details of the patients concerned through these services.

35

Non Functional ServicesMessaging or notifications mechanisms, data access, services manager and user authentication and access controls are typical functionalities of non-functional services. Messaging / Notifications mechanisms: Enterprise messaging provides a reliable, flexible service for the exchange of business data and events throughout an enterprise. This can be achieved using JMS/MSMQ. Data Access: This can be defined as Shared Data Access services that expose data access functionality based on web services standards. These services abstract the knowledge of underlying data stores from the applications

that access the data from them. They also provide a single point interface or gateway for the underlying heterogeneous data sources to the outside world. This reduces the number of connections (N*N) required to connect N applications to the N data sources that applications access for information. An example for this is BEA’s Liquid Data.Services Manager: This provides the functionalities like service registry, policy and metadata management and service versioning.User Authentication and Access Controls:Authentication is used for verifying the use through a username and a password. Access control is used for controlling access to a

APPLICATION TIER

Bank

Business Process Execution Language

Infrastructure

Enterprise Service Bus

SERVICE TIER

DATA TIER

Partner HIS Insurance Others

Notification/ Messaging Service Manager Exception Handling Authentication / Access Control

Querying Admin Patient Care

General ReportingLab ReportingAccounts

Shared Data Services

RDBMS Hierarchical DBMS XML Data Files OODBMS Flat Files Legacy Data Stores


Figure 1: Proposed Technical Architecture Source: Infosys Research

36

resource. Access can be granted or denied based on the user, IP address, time, browser which is being used. These can be achieved by using WS-Policy or XACML.

Reporting ServicesThese services can be classified as general and lab.General: This covers reporting aspect of the system in terms of accounting reports like balance sheet and profit & loss, inventory usage reports and such other items.Lab: These services cover the reporting aspect in electronic statements/records of medical reports, observation charts and prescriptions so that these can be accessed over a network by insurance agencies and other partners. These reports should be complaint with the standards specified by HL7 and HIPAA. CONCLUSIONThe trend in healthcare is shifting to a scenario where the healthcare service providers need interoperability not only between the internal systems, but also with those of their partners as well as other healthcare service provider networks. Hence healthcare service providers must be able to offer a single point source for intra- as well as inter-organizational collaboration to achieve superior service delivery. SOA enabled with web services shows promise in achieving this at reduced cost by leveraging existing investment in legacy systems and thereby increased efficiency for these enterprises. Web services increase flexibility by offering the possibility of creating flexible new business processes from existing IT infrastructure [2, 3]. To that end, we outline a reference SOA-based architecture which leverages web services and

handles all the functionalities as desired for a healthcare service provider. The architecture described provides the core service-orientation to healthcare service providers. The following are some of the benefits for healthcare service providers in implementing a SOA based on Web services:

SOA-based IT architecture would allow the healthcare service providers to offer their applications as services across their customers and partners allowing for increased flexibility and reuse

SOA based on Web services would enable the healthcare service providers to be compatible with other internal systems without considerable efforts in interfacing

SOA based on Web services would allow the healthcare service providers to service the requests of their customers regardless of the channels through which they want to access the service.

REFERENCES1. To Err Is Human: Building a Safer Health

System, Institute of Medicine (IOM) report, 1999.

2. J. Ganesh and D. Moitra, Web Services and Flexible Business Processes: Towards the Adaptive Enterprise, Forthcoming in Information and Management.

3. S. Padmanabhuni, J. Ganesh., and D. Moitra, Web Services, Grid Computing, and BPM: Exploiting complementarities for business agility, IEEE International Conference on Web Services (ICWS 2004).

37


SOA implementation in Transaction Banking domain

By Jayakumar Venkataraman and Siddhartha Vijay Joshi

Infuse agility, flexibility and reusability into banking processes with SOA

Banking and financial services companies are facing tremendous competitive pressure in

the delivery of new products and services that enable them to meet customer requirements. Competitive pressures, reducing shelf life of products and waning first-movers’ advantage make it imperative for banks to constantly innovate and introduce newer products. Consequently, reducing the time-to-market for new product introductions has become critical. There has been a raft of regulatory interventions in the recent past such as SOX, Basel II, SEPA and the banks have had to make substantial investments in technology to achieve compliance and there has been a need to balance fresh technology investments with re-using the existing infrastructure. The need for reducing the processing cost of transactions has meant increased operation and Straight Through Processing (STP). This calls for interoperability between various applications in the front-to-back processing of the transactions. Interoperability becomes a critical requirement in developing a

unified customer view -- a key requirement from both sales and risk management perspective that would need data to be gathered from multiple diverse applications across the enterprise landscape. Technology plays an integral role in the banks’ ability to deliver the products to the marketplace and the ability to process them in large volumes in an efficient manner. Cash Management & Payments businesses, like Cards and Mortgages processing, have been built leveraging technology and have often led technology investments as compared to other businesses. Consequently, these businesses have also been at the forefront of adoption of new technologies, design and development approaches. Many surveys of CIOs of large companies across businesses indicate that their business models have significantly changed in the last two years. Their key constraint has been limited flexibility and adaptability in their IT Architecture. While there are many ways to

38

Cash Management System

Payment Module• Cheque / Drafts• Wire / Elec tronic Funds Transfers• SWIFT Pay mentsMainframe / AS 400 / VAX

Risk Management / Limit Monitoring System

Cash flow (Payments & Collections) forecasting Module

Client Ac-counting/ Reference

Data(can be DB2/

Oracle/ or any other database

type

General Ledg-er (This may

be a part of the core Banking platfrom and

hence may not be a separate

database)

Transactional Data

(can be DB2/ Oracle/ or any other database

type

Anti-Money Laundering/

OFAC/Compliance

Data(can be DB2/

Oracle/ or any other database

type

Collections Module• Local / Outsta tion Cheque• Electronic Funds Collections• Cash Pooling & ZBA AccountsMainframe / AS 400 / VAX

Accounting Module• Client Account ing• GL Accounting• Product AccountingMainframe / AS 400 / VAX/ NT

Client / Bank / Vendor Billings Module

Product / Service Profitability & Other Analytics Module

reconciliation & Exception Management System

MIS & Reporting Module AS400 / NT / PC-LAN/

Docu

men

t & Im

age

Man

agem

ent S

yste

mVa

lidat

ions

& B

usin

ess

Rule

s M

odul

eCo

rresp

onde

nt/ P

ayee

bank

/ PM

T Ga

tew

ay In

terfa

ces

Bank Reference Data-Cor-

respondent/Payeebank (Can be DB2

Oracle / or any other database

type)

Risk Management Data (Can be DB2/Oracle/or any other da-tabase type)

COPL

IAN

CE F

ILTE

RSfo

r e.g

. Ant

i-Mon

ey L

aund

erin

g / O

FAC

/ Reg

ulat

ory

FILT

ERS

LAN/WAN/

Internet

Internet/ Private

Payment Gateways

Inte

face

s to

the

LOCA

L CL

EARI

NG

HOUS

E / I

ndiv

idua

l Pay

ee B

anks

Inet

erfa

cess

to th

e In

divi

dual

pay

ee B

anks

pa

rt of

a P

rivat

e Pa

ymen

t Gat

eway

s

Payee Banks

Payee Bank 1

Payee Bank 2

Payee Bank 3

Payee Bank 4

Payee Banks

Payee Bank A

Payee Bank B

Payee Bank C

Payee Bank D

Incoming Transactions processing

desk

Central Processing centre

Outgoing Transactions processing

deskRisk

Monitoring & AML

Monitoring Desk

Client & GL Accounting

DeskReceivables & Exception Mgmt Desk

User

Acc

ess

Fron

t End

Can

be

- ter

min

al o

f a M

ainf

ram

eSy

stem

/ In

tern

et/ I

nter

net A

cces

s et

c

Client / User Front-End

Client / Field

Location 1

User

Acc

ess

Fron

t End

Can

be -

te

rmin

al o

f a M

ainf

ram

eSys

tem

/ In

tern

et/ I

nter

net A

cces

s et

c

Client / Field

Location 1

Client / Field

Location 1

LAN/WAN/

Internet

Figure 1: Cash Management Landscape Source: Infosys Research

39

achieving a flexible architecture, SOA is emerging as a very hotly debated option. A Celent report states that 36% banks mentioned SOA as one of their key IT priorities [1]. SOA represents the conceptual model of an enterprise where most of the collaborating systems produce or consume services that are loosely coupled entities representing coarse grained business functions. SOA can be implemented using web services that provide open standards to provide a flexible model of integration without depending on any specific implementation technology. Ease of integration, process flexibility and re-usability of services are the key benefits of the SOA approach. In this article we look at SOA Implementation in the Transaction Banking space and specifically in the Cash Management

& Payments space with particular focus around identification of business services. The typical Cash Management landscape in a bank is dotted with multitude of applications, across a variety of technology / software platforms ranging from legacy to the modern ones [Fig. 1]. One of the primary steps in transforming the current landscape to a SOA model is to get an accurate understanding of the current architecture and define the to-be-architecture. The current state architecture is often a jumbled potpourri of applications as indicated in Figure 1 and the documentation is often sparse, outdated and has not kept in pace with the changes to the application portfolio. Take for example a front-to-back Payments Value Chain as depicted in Figure 2.

Payments Value Chain

Accounting & Reporting Routing & Payment GatewaysTransaction ProcessingClient Access Layer

Product Selection & Transaction Initiation

Basic Transaction Validation

Enquiries & Reports Initiation

Accounts & Other Validations

Limits Approvals &Verification

Billings & Entitlements

Transaction Queueing Bundling / Unbundling

of Payments

Generate Accounting Entries

GL / Client / Product Accounting

Alerts & Notifications

Statements Generations & Reconciliations

Payment Message Transformation

Send Payments through Gateways / Clearing House

Interfaces

Determine Routing

Transmission Status Monitoring

Figure 2: Payments Value Chain Source: Infosys Research

40

The Top layer broadly describes the high level process in the value chain while the boxes below indicate the functionality that is performed as part of the process. While functionalities such as validations, limit verifications, routing etc., are expected to be present within the appropriate high-level process as indicated, it has often been found to be spread all across the value chain. Some likely observations on the business functionality from the current state architecture study may typically be: COMMON BUSINESS FUNCTIONALITY EXECUTED AT MULTIPLE PLACES ALONG THE VALUE CHAINIt has been observed that certain functions like client validations, authentications, payments/transaction queuing, etc., are performed in front -office as well as in back-office applications. This implies that any common changes to a functionality, say validations, need to be introduced at all places where they are performed thereby increasing the difficulty and cost of change. COMMON FUNCTIONALITY PRESENT ACROSS SIMILAR BUSINESS FUNCTIONS Common functionalities such as user validations, transaction validations, limit verifications etc., may be duplicated either across multiple applications within the cash management businesses or even across other business lines such as trade finance or loans. For example, limits verification is a functionality that will be used by all applications that process credit products and interface with Credit Limit Management Systems. Therefore at an enterprise level, any changes to the Limits Verification functionality will need to be carried out at multiple places.

COMPLEX BUSINESS LOGIC IS STRONGLY EMBEDDED IN THE CORE TECHNICAL FUNCTIONS Often complex business logic is tightly embedded in the code in combination with a technical service, greatly reducing process flexibility. This also makes introducing changes to the business logic difficult and increases the time taken to introduce the desired changes to production. For example, the functionality for validation of file formats, duplicity, syntax, generic and specific business rules etc., may be intertwined in the payment routing function. Or the verification of limits prior to processing of the transaction which requires interfacing with credit systems may be combined with the various validation functions. Implementation of Service Oriented architecture (SOA) permits the organizations the key features of re-usability and process flexibility and orchestration through identification and building of business services. This calls for decoupling the business logic from the core technical services, achieving optimization by consolidating the business functionality spread across the value chain and evaluating the possibility of developing a common business service. For example, validation functionality spread across the value chain can potentially be consolidated into a single business service component. This would mean that across the value chain wherever the validation functionality is to be performed this service component would be called. Thus the service needs to be developed once and can be re-used many times and introducing any changes to the validation functionality can be easily achieved. There might however be a lot of constraints in such service definition. One of the key decisions that needs to be made is around

41

the service granularity. Fine-grained service, may house only a small business functionality and orchestrating a process would require many such services while coarse-grained service may encompass a larger chunk of functionality becoming very complex though a lesser number of them may be required to orchestrate a process. The possible landscape after implementation of a SOA approach would resemble the diagram as depicted in Figure 3. The landscape would comprise of a layered architecture with presentation layer, orchestration layer, service layer etc., clearly defined and implemented. The service transport layer would manage the service calls from the

orchestration layer and the service layer. A sample set of services that may be identified for the Cash Management business are as follows:

a. Validations-related Services Client Validations Product Validations Transaction Validations Entitlement Validations.

b. Limits-related Services Get Limits Service Update Limits Service Block / Release Limit Service.

Web layer

Mobile layer

Business Process

Orchestration Layer

Service Transport

LayerService Layer

Application Platform

Shared Data Services Platform

Figure 3: Post SOA implementation landscape Source: Infosys Research

PaymentCreationFront-End

Applications

LoanApplicationFront-End

Applications

CustomerProfile

Management

PaymentCreationProcess

LoanApplication

Process

CustomerShared Data

Services

AML Service

AccountingService

Loan StatusService

Loan DataService



LoanProcessing

GenerateAccounting

Entries

LimitsCalculation

Payment Processing

Customer DataManagement

Data Access/Update

Consolidated CIF

Data Synchonization

TransactionalDatabase

Front-end Mapping

DeviceTranslation

42

c. Accounting-related Services Client Accounting Service Product Accounting Service GL Accounting Service.

d. Interest Calculation-related Services

e. FX Rates Service Get FX Rates Service Calculate Cross-Rates Service.

Some of these services have a high degree of re-usability with other transaction processing functions such as trade finance or loans processing (limits service, FX rates service, interest calculation service etc).

CONCLUSIONSOA can provide the much required flexibility and interoperability in the IT architecture for banks, for addressing business drivers like regulatory compliance and time to market. As part of SOA planning, identification and composition of the business services renders competence to the enterprise to negotiate challenging complexities. In this article, we have presented a sample set of business services for a cash management scenario. However, SOA implementation is far more involved than just the identification of appropriate business services that would

need to be composed. It encompasses much wider challenge around defining a roadmap, policies around governance (owners / service custodians), change management and such other enterprise-wide issues.

REFERENCES1. North American Bank Priorities:

Convention or Innovation? Celent Report, August 2006.

2. Jayakumar V. and Sriram Anand, An Architectural Framework for Web Services based SOA realization in a Bank, Information Resources Management Association on Emerging Trends and Challenges in Information Technology Management, Conference Proceedings, 2006.

3. Sriram Anand and Jayakumar V., Drivers for SOA in the Transaction Banking Domain, IEEE’s ICWS/SCC’s SOA Industry Summit Paper, 2006.

4. Jayakumar V., Sriram Anand & Phani Venkata P., Future Proof your Bank’s IT Architecture, HSBC’s Guide to Cash and Treasury Management in Asia Pacific, 2006.

5. Srinivas Padmanabhuni et al., Service Orientation in Cash Management, HSBC’s Guide to Cash and Treasury Management in Asia Pacific, 2006.

43


Recasting Enterprise Integration in SOA mouldBy Rakesh Mishra and Yale Yu

Integration will become de-facto core for SOA materialization, but only after it is

recast in a new avatar

When IT consultants around the world look at the evolution journey for

integration domain moving from interfaces to EAI to BPM and wonder if this is where it will settle down, here comes SOA and composite applications making their way through hype curve to pilots and then to real-life projects. So that brings up new challenges for integration specialists once again to deal with new trends of SOA and composite application for aligning enterprise integration blueprints and ensuring that evolution in IT architecture doesn’t leave integration out. SOA brings in formal focus of “multi-tier specialization stack” in integration architecture definition by looking at various integration solution capabilities in terms of intelligent services that can be instrumented together to build a business solution. At the same time, composite applications style of architecture compliments SOA in terms of a vision to build

any solution by assembling together working parts that are commonly available in the organization as shared enterprise assets. Though composite application style is primarily talked about around business functionality modules, nonetheless, as a concept, it is equally appealing and relevant for integration architecture. It is a fact that enterprise integration has entered the age of business process-centric integration which becomes part of the kingdom of BPM. And enterprise-level integration of business processes, services/applications and corporate data has become one of the most important requirements for organizations and building a SOA, aligning technical enterprise integration platform supporting BPM has become a more and more outstanding factor to make the whole enterprise more competitive and agile. Due to this, SOA has been proved to be the enterprise architecture blueprint with

44

the highest level of flexibility and agility and of efficient reusability against the increasing cost pressure faced by all organizations.

SOA AND COMPOSITE APPLICATIONSIn our view, composite application paradigm is seeing much more accelerated adoption than what SOA has been in last few years. Even though as industry analysts say that adoption of SOA is unstoppable and inevitable which we believe is true, probably the reason why composite application approach is gaining faster adoption is two fold. One, it is far more tangible and concrete than SOA and second, it fundamentally conforms to SOA vision. Just to get plot clear, let us not forget that composite application paradigm is just one of the architecture styles that can deliver SOA. Composite application in simple terms is a logical collection of business processes that are implemented by selecting and orchestrating loosely coupled common business services that are available in enterprise service pool, typically via Enterprise Service Bus. It means that various business functions that traditionally had been locked inside sacred boundaries of packaged or custom applications and had been only available through application specific APIs, will be now readily available as enterprise services accessible through standard interfaces like web-services. In order to build a new business capability, enterprises have to just identify required business functions, locate services in the service repository corresponding to those business functions and use them in orchestration on BPM platform to deliver end-to-end business process. Evident in this approach is the backbone of SOA that composite applications paradigm uses. Adoption of composite applications paradigm also means that enterprises will have to change the way they develop, deploy,

manage and maintain software solutions, especially around dimensions of software architecture, development approach, costing/funding models, infrastructure organization and not to forget, the operational management capability. As far as integration architecture approach is concerned, it will have to be refined at two levels: one to fit into overall SOA and

Traditional Architecture

A

Integration platform

B

C

Composite Application Architecture

A

Enterprise Service BUS

Enterprise Service Warehouse

BPM platform

B C

Figure 1: SOA transformation

Source: Infosys Research

45

composite application strategy and second to adopt SOA and composite application paradigm within integration architecture itself. SOA RECAST OF INTEGRATIONBefore we dive into SOA empowered integration architecture, let us quickly touch upon some of the enterprise business drives that are becoming prevalent and which definitely will play a significant role in defining integration strategy of the enterprise:

a) Channel integration: Businesses are expanding to all available channels forcing IT architecture to integrate all channels into IT solutions

b) User experience unification: Enterprises are gearing to unify user experience and integrating various heterogeneous user interfaces within standard portal through portlets

c) Single customer view: Easy access to single and standard customer record across enterprise is becoming essential mandate for IT strategy

d) Single sign on and online self-service: Driven by requirements of operational cost reductions and information flow-thru

e) Improvements: Enterprises are invariably adopting online self-service capabilities for both customers and partners empowered by single sign-on facilities and rich internet applications (RIA)

f) Application rationalization: More and more enterprises are taking up IT transformation initiatives focused around consolidation and rationalization of enterprise applications to clean up complexities buried into spaghetti of applications.

Some of the drivers described above put enormous responsibility on integration architecture to accomplish the business objectives. Let us take our focus to recast the integration architecture re-drawn on SOA fabric and get to the toughest question: What does SOA empowered integration architecture mean? In the conceptual world it signifies that integration architecture blueprint is conceptualized as a stack of horizontal service layers that can be instrumented together to deliver both simple and composite integrated vertical business services. Taking it further, composite application paradigms enables us to create any business integration solution by composing and orchestrating various design-time and run-time services provided by common components of horizontal service layers in the integration architecture blueprint. In order to technically and fully support the requirements of service-oriented and process-centric enterprise integration, a technical platform should have following major functional components to meet the requirements of enterprise integration:

BPM should be the focus of the enterprise integration and should be fully supported by the technical EI platform in terms of business process modeling, business activity monitoring

Standard-based should be the main theme of the EI platform and both business standards, such as B2B integration standard ebXML and RosettaNet, and technology standards, such as Web Services, JMS, HTTP/HTTPS and etc, should be supported by the technical EI platform

All levels of the enterprise integration such as process integration, services/

46

applications integration and enterprise data integration should be supported by the technical EI platform

SOA principles such as loosely-coupled principle should be followed by the technical EI platform.

Figure 2 shows the Technical Platform Reference Model of Service-Oriented Enterprise Integration:

Business Process Modeler to model manual business processes of people to people and people to services or processes, and automatic business processes of service to service and service to process. It should have an easy to use, non-technical oriented intuitive graphical user interfaces and support

WSBPEL or BPEL4WS and other major BPM modeling-relevant standards and provides all business process modeling relevant facilities such as information or data model designer and testing tools.

Process Runtime Engine to execute the processes designed by business analysts via Business Process Modeler. This is a runtime component and should have high scalability, stability and availability with high performance.

Rule Engine to provide a mechanism to configure and execute the rules incorporated in the business processes. It should support static and runtime dynamic rule configuration to provide a better flexibility.

Business Activity Monitoring Component to allow configurable monitoring of all

Business Process Services Modeler

Business Process Engine

Business Rule Engine

Business Activity Monitoring

Services Registration

Services Discovery

Services Invocation

Services Entitlement

ESB(JMS)

Message & Service Routing

Message & Transfor-

maton

Message & Monitoring

Domain Services Adapters

Domain Services Adapters

Legacy System

Legacy System

Figure 2: Technical Reference Model for EAI with SOA cast Source: Infosys Research

47

the activities or tasks and status in a end to end process so that all levels of the company can have real-time visibility into business processes and be able to identify where the bottlenecks are and so that they can dynamically change and optimize the processes at all levels of the organization to achieve greater competitiveness.

Enterprise Services Bus (ESB) is a service-oriented EI mechanism in the whole enterprise integration architecture to provide facilities to expose, register and discover enterprise services or interfaces in multiple forms, mainly in Web Services, over multiple transports such as HTTP/SOAP and JMS bus, to route messages or services based on message content, to do message transformation and translation between different destinations or between B2B standards and protocols and provides security and entitlement mechanism to cater for authentication, authorization and integrity of services and messages.

QoS (Quality of Service) of ESB is one of the key criteria to differentiate the enterprise integration platforms.

Administration Tools to allow the integration technical staff to install and configure integration platform components, administrate users and monitor low level system status of the common integration infrastructure.

Adapters which are a bunch of COTS adapters to support different technologies and most of key packaged applications such as CRM and ERP applications and legacy systems such as existing mainframe systems.

CONCLUSIONIntegration architecture blueprints as well as leading products around integration will evolve through recast of SOA. This will mean that everything surrounding that makes it run in the enterprise will also have to go through the transformation, be it integration delivery methodology or the integration operational infrastructure. We envisage the following trends in the context of this transformation:

Web-services becoming de-facto interface standards

SOA transitioning from vision to operational reality in production environments

Composite application practices having reasonable penetration in application architecture and this demanding greater need of SOA enabled platforms.

Sooner enterprises are able to identify the “recast avatar” of the integration, easier it will become for them to materialize the SOA vision into operationally transformed eco-system.

REFERENCES1. David, W.H., and Malone, M.S, The

Virtual Corporation: Structuring and Revitalizing the Corporation for the 21st Century, Harper Collins. 1992.

2. Camarinha-Matos, L.M. et al., Towards an Architecture for Virtual Enterprises, Journal of Intelligent Manufacturing, 9(2), 1997.

3. Vernadat, F., Enterprise Modelling and Integration, Chapman and Hall, 1996.

4. Gruden, A. and Strannegard, P., Business Process Integration : The Next Wave, eAI Journal, pp. 8-12, 2003.

48

5. Enterprise Information Integration, Whitepaper, MetaMatrix, 2002.

6. C. Matthew Mackenzie, et al., Reference Model for Service Oriented Architecture 1.0, OASIS Open, Feb. 2006.

7. Xiaowei Huang and Yale Yu, EAI Technologies and its Evolution Trends, Journal of Modern Electronics Technique, Vol 204, July 2005.

8. TIBCO Software Inc. Web Site: http://www.tibco.com/software/default.jsp

9. Krafzig, D. et al., Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall, 2004.

10. Noel, Jasmine, BPM and SOA: Better Together”, Whitepaper, IBM Corporation 2005.

49

SETLabs BriefingsVOL 5 NO 2Apr- Jun 2007

SOA based Enterprise Architecture for Communication Service Providers

By Gnanapriya C and Binildas C. A.

The future CSP should implement enterprise architecture capable of providing services of a “total

solution provider”

Traditionally in the telecom industry, Communication Service Providers (CSPs)

used to deliver end-to-end services to their customers and the entire value chain was controlled by a single CSP. In the liberalized market, CSPs have to respond to stiffer competition and the increased demand of the customers for superior customer service. Due to the technological advancements with convergence on IP, the market place is open to all players (wire-line, wireless, cable, VNOs etc.) to capture market share. CSPs vision is to become a Total Solutions Provider. This focus pushes them out of their existing siloed way of operations into a converged solution and service oriented architecture (SOA) for their enterprise helps in achieving the same. This article focuses on applying SOA to yield benefits in the areas of application/data integration and supplier/partner web service,

and providing differential QOS for different category of enterprise systems. Today, growth in communication technology is impacting the way CSPs operate [Fig. 1]. We pick Service Delivery (O2B – Order to Bill) in the CSP domain as an example to discuss more on how to implement SOA-based integration principles to facilitate the total solutions vision.

CURRENT CSP ENVIRONMENTExisting enterprise have multiple applications / systems covering different overlapping business functionalities, thus making service delivery in silos dedicated to services and execution of service plan(s). Since these applications were developed over time and on a need basis without considering “re-use” or “best practices in leveraging technology platforms,” the enterprise has a huge application inventory. This has led to several

50

issues like repetition of business functionality implementations across applications; diverse platform/hardware, software and technologies

leading to higher cost of management; lack of common standardized way of representing information (e.g., each system has different

Future

Serv

ice

1

Serv

ice

2

Serv

ice

N

• Service delivery in Silos dedicated to Services• Highly inefficient and expensive to operate• Not scalable to address convergence

• Service delivery based on converged IP Infrastructure • Service share Transport and Application Resources • Scalable and simple support of new and personalized services

Past/ Present

Serv

ice

1

Serv

ice

2

Serv

ice

N

Application Application Application

IP Multimedia Subsystem

Subscriber data

Media Functions

IN nodes Billing PS Domain CS domain OSS Pre-pay

IN nodes Billing PS Domain CS domain OSS Pre-pay

Application

Subscriber data

Media Functions

Service Delivery Platform

Application Application

Subscriber data Subscriber data

Media Functions Media Functions



Packet SwitchedDomain

Circuit SwitchedDomain

ActivationProvisioningAssurance

Figure 1: CSP Siloed Vs Converged Operations Source: Infosys Research

51

product codes and customer codes for same physical product and customer) and non-scalable model to address convergence. Dynamism has besieged the CSP landscape and today one can observe lot of changes in key areas like technology, competition, customers and costs.

Technology: Lot of emerging technologies, different type of products and services are coming in, that are changing the ways of doing business.

Competition: Products that used to be differentiators have become commoditized and now yield lower margins

Customers: Have become more demanding, less tolerant, not loyal

Cost: Increase in capex and opex in the initial phases of transformation.

In order to resolve issues within the changing landscape of CSP, an enterprise architecture is required which will define guiding principles and architecture, deliver tools, build actionable blue prints based on SOA, involve relevant teams, align blueprints and systems, deliver permanent cost reductions, simplify operating environments and provide complete integration with existing technology development process.

FUTURE CSP ENVIRONMENTFuture Enterprise is defined considering the trends in telecom domain (convergence IP), demanding customers, cost of products and services and competition. This future enterprise shall focus on a set of services for customers arrived at by indulging in application rationalization and consolidation and by implementing an enterprise architecture that is capable of providing services for a “total solution provider.”

Below are listed the major focus areas and the implications of the future architecture on the areas:

Organization Models: Consolidated / Integrated Business Units, Interface with external partners, Mergers and Acquisitions

Information/Data Models: Common Information model, Master Data Management, Data interchange (B2B, B2C), Information Security & Data Integrity

Applications: B2B Information exchange, Management of Customer relationships, Enterprise Application Integration, Regulatory Compliance and consolidation of applications

Technology: SOA Architecture based on the concept of an Enterprise Service Bus (Process Orchestration, Transaction Management, Process Security, Service registry, Process Service Interface, Process QoS & Monitoring and Management)

Figure 2 is illustrative of the future high level Enterprise Architecture for a CSP. The key advantage of this architecture over the existing architecture is that it is based on SOA.

Applying SOA should yield benefit on the following fronts: Applications Integration: In the existing architecture, the integration between the enterprise systems is through a mix of EAI and point-to-point mechanisms. In the future architecture, integration is based on SOA approach based on ESB. Integration between the different systems happens over ESB using SOA standards like Web Services (SOAP).The Supplier/Partner Web Service gateway: This allows a standard way of integrating

52

Figure 2: Illustrative Future CSP Enterprise Architecture Source: Infosys Research

Employees

Desktops/windows/Linux

An application on Unix / Linux / Windows etc developed on

Java/ MS/ C/

Logical Connections

LegendsDesktops/windows/Linux

Desktops/windows/Linux

HR Activation Order Management

Billing CRM Service Assurance

Capacity / Performance Management

Leave

Support Systems (IS)

SCM

Business, Service Delivery Systems

Parlay/OSA Web Services

Inventory

Radio Tower

Network Element / Data

MediationNMS Systems,

Service Assurance

Radio Tower

Radio Tower

Wireless Service Delivery


DMS BPMS BRMS


Ente

rpris

e Se

rvic

e Bu

s

DMZInner Firewall Outer Firewall

CustomersSupplier / Partner

Parlay Gateway Supplier PartnerWeb service Gateway

Employee / Customer Web Server

Enterprise SOA

Parlay / OSA based Application hosting partner

Request routed

to target application

Incoming requests

from Internet

Fault Manage-

ment

53

with suppliers and partners. There is also a possibility to build vertical standards (e.g. RosettaNet in the electronic/hardware industry) which could further improve standardization for CSPs. Providing differential QOS for different categories of Enterprise systems: Different categories of systems need different QOS (or SLAs) from the ESB, depending on the service type. For e.g., Network Management Systems interfacing with the Network Elements of the “Wireless Service Delivery” facility will need the highest level of QOS from the ESB. So the ESB has to reserve enough capacity (in terms of bandwidth) and do prioritized routing for NMS systems. The differentiation could be further extended to individual applications. The other important aspect of the future architecture is to support standard gateways which allow partner application providers to develop applications in a CSP neutral way. Detailed application architecture for the CSP based on SOA is provided in Figure 3. Two representative areas in the SOA based Enterprise Architecture for a CSP are:

Service Delivery (Order to Bill – O2B) Common Data model (with SID) and Data

exchange, interoperability (with ESB).

SERVICE DELIVERYService delivery includes the following activities: service order entry, validations, order decomposition, check for availability of resources with the inventory and finally does the activation in the network elements and informs the CRM & Billing system and the service becomes active for the customer to use [Fig. 4].

Order ManagementOrder Management system is the core of the

service delivery. It has the workflow component and manages the orders received and maintains the status of the complete order life cycle. It takes care of scheduling the various tasks to other OSS entities like inventory, activation, procurement, field force, etc., and manages the complete lifecycle of service fulfillment. The key functionalities include:

Order Capture (Order entry, validation, check for order types, UI for order entry)

Order fulfillment (workflow engine for management of the complete cycle, order templates for reference solution, automation of tasks, provision for manual intervention, maintaining complete history).

Inventory ManagementInventory system holds the inventory data of both network (physical, logical) and service. This helps in blocking and allocating resources for service delivery and auto discovery of network elements. Details on the inventory help in further capacity planning. It gives a complete view of the network and services for specific customers and their linkage with the network entities.

Service Configuration & ActivationInvolves specifying which pieces of equipment and network routes a given service will utilize. The activation system activates service on the proper network elements - any piece of network hardware, such as a switch, multiplexer, or cross-connect system. Today’s requirement for service providers is to provide flow-through provisioning or zero touch provisioning. Looking into the steps of service delivery of

54

Reseller Partner

Dashboard Content Taxonomy Personalization Mulit Device Admin and Management

Presentation

Profile

User Portals

• Self Service / Online Portal• Dealer / Partner Management Portal• Contract Centre / Voice Portal• Retail / POS portal

Technical ServicesIdentity Access Management• Audit and Reporting• Data management• Lifecycle Management• Federated Identity management

Web Content management• Structure• Creation• Aggregation

• Publishing• Versioning• Day

Online Common Services• Web Analytics• Subscriptions• Chat• Streaming• Messaging and Notification Forums

Enterprise Search• Index• Query

Business Services

Sales & marketing• Shopping Cart• Catalog• Shop front Designer• Configurator• Marketeting Exec• Customer data maintenace

Assurance• Trouble Tickets• Customer compliants

Fulfillment• Check order Status• Order processing• Order management

Billing• Account Maintenance• EBPP• Billing reporting & analysis• Disputes

• Service Config• Service Monitoring

Customer Dealer

Technical Services

Identity

CRMPartner Relationship Management• Partner / Dealer management• Market Development Treads• Event management• Partner Sales management• Partner Order management

Sales and Marketing• Lead management• Opportunity management• Visit management• Loyalty management• Campaign management

Order management• Order Capture• Order Validation• Product and Services management• Subscription and Asset Management• SLA Management Account Management

Customer Care• Interaction management• Issue management• Claims management

General• Document management• User management• Addrehss management• Activity management• Work flow Assignment management• Rules management

Analytics

External Interfaces

CRM DB

ESB

BillingCustomer Account• Customer Hierarchy• Package, product, services, bill view• Payment

Account Receivable

Billing Catalogue• Create Price Plan• Create Packages• Create Bonus schemes Etc.

Rating Catalogue• Hold rate plan• Multiple rating scenario• Multi-currency rate plan etc. Convergent

ConvergentBillingEngine

Payment Hierarchy

Bill DetailsUn-billed usage

Event rating• File based / Event based rating• Price override of events• Pre-authorization of charge• Rating based on duration, time, size, event type etc.

Service Delivery

Order management • Order Entry (Single / Bulk)• Order Translation• Order Validation• Order Assignment• Order Decompossition

Technical Order Management

Workflow Engine• Rules Engine• Task manager / Scheduler• Notification• Order management / tracking• Milestone management• Roll back• Process Exception handling• Inference Engine

Inventory• Design / Assign Features• Extensible user interface• Standard, Adhoc Reports• Auto routing / assign ment of resources• Engineering process and work management• Visual Expectation• Service Catalogue• Inventory Details• Auto Discovery

Inventory Management

ESB

General• Full Audit Capabilites• Error handling• Work group management• Front Door management• Rules / meta data editor• Logging• Tracking and reporting

General• Admin• Full audit capabilities• Error handling• Work group management• Meta data and rules editor• Logging• Tracking and reporting

CRM DB

• Flow through provisioning• Transaction management

• Convergent Activation Engine

Activation

General• User management process• Notification• Logging, Error• Reports

Activation DB INV DB

Mediation

Data processing• Aggregation• Correlation• Validation and enhancement• Record correction• Usage record cloning• Duplicate data detection• Error record processing• Rule based filtering

General• Monitoring• Reporting

Collector• Support for multiple record formats• Configurable record format• Multi transport mechanism• Real time data collection• Support polling

Distributor• Support for multiple o/p record formats• Real time data distribution• Transport Mechanism• Selective data distribution

Assurance

Customer TT• Customer complaints• Call flow mgmt• Call monitoring• Reporting

Network Trouble Ticketing• Capture network faults• Correlate with customer services

WFM• Field force• Scheduling, plan & roll-out (dispatch)• Reporting• GPC/GIS

SLA mgmt & Qos• Measure & manage Service perfomance• Identify Trends, potential failures• Proactive Alerts• Measure business Impact

Fault management• Collect events• Filtering• Correlation

• Alaram forwarding• Root Cause• Reporting• TT invocation

Performance Management• Threshold Mgmt• Collect Perf. Data• Correlate Service quality to perf • Analyze Perf. Data Reporting

Capacity Mgmt.• Analyze perf data• Traffic patterns• Trends• Resource• Capacity• What if analysis

Network

Human Resources Management Pay roll General Health

Logistics, Fleet Management

Procurement, Purchasing

Training & development

Enterprise BPMEnterprise Costing,

Accounting

BatchESB

Figure 3: Future CSP Application Architecture Source: Infosys Research

55

couple of services like IPTV and DSL as depicted in Figure 5, we can come up with the generalized services as given below:IPTV Service Delivery Customer IPTV service request Locate / create customer record Pre-qualify line Filter available IPTV packages Appropriate customer package Determine video hub office Activation (IPTV network activation,

activate MSTV account, deliver STB) Await STB (Set Top Box) connection Authentication confirmation Update details.

DSL Service Delivery Customer DSL service request Locate / create customer record Verify credits

Web Portal

Service Provider CRM

Integration Layer

Service Order Management Billing

Inventory Management Service

Inventory Network Inventory

Service Activation

Network, Applications and System Management

Network and Data Center Elements

Figure 4: Integration Case for Service Delivery


Verify Service availability Pre-order LSR (loop qualification) Request DSLAM port LSR Request CPE Installation Test facility Customer Acceptance Trigger Billing Order Completion.

COMMON DATA MODEL (SHARED INFORMATION DATA MODEL), DATA EXCHANGE AND INTEROPERABILITY WITH ESBMultiple Services, Different Players and Provider/Consumer RolesIn today’s CSP forum a provider for a service to a consumer can become a consumer for a different service offered by the earlier provider. Products and services offered by CSP enterprises are varied and changing and face strict market competition. When we get a new customer we have to intelligently find out whether she is truly a new customer, if not, what her profile details and buying/spending behavior are like. Customers can be primary or secondary, and as such when a secondary customer wants to buy a service directly from the enterprise her role changes to a primary customer and as such the provisioning systems have to smartly identify the available network resources in this new premise and create new work order if and only if required. Resources, whether network or other kind have to be used to the fullest extent. Here a CSP may opt for the service provided by another service provider which turns out to be cheaper than extending its own network. Setting up a new network is much more expensive than extending the old one. Depending on the closeness of the planned service area to an existing point-of-presence a judgment has to be made.

56

a business as well as a systems perspective. SID thus provides a knowledge base that is used to describe the behavior and structure of business entities as well as their collaborations/interactions. Thus CSP’s recent trend is to align the data model based on SID. SID specifies data semantics at cross-entity level, by defining Aggregate Business Entities (ABE) in specified CSP domains as well as defining their relationships. Given the fact that there is a prescription available for generating a Common Data Model (CDM), the next step is to standardize the data consumption mechanism. XML in SOAP format over HTTP is the preferred way to access data, but here we need to be concerned about the request and response content as well as the Message Exchange Pattern (MEP).

Web Portal

Service provider CRM

ESB

Service Order Management Billing

Inventory Management Service

Inventory Network Inventory

Service Activation

Network, Applications and System Management

Customer Management ServiceManage CustomerManage Customer Order( Customer, Supplier, Partner )Manage Product OfferingManage Billing Trigger

Order Management Services Manage Technical (Service) Order

Billing Service Manage Billing order

Resource Activation ServicesManage Resource Activation

Inventory Management ServicesManage DesignManage Service InventoryManage Capacity

Network Management Services

Figure 5: Services Identified for Fulfillment (Service Delivery)


Autonomous Systems and Federated DataFor years we have been building systems – enhancing older ones or adding newer ones, enhancing product catalogues and extending user base. It is common to see not less than 200 to 500 systems in each line of business, serving different customers and employees of the enterprise. Data is duplicated in multiple systems and no single system is able to provide an end-to-end view of a business entity. Moreover there is mismatch between the data model available in multiple schemas in multiple systems and the consumer requirement. The SID (Shared Information/Data model) by New Generation Operations Systems and Software (NGOSS) provides an information/data reference model and a common information/data vocabulary from

Network and Data Center elements

57

Figure 6: Illustrative Technical Architecture for ESB Based Service Definition


Application n – Fault Management

Application 1 – Network Management

Axis Context

Hibernate Mapping

AccessCircuit

.hbm.xml

PERouter.hbm.xml

Business Service

Circuit Info Business Service

Web Service

Circuit Web Service Others...

SOA Ecosystem

ChannelAdaptors

TransportChannels

BPM in Service

Network

Other Domains

Aggre-gate

Service

Intelli-gent

Routing

XSLTranslate

Norma-lizer

RecipientList

ESB

POJOBindings

SOAPBindings

RelationalWorld

LegacyAssets

SID Domains(Schema)

SIDRational

Rose UMLModel

DataSilos

• Oracle Warehouse Builder• Custom Made Mapping Tool • Etc.

ObjectWorld

Provider/Consumer

Roles

Spring Context

ETL

Application 2 – Provisioning System

WSDL

Equipment Business Service

DAO

Model

Access Circuit .java

PE Router.java

Enterprise

Supplier/Partner

Resource

Service

Customer

Product

Market/Sales

CommonBusiness

TCP/IP

JMS

HTTPService Delivery

CreateSupplier Order

ReserveInventory

CreateShipment Order

ScheduleShipment

CreateCustomer Order

Product Catalogue

Bundling/Marketing

EquipmentDefinition

Pricing/Discounting

ProvisioningRules

ServiceDefinition

OtherBindings

Access Circuit Dao Hibernate

PE Router Dao Hibernate

58

Service WorkbenchCommercial Off-the-Shelf (COTS) components play a big role in exposing data models to CSP applications. Each COTS component or application has to expose a well defined interface which forms the contract for another COTS package or for an application The application can even be an UI with which the user interacts with the system. Thus COTS components share COTS Data Model (CoDM) with each other and when they do so they first normalize the model to a Shared Data Model (SDM). SDM is thus the common, external representation of information which COTS components exchange with each other.

ESB Based Services Eco SystemCOTS components interact with each other using services. In the traditional point-to-point integration approach, if a consumer interacts with ‘n’ service providers we need ‘n’ adaptors at providers’ end to flatten the request/response. This means for ‘n’ systems to interconnect fully, we need ‘nXn’ adaptors. In the proposed ESB-based architecture we need only ‘2n’ such adaptors. This means as business expands and number of systems and applications increase, we need not always increase the complexity to interconnect systems. ESB provides Service Engines (SE) and Binding Components (BC). BCs bind local or remote services to the ESB, either in the provider or consumer role. Thus, COTS applications once bound to the ESB can participate in data exchange in both the provider and consumer role. SEs consist of computing code directly deployed in the ESB runtime which will provide functionalities like Format Translation and Rule matching. Coming back to the CSP domain problem of not having a standardized schema for

service level definition as against the SID based data model, ESB can play the role of building a services fabric. In this fabric we can access ABE data in the form of fine grained services through suitable bindings (SOAP BC, POJO BC). These are then aggregated and translated to match with the SDM schema, and then exposed through suitable channel for external and/or internal access. ESB based approach provides us with enough toolkits and hooks to mix and match services and do format and protocol translations which are of utmost importance to enterprises if they are to be truly agile and still be able to reuse all current assets in future

CONCLUSIONSOA in a CSP industry helps negotiate issues and fill gaps to provide next generation services especially while there is a paradigmatic shift in the way businesses are moving from siloed operations to a converged operations model.

REFERENCES1. Gnanapriya C et al., Enterprise

Architecture for Communication Service Provider Industry, iCTO Final Assessment, Sep 2006.

2. NGOSS frameworks, http://www.tmforum.org.

3. David Chappell, Enterprise Service Bus: Theory in Practice, O’Reilly Media, 2004.

4. Reliable Messaging in a Services Network, Available on http://www.ftponline.com/ea/magazine/summer2005/columns/soainsights.

5. An EAI Solution using WebSphere Business Integration. Available on http:// www.redbooks.ibm.com/abstracts/sg246849.html?Open.

59


Chemistry Workbench – A composite services approach to

transform drug research By Anirban Ghosh, PhD

SOA-based Chemistry Workbench remediates in the Lead Optimization phase of research to align to the compelling pressures of dynamic

drug discovery research

Drug discovery research desires constant innovation to test novel ideas and provide

leads for new drugs. Researchers either improve on existing processes or adopt emerging methods to enable better research outcome. An SOA-based modeling approach is adopted to align the activities better with the changing processes. Chemistry Workbench (CWB) is an SOA-based remediation tool for the chemists who identify and optimize lead compounds. It provides a common virtual interface for the lead optimization research group, based on a set of services to identify, validate and optimize lead compounds. The CWB facilitates quick dynamic access to data and documents intuitively and provides new collaboration possibilities. R&D challenges that can be addressed through SOA modeling approach are discussed in this article.

Also, emphasis is laid on building a remediation tool using suitable technologies.

TRENDS IN LIFE SCIENCES DISCOVERY RESEARCHLife sciences (LS) companies include pharmaceuticals, biotechnology, chemicals, crop protection and analytical instruments. Discovery research is an integral part of all LS group of companies which convert ideas to products [1]. Ideating for a product e.g., a drug molecule, needs constant innovation to test hypothesis, which implies continuous adoption and integration of novel methodologies into existing systems. Research groups also strive to optimize and improve existing processes to enhance productivity [2]. Therefore, the systems and processes under discovery research are

60

constantly challenged by emerging fields of therapeutic research process, and demand for adaptation and legacy modernization. Consequently, information technology systems need to suitably support the changes and offer an opportunity for service orientation in data management, reporting, decision making and collaboration [3]. The problem gets exaggerated during integration or bringing together of two different research processes closer by mapping tools and applications. Most often these tools are based on different platforms with incompatible architectures. Existing architecture definition methodology for each of the niche research processes is requirements driven and is currently built on components and class definitions. Again, some applications may not provide open interfaces to be integrated with other services, as they are third party vendor products. There may be instances of old legacy systems which may not be easily service-enabled. Thus, the adaptation of systems to align with changing research requirements is often slow and complicated.

SOA MODELING IN DRUG DISCOVERY RESEARCHIt has become imperative to face unpredictable risks while adopting new processes, integrating or interfacing two collaborating processes, or optimizing legacy systems and processes. SOA comes in handy to mitigate such uncertainties. SOA helps achieve agility in business processes by orchestrating reusable services identified after aligning business and IT processes in a technology and platform agnostic way [4]. The concept of SOA revolves around loosely coupled business functions and processes known as services [5]. A fundamental element of SOA is the separation of lines of business activities by service interfaces [4, 6]. These identified services

provide support for dynamic reconfiguration and enable loose coupling between the service consumer and provider [4, 6, 7]. Adopting inSOAP, the Infosys SOA adoption framework for service identification, definition, realization and service institutionalization in enterprises [4], a CWB for drug discovery researchers was developed by the author. This workbench is a composite services application prototype which addresses improvements in collaborative decision making. Companies need to consolidate their portfolio of R&D applications and migrate to a SOA framework which will be a less disruptive, low cost, and long standing solution to streamline drug discovery research. The objective is to create a common workbench interface for the R&D-IT users. This workbench should enable them to respond and accommodate all possible means and mechanisms to test hypothesis through dynamic exchange and analysis of research results. The ensuing section describes the makings of CWB, while elucidating the staged approach to arrive at the set of lead optimization services constituting the CWB which can enable a lead compound research unit to improve decision making capabilities.

OVERVIEW OF LEAD OPTIMIZATION RESEARCH PROCESSLead optimization is a critical phase in drug discovery research, in which one or more chemical molecules are selected for animal testing in the pre-clinical phase. Lead optimization starts with biologists performing high throughput screening of chemical compounds against therapeutic targets [Fig. 1]. The compounds from diverse chemical libraries that bind strongly with the target are identified as “HITS.” These molecules are further passed through secondary screening

61

to study their dose response or enhance binding affinity by altering their structure. Informatics specialists search and query databases to identify novel homologues, while computational chemists reengineer the structure using computational predictive methods. These predicted molecules are synthesized by organic chemists, and supplied to biochemists to test whether they have improved binding efficacy. Scientists refer published literature, patents and competitor information to study and compare the screened candidates. All the activities are focused to significantly improve selectivity and specificity property of chosen molecules and to optimize “HITS-to-Lead.” Lead molecules are tested by pharmacologists for safety and bio-availability in the laboratory models, which improve the chances for the next phase of drug development.

TRENDS IN THE LEAD OPTIMIZATION RESEARCH PROCESSLead optimization phase is the most complex research intensive process in drug discovery research. It involves a collaborative effort from biology, chemistry and pharmacology research groups. While the biologist community screen for active compounds against therapeutic targets, chemical researchers synthesize and re-engineer active compounds to improve their potency and specificity of binding activity, and the pharmacologists test safety and efficacy of each of the candidate compounds in the final stages of lead optimization. Scientists and laboratory managers from these groups together identify, optimize and validate lead compounds for all therapeutic research programs, in a purely milestone-based and performance-oriented approach.

LiteratureSearch

ComputerModeling,Docking

Primary Screening forActive Compounds

Structure ActivityRelationship

Targets, Library ofChemical Compounds, Biochemical

or Cell Based Assay

ActiveCompounds

LeadsPharmac okinetics,Pharmac ody namis

Tertiary Screening forLeads

HITS, Profile againstSafety & Toxicity Screens

Secondary Screeningfor HITS

Selectivity,Specificity, Potency

HITSActive Compounds,Multiple Bioassays,

Changing Concentration

Dose Response Curve,Determine MIC, IC50

Chemical Substructure& Homologue Search

Figure 1: Functional workflow of Lead optimization Source: Infosys experience

62

All research groups mentioned earlier have their own siloed portfolio of applications and systems which support their research activities. These applications – either customized or third party vendor distributed -- consist of heterogeneous databases servicing applications, niche laboratory platforms and document management systems. For example, the biologists use Cerius2 [8] as the structural biology and visualization tool, while chemists access PubChem [9] to search and query chemical compounds tested for any therapeutic assay. The involved technologies are thus often disparate and further, some of these are legacy systems. Integration of chemical database technology is also not possible since the data types and formats are not interoperable. Many vendor applications have been licensed for their domain

criticality, alignment with the business, user preference, and quality of technology. Currently, with the change in research activities owing to implementation of innovative methodologies e.g., chemical genomics, the functionalities of existing applications are underutilized. Also, the scenario can be such that a change in activities of one group impacts the entire lead optimization process, which necessitates optimal integration among various groups, currently not present in application-based architecture. Further, the vendor and custom-built functional applications either need optimization for overlapping functionalities, or in some cases do not support certain key activities. Currently lead optimization research is transforming from siloed approach to services exchange approach. Services based open

Lead Optimization Phase

Screening of BiologicallyActive Compounds

Synthesis and Re engineerActive Compounds

Safety and Efficacy Test toOptimize Lead Compounds

BiologicalResearch

ChemicalResearch

PharmacologicalResearch

Accord, BioBook,WinNonLin

SYBYL, ISIS,LeadSelect,

Pubchem

Cerius,ActivityBase, LIMS,PubMed, Spotfire

Figure 2: Services Exchange Approach – Research Components

Source: Infosys experience

63

interfaces implies that member scientists from one line of research are now able to access, read, and understand research outcomes of other associated line of research units, dynamically and offline, via services [Fig. 2]. Open services based approach to executing business workflows in an SOA-based approach mandates proper breakage of lead optimization research processes into constituent services, such that the end users can virtually access all systems and information therein, intuitively via the services. This will help users to cross-correlate data from diverse disciplines seamlessly and effectively to make an informed decision in a fast, interoperable and efficient way.

A COMPOSITE SERVICES VIEW OF LEAD OPTIMIZATION RESEARCHThere are separate lines of research that need to be actively communicating with each other through services to make efficient progress in therapeutic research. Therefore, an integrated view of services provided and consumed by various research groups can help assimilate all research data at one place to make an informed and holistic decision on the progress of each lead compound [Fig. 3 and Table 1]. So to address the functional transformations and accommodate exceptional research scenarios, first the processes among the functional groups need to be tightly integrated. Secondly, there should be a seamless

COMPUTATIONAL BIOLOGIST

BIOCHEMIST

COMPUTATIONAL CHEMIST

ORGANIC CHEMIST

PHARMACOLOGIST

Docking, Modeling, Literature Search

Structure Activity Relationship

Screening for Binding Efficacy, Safety, Dose

Response Study

Modeling, Search & Query for Chemical Library &

Literature

Synthesis of Re-engineered Chemical

Compounds

Integrated View of Service Provided and Consumed

Figure 3: Composite services view of Lead Optimization Research

Source: Infosys experience

64

integration of IT systems and applications across the functional groups via services. Thirdly, the systems should be broken into logical components fulfilling the services such that any alterations made in the functional role can be swiftly accommodated at the IT systems and functionality level.

SPECIFYING REQUISITE PORTFOLIO OF SERVICES IN OPTIMIZING A LEAD COMPOUNDFrom the currently existing vast and complex research process, only a few representative set of services have been highlighted to build CWB.

Expert Group

Computational Biologist

Biochemist

Organic Chemist

Pharmacologist

Computational Chemist

Functional Service Consumed

Docking & Modeling of Target & Inhibitors, Literature

Primary Screening for Binding Affinity, Literature Search

Chemical Synthesis of Scaffolds, Sub- structures;

Secondary Screening for Safety, Efficacy, Literature Search

Pharmacophore based models, Chemical library search, Literature Search

Provided

Predicted HITS

HITS or LEADS

Modified HITS or LEADS

Dose Response for LEAD compounds

Model & Analysis of LEAD compounds

Applications / Tools

Cerius2, LIMS, Marvin Draw, Spotfire, PubMed

LIMS, ActivityBase, PubChem, PubMed

ISIS, Marvin Sketch, LeadSelect, PubMed, PubChem

BioBook, Accord, WinNonLin, PubChem, PubMed,

SYBYL, ISIS, Marvin Draw, LeadSelect, PubChem

Table 1: Service specifications in Lead Optimization Research


High Throughput Screening is one of the key processes to identify lead molecules, but such a process takes a lot of time, is budget consuming and is largely a trial-and-error process. Therefore, predictive IT tools are developed and used to improve process efficiency of identifying lead molecules. Ligand Identification and Matching tool is one such novel predictive application which uses a database of chemical ligands to search for better and effective lead molecules which binds to target active sites [10]. Preliminary experimental binding data is used as input to this application. These input molecules are used to construct general profile

65

of the hypothetical binding molecules and search for novel homologues from the backend chemical database. The workbench contains a compound screening service registered for this application. Also, within is a molecular sketch and modeling tool called Marvin Sketch [11], which is a popular desktop tool available to the chemistry community. Molecular modeling service is opened in the CWB to enable users to draw chemical structures and convert models into chemical strings called “SMILES” [12]. Also identified in the CWB is a literature service, for user to search and reference published literature for chemical compounds which have advanced in their hypothesis testing. This literature service can even reach out to external data servers to execute remote search against the PubMed [13] literature database. The workbench also includes capabilities to generate matrix that is hooked from a custom-built utility which calculates probability of one atom chemically replacing another at an active site.

Figure 4 summarizes the services available in the CWB prototype.

REALIZATION OF CHEMISTRY WORKBENCHThe composite services representing the research tools and applications which help the biology, chemistry and pharmacology expert user groups to pursue lead optimization research is developed as CWB. The close collaboration of these tools/applications with limited to full functionality opened as services to various users across the lead optimization research community is a classic solution of SOA enablement in a transformed research environment. CWB has been implemented in Microsoft Composite UI Application Block (CUIAB) .NET 2.0 Framework [14]. The components of this workbench are client-tier components (Composite UI Application Block) running on the client machine, middle-tier components that include business and service components running on the web server, and flat

Annotated MDLDatabase

PubChemData server

NCBIData server

PubMedPubChemLigand Identification

Web Service

Web Reference

Compound ScreeningUser Controls

Molecular DisplayUser Controls

Generate MatrixUser Controls

LiteratureUser Controls

Molecular ModelingUser Controls

Integration API WSDL WSDL

Marvin Sketch

WSDL

Web Service Web Service

Module Handling/ Hosting Services

Event/State Handling Services

Common XML Schemas (XSD)

Figure 4: CWB Services Source: Infosys Research

66

files used for data storage. Figure 5 highlights all the features of the CUIAB framework used in the CWB. This workbench can help chemists search for novel homologues to HITS identified by biologists through primary assays. The novel alternatives suggested by predictive screening can be viewed for additional structural and chemical attributes through the chemical drawing and modeling software. If literature and toxicology related information need to be retrieved for select molecules, external PubMed literature sources can help supply the abstract of information on the molecule. The workbench can help users hook up custom utilities such as matrix generators

for computational biologists to analyze any probability matrices. This workbench can also facilitate hooking into web-enabled laboratory reporting tools for the pharmacologists. Figure 6 shows two snapshots of the CWB highlighting the services available to the lead optimization research community. This prototype is realized through the SOA modeling approach and by adopting the CUIAB framework of Microsoft.

CONCLUSIONThe CWB is a loose modular integration of services identified across biology, chemistry and pharmacology research community. It provides a common virtual interface of functionalities of applications for various expert users groups to

UI BementsShell

Module

Smart Part

Zone Workspace

Figure 5: Prototype of CUIAB-led CWB Source: Infosys Research

67

access, execute and analyze research data. It aligns with the increasing demand in data exchange capabilities to activate a pipeline of applications. Since this is currently an internal prototype, the CWB can be expanded dynamically by adding new services to the existing dashboard. The workbench defines new collaboration possibilities in response to transformed research requirements. It can handle better knowledge management capabilities to improve decision making on new hypothesis testing approaches. It also helps streamline business activities in each silo of research. It can further help improve chances of matching and mapping common business processes across silos of research groups. The advantage of using CUIAB is that it provides proven practices to build complex smart client UI. Simple user interface parts can be combined to create complex solutions, while concurrently allowing these parts to be independently developed, tested and deployed. It also increases productivity and faster ramp-up time for large development teams, by hiding

complexity and by focusing on business-related components instead of on the underlying infrastructure and complex aspects of user interface development, such as threading and asynchronous processing. All the application logic is executed on the server side and is not contained on the client. Smart clients can be deployed and updated from a centralized server. In conclusion, discovery research is increasing under pressure to deliver better, safe and effective drugs in quick time. In order to align to the changing research demands, the supporting IT systems need suitable SOA-based remediation. The CWB is one such remediation tool in the lead optimization phase of research and such SOA-based adoption is possible in any R&D unit of a life sciences company.

REFERENCES1. Thillai Rajan A., The Life Sciences

Challenge: An industry under pressure to innovate, SetLabs Briefings Vol2 No1, Jan-Mar 2004.

Figure 6: Snapshots of the CWB Prototype Source: Infosys Research

68

2. Anirban Ghosh and Thillai Rajan A., How Plasma Therapeutics leverages IT to transform drug discovery? SetLabs Briefings Vol2 No2, April-June 2004.

3. Hussain Mooraj, Colin Masson and Dennis Gaughan, Priming Pharma and Life Sciences for SOAs, AMR Research, April 2006.

4. Abdelkarim Erradi, Sriram Anand and Naveen Kulkarni, InSOAP: An Architectural Framework for Service Definition and Realization, Proceedings of ICWS 2006.

5. Making Sense of SOA, Alan S. Horowitz, TechTarget CIO Decisions Media.

6. Ali Arsanjani, Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA, IBM, Nov 2004.

7. L Cherbakov, et al., Impact of service orientation at the business level, IBM Systems Journal, Vol. 44, No4, 2005.

8. Cerius2 is a suite of molecular modeling and simulation package for structure based drug design. https://www.accelrys.com/products/cerius2.

9. PubChem is a public service database which has information on biological

activity of small molecules. http://pubchem.ncbi.nlm.nih.gov.

10. Anirban Ghosh and Nagasuma Chandra, Systems and Methods on Ligand Identification and Matching – A novel predictive methodology on identifying chemical homologues which improve binding against therapeutic targets and reduce adverse effects, Patent pending (US PTO), November, 2006.

11. Marvin Sketch and Marvin View, http://www.chemaxon.com/marvin.

12. SMILES is a simple, concise and rather readable molecular structure specification format. SMILES, a Chemical Language and Information System. 1. Introduction to Methodology and Encoding Rules, J. Chem. Inf. Comput. Sci. 1988, 28, 31-36. http://cactus.nci.nih.gov/services/smiles.html.

13. PubMed is a public repository of life sciences journal articles. http://www.n c b i . n l m . n i h . g o v / e n t r e z / q u e r y .fcgi?DB=pubmed.

14. http://msdn.microsoft.com/library/defau l t . asp?ur l=/l ibrary/en-us/dnpag2/html/cab.asp.

69


SOA: The missing link between Enterprise Architecture and

Solution ArchitectureBy Jaidip Banerjee and Sohel Aziz

Build service portfolios incrementally, discard the big-bang approach

Enterprise Architecture (EA) is increasingly acknowledged as a recognized way to

maximize existing IT investment while planning for future growth. As a discipline, enterprise architecture is tasked to ensure business-IT alignment through architectural oversight and guidance. It provides the enterprise with a four-dimensional model ---business, information, application and technical architecture -- to analyse and determine the right set of IT related decisions that enable and support business strategy. Service Oriented Architecture (SOA) is essentially about bridging the gap between business and IT through well defined business-aligned services, developed by subscribing to established design principles, frameworks, patterns and methods. The objectives of EA and SOA are quite similar. However, while EA is a framework that covers all dimensions of IT architecture for

the enterprise, SOA provides an architectural strategy that uses the concept of a “service” as the underpinning business-IT alignment entity. What is the impact of services in the way we develop our enterprise applications? What fuels the need for the identification and development of a service? Is there a link between the solutions we develop using the SOA strategy within the context of the enterprise architecture? Is it possible to define traceability from the Enterprise Architecture through to the development of solutions via services? In this article, we address the dependencies between an EA framework and a SOA strategy from an artifact’s point of view and answer the questions posed above by discussing the impact of introducing a first order entity such as service in EA as well as Solution Architecture (SOLA). SOLA is the architecture associated for a given business solution. Multiple

70

business solutions collectively define Enteprise Architecture.

ENTERPRISE ARCHITECTURE - ITS PURPOSEEnterprise Architecture is a guide to an organization’s competitive fitness. It is a dynamic process of managing enterprise IT change through a planned transformation. The transformation plan also provides required explanations, prioritizations, and tradeoffs for the involved deliverables. The aim is to develop business capabilities over a period of time, which gives the enterprise its competitive edge. This requires investments in people, processes and technologies with an expectation of attractive returns.

EA DISCIPLINESThe essence of EA is to create a map of IT assets and business processes and a set of governance processes that drive alignment between business and IT. There are many different frameworks – to name a few -TOGAF, DODAF, Zachman - for beginning an enterprise architecture effort. The four architectural disciplines that are commonly accepted as subsets of an overall Enterprise Architecture are highlighted in Table 1.

EA WITHOUT A TRANSFORMATION METHODUntil recently, most EA efforts were focused on developing an enterprise map of IT assets and a set of technical standards that aimed at harmonizing IT procurement. This has always been a significant, time consuming and expensive undertaking, whose ROI has often been opaque to the business. Standardizing, mapping and controlling IT assets do not make business more flexible, capable or profitable. Without a mechanism to deliver the standardization and reuse that EA advocates, EA efforts often fail or become completely technology-centric. An EA exercise must ensure that there are two major deliverables. First, the target enterprise IT architecture based on an articulation of the business requirements vision and second a governance model that enables the achievement of that vision through a well defined orchestrated transformation plan.

Defines the business strategy, governance, organisation, and key business processes

Provides a blueprint for the individual application systems to be deployed, their interactions and their relationships to the core business processes of the organization

Business Architecture

Applications Architecture

Describes the structure of an organization’s logical and physical data assets and data management resources

Describes the software infrastructure intended to support the deployment of core, mission- critical applications. This type of software is sometimes referred to as “middle ware”

Information Architecture

Technology Architecture

Table 1: Architectural Disciplines


71

SOA AND ITS IMPACT ON EAAdvances in integration technology, primarily intelligent and flexible middleware and web services, are providing new ways for designing more agile, more responsive enterprise architectures that provide the kind of value that business has been seeking. With these new architectures, IT can build new business capabilities faster, cheaper and in a vocabulary the business can understand. These advances are giving new life to a couple of old concepts like services and events that can inspire new EA efforts and revive failing ones. The first concept is the service. This provides the value to the business that in the old enterprise architecture was rarely more than a vague promise. Business people can call for a service in a language they can understand and IT can quickly link these with other services to form a process or, if need be, build a new ‘application.’ The second concept is the event. An event is something that happens due to enterprise business processes or due to external factors causing or influencing a shift in enterprise behaviour. If services make enterprise architectures more flexible and responsive, events make them more alert and better prepared to sense risks before they become issues.

WHAT IS SOA?Several definitions of Service Oriented Architecture (SOA) exist from IBM, Zapthink and CBDI to name a few. Essentially SOA may be defined as: An architectural strategy that aims to isolate and separate the consumption of business functionality from the provision of this functionality through a commonly defined and accepted service contract.

Figure1: SOA - Key Concepts


Service Provider

Service Registry Service Consumer

Publi

sh Bind

Find

Encapsulates some business domain specific logic and is exposed through a open standards based interface

Stipulates the conditions and terms under which a service is provided

Consumes the service or an assembly of services to deliver a particular business process

Provides the service based on a predefined service contract that guarantees a minimum service level which may include performance, reliability and usage cost

Holds the descriptions and contracts associated to the services available for consumption

Service

ServiceContract

Service Consumer

Service Provider

Service Registry

Table 2: SOA Concepts


The key concepts of SOA revolve around Service Provider, Consumer and Service Registry as shown in Figure 1 and explained in Table 2.

72

SERVICE ORIENTATIONService Orientation is a design philosophy, that considers IT resources as being made available on a network in a location independent way. The philosophy allows designers to furnish a layer of abstraction, masking the technical complexities that underlie such services.This allows business users access to IT functionality as and when needed, in a flexible, dynamic and cost effective manner.

APPROACH TO SERVICE ORIENTATIONThe two main approaches to introducing service orientation within any enterprise are:

Process driven (Top Down) ApproachThis approach takes advantages of business processes to identify and categorise services, whose implementations can be choreographed to provide scaleable and flexible on-demand solutions. This top down approach concentrates on the organization’s ability to model itself as a provider of services, especially business services. This is realised by

Identification of the business processes and events

Business information requirement for the identified processes

Decomposition of the business processes to a level of granularity wherein they are self-contained and independent

Classification of these self-contained and independent units also known as “Business Service” for realization by IT.

Application driven (Bottom Up) ApproachThe approach here harnesses existing applications by identifying areas of loose coupling and engaging in reusability before developing core services. These services are

assembled, supported by coherent interfaces to provide scaleable and flexible on- demand solutions. Steps to introducing SOA to an existing legacy environment following a bottom up approach generally are:

Identification of functionality within legacy systems to be published as services

Re-factoring and wrapping these functions to be exposed as services

Layering of services Orchestrating the exposed services to

achieve the functionality currently being provided by the existing applications

Re-evaluating the existing applications portfolio with the aim to weed out any redundancies.

Identification of the business process and its inter-dependencies, business events, business information requirements, application and technology landscapes are some of the key outcomes of any EA exercise.

Business process and its dependencies define how business goals / objectives are achieved

Business events define when a business process needs to be invoked to achieve the desired objective

Business information defines the information needs of the business process and business event

Application and Technology landscapes define the bricks and mortars for the enterprise.

SERVICE PORTFOLIO FOR SOAAs we identify services, there is a need for rationalization in line with the business processes

73

/ application, these services have been perceived to serve. As services are identified, it is also necessary to record their functional and non-functional details in a structured manner and create a portfolio - service portfolio. A service portfolio is consolidation of all services that have been identified and are required to support the business. It holds information such as service definition, access and usage policies and non-functional requirements for the service.

Figure 2 illustrates a process of populating the service portfolio both in top-down and bottom-up approaches. The dependencies between enterprise architecture and service oriented architecture are clearly addressed by a portfolio of services, that provides a bridge between how one wants to align business with IT via a set of planned business services. It provides the mechanism to feed processes translating business needs into a flexible design capable of easily adopting to business changes.

Enterprise Artifacts

Layering of Services

Service Portfolio

Applications Services

Appl 1

Appl 2

Appl 3

Appl 4

Appl 5

Appl 6

Processes Services

Process 1

Process 2

Process 3

Process 4

Process 5

Process 6

Business Processes-Services Mapping

Application- Services Mapping

Services Services

Figure 2: Service Portfolio Source: Infosys Research

74

Service portfolio is impacted by the business vision and objectives and also by how and when business wants to achieve its objectives. This in turn drives the identification, creation, definition and specification of services. A service portfolio plan provides enterprise users with three kinds of views: conceptual, logical and physical [Table 3].

In order that contextualised information on these artifacts is made available to the wider community within the enterprise, in a reliable and searchable way, there is the need for a central repository. This repository may be home to the service portfolio plan - a planned list of defined services that result from the decomposition and subsequent classification of EA artifacts like business process, events and information.

SERVICES & PATTERNS?In a top down approach to service orientation, business processes are core to a business. Decomposed to a level when they can be considered self contained & independent, these processes are Business Services. Once business services have been identified, one can decompose and classify them further, based on established patterns to populate the service portfolio with the information that is required to support the views that the service portfolio offers to its users [Fig. 3]. Business services can be classified as value services i.e., services that can only be provided

Supporting the conceptualization of service along with their governance needs

Supports the solutions architecture components for the services conceptualized

Identifies the physical implementation components of the services and their characteristics

Conceptual view

Logical view

Physical view

Table 3: Three views of Service Portfolio


Business Services

Value Services

Human Services

Factory Services

ProcessServices

FunctionalServices

InformationServices

UtilityServices

InfrastructureServices

Technical Services

Implemented as

Implemented as

Figure 3: Services & Patterns Source: Infosys Research

75

manually and factory services i.e., services that are candidates for automation and are implemented by technical services. Technical services are the physical implementations that support the various service patterns. These services implement both functional and non-functional requirements. These also include infrastructure services that help with operating the services and provide monitoring and management capabilities.

HOW EA ENABLES A SOA STRATEGY?One of the outcomes of an EA exercise, i.e., the definition of the enteprise business process model provides a basis for service orientation, through a top down approach. The dependency of a planned list of EA artifacts on the development of SOA is shown in Figure 4.

Any change within the enterprise has an impact on the constituents of service portfolio i.e., new business line, introduction of critical customer service SLA’s, improved security needs for a business operation, etc. Similarly, provisioned services - a service for which a detailed specification and system-tested software exist, and which is ready to be certified - have to be reflected back into the EA artifacts to maintain integrity between the proposed and implemented services.

SOLUTIONS ARCHITECTURE (SOLA)Solution architecture describes the components and elements required to deliver a solution successfully, how they fit together and the core technologies required. The solution delivers on the objectives derived from business and IT requirements.

Figure 4: EA artifacts for SOA Source: Infosys Research

InformationArchitecture

ApplicationsArchitecture

TechnologyArchitecture

Service Deployment

Impact of Service Provisioning

ServiceProvisioned

Certified

Retired

Archived

Operational

Specified

PlannedServicePortfolio

Roadmap & Planning

List of Services

BusinessArchitecture

Business Process, Events & Services

BusinessInformation,Application Landscape

Technology & Infrastructure

Landscape

ServicePortfolio

Business Objectives & Vision

Enterprise Architecture

EA - SOLA

Service Lifecyle

Solution Architecture

76

SERVICE ORIENTED SOLA Key to comprehensive solutions architecture is clarity of objectives. As well as being precise in requirement, the definitions have to be located in an environment visible to the stakeholders. Business needs to know that the business services defined are complete, in order that these services can be reused. Designers need to understand the services in order to manage changes in the service design. Program managers need to know the existence of these services, to promote reuse and avoid duplication. As mentioned earlier, identified services along with their functional and non functional requirements have to be in a location that is visible to the enterprise stakeholders. Service Repository can be such a location [Fig. 5]. For the services to be developed in line with the concepts of service orientation, solutions have to be crafted, verified, documented and made available to the stakeholders, before any development work starts. Detailed specifications for the services provide an insight into the to-be architecture of the solution. Finally once the solution has been agreed upon, the service portfolio needs to be updated to reflect the current state of the relevant service.

SERVICE LIEFCYCLEKey to solutions architecture is the articulation of its work products, the objectives that the solution is expected to achieve and any dependencies that need to be addressed before and while developing the solution design [Fig. 6]. A service repository is a natural fit, as it provides a centralized view into all service related information to the service stakeholders. A relationship exists between EA and SOLA via the service repository.

SERVICE REPOSITORYA service repository plays a critical role in providing visibility into services for reuse,

Portfolio ofservices

Solutions Specification of Services

Maintains Status Leads to

Enables architecting

Figure 5: Service Repository


-Maintain a catalogue of all service artifacts-Provide service change management-Enforcement of policies-Provide dependency management-Provide a comprehensive search facility-Provide Metadata-Allow service developers access via design tools-Enable service management information for Infrastructure Specialist-Provide impact analysis capability to service designers-Provide architects with data to analyse service utilization and their deployment

Responsibilities

Collaborations

Table 4: Service Repository: Responsibilities and Collaborations


77

Figure 6: Service Life cycle Source: Infosys Research

governing service production and consumption and measuring the benefits of SOA. Providing access to all stakeholders, the accuracy and integrity of information in the repository is maintained by its collaboration capabilities. A simplified representation of a service repository is shown in Figure 7. The repository caters for all information pertaining to a service lifecycle. Table 4 lists some of the key responsibilities and key collaboration facilities provided by the service repository.

DRIVING SOLASolution development is always influenced by business objectives and is triggered by service deployment plans recorded in the service portfolio. These deployment plans are tied to the timelines of the business objectives and hence are

Service Repository

Service Registry

Service Management Information

Service Runtime

Information

Service Developer

Other User

InfrastructureSpecialist

Solution Architect

Enterprise Architect

Business Analyst

Figure 7: Simplified representation of Service Repository


Service Deployment


Service Lifecyle

ServiceProvisioned

Certified

Retired

Archived

Operational

Specified


Roadmap & Planning

List of Services

ServicePortfolio

ServiceRepository

List of Services


SOA - SOLA LINK

Service Oriented Architecture

78

crucial to the development and implementation of the solutions. Policies around non-functional requirements and quality criteria are detailed against planned services and form the basis for solutions architecture. Figure 8 depicts the flow determining development and implementation of services. Information recorded in the service repository not only enables the design and development of solutions, but also reflects changes in the information characteristics, when solutions have been defined and implemented. A rich specification of services, completed as a part of service provisioning is critical to solutions design and development. This provides detailed information on core functional and non-functional capabilities of the services being developed in line with the planned services in service portfolio.

EA TO SOLA - THE MISSING LINKFollowing the trail of services, from its inceptions at dizzying heights of abstraction within enterprise architecture through to its definition in the realms of service oriented architecture and

finally the solution design and deployment, we have unearthed the constituents of a common thread that is the missing link. Figure 9 highlights the missing link - service portfolio and service repository. These artifacts drive the transition from envisioning services as a means to achieving business objectives to managing its lifecycle while being implemented. They are also the providers of all quality of service data, enabling continuous improvement. Between them they also enable SOA governance and a visibility of all changes, both current and future.

SOA WITHOUT EAOrganizations without an EA function, more often than not, still have some of the elements of EA artifacts like business processes, business event, etc. These artifacts in most cases are not recorded and are often word of mouth artifacts. Furthermore, there is no clear planning process for IT architecture. For an organization to build business solutions with a strong focus on reusability and an agile infrastructure that can change with

Lead toMaintains status

Enables architecting

Facilitates

Service Provisioning

Service DevelopmentLifecycle

Solutions

Service Repository(Maintains Integrity)

Service Portfolio

Figure 8: Delivering SOLA in a Service Oriented fashion Source: Infosys Research

79

changing business requirements, it requires an enterprise perspective on needs and their implications. This cannot be achieved without an effective EA program. Without an EA program, there is a clear lack of IT appreciation of the business changes and its impact on IT. This lack of visibility results in management’s reliance on an inaccurate or incomplete information about the state of the enterprise while arriving at key management decisions. SOA adoption in this case is often “technology” focused and restricted to individual projects. A critical success factor for SOA adoption is its adoption across projects - focusing not only on technical aspects but also, on functional aspects, within the boundaries of reference architectures and managing its

introduction as a programme. Without the right focus SOA adoption can easily lead to an application portfolio in which all applications/services depend on all applications /services in an enterprise level spaghetti architecture.

CONCLUSIONService portfolio and service repository provide the link between how the business percieves solutions to achieve its objectives and its interpretation of the perception along with its implications. This helps to create a common view of how an enterprise achieves and maintains agility. The need for a service portfolio is undoubtedly critical. It has to be acknowledged that undertaking such a task of building a service portfolio is anything but trivial both in terms of

InformationArchitecture

ApplicationsArchitecture

TechnologyArchitecture

Service Deployment


ServiceProvisioned

Certified

Retired

Archived

Operational

Specified


Roadmap & Planning

List of Services

BusinessArchitecture

Business Process, Events & Services

BusinessInformation,Application Landscape

Technology & Infrastructure

Landscape

EA - SOA-SOLA-The Missing Link

ServicePortfolio

ServiceRepository

Business Objectives & Vision

Enterprise Architecture

List of Services

Service Lifecyle


Figure 9: EA - SOL A - The Missing Link Source: Infosys Research

80

complexity and cost. Enterprises must embark on building their service portfolio in an incremental manner and not in a big bang fashion. Key to the success of any project is the visibility and communication of intention and its consequences. Service repository is the enabling component that aids stakeholders interested in service-related information (e.g., definition, design, implementation, testing, use, and retirement) obtain it in a manner appropriate for their objectives.

REFERENCES1. ZapThink, LLC : http://www.zapthink.

com. 2. IBM Developerworks : http://www-128.

ibm.com/developerworks. 3. The Open Group : http://www.

opengroup.org. 4. SOA Enterprise Patterns: http://

orchestrationpatterns.com. 5. CBDI Forum: http://www.cbdiforum.

com.

81


Addressing OEM integration through a SOA based

integration layer

SOA based integration layer can effectively address OEM needs

Automotive retail domain involves four key stakeholders: OEMs, Dealers, Dealer System Providers (DSPs) and end customers. Dealers have to interact with the OEMs to order parts, submit warranty claims and for a multitude of other product related business activities and they do so electronically through one of the two sources ---- Dealer Communication System (DCS) which is usually a web-based system provided by the OEM and/or OEM interfaces available through their Dealer Management Systems (DMS) supported by the DSPs. A DMS is used by the dealer to manage internal dealer operations such as inventory, finance and accounting etc. A multi-franchise dealership has to deal with additional complexity of interacting with multiple brands due to diverse OEM systems and data interchange requirements. OEMs have their own data exchange formats defined in order to communicate with dealers. The European market is extremely fragmented with a large number of DSPs and

the IT landscape is further complicated with changes in the Block Exemption Regulation (BER) that empowers the dealers to sell multiple brands under one roof. On account of BER, the market is witnessing lot of M&A activities in the dealer space. All this essentially means that there are a high number of DMS that each OEM system needs to communicate with. In addition, each DMS has to handle several OEMs [1]. The US DSP market is dominated by the big two --- UCS/Reynolds & Reynolds and ADP. With the recent acquisition of R&R by UCS, the market is in a state of transition [2].

NEED FOR AUTO RETAIL INTEGRATION: BUSINESS CHALLENGEHigh investment and prioritization is required to fully integrate the disparate DMS’ and other specialist systems (for e.g., lead management) with the OEM’s DCS and retail systems to obtain the benefits of integration. Certification process for a DMS takes time and effort for OEMs.

By Mani Krishnamurthi, Anandh R and Shashikiran Suvarna

82

Incomplete or partial integration will lead to lack of supply and demand chain visibility resulting in:

a) Higher order-to-delivery time (OTD). Average OTD time is 41 days with a minimum of 13 days and a maximum of 109 days. Today the customer demands and expects faster vehicle delivery time. 63 percent customers for mass market brands such as Ford and Volkswagen regard less than two weeks as ideal waiting time [3].

b) Inability to keep the customer informed about vehicle delivery time.

c) Unwanted vehicle and parts inventory leading to inefficient inventory management, over-capacity in the industry and inefficient means of disposing vehicles --- through auctions where the disposition costs are extremely high and the residual value of a vehicle is low.

d) Lost vehicle sales due to inability to meet customer choice.

e) Inability of vehicle owners to schedule vehicle service, order parts, leading to lost revenue and a higher detection-to-correction cycle for warranty management.

NEED FOR AUTO RETAIL INTEGRATION: TECHNOLOGY CHALLENGEDMS’ have their own data formats for multiple transactions in vehicle, parts, service and finance business domains and the OEM has to work closely with the DSP to ensure data transformation to its format in developing interfaces. The problem is compounded if OEM-specific business process requirements have to be incorporated into the DMS. The disparate technologies of individual DMS’

pose a huge challenge if multiple DMS’ are involved. OEMs are at various levels in the completeness of their DCS – some of them are web portals whereas others are mainframe solutions with a terminal at the dealer’s end. OEMs are also allowing dealers to interact with their DMS through interfaces in the DCS. Hence, there is an overlap in functionality between the DMS and DCS, leading to duplication of manual effort at the dealer’s end in data entry into these systems. Beyond DCS, commonly additional communication standards and data transfer mechanisms are applied between DMS and OEMs. Some DMS’ still work in flat files and interface with OEM systems in batch mode. Interfacing with specialist systems like lead management involves working closely with many smaller DSPs who may lack the scale, knowledge and infrastructure to work with OEMs.

SHOWCASING SOLUTION: AReIS All the aforementioned factors drive the need for a flexible, standards based and scalable communication model. A cost effective, robust solution should address their current IT landscape and account for legacy systems while enabling flexible and real-time communication. A web services-based service oriented architecture (SOA) provides one such seamless technology that can be used to integrate disparate systems. Such approach uses standards-based interfaces to applications (web services) that can be published, located and invoked by other applications over the network with minimal interoperability issues. We showcase a solution called Auto-Retail Integration Solution (AReIS) that addresses the needs of key stakeholders in the auto-retail domain by enabling them to leverage

83

their current systems. The solution uses web services-based SOA to enhance communication between OEMs and their dealers. SOA provides the desired framework for developing loosely coupled, cross organizational distributed applications and uses web services as application entry points while incorporating critical business factors such as service reliability, message integrity, transactional integrity and message security. The solution is standards-based, scalable and extensible and can effectively address the needs of an OEM, dealer group or a DSP. The OEM focused solution can reside inside the OEM’s domain and effectively abstract the functionality of multiple DMS’, used by dealers, while sending data to the OEM systems in their format. This solution leverages Standards for Automotive Retail (STAR), a domain standard for auto retail. AReIS is a middleware solution that enhances OEM-dealer and dealer-dealer communication, leading to seamless and effective collaboration and also shields them from multiple point-to-point interfaces with different formats. The solution would be beneficial to all the entities in the auto retail value chain.

TECHNOLOGY CONSTRUCT OF SOLUTIONThe technical challenge of enhancing and streamlining the real time communication channel between DMS and OEM systems is addressed by web services-based SOA. The exposed services adhere to the strict standards (STAR standards) that enable the systems deployed in disparate environment to communicate easily with each other. The detailed schematic of AReIS is shown in Figure 1. Usage of STAR standards for exchanging messages allows one to reap the

advantages of using a common exchange protocol and a document style web service.

AReIS solution leverages on Syndeo , an in-house service management framework/ESB –which works as an integration platform to model synergy among the services in an SOA. The framework consists of service management, security, reliability and governance modules. Further, the solution uses WS-Addressing specification that enables the AReIS framework to exchange messages with the DMS in a transport agnostic manner. To increase the scalability of the solution, all the STAR Business Object Documents (BODs) exchanged between the DMS/DSP and the OEM DCS are exchanged in an asynchronous manner. There are two different ways through which AReIS provides the DMS/DSP to communicate asynchronously with the OEM DCS. The first approach is by using a reply end-point using HTTP transport through which dealers connected to the OEM network can receive callback messages. The second approach is through an independent polling module developed as a part of DMS Client Interface module that is responsible for getting the results. Of the two approaches, the second one is non-intrusive, in the sense that the client interface does not need additional interfaces to be exposed to other applications though this might put a very heavy load on the Message Exchange Gateway servers. The AReIS solution allows the DMS clients to post STAR BOD compliant XML message requests to WebServices Messaging Gateway. AReIS has the capability of exchanging asynchronous messages with DMS clients having addressable end-points through off-the-shelf modules available as a part of the Syndeo framework. AReIS can also interact with clients having non-addressable

84

end points through support for polling DMS clients. Advantage of polling mechanism over the direct addressing approach is that the dealer needs an internet connection to access the OEM network and does not have to invest in a direct infrastructure link (e.g., VPN) to the OEM or any other infrastructure (like a Secure SMTP gateway). Each DMS has different formats for transactions in different domains (for e.g., parts order) and hence it becomes necessary to reliably transform the input transaction data into STAR standard before sending documents to the OEM Web Services Messaging Gateway. AReIS supports transformation of these formats

Figure 1: AReIS Solution Source: Infosys Research

to OEM specific format through a Document Transformation Engine. In addition to above, the Custom Integration Framework contains ESB Adaptor --a part of Syndeo framework – that is responsible for smooth integration with ESB.

DMS Client Interface ModuleFor DMS’ that are not fully STAR standards and web services compliant, adaptors are required for enabling the communication between the DMS and OEM systems. This adaptor in the form of a web services client is installed on the DMS/DSP server machine. It acts as a façade and helps DMS to interact/consume the remote

Dealer/DSP Infrastructure OEM Infrastructure

AReIS

ENTE

RPRI

SE S

ERVI

CE B

US

Direct Communication

link with OEM

WebServicesMessagingGatewayInternet

Internet Proxy

DMS

DMS

DMS

DMS

DMS

DMS HUB

Dealership Network (having direct OEM connection)

DCS Web Portalproviding Parts/Vehicle QueryFunctionality

STAR

WS-

Polic

yST

ARW

SDL ST

AR W

S-Re

liabl

e M

essa

ging

STAR

WS-

Secu

rity

STAR

UDDI

Web

Ser

vice

sM

onito

ring

WS-

Addr

essi

ng

Exce

ptio

nM

anag

emen

t

Tran

sfor

mat

ion

Engi

ne

Mes

sagi

ngSe

rvic

esES

B A

dapt

ors

Logg

ing

and

Pers

iste

nce

Audi

ting,

Rep

ortin

gan

d Ad

min

istra

tion

J2EE/.NET

applications

EAI S

AP

Adap

tor

EAI M

ainf

ram

eAd

apto

rsEA

I JDB

CAd

apto

rs

Existing EAI Layer

Data sourcesand Legacy

Applications Syndeo WebServices

Framework

85

web services exposed by OEM Web Services Messaging Gateway. This client module is also responsible for communication with the DMS for extracting the required information and constructing STAR compliant SOAP message and then posting it to the Messaging Gateway. This client module polls for any generic broadcast message that has been posted by a collaborating dealer and posts results accordingly. Security and Messaging Reliability in the solution is supported by WS-Security and WS-Reliable Messaging standard respectively that are a part of the Syndeo Framework.

BUSINESS BENEFITS OF AReIS SOLUTION Improving parts inventory managementAReIS enables dealers and OEMs to manage parts inventory by seamlessly integrating the DMS of individual dealers with DCS of OEMs and helps in automated replenishment initiative of the OEMs. It also provides dealers with visibility of parts inventory of other dealers and hence increases the sales of parts.

Vehicle swapOEMs do not have to develop expensive DCS to communicate with dealers. AReIS is capable of complementing DCS and provides real time information exchange. AReIS can help OEMs in quickly integrating dealers with different DMS’ to their own systems without much effort. OEMs can implement STAR standards without depending on DSP’s compliance and timelines for being STAR compliant. In addition, they do not need to make big changes to their legacy systems. We show the vehicle swap functionality as a case study in the subsequent section.

Warranty claimsAReIS helps streamline warranty claims request and makes the transaction real-time by enabling

interface with the DMS. Real-time transaction reduces the detection-to-correction time by shortening the time taken for a claim to reach the OEM from a dealership.

Key StakeholdersThe dealer facing business groups at the OEM and the IT department of the organization are the biggest stakeholders in the solution. The solution does not necessitate any change in the business processes. However for the OEM focused solution, the AReIS layer can be implemented in the customer’s server and the web services can be enabled for this server. Further web services may be required on the dealer systems as well.

CASE STUDY: MAXIMIZING VEHICLE SALES BY ENABLING VEHICLE SWAP FUNCTIONALITY Vehicle swap functionality is provided by DCS of some OEMs that enable dealers to view vehicle inventory of other dealers and be able to exchange (swap) vehicles between dealers.

Process flowFigure 2 depicts the process flow of vehicle swap functionality.

Limitations of current processBusiness value of this feature is dependent on the extent of integration. Dealer vehicle inventory data that resides in their DMS needs to be shared with the OEM and this requires DMS-DCS integration. Tighter integration can lead to increased vehicle inventory visibility and hence increased sales through vehicle swap. Vehicle swap is also dependent on latency of data. Up-to-date inventory information

86

can enhance this functionality. Batch processing and inventory update on a daily basis could sometimes lead to non-synchronization of actual versus displayed inventory.

AReIS SOLUTION APPLICABILITY IN THIS SCENARIOAReIS solution can be applied in this scenario to enhance the vehicle swap functionality by integrating the OEM’s DCS with DMS of the individual dealerships [Fig. 3]. AReIS integrates different DMS with the DCS and

hence increases vehicle visibility leading to increased sales. It enables dealers to post a vehicle/part inventory check request with other dealers and OEM and it also enables the dealers to confirm the order for the vehicle/part with the dealers or OEM online. AReIS can handle all the background processes to complete this transaction. AReIS enables integration across dealerships, irrespective of the type of DMS they may have.

Dealer reviews his Inventory to determine

match

Dealer sells vehicle

to customer.Dealer uses vehicle

Configurator in portalto search for vehicle, also

chooses dealer radius

Dealers search for vehicle to swap from Dealer Portal

Customer seeks a “blue” color vehicle of a particular brand

from Dealer

Vehicle swap process flow

Vehicle available in

lot?

No

Yes

End

Portal displays vehicles available with selected

Configuration andDealerships available

Dealer will contact Dealer whose vehicle

Config is closest to Customer match & swap

Vehicles from theirinventory

Vehicle swap process can be Automated

(thru portal) orManual-by phone

Dealer obtains vehicle & sells to

customer.

Dealer will manually Update DMS/dealer Portal or automated process will take

care of updating systems

End

Figure 2: Vehicle Swap Process Flow Source: Infosys Research

87

• Vehicle inventory info flows from Dealer DMS into Dealer Portal through integration layer, AReIS

• AReIS ensures standards based communication• Vehicle configurator will display closest matching combination from selected dealerships• Automated swap process will ensure vehicle

exchange & update relevant systems

Data/transaction flow:

Transaction flow of the AReIS solution

Data format:

Data format:Communication

SOAP xml files

OEM Corporate Applications

ServiceVehicleCRM

F&IWarranty Claims

PartsDCS Portal

AReIS

OEM Retail Apps.

DCS Data Repository

Dealer 1DCS

Web portal

DMS

Dealer 2DCS

Web portal

DMS

Dealer NDCS

Web portal

DMS

Communication:

httpsXML in legacy format

Figure 3: Transaction flow of the AReIS Solution Source: Infosys Research

A sample business case [Exhibit 1] showcases the value of enhancing the vehicle swap functionality to an OEM.

AReIS, through its web-services based architecture, can enable real-time communication and ensure that up-to-date data is available.

SUMMARYWe have showcased the applicability and business value provided by the SOA-based AReIS solution by highlighting a real-life business process in the auto-retail environment. AReIS serves as an integration layer that resides within an OEM system environment and abstracts the DMS residing in dealerships and provides seamless and ubiquitous communication between the OEM and various dealers it interacts with through its SOA based design.

# of OEM vehicles sold annually

Increase in vehicle sales due to enhanced Vehicle swap functionality

Profit made per unit

Increased profit due to increased sales

~1 Million vehicles

5,000 (at a conservative 0.5%)

$1000

$5 Million

Exhibit 1: Sample Business Case


88

REFERENCES1. Woods and Seaton, Automotive Systems

and Communication Service, Automotive Retailing in North America, Development and Trends in Systems and Processes, Volume 1, September 2005.

2. Woods and Seaton, European Development and Trends, Volume 1, January 2004.

3. Ben Waller and Simpson Carpenter, The Customer and the 3 Day Car, Focus Group, May 2000.

4. Collaboration in Auto Retailing, Infosys white paper. Also available at http://www.infosys.com/industries/automotive/white-papers/default.asp.

5. Mercer, G.A., A new way to sell cars, McKinsey Quarterly, pp.132, 2003.

6. Thilo Koslowski and Michael Doman, As EU rules shift automakers need to focus on Customers, not control, Gartner G2 research, March 2004.

89

“SOA creates powerful virtual ecosystems of business

collaboration”

“….. the suite of E-commerce services offered by Amazon demonstrates this concept.” Consulting Editor, Dr. Srinivas Padmanabhuni envisions that in future, business applications will be assembled from best of breed services available within or outside the boundaries of the firm.

In the previous issue, we explored the different best practices in terms of achieving practical

SOA roadmaps in enterprises. While this issue has explored myriad opportunities in terms of business solutions on both horizontal and vertical dimensions – one common theme that appears is that the modularity and flexibility SOA offers has begun to provide meaningful results. The key to leveraging standards based contract driven approach to IT provisioning for business, lies in successful engineering of the contracts with a business orientation. From a business perspective, SOA will enable bringing rigid engineering principles to building business solutions. On the same note, it will enable availability of business modules which can be assembled on the fly. To

enable large scale realization of this vision, an immense opportunity awaits the enterprises, with a real chance of getting closer to the all elusive business-IT alignment. Already many early adopters are showing the way in terms of proving the value of SOA, notwithstanding the hype, reality has begun to sink in terms of business benefits of doing SOA right, with a business perspective. Notwithstanding the abovementioned vision, the pace of adoption of SOA in delivering business solutions has not been the same across different verticals. The early adopters include the financial services, health care and telecom verticals. Other niche verticals like transportation, logistics, automotive and manufacturing are slowly picking pace. Even

THE LAST WORD

90

some unconventional verticals like utilities industries have begun to realize the value of SOA. Another key adopter of SOA is the government sector across the world, right from USA to Europe to Asia. Tens of G2G,G2B, and G2C initiatives are getting spawned on the SOA backbone. Several US federal government departments have launched SOA based initiatives to deliver on the promise of faster integration. On a related note, by virtue of being namesake, some recent initiatives from IBM and others, have started focus on leveraging SOA to bring science to “Services”, a key constituent of major economies today. A large number of opportunities are being opened by SOA for enterprises. In terms of quick wins, SOA has found easy acceptance for immediate ROI in integration focused opportunities like legacy enablement to SOA for legacy platforms like mainframes, enabling a service based approach to accessing legacy assets via service wrappers. Likewise, opportunities around data and information integration (including portals) are getting mainstream with services appearing as natural interfaces over heterogeneous data sources. Further quick wins have also been demonstrated in opportunities like self-service applications and multi-channel integration. Beyond the quick wins, many organizations are also realizing the strategic value of SOA and are taking bold steps in SOA adoption. In many organizations SOA is being used as a strategy to do phased and smooth long term legacy modernization, in contrast to the quick win legacy wrapping approach. Some organizations have started leveraging the power of SOA to trigger enterprise architecture transformation wherein SOA is being used to bring business architecture to the forefront, an aspect of enterprise not paid much attention

hitherto. In this context, SOA is emerging as a complement to BPM trend in enterprises. In some more forward looking deployments, SOA has been deployed for strategic infrastructure virtualization initiatives by leveraging Service Oriented infrastructure mechanisms yielding next generation data centers. However, the power of SOA is not being limited to single enterprises; it has started percolating to create powerful virtual ecosystems of business collaboration. Power of SOA in creation of such virtual business ecosystems is demonstrated by the success of the suite of E-commerce services offered by Amazon. It has spawned off a whole ecosystem of businesses leveraging services not necessarily developed in-house. In tune with this trend of making business functions available as a service, it is envisioned that the future business applications will not be developed in a custom manner or procured as a product, but will be assembled from best of breed services available internally or externally. Such trend of composite applications will become commonplace in the near future. A key catalyst for this kind of ecosystem is the emergence of SaaS (Software as a Service) as a mainstream business model. While SaaS is about delivering software in a hosted mode as a service, SOA has a key role to play in SaaS. Doing SaaS based on SOA, can guarantee flexibility and scalability owing to the fact that it might not always be possible for a SaaS vendor to deliver on all the services the consumers may require, that can be overcome by an SOA based way of mixing the services from the SaaS vendor with other services from other providers a la composite applications. While we have discussed the near and long term vision in terms of opportunities SOA can offer, different pieces of the underlying enabling SOA ecosystem are still

91

being researched. At a base level, there is now a decent understanding of the basic concepts of SOA, and some of the core standards and architectural principles in SOA. However, stretching that further, when we enter the arena of bringing the concept of service orientation to build software systems, a whole new paradigm of service oriented software engineering (SOSE) is born. SOSE is currently in very early stages of definition, and a clear picture of life cycle view of software development in SOSE is yet to emerge. This is an open invitation to the software engineering community and to the software architecture community to put investment in moving beyond SOA to SOSE…

About the AuthorDr. Srinivas Padmanabhuni is a Principal Researcher and heads the SOA Centre of Excellence in SETLabs, Infosys. He specializes in Web services, Service Oriented Architecture, and Grid technologies alongside pursuing interests in semantic web, intelligent agents, and enterprise architecture. He has published extensively in international conferences and journals alongside speaking at thought leadership forums in the areas of SOA and Web services. Prior to joining Infosys, Dr. Srinivas has worked in multiple capacities in startups in North America. Dr. Srinivas holds a PhD in computing science from University of Alberta and undergraduate and graduate degrees in Computer Science from Indian Institutes of Technology (IIT) at Kanpur and Mumbai respectively

92

Index

AJAX 14-18, 20API 9-10, 33, 44, 65Amazon 14-15, 18-19, 89-90Block Exemption Regulation, also BER 81Business Process Management, also BPM 27, 29, 36, 43-46, 48, 57, 90Business Process Modeler 46CRM 47, 52-55, 87 Cerius 62, 64, 68Chemistry Workbench, also CWB 59-60, 64-67Commercial off-the-shelf, also COTS 47, 57 components 58 Communication Service Provider/s, also CSP/s 49-56, 58Component binding 5-7, 11, 58 framework 5Dealer communication system, also DCS 81-87 management system, also DMS 81-87 system provider, also DSP 81-85Document Object Model, also DOM 19EAI 4-5, 43, 46-48, 51, 58EJB 10Engine Rule 46, Service 5-6, 58Enterprise Information System, also EIS 8Enterprise Service Bus, also ESB 3-5, 9-12, 35, 44, 46-47, 51, 53-58, 83-84HIPAA 32-33, 36HL7 33-34, 36JMX 5-7, 11Java Business Integration, also JBI 5-8, 10-12Layer orchestration 41

presentation 16, 41 service 41, 45 transport 41

Loose coupling 4, 11, 28, 60, 72Marvin Sketch 64-65, 68Message Exchange Pattern, also MEP 56Message Queue Middleware, also MQM 5, 9, 11-12Normalized Message Router, also NMR 5-6, 12PubChem 62, 64-65, 68RSS 2.0 16 Feeds 13-14Representational State Transfer, also REST 14-15, 17-18Rich Internet Applications, also RIA 13, 45Ruby on Rails, also RoR 14-15, 17, 20SMILES 65, 68SOAP 14-15, 17-19, 47, 51, 56, 58, 60, 85, 87Service component architecture, also SCA 5, 7-9, 11-12 data objects, also SDO 8-9 delivery 36, 49, 53, 55-56 level agreement/s, also SLA/s 27-28, 53-54, 75 lifecycle 5, 77 -oriented architecture, also SOA 3-4, 12-16, 19, 27-29, 31, 33-34, 36-37, 39- 53, 56, 58-60, 69, 75, 77-79, 82, 91 portfolio 69, 72-80 repository 44, 69, 76-80Standards for Automotive Retail, also STAR 83-85Stateless Session Bean, also SSB 8Straight Through Processing, also STP 37

93

WSDL 5-9, 17-19, 57, 65, 84Web 2.0 13-20Web Services 3, 10, 14-20, 33-36, 39, 42, 44-45, 47, 51-52, 71, 82-85, 87, 91XACML 36,

XML 5, 7, 10, 17, 18-19, 33, 56, 83 interfaces 17XSLT 6-7, 19, -based transformation 6 service engine 6

SETLabs BriefingsBUSINESS INNOVATION through TECHNOLOGY

EditorGeorge Eby Mathew

Consulting EditorSrinivas Padmanabhuni

Deputy EditorsPraveen Bhasa Malla

Sumanta Deb

Copy Editor Anupama Gummaraju

Graphics/Web EditorsRamesh RamachandranSanjay Eknath Nayak

ITLS ProgramAjay Kolhatkar

Marketing Managers Jacob Varghese

Vijayaraghavan T S

Production ManagersSudarshan Kumar V S

V H Suresh Kumar

How to Reach Us:

Email: [email protected]

Phone: +91-80-41173878

Fax:+91-80-28520740

Post: SETLabs Briefings,

B-19, Infosys Technologies Ltd. Electronics City, Hosur Road,

Bangalore 560100, India

Subscription: [email protected]

Rights and Permission:[email protected]

Reprints:[email protected]

SETlabs Briefings is a quarterly published by Infosys’ Software Engineering & Technology Labs (SETLabs) with the objective of offering fresh perspectives on boardroom business technology. The publication aims at becoming the most sought after source for thought leading, strategic and experiential insights on business technology management.

SETLabs is an important part of Infosys’ commitment to leadership in innovation using technology. SETLabs anticipates and assesses the evolution of technology and its impact on businesses and enables Infosys to constantly synthesize what it learns and catalyze technology enabled business transformation and thus assume leadership in providing best of breed solutions to clients across the globe. This is achieved through research supported by state-of-the-art labs and collaboration with industry leaders.

Infosys Technologies Ltd (NASDAQ: INFY) defines, designs and delivers IT-enabled business solutions that help Global 2000 companies win in a flat world. These solutions focus on providing strategic differentiation and operational superiority to clients. Infosys creates these solutions for its clients by leveraging its domain and business expertise along with a complete range of services. With Infosys, clients are assured of a transparent business partner, world-class processes, speed of execution and the power to stretch their IT budget by leveraging the Global Delivery Model that Infosys pioneered. To find out how Infosys can help businesses achieve competitive advantage, visit www.infosys.com or send an email to [email protected]

Editorial Office: SETLabs Briefings, B-19, Infosys Technologies Ltd.Electronics City, Hosur Road, Bangalore 560100, India

Email: [email protected] http://www.infosys.com/SETLabs/briefings/

© 2007, Infosys Technologies Limited Infosys acknowledges the proprietary rights of the trademarks and product names of the other companies mentioned in this issue. The information provided in this document is intended for the sole use of the recipient and for educational purposes only. Infosys makes no express or implied warranties relating to the information contained herein or to any derived results obtained by the recipient from the use of the information in this document. Infosys further does not guarantee the sequence, timeliness, accuracy or completeness of the information and will not be liable in any way to the recipient for any delays, inaccuracies, errors in, or omissions of, any of the information or in the transmission thereof, or for any damages arising there from. Opinions and forecasts constitute our judgment at the time of release and are subject to change without notice. This document does not contain information provided to us in confidence by our clients.

Authors featured in this issue

ABHISHEK CHATTERJEEAbhishek Chatterjee is a Software Engineer with the Web Services Center of Excellence, at SETLabs, Infosys. He can be reached at [email protected].

ANANDH RAJAPPAAnandh Rajappa is a Principal with the Automotive and Aerospace business unit, Infosys. He can be contacted at [email protected].

ANIRBAN GHOSHAnirban Ghosh, PhD is a Solutions Manager with the Life Sciences practice in the Insurance, Healthcare & Life Sciences business unit, Infosys. He has made significant contributions in informatics through international publications and patents. He can be contacted at [email protected]

BIJOY MAJUMDARBijoy Majumdar is a Technical Architect with the Web Services/SOA Center of Excellence in SETLabs, Infosys. He can be reached at [email protected]

BINILDAS C. A.Binildas C. A. is a Senior Technical Architect with the Communication and Service Providers business unit, Infosys. He can be reached at [email protected]

GEO PHILLIPSGeo Phillips is a Software Engineer with the Web Services / SOA Center of Excellence at SETLabs, Infosys. He can be reached at [email protected].

GNANAPRIYA C.Gnanapriya C. is a Principal Architect and heads the technical architects group at the Communication and Service Providers business unit, Infosys. She can be reached at [email protected]

JAI GANESHJai Ganesh, PhD, is a Senior Research Associate with the Web Services/SOA Centre of Excellence, SETLabs, Infosys. He can be reached at [email protected].

JAIDIP BANERJEEJaidip Banerjee is a Senior Architect with the Technical Consulting Group, Infosys. He has extensive experience covering enterprise architecture definition and implementations. He can be reached at [email protected]

JAYAKUMAR VENKATARAMANJayakumar Venkataraman is a Principal Consultant with the Banking Domain Competency Group, Infosys.He can be contacted at [email protected]

MANISH SRIVASTAVAManish Srivastava is a Principal Architect with the Microsoft Technology Center, Infosys. He currently manages the solution development program for Catalytic IT – a joint initiative between Microsoft and Infosys to develop technology led business transformation solutions. Manish can be reached at [email protected] .

MANI KRISHNAMURTHIMani Krishnamurthi is a Principal with the Automotive and Aerospace business unit, Infosys. Mani has more than 14 years of business experience in the automotive industry with a strong background in supply chain and automotive retail. He can be contacted at [email protected].

RAKESH MISHRARakesh Mishra is a Principal with Enterprise Solutions, Infosys. He specializes in enterprise integration and enterprise architecture solution. He can be contacted at [email protected]

SOHEL AZIZSohel Aziz is an Associate Vice President and Principal Architect with the Technical Consulting Group. Infosys. He has extensive experiences covering IT strategy, enterprise architecture definition and implementations. He may be reached at [email protected]

SHASHIKIRAN SUVARNAShashikiran Suvarna is a Technical Architect with the Automotive and Aerospace business unit, Infosys. He can be contacted at [email protected]

SHAURABH BHARTIShaurabh Bharti is a Junior Research Associate with the Web Services SOA Center of Excellence, SETLabs, Infosys. He can be reached at [email protected].

VIJAYA BHASKAR PEDDINTIVijaya Bhaskar Peddinti is a Software Engineer with Web Services/ SOA Centre of Excellence in SET Labs, Infosys. He can be reached at [email protected].

SIDDHARTHA VIJAY JOSHISiddhartha Vijay Joshi is a Consultant with the Banking Domain Competency Group, Infosys. He can be reached at [email protected].

TERANCE DIASTerance Dias is a Software Engineer with the Web Services / SOA Center of Excellence, SETLabs, Infosys. He can be reached at [email protected]

UJVAL MYSOREUjval Mysore is a Software Engineer at the Web Services / SOA Center of Excellence, SETLabs, Infosys. He can be reached at [email protected]

VARUN PODDARVarun Poddar was a Software Engineer at the Web Services / SOA Center of Excellence, SETLabs, Infosys.

YALE YUYale Yu is a Senior IT Architect with Enterprise Integration Services, Infosys Australia. He specializes in enterprise integration strategies and enterprise architecture. He can be contacted at [email protected]

Subu Goparaju Vice President

and Head of SETLabs

“At SETLabs, we constantly look for opportunities to leverage tech-

nology while creating and implementing innovative business solu-

tions for our clients. As part of this quest, we develop engineering

methodologies that help Infosys implement these solutions right

first time and every time”.

For information on obtaining additional copies, reprinting or translating articles, and all other correspondence,

please contact:

Telephone : 91-80-41173878

Email: [email protected]

© SETLabs 2007, Infosys Technologies Limited.

Infosys acknowledges the proprietary rights of the trademarks and product names of the other

companies mentioned in this issue of SETLabs Briefings. The information provided in this document

is intended for the sole use of the recipient and for educational purposes only. Infosys makes no

express or implied warranties relating to the information contained in this document or to any

derived results obtained by the recipient from the use of the information in the document. Infosys

further does not guarantee the sequence, timeliness, accuracy or completeness of the information and

will not be liable in any way to the recipient for any delays, inaccuracies, errors in, or omissions of,

any of the information or in the transmission thereof, or for any damages arising there from. Opinions

and forecasts constitute our judgment at the time of release and are subject to change without notice.

This document does not contain information provided to us in confidence by our clients.

Apr - Jun 2007libvolume3.xyz/computers/btech/semester8/servicesorientedarchitec… · Enterprise...

Documents

Transcript of Apr - Jun 2007libvolume3.xyz/computers/btech/semester8/servicesorientedarchitec… · Enterprise...