Page 1

SETLabs Briefings VOL 5 NO 3 Jul-Sept 2007

SOA Based Integration for Creation of Collaborative Supply Chain in Automotive Domain By Krishnendu Kunti, Terance Dias and Ashwini Jeksani

Enable collaboration among supply chain partners using SOA-based integration platform

A

utomotive industry has one of the most

by the SOA based integration platform and

complex supply chains primarily because

highlight the major pain points addressed by

of the complex nature of the end product,

such a platform.

number of supply chain partners involved and the geographical dispersion of supply chain

EVOLUTION OF SUPPLY CHAIN

partners. A typical vehicle requires somewhere

AUTOMOTIVE INDUSTRY

around 5,000 to 7,000 finished parts; these

During the early 20th century the modern

finished parts in turn consume nearly 130,000

automotive industry came into existence. One of

subparts [1]. These parts are either manufactured

the events that brought automobiles within the

in-house or sourced from multiple supply chain

reach of general consumers was the introduction

partners across the globe resulting in complex

of Ford T model [2]. The T Model was based

supply chains.

on mass production of single base model with

Supply chain in automotive

industry has matured over time and is still in a

zero customization resulting in huge economies

flux, driven by business needs.

of scale. Every component required in Ford T

We discuss the nature of supply chain

model was manufactured in-house resulting in

in automotive industry, the present business

a simple supply chain. However this mode of

drivers and resulting demands on supply chain

manufacturing resulted in huge amount of safety

integration. We also propose on how a SOA

stock for individual components. Also it did not

based integration platform is best suited to

allow desired customization to the base model

address these issues. Subsequently, we discuss

and did not outsource better engineering and

the required functionalities to be supported

manufacturing skills from other organizations.

1


During the early 1970’s Toyota introduced an

Automotive majors have realized that

alternative manufacturing model --- a model

in order to survive they should strive to get the

that brought together advantages of economies

best of technology at the lowest of cost and in

of scale and customization as per customers’

the fastest time to market possible. In order to

demands.

Toyota’s

manufacturing

was based on principles of

model

achieve the target they need to collaborate with

just-in-time (JIT)

multiple supply chain partners across the globe.

manufacturing and keiretsu [3]. JIT is based on pull system that provides information on exactly

EMERGENCE OF COLLABORATIVE

what components and sub-assemblies need to be

SUPPLY CHAINS

produced by means of paper based cards known

In a collaborative supply chain scenario,

as kanbans [4]. Keiretsu relies on collaboration

supply chains of stake holders are intricately

among multiple business stakeholders towards

interwoven. Supply chain partners not only

achieving common business goals. When applied

collaborate towards exchanging data for final

to automotive supply chain this results in

goods delivered (e.g., sending information on the

outsourcing of some functions to other business

items to be procured) but also share information

Huge synergies can be gained by different partners in an intricately woven collaborative supply chain scenario

entities that are better equipped to execute the

leading to visibility across each other’s supply

function. For instance, an automotive design-

chains. Virtually collaboration can happen at

house could design multiple variants of the

any level of business, for instance, OEM getting

same base model faster than an in-house design

discounts for a medium scale supplier or dealers

team. Extending JIT to supply chain partners

deciding on promotion in conjunction with OEM

resulted in even better inventory control and

to push a particular make of a vehicle. The final

smother response to variations in demand. Using

realization is that business is driven by efficiency

the Japanese manufacturing system, companies

of the whole supply chain rather than efficiency

were able to meet varied customer demands,

of a single organization. Any gains made by

with lesser inventory in a shorter period of

one supply chain partner will be passed on to

time. In recent years apart from reasons of

other members of the supply chain and vice

technical expertise manufacturing has also been

versa. Essentially participants of a collaborative

outsourced to other business entities because

supply chain can be seen as a single distributed

of price differentials arising out of location

business entity that collaborates at multiple

advantages.

levels of business requirements. The success

2


towards creation of collaborative supply chain

medium size vendors are reluctant to accept such

depends on the ability to share information

technology. Also, EDI is not sufficient to capture

across multiple supply chain partners with the

