Sandvik Systems Development From bottom up integration towards an information based enterprise...

Sandvik Systems Development

From bottom up integration towards an information based

enterprise architectureSSD/CAT - Jan NilssonSSD/CAT - Pontus Gagge


Agenda

Sandvik background

Integration history

Total Business Integration

Future focus

Lessons learned


Sales 2006: SEK 72 billion (USD 10 bn)

42,000 employees in 130 countries

Products with high R&D and added value

Global leader in selected areas


“Extract from a letter of 2 March 1869 from the Sandvik agent in France to A H Göransson inS:t Petersburg, on Sandvik’s first sales tripto Russia.”

Sandvik’s business philosophy since 1868

Direct contact withcustomersProduct development

together with customers

Own marketingchannels

Innovation and ResearchNiche products

High value added


Sandvik – Global leader

Sandvik ToolingSandvik

Mining and ConstructionSandvik

Materials Technology

Three business areas

Invoiced sales, SEK M

Employees

22,500 25,000 19,300

15,100 12,200 8,600


Close to +50 companies in 20 countries

SEK +22 bn in sales

+15,000 employees

Acquisitions 1996-2006


Historical view of IT at Sandvik


Problems for legacy systems

Internally developed ERP system (SOPIC v1 early 70’s, current ver. late 80’s->)

4GL language for rapid application development (Synon) Little layering, monolithic application

Focus on internal use of information & ”services” Info & Services an IT issue One consumer (internal GUI) No ownerhip other than application No common processes (process need)

Integrating applications considered an IT problem Solved on domain level Not from the Stakeholders perspective Data constraints (fixed record format) Monitoring of programs and procedures


Problems for integration

Brokers tend to ”pop-up” everywhere Almost all supplier deliver a broker

Without a strategy, back to point->point (higher cost)

Service creation No common nomenclature

Project scope for services

Less re-use

Monitoring Less knowledge about failure on the outside

Alerts escalated only to IT

Almost no proactivity


Integration history: breaking the silos

Process level (A2A) Protocol: legacy text files, database

sharing(!), some scattered XML

Functions: e.g. work orders, distribution, invoicing, PLM, …

Business to business level Protocol: mostly EDI, some WS

Functions: customer & supplier orders, invoicing, …

Presentation level Protocol: mostly XML, some web

services

Functions: request-reply complements to legacy systems (modern user interfaces!)

Analytical Ad hoc, locally determined

Bu

siness to

Bu

siness

Process Level

Presentation Level

Analytical (BI/DW)Analytical (BI/DW)


From flat file integration

to schema and XML representation

From “point to point”

PDA

FirewallExternal

Application

AS/400

OS/390

BizTalk

OutboundInbound

SAP R/3

FileMSMQ

HttpSMTP

FileMSMQ

Http

MQ Series

Web Services

SAP R/3 Idoc

Firewall

MQ Series

Web Services

SAP R/3 BAPI

SAP R/3 Idoc

ExternalWeb Service

InternalWeb Service

OS/390

AS/400

SAP R/3

NT/2003NT/2003

Mapping & Routing

Synchronous Q&A

Standard func. Standard func.

Adapters AIC

SQL ServerDB/2

DominoOTMAOracle

In the pipe...

to a broker scenario

IntegrationHistory->Today


IntegrationProblems

All ERP- and Product-supplier deliver a broker a broker requires..

CompetenceResources (human/machines)

LicensesAdaptors£ MQ£ FTP£ HTTP£ SAP

Requires Strategy

Otherwise…….


IntegrationFuture?

Mainframe

AS/400-Sopicor equal

Back to point to point integration?


Consumer shift


Current infrastructure(rough picture)

FromFromoneone

ConsumerConsumer//

suppliersupplier

ToToanyany

consumerconsumer


TBI Integration broker: BizTalk

Basic broker functions: Transport protocols Message formats Message transformation Message routing Operational supervision

Also Orchestration Business Activity

Monitoring I&AM Credentials vault … Kitchen sink?

- Version migration: adaptor upgrades…

- Expensive licenses

- Centrally placed servers

PDA

FirewallExternal

Application

AS/400

OS/390

BizTalk

OutboundInbound

SAP R/3

FileMSMQ

HttpSMTP

FileMSMQ

Http

MQ Series

Web Services

SAP R/3 Idoc

Firewall

MQ Series

Web Services

SAP R/3 BAPI

SAP R/3 Idoc

