TOYOTA MOTOR EUROPE

How "Toyota Way" principles guide Toyota's REST APIsCase study: Product Datahub

Philip RademakersSenior Manager, Enterprise Architecture

Information TechnologyToyota Motor Europe

TOYOTA MOTOR EUROPE

• European headquarter in Brussels (Toyota Motor Europe - TME)

• Began selling cars in 1963

• Over €8 billion invested since 1990

• €20 billion turnover in 2014

• More than €4.3 billion spent with European-based suppliers per year

• 888,015 vehicles sold in CY 2014

• Close to 1.000.000 hybrid vehicles sold in Europe to date

• 4.8 % market share in CY 2014

• Employees 20,000 (direct; including TPCA, 50/50 joint venture Toyota/PSA Peugeot Citroën)

Toyota in Europe

2

TOYOTA MOTOR EUROPE

Toyota’s European Facilities

• Head office in Brussels (Belgium)

• R&D technical centre in Zaventem (Belgium)

• Toyota motorsport in Cologne (Germany)

• Toyota ED2 – European Design/Development in Nice (France)

• European manufacturing

• 6 vehicle plants (Avensis & Auris, Yaris, Camry, Aygo, Corolla & Verso, Dyna)

• 3 engine / transmission plants

• 30 National marketing and Sales companies (NMSC) (56 countries)

• 2749 Toyota dealers, 274 Lexus dealers

• 14 Parts logistics centres, 9 Vehicle logistics centres

3

TOYOTA MOTOR EUROPE

TME Information Technology (IT) division (pan-European)• 260+ employees

• Responsible for:

• (Application) Development

• Infrastructure

• Networking, (mobile) communication

• User support

• Functional areas within IT:

• Business facing: R&D/Purchasing Systems, Manufacturing Systems, Sales Systems, Corporate Systems

• IT support functions: Systems engineering, Pan-European IT management

• 5 different countries (7 different locations):

• Belgium, Germany, Poland, United Kingdom, Turkey

4

TOYOTA MOTOR EUROPE

Enterprise Architecture department within Toyota’s IT

5

Support project’s application architecture

Application integration

Development & tools support

Define IT standards and technology roadmaps

Establish reference architectures

Master data management

R&D

Applications

Manufacturing

ApplicationsSales

ApplicationsCorporate

Applications

Infra &

Data centre

TOYOTA MOTOR EUROPE

Architectural principles

6

Toyota Way principles (applied in IT)

Just in time

Solutions support

small PDCA

cycles

Architecture

starts small and

supports only

what is needed

Jidoka

Each process

passes on quality

results

Software has

check & stop

capability

Architecture principles

Eliminate Waste

Avoid duplication

of data, platforms

standards

Solutions are

resilient without

redundancy

Built-in quality

IT solutions have

built-in quality

with clear

ownership (JKK)

Components

have low degree

of dependency

Standardization

Use standards

where possible

Solutions employ

open and

extensible

standards

Kaizen

IT solutions are

flexible to kaizen

Components can

grow / evolve

independently

• Allow us to assess that we’re “doing the right thing” (before “doing things right”)

• Embody company’s culture in IT architecture processes

TOYOTA MOTOR EUROPE

The problem of “Application Integration”

7

TOYOTA MOTOR EUROPE

Application integration: Shared database (1990’s style)

8

Product Order

Car

ConfigCustomer

TOYOTA MOTOR EUROPE

Application integration: Shared database

9

• Advantages

• Simple, consistent view on data across applications

• Disadvantages

• Very tight “coupling” between applications

• Creates dependencies on physical data models (which tend to change over time)

• Violates an important Toyota way principle

• Any improvement to an application’s data structure immediately impacts other apps (continuous improvement in one application can be destructive for others)

Kaizen

Continuous improvement

TOYOTA MOTOR EUROPE

Application integration: Enterprise Service Bus (2000’s style)

Product Order

Car

ConfigCustomer

Enterprise Service Bus

10

TOYOTA MOTOR EUROPE

Application integration: Enterprise Service Bus• Advantages

• Decouple service from physical data/process implementation

• Support various adaptors, protocols, messaging styles

• Disadvantages

• Usually requires (expensive) “middleware” to deploy services supported by middleware team

• Violates an important Toyota quality concept

• Often service bus gets cluttered with (hidden) business logic (lack of ownership)

• Middleware team is not involved in application use cases (lack of ownership)

• Middleware team can’t grasp impact in case of failure (decreases quality)

11

Built-in quality with Ownership

(JKK: Jikotei Kanketsu)