different kind of data interchanges required for

least cost and effort. Given the number of supply

creation of collaborative supply chain.

chain partners in a collaborative supply chain

Requirements to support different

and the fact that often a single entity takes part in

data

more than one supply chain (e.g., single supplier

that communicate using different protocols

supplying to more than one OEM) it becomes

and are deployed in disparate systems poses

extremely difficult to meet the integration

considerable

requirements in such scenarios.

collaborative supply chain . •

format

across

multiple

challenge

in

applications

integration

Supporting multiple data formats (e.g.,

IT LANDSCAPE SUPPORTING SUPPLY

EDI, flat file, any business specific

CHAIN MANAGEMENT

defined schema like STAR etc) both

Typically supply chain applications were either

within enterprise and external to

home grown or procured from supply chain

enterprise (supply chain partners)

vendors. These applications addressed specific

of

Exposing business interfaces locked in

supply chain functions such as demand planning,

supply chain applications as services

factory

using standards based syntax (e.g.,

planning,

production

scheduling,

transportation management etc. Within an

WSDL) •

enterprise if a supply chain suite is procured from a single vendor, the vendor, more often

Supporting multiple types of end points e.g., JMS, HTTP, .NET, EJB, RMI,

than not, provides an integration application to

databases etc •

coordinate among its own suite of applications

Support for widely adopted standards

e.g., i2 operational data store [5], or uses EAI

for business document interchange e.g.,

tools for integration. However, if within a supply

RFC4130

chain, applications are procured from multiple

EDIINT (aka. AS2) transfers (use for

vendors then there does not exist any standard

EDI)

means of integration between these applications

Business Object Documents (XML)

and in such a scenario integration is done by

and

for

MIME-based

STAR

HTTP

specification

for

transfer using ebXML and web services •

batch mode data extracts or using EAI tools.

Defining common business schema,

Integration based on batch mode data extracts

that maps to different application

induces latencies inherent to batch processes

specific

and creates point to point connections which are

transformations •

hard to maintain. While EAI tools might provide

schemas

and

required

Providing means to create process from

real time integration they create vendor lock-in

services using workflow languages like

and are often expensive to implement. The other

BPEL etc •

issue faced in such scenarios is standardization

Manage

authentication

of exchanged data format. EDI [6], an existing

authorization across multiple business

approach for data interchange in the automotive

domains •

industry, is often expensive both in terms of cost and effort to implement and hence small and

Integration of supply chains with least cost and minimal effort.

3

and


Often organizations handle integration of supply

based

format

(e.g.,

Xquery,

OQL)

chain in piecemeal manner using custom code

exposing them to standards based interface

(e.g., ABAP for data extraction form SAP ERP

definition language (e.g., WSDL) or using

to be used in planning applications) resulting

API. Data services layer also provides value

in point to point connections that cannot be

added features like caching, profile based data

reused by other applications requiring the

filtering and meta data management. Output

same data.

from data access services can be translated

and

and transmitted over required protocol to SOA BASED PLATFORM FOR SCM

destination systems using SOA based integration

COLLABORATION

backbone.

A SOA based platform to manage supply chain integration should handle integration needs at

Application level services: Application level

multiple levels of enterprise IT viz., data access

services are

layer, application layer, integration layer and

API’s. However application level API can only

process layer.

be accessed on a particular platform. At this

provisioned

from

application

A highly distributed architectural platform like SOA should be able to address supply chain integration at all levels of enterprise IT to achieve maximum SC collaboration

layer a SOA based integration platform provides

Data services layer: In enterprise supply chain

application

integration,

tools for rapid generation of services from

integrators

are often faced with a scenario where in the

platform dependent API (JAVA, .NET, Legacy

absence of API for data access, point to point

etc). Tools enable faster migration of application

custom code needs to be written for data

interfaces to SOA and allow incorporation of

movement. For instance, if data needs to be

value added features like caching and security.

moved from one or more manufacturing

These tools can also be used to auto generate

applications

to

one

planning

applications

formats,

writing

or

point

more requiring to

service interfaces (e.g., web services artifacts),

destination

provide mapping between service schema

