Enabling « Easy to do business with » through solutio n architecture

5 November 2014

Dimitri De Wolf - Application Architect

Contents

1. B2B at Doosan and Bobcat2. How architecture helps “Easy to do business with”

B2B AT DOOSAN AND BOBCAT

Company profile

Doosan Infracore

Construction

Equipment

• Construction Equipment manufacturer

• Global presence

• Korean parent company

• North Dakota roots (Bobcat)

Brands and Products • Bobcat – Compact Equipment and Attachments

• Doosan – Heavy Equipment

• Doosan Portable Power – Compressors and

Generators

• Geith – Buckets

• Montabert – Hydraulic Breakers

Anatomy of the dealer channel

Customers o Small community of recurring customers

o High average order value

o High number of transactions per customer

Products o Machines and Attachments

o Configurable

o Serialized

o Parts

o Same day shipping

o All the rest

o Warranty plans

o Software

o Services

o Training

o Manuals

o And more …

Systems o ERP is the “Order” and “Customer” master

Manufacturer

Dealer

End-User

Wholesale

Retail

Commerce is just a

fraction of our

interactions with

dealers

Key challenges

• Almost all transactions have a strong on-line component today– Volume of email / phone / fax orders is marginal

• Many disconnected solutions supported by multiple IT systems• Need to serve multiple brands and geographies

Generate leadsConfigure and quote

Order machine and

attachments

Order parts

Return parts

Research products

Service equipment

Arrival condition

report

Delivery report

Manage field

inventory

Financing

HOW ARCHITECTURE HELPS “EASY TO DO BUSINESS WITH”

Build a service layer

Mirror the ERP data model• Simplify mappings and support

• Reduce the cost of changes and enhancements

Put a service between the data and the channel• Drive technical and functional consistency

• Improve agility

• Examples:

• ProductService#isTransactable

• OrderService#getOrderLineStatus

Back-office

systemsChannel

Service

LayerData Business concepts

ecommerce application

The right answer

depends on the

customer and changes

over time

It’s easier to

change the logic

than adjust the

data

Example - Mapping the Channel to the ERP

Most ERP concepts are too complex for easy consumption- Channel policies don’t map directly to a single ERP attribute

- Rules and policies change over time

Enforce consistent process patterns, allow variatio n within each step

• Enforce a single process pattern• Integrations

• Data model

• System roles and responsibilities

• Allow easy customization/configuration of process rules and decisions

Step 1 Step 2 Step 3 Step 4

Promote smaller packaging

alternatives for national

accounts

Disable promotions for national

accounts and use ad-hoc price

lists

Offer Next Day Air for domestic

customers

Allow returns up to 30 days after

order

Automatically substitute

materials in product range A

(but not B)

Display retail and wholesale

pricing for domestic customers

Offer Ocean shipping for export

customers

Allow returns up to 90 days after

order

Disable core charges for export

and internal customers

Disallow freight forwarders for

domestic customers and

national accounts

Parts Ordering funnel

Build a strong integration layer

Having middleware is not enough

Create an eco-system to make integrations “easy”• Detailed specifications

• Schemas allowing automated validation of contracts

• Attention to non-functional requirements

• Support mocking

• Use a framework providing access to the full range of integration patterns

Unexpected data will disrupt your processes• Explicitly define what data is ‘right’

• Pay attention to exception handling processes

• Support “data” fixes to keep the processes running

• Reduce the scope of transactions to the smallest meaningful business object

Example: Robustness often matters more than correct ness

Real life example – Shipment method

ecommerce value ERP value

AIR_UPS_2AM AIR UPS 2AM

The unexpected will always happen• During the project

• During operations

• 98% correct is 100 % failed• Errors tend to hide other errors

• Simple errors can block multi-day test scenarios (project) or disrupt a business process

(operations)

• “Quick and dirty” fixes are essential to drive velocity

Use Agile techniques (even if you are a Waterfall s hop)

Organization and / or program may mandate waterfall, but Agile techniques help

reduce risks

Examples

• Daily coordination calls with the core team

• The most important call of the day

• Proper conferencing tools are a must (good audio, screen sharing)

• Reduce email traffic and mis-communication, drive ownership

• Fanatic logging of issues and change requests

• Issue which are not logged do not exist

• Issue quality is key

• Product Owner / Architecture Owner is key

• Needs to be an efficient duo

• Empowered and willing to make decisions

• Strive for reliable delivery before you increase the team size

• On time

• First time right

Documentation methodology matters

Strive for “Clear, concise and complete”

• Prefer dynamic Wiki-style documentation over static Word documents

• Wireframes vs User Stories

• Invest time and effort in good wireframes

• Use use cases for non-standard interactions only, leverage the service

layer concepts to keep them short

• Less is More

• Write as little documentation as possible

• Use visuals, use tables, use lists

• Let the development team figure out the technical implementation

details

DISCUSSION AND QUESTIONS