Team responsible for an IT service:

- “knows” the service (ownership)

- can see (visually) problems with the service

- can analyse and fix problems with the service

TOYOTA MOTOR EUROPE

Application integration via REST

Product Order

Car

ConfigCustomer

REST API REST API

REST API REST API

HTTP

- GET

- PUT

- POST

- DELETE

URLURL

URL URL

12

TOYOTA MOTOR EUROPE

What is REST?• Representation State Transfer (REST) is an architectural style

centered on resources (vehicle, customer, order) and representations of those resources

• Typically implemented over HTTP (but does not have to) and relies on a stateless, client-server interaction

• REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (e.g. SOAP)

• REST is language independent, platform independent

• REST allows for cacheable responses (to improve performance)

• The client of a REST API sees a representation of a resource, not the actual resource itself, state is only transferred between client/server via resource representation

• Resources are accessible through a URL; CRUD operations (create, read, update, delete) are performed using HTTP verbs (POST, GET, PUT, DELETE)

13

TOYOTA MOTOR EUROPE

Simple REST example

14

Resource URL: https://customer.toyota-europe.com/customer/1234

GET /customer/1234

Accept: application/json

GET /customer/1234

Accept: application/xml

/customer/1234

/customer/5432Resources

Server{ “Name” : “Mike Orzen”,

“ID”: 1234 }

<customer>

<name>Mike Orzen</name>

<ID>1234</ID>

<model>Avensis</model>

</customer>

Client

Client

Representation

/customer/5432

TOYOTA MOTOR EUROPE

Why use REST for application integration?

• Simple and general

• Scalable (loose client/server coupling due to “stateless”-ness)

• Independent (few dependencies on other technologies)

• Latency (caching)

• Security (on top of HTTPS, coupled with – separate – authentication)

• Encapsulation (only show things that one needs to show)

• No heavyweight tool chain required (standard web server)

• Relatively easy to test (simple HTTP requests)

• No “intermediary” message handling components (plain HTTP)

• Does not require extra middleware (no ESB)

15

TOYOTA MOTOR EUROPE

Case study: Toyota’s product data

16

Vehicle

Access

ory

Vehicle

pricing

Part

pricing

France

Italy

United Kingdom

1Many point-to-point integrations

(muda: over-production)

2Different integration interfaces

(muda: unnecessary motion)

3Not fully consistent

data model (quality)

SOAP

XFB

4Some data is duplicated across

systems (muda: inventory;

inconsistencies)

5“Master” data scattered

with “operational” data

Poor value proposition resulting

from silo-based (legacy)

systems

TOYOTA MOTOR EUROPE

So how did we resolve those problems? Overall steps:

17

4S

business

data

Single

consistent

data model

and

semantics

Introduce

“Product”

master

data

domain

with clear

business / IT

ownership

Decouple

application

integration

from

(legacy)

source

systems

with REST

+ + +

Eliminate waste,

improve quality

Standardize Customer first,

Just in time

Kaizen

legacy

condition

4S: Sort, Straighten, Sweep, Standardize

*

TOYOTA MOTOR EUROPE

Product data architecture

18

Vehicle

Access

ory

Vehicle

pricing

Part

pricing

France

Italy

United Kingdom

1Central product

data hub

Product

data hub

3Single quality data

model, central logic

to guarantee

data consistency

5Clients access

data only through

API

4Resource

based

REST API

R

E

S

T

2 4S source data

6 Atom change

feed

TOYOTA MOTOR EUROPE

Details on the data model (simplified)

19

Vehicle

familyVariation Suffix Accessory

Color

{ Avensis,

Auris,

Yaris,

... }

{ Sedan - 3 door – petrol,

Wagon – 5 door – diesel,

...}

{ Sunroof,

SatNav,

Roof rack,

... }

{ White metallic,

Black,

Green,

... }

TOYOTA MOTOR EUROPE

Detail on the REST APIGET /family