different point

and

data

business

data

definition

schema,

extraction code can be time consuming and

provide value added features like caching,

cost intensive and extremely hard to maintain

authentication, etc., and finally deploying

in the

generated artifacts. However it is important to

long run. In such scenario shared

data services[7] platform can be used for

note that an application level API can be directly

defining distributed queries in a standards

consumed at integration layer as well. The

4


Process Layer Definition of coarse grain business function services by creating workflows from services in data access, application and integration

Integration Layer

Service Meta Data Ontology and Repositor relations

Standards based handling of integration, routing, content-based routing, multiple invocation models, distributed security handling and value added features

y

Application Layer API for exposing existing applications as services, support for multiple types of endpoints, protocols, data translation, value added features

Data Services Layer Standards based distributed data access definition, Meta data management, standards based interfaces for data query, value added features

Figure 1: SOA Based Integration Platform for Supply Chain Integration

Source: Infosys Research

only differentiator being, if an application

__ these systems might exist across multiple

interface on itself qualifies to be exposed as

domains and accept data in different formats.

reusable component rather than just a part of

ESB (Enterprise Service Bus) can be used to

flow towards creation of reusable service, then

handle such scenarios with minimal effort [9].

it is better to expose the application interface as

Finally an integration layer acts as a gateway for

service.

external services and provides / receives data from external service in their supported formats

Integration level services: Services at integration

over required transports.

layer create coarser grained business functions from services at data access layer, application

Process level services: These services are

layer and native application API. Integration

coarse grained and are similar to integration

layer is used for transport bridging, content based

layer services. They can be implemented at

routing, translation, provisioning of distributed

integration layer or using workflow language

security [8], supporting different invocation

based orchestration layer. These services usually

and communication model. For example, an

represent

engineering change might be required to be

interface that internally drive a number of steps

propagated to planning and inventory systems

in a process. For instance, submission of demand

5

business

document

interchange


order function can be exposed as process interface

individual services. Hence it is important to

where a submitted demand is processed by a

manage non functional requirements such

set of services at integration, application and

as business activity monitoring, distributed

data access layer using production planning,

security, service look up etc.

scheduling, manufacturing, purchasing and finance functions.

A BUSINESS USE CASE FOR SOA BASED COLLABORATION IN SCM

Meta data repository: In enterprises, IT systems

Let us consider a business scenario that involves

often

introduction of a new vehicle for a particular

represent

differently

a

based

single on

business

different

entity

ontological

segment of buyers viz., young professionals,

classifications. For instance, a unique part

elderly, householders etc. The process typically

identifier might be referred to as partid in one

starts with a market survey across multiple

system and partno in another system. In SOA

geographies carried out by the OEM along with

Maintenance of service ontology in a metadata repository can help negotiate confusion related to multiple naming of a single entity

where a process is created from a number of

other stakeholders like dealers, advertisement

services, managing disparities of data format

agencies, etc. The outcome is refined into broad

pose a major challenge. This issue can be

level features and pricing. The concept is then

addressed by maintaining service ontology

communicated to styling for creation of 3D, 2D

and

semantic

repository.

relations

These

in

ontology

a

metadata

and

semantic

and clay model. Once there is mutual agreement on the looks and features by stakeholders __

relations can be used at multiple levels of

like engineering, marketing, purchase, senior

SOA. For example,

service bus can use the

management , the concept is said to be finalized.

semantic

from

relations

provisioning

of

A new vehicle is either designed from scratch

translation or shared data services platform

or created by reusing existing platform and

can use these semantic relations for part

components with some modifications. The

lookup where a part identifier field is known by

design and engineering process necessitates

different names in different systems.

availability of systems that allow creation

SOA is loosely coupled and highly

and sharing of documents, CAD integration,

distributed architectural paradigm. In SOA a

versioning of product design information, work

process might span across multiple user domains

flow management, role-based access and API for

and finally success of a process depends on

sharing/ accessing data with other applications.

6


Java/xml/ web service

Europe Manufacturer Design Systems

Asia Manufacturer Design Systems Flat file over FTP Asia Manufacturer prototyping system