ExternalWeb Service

InternalWeb Service

OS/390

AS/400

SAP R/3

NT/2003NT/2003

Mapping & Routing

Synchronous Q&A

Standard func. Standard func.

Adapters AIC

SQL ServerDB/2

DominoOTMAOracle

In the pipe...


What is iBridge?

z/OS

WindowsServer

iSeries

SQL Server

Domino Server

Operators

iBridgeControl Center

Microsoft Operations Manager


iBridge key properties

Lightweight A2A integration broker (small footprint, low cost)

Wholly distributed to individual servers

Standardized plugin interfaces, in- and outbound, any transport protocols and endpoints

Servers operate independently of each other

Filter-based supervision to central repository

Central configuration and supervision console

Complement to heavy-weight central brokers, not a replacement

MQBAPISOAP


When should iBridge be used?

We always consider using iBridge whenever a need for platform or system integration arises

First call when integrations only need to deal with transport protocols and individual messages (no complex transformations or orchestrations)

We improve Operations’ ability to monitor and handle alerts with fewer solution variations

Business areas gain from shorter project time, reuse of existing infrastructure, central monitoring and logging


BackEnd System

Any Consumer

MappingSystem model

Messagebuilder

Business objects

Business

Façade

jIntegrator concept overview


Solution J-Integrator

Integration framework A generic adapter to receive/send

messages Support webservices and Xml-messaging

with MQ or http. Configuration and generation

Implementation framework Create java operations towards your

system Developers can more easily translate

business process to java implementation

Runs on all platforms/systems Very high degree of reuse between

platforms Possible to reuse existing business logic Based on open source standard

componentsF

açad

eF

açad

eF

açad

e


TBI current state: service facades


Some TBI results

Stock status defined for use in web solution,

reused in mobility demo

– suddenly we got the schema/integration message across!

Active pursuit of legacy modernization prolong lifetime of legacy

investments

simplify new integrations

– with CIO sponsorship as strategic issue

Brand name recognition: everybody wants TBI


Efforts for the future

MonitoringOwnership


• <Owner>• <Business model>• <Static/common data>• <Methods>• <Schemas (contract)>• <Glossary>• <Discovery/display>• <….>

Business Process Model

DELIVERYDELIVERYCRM SALES

MARKETING

SUPPLYSUPPLYFORECASTFORECAST

Product on market

Customervalue

Customerdemand

Market

Marketdemand

R&D

Purchase Tender Sales Invoice ShippingPacking

OMT Process Order to delivery

Meta- and Master-data


History = > Today


Process Monitoring

App 2App 2 BiztalkBiztalk

Mainframe QMPMainframe QMP Mainframe QMPMainframe QMPMainframe QMPMainframe QMP

MQ MQ

App 1App 1

Monitoring

Process Process OwnerOwner

SITSITSSDSSD


Process Monitoring

SatinSatin BiztalkBiztalk

MainframeMainframe MainframeMainframeMainframeMainframe

MQ MQ

TeklaTekla

Monitoring Control Center

Benefits Information to stakeholders

Complete overview of the whole flow

Fulfilment according to the SLA

Proactive & Productive improvements

Reducing maintenance costs

Reduce key person dependencies

Measure the process


Master data initiatives

Product master (one BA specific)

Customer/supplier master (all Sandvik)

User/identity (all Sandvik)

Organization (primarily meta data)

ERP

CRM

PIMFinance

Customer

Customer

ContactAccount

Customer

Lead

Prep

MLR

Product

Recipe

Product

Stock

Product

AD

Notes

MF

HR

Employee

User

Mail

User

RACF

OrganizationCompany

Department

Cost centre

Unit


Information architecture(information centric)

From Technical Platform to Information flow

Consumer to subscribe for data

Data supplier to publish changes Infrastructure to know who to inform/update

Ability to switch from integration points to information infrastructure Integration in full control

Integration by configuration (no coding)

Information architecture to be of high importance Data Modelling

Service creation

Standardized schemas

Ownership

Publish & Subscribe

Librarian


Lessons learned

Without business EA commitment, do just enough bottom up, one step at a time

What is in a name? A lot – internal marketing of TBI

Define facades to delay legacy replacement and ease M&A’s

Awareness grows gradually the need for architecture

the key role of information

Sandvik Systems Development From bottom up integration towards an information based enterprise...

Documents

Transcript of Sandvik Systems Development From bottom up integration towards an information based enterprise...