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.