XML format 1/ over JMS Service bus at integration layer

Java/xml/ web service Service bus at integration layer

Flat file over JMS

Asia Manufacturer manufacturing system

Asia Manufacturer purchase system

STEP

XML format 2/ over FTP Data services xml over http

xml over http

Preferred Supplier design systems

Supplier purchase systems

Asia Manufacturer planning system

Service ontology, relations and translations

Figure 2: Typical Integration Scenario in Supply Chain Collaboration

Source: Infosys Research

Sharing information with other systems is one

purchase, finance as well as preferred suppliers

of the key requirements for design and

design systems.

engineering systems For example, an OEM

The various entities involved in this

decides to introduce a variant of an existing

scenario are shown Figure 2 which depicts a

platform of one of its subsidiaries in Europe

typical integration challenge in supply chain

to

another

subsidiary

in

Asia

after

collaboration and the way it can be addressed

incorporating some customizations. In such

using an SOA based integration platform. In most

a scenario the Asian subsidiary of the OEM

scenarios, the design systems of a manufacturer

will need access to design systems of the

in different geographies will be different. In

European subsidiary. In addition the design

the stated scenario data needs to be moved from

systems of the Asian subsidiary will also need

design system in Europe to a design system

to share information with production planning,

in Asia.

7


Design system in Europe provides

lookup for a particular part in the European

application interfaces for data extraction as

OEM’s design systems. However, due to

XML. However, data needs to be provisioned as

different naming conventions it might be

a flat file over FTP to the design system in Asia.

difficult to locate the exact required part. In

In order to transfer data between concerned

such scenarios, shared data services platform

applications, individual pieces of code can

can use semantic definitions in metadata

be written that invoke API in Europe design

repository

system that obtains data as XML, formats it

that follow different naming conventions.

to a flat file and saves it in a required location

to

perform

lookup

for

The design system at Asian OEM

in Asia subsidiary’s system. Such point to

needs to share data with other systems like

point connection based approach will require

manufacturing systems, prototyping systems

application to invoke the native API (e.g.,

and purchasing systems, all of which require

JAVA). However, any other application that

different data formats over multiple protocols.

desires to get the same data will need to replicate

Also there is a need to share design data

the same function.

with preferred supplier design system using

The solution lies in exposing native

STEP (ISO 10303) for PLM (Standard for the

API as services (e.g., web services using

Exchange of Product Model Data) [10].

SOAP over HTTP) that adhere to enterprise

A service bus can be used for

level data formats. Once created, these services

achieving the desired integration and for

can be used by any other applications. In the

provisioning

absence of required API, data services can be

exchanging data with preferred suppliers’

directly generated from the concerned data

systems located across different domains.

sources.

The planning system at Asian OEM requires Data

services

are

parts

generated

by

data

from

of

federated

one

or

security

more

manufacturing

these

manufacturing

definition of standards-based query in a

systems.

centralized data services platform and exposed

systems do not provide any API for retrieval

either using standards based interfaces like

of such data. Traditional means of achieving

web services or some API. The retrieved data is translated to the required flat file format __

the result would be by writing custom JDBC or

where the source and destination ontology

case of SAP). However, the resulting point to

and required translations are drawn from a metadata repository __ and transmitted to

point connections are hard to maintain and are

However,

while