{ “family” : [ { “name” : “Avensis”,

“code” : “123”,

“links” : [ { “rel” : “self”,

“href” : “/family/avensis” } ] },

{ “name” : “Auris”,

“code” : “234”,

“links” : [ { “rel” : “self”,

“href” : “/family/auris” } ],

“link” : { “rel” : “self”, “href” : “/family” },

}

GET /variation

{ “auris” : [ { “name” : “variation1”,

“body” : “3door”,

“engine” : “petrol”,

“links” : [ { “rel” : “self”,

“href” : “/family/auris/var1” },

{ “rel” : “parent”,

“href” : “/family/auris” }

20

1

2

5

3

1. JSON as default representation (XML also possible)

2. Resources follow entities from the data model as collections and individuals

3. Collections contain “most important” detail of children

4. “Links” are provided to obtain detail on child resources

5. Individual entities provide back links to their parent collection (navigation)

4

TOYOTA MOTOR EUROPE

Principle 1: Jidoka (software has check & stop capability)

21

Error

Code

Condition Error Message

401 When authentication fails Error message produced by the TAAS Service

403 When authorization fails Error message produced by the TAAS Service

503 Service Unavailable due to

database down or other reasons.

Service Unavailable

500 Any internal service logic error Internal Error

400 URL Parameters not correct or

invalid URL requested

No specific Error Message

404 When the resource could not be

found

No specific error message will need to be passed.

410 When the resource is already

deleted in Datahub

No Specific Error Message

• All API calls

• utilize standard HTTP response codes (e.g. 200=OK, 201=resource created)

• must implement a standardized set of error codes

• may implement API specific error codes

• Any internal error in an API call gets automatically logged

TOYOTA MOTOR EUROPE

Principle 2: Just in time (architecture starts small, supports only what is needed)

• API focuses on what current set of clients need

• Additional “requirements” can be developed (later) through

• additional API calls (evolution)

• additional representations (e.g. XML over JSON)

• descriptive links (indicating what can be done “next”)

• API calls provide “most common” info with links to obtain more “detail” (if client wishes)

22

GET /variation

{ “auris” : [ { “name” : “touringsport”,

“body” : “3door”,

“engine” : “petrol”,

“links” : [ { “rel” : “self”,

“href” : “/family/auris/variation1” },

{ “rel” : “parent”,

“href” : “/family/auris” }

TOYOTA MOTOR EUROPE

Principle 3: Eliminate waste (solutions are resilient without redundancy)

• API itself only requires an HTTP server as infra + a network

• No other intermediary middleware between client/server

• Compute “load” can be controlled through server scaling

• Data “availability” can be controlled in back-end(e.g. “always-on” configuration; redundancy)

• These “choices” are independent of the API

23

R

E

S

T

R

E

S

T

R

E

S

T

R

E

S

T

R

E

S

T

Product

data hub

Product

data hub

TOYOTA MOTOR EUROPE

Principle 4: Built-in quality (components have low degree of dependency)

• Functional monitoring

24

• Utilization logging(Problem visualization)

(Jidoka)

(Problem solving) (Ownership)

TOYOTA MOTOR EUROPE

Principle 5: Standardization (solutions employ open standards)

• REST is not a “formal” or open internet standard butwidely used (e.g. Google, Twitter, Amazon, ...)

• HTTP, JSON are standards and allow to leveragecaching, security and a simple data format

• Promote REST as primary standard for inter-application communication and data exchange

• Promote REST as primary standard for interaction between client (GUI) andserver

25

REST

Product Customer Dealer Part

http http http

TOYOTA MOTOR EUROPE

Principle 6: Kaizen (components can grow / evolve independently)

26

• Easy to scale (stateless) horizontally (new APIs)

• API can also “grow” without affecting existing clientsfor example through versioning or by enhancing multiplerepresentations

• Backend systems can evolve independently without affectingexisting clients (REST API serves as a “contract”)

• API is evolving into V2 (incremental version)

• Design to run in the cloud

• Data aggregated to JSONdocuments stored in Mongo DB

Aggregated

Data

TOYOTA MOTOR EUROPE

Is REST the holy grail for application integration?

For some use cases it is not a good match:

• “Streaming” based data (e.g. video, social data)

• Push style notifications (e.g. as in mobile, server-initiated communications)

• Bulk offline data transfers (e.g. use an ETL tool)

• Asynchronous data (e.g. event interactions)

• Big data (e.g. better use event streams)

But REST:

• Fits well with our Toyota way architectural principles for inter-application integration

27

TOYOTA MOTOR EUROPE

Future work

• Reengineer source applications to directly interface with master data domain (eliminate duplication)

• Yokoten (best practise sharing) concept to manufacturing applications/area

• Implement “data as-a-service” in other domains (customer, dealer, parts)

• API “management”(documentation, discovery, usage, lifecycle, reporting, governance)

• Partner and Open APIs (allow 3rd parties to interface with Toyota’s data)

28

TOYOTA MOTOR EUROPE

Q&A

Thank you !

29

Philip Rademakers, Senior Manager, Enterprise Architecture, IT division, Toyota Motor Europe