application API centric code (for e.g., ABAP in

replicated for every new application. The solution lies in definition of

a physical location using enterprise service bus (service at integration layer). This approach

distributed queries in standards-based manner

allows standards-based definition of service

in SDS platform and exposing these queries as

interface that exchanges data in mutually

services to be re-used. SDS platform takes care of

understood format and introduces a mediation

distributed connection management, transaction

layer that handles translation, routing and

management, caching and tool based generation

transport bridging (HTTP to FTP, in this case).

of service interfaces.

In

certain

scenarios

there

might

Finally the submission of purchase order from Asian manufacturers’ purchase

be a need for designers at Asian subsidiary to

8


system to suppliers’ purchase system can be

5.

I2 Operational data store. I2 technologies

seen as process level service that internally

LTD. http://www.i2.com/assets/pdf

drives manufacturing process at suppliers end

/PDS_ods_v61_pds7262_091304.pdf.

and provides asynchronous callback handlers

6.

John Leslie King and Kalle Lyytinen,

to service consumers for checking status of

Automotive Informatics: Information

purchase order.

Technology

and

Enterprise

Transformation in the Automobile CONCLUSION

Industry. http://www.si.umich.edu/

Collaboration in auto supply chain involves

~jlking/Auto-MIT-Final.pdf.

participation of multiple stakeholders across

7.

V

Niranjan

et.al.,

Shared

Data

the supply chain towards sharing information

Services: An Architectural Approach.

at different levels of supply chain management

http://portal.acm.org/citation.

activities. Traditional means of point to point

cfm?id=1090954.1092078.

application integration falls short of achieving

8.

Bijoy

Majumdar

et.al.,

Security

for agile business processes. SOA provides a

techtarget.com/tip/0,289483,sid92_

new approach to address integration needs

gci1168738,00.html.

in auto supply chain management towards

9.

enabling collaboration. An

Modelv2.0.

SOA

the objective of collaboration and is not suited

http:/whatis.

Enterprise service bus, http://www3 0 6 . i b m . c o m /s o f t w a r e /i n f o 1/

SOA based integration platform

websphere/index.jsp?tab=landings/

allows standards based integration of multiple

esbbenefits.

types of interfaces that communicate using

10.

different data formats over different protocols.

(ISO

10303).

http://www.

steptools.com/library/standard/.

Hence such a platform is ideally suited to handle fluid integration requirements in

STEP

11. a

The American Automotive Industry Supply Chain- In the Throes of a

collaborative supply chain.

Rattling Revolution. http://www.ita. doc.gov/td/auto/domestic/

REFERENCES 1.

SupplyChain.pdf.

Laurie Sullivan, Auto-Parts Makers

12.

Week,

Leadership.

Available

at

http://www. 13.

Systems

Supply

Chain

http://www.ht2.org/

Ricardo UL Ltd, Skills4Auto Ltd. Vision

Ford T Model. http://en.wikipedia.

of UK Automotive industry in 2020.

org/wiki/Ford_Model_T.

www.ricardo.com/media/

Peter Wad, Workers in the Supply Chain

medialibrary/Vision_for_the_UK_

of the Global Automobile Industry.

Automotive_Industry_in_2020.pdf.

http://www.amrc.org.hk/5404.htm. 4.

Modularity, and

conference/pdf/SYM1.pdf.

041904.pdf.

3.

Araujo,

Integration

agile.com/news/2004/infoweek_ 2.

Luis

Open Their Networks, Information

14.

Where is the auto industry headed?

Kanban, University of Cambridge.

http://www.deloitte.com/dtt/article/

http://www.ifm.eng.cam.ac.uk/

0,1002,cid%253D120316,00.html.

dstools/process/kanban.html.

15.

9

Andrew Cummins, Supply Chain vs.


Supply Chain - automotive industry

www.findarticles.com/p/articles/

distribution - Brief Article. http://

mi_m3012/is_6_181/ai_76855607.

10


Author profile KRISHNENDU KUNTI Krishnendu Kunti is a Senior Technical Specialist with the Web Services CoE, SETLabs, Infosys. He can be reached at krishnendu_kunti@infosys.com. TERANCE DIAS Terance Dias is a technical specialist with the Web Services/SOA Center of Excellence in SETLabs, Infosys Technologies Limited. He can be reached at terance_dias@infosys.com. ASHWINI KUMAR JEKSANI Ashwini Kumar Jeksani is a Software Engineer with the Web Services/SOA Center of Excellence in SETLabs, Infosys Technologies Limited. He can be reached at Ashwini_Jeksani@infosys.com.

For information on obtaining additional copies, reprinting or translating articles, and all other correspondence, please contact: Telephone : 91-20-39167531 Email: SetlabsBriefings@infosys.com

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

Integration soa based integration  

SOA based integration for creation of collaborative supply chain in Automotive domain

Read more
Read more
Similar to
Popular now
Just for you