No Slide Title
Download
Report
Transcript No Slide Title
From bottom up integration
towards an information based
enterprise architecture
SSD/CAT - Jan Nilsson
SSD/CAT - Pontus Gagge
Sandvik Systems Development
Agenda
Sandvik background
Integration history
Total Business Integration
Future focus
Lessons learned
Sandvik Systems Development
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
Sandvik Systems Development
Sandvik’s business philosophy
since 1868
Innovation and Research
Niche products
High value added
Direct contact with
customers
“Extract from a letter of 2 March 1869 from the
Sandvik agent in France to A H Göransson in
S:t Petersburg, on Sandvik’s first sales trip
to Russia.”
Sandvik Systems Development
Product development
together with customers
Own marketing
channels
Sandvik – Global leader
Three business areas
Sandvik Tooling
Sandvik
Mining and Construction
Sandvik
Materials Technology
Invoiced
sales, SEK M
22,500
25,000
19,300
Employees
15,100
12,200
8,600
Sandvik Systems Development
Acquisitions 1996-2006
Close to +50 companies in 20 countries
SEK +22 bn in sales
+15,000 employees
Sandvik Systems Development
Historical view of IT at Sandvik
Sandvik Systems Development
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
Sandvik Systems Development
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
Sandvik Systems Development
Integration history: breaking the silos
Process level (A2A)
Protocol: legacy text files, database
sharing(!), some scattered XML
Business to business level
Presentation Level
Process 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
Sandvik Systems Development
Analytical (BI/DW)
Business to Business
Functions: e.g. work orders,
distribution, invoicing, PLM, …
Integration
History->Today
From “point to point”
From flat file integration
to schema and XML representation
to a broker scenario
BizTalk
Inbound
Outbound
Standard func.
Standard func.
File
MSMQ
Http
OS/390
File
MSMQ
Http
SMTP
Mapping & Routing
Adapters
OS/390
AIC
MQ Series
AS/400
AS/400
MQ Series
SAP R/3 Idoc
NT/2003
SAP R/3 Idoc
NT/2003
SAP R/3 BAPI
Synchronous Q&A
Web Services
Web Services
SAP R/3
SQL Server
DB/2
Domino
OTMA
Oracle
PDA
External Firewall
Application
SS
Sandvik Systems Development
SAP R/3
In the pipe...
L
Lig
ht
Au
th.
Pe
an
rm
rfo
Internal
Web Service
Firewall
ce
Sta
s
tic
tis
Lo
gg
ing
SN
MP
External
Web Service
Integration
Problems
All ERP- and Product-supplier deliver a broker
a broker requires..
Competence
Resources (human/machines)
Licenses
Adaptors
Requires Strategy
£
MQ
£
£
£
FTP
HTTP
SAP
Otherwise…….
Sandvik Systems Development
Integration
Future?
Mainframe
AS/400-Sopic
or equal
Back to point to point integration?
Sandvik Systems Development
Consumer shift
Sandvik Systems Development
Current infrastructure
(rough picture)
From
To
one
Consumer
/
supplier
any
consumer
Sandvik Systems Development
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
…
- Version migration: adaptor upgrades…
Kitchen sink?
- Expensive licenses
BizTalk
Inbound
Outbound
Standard func.
Standard func.
File
MSMQ
Http
OS/390
File
MSMQ
Http
SMTP
Mapping & Routing
Adapters
AIC
MQ Series
AS/400
OS/390
MQ Series
AS/400
SAP R/3 Idoc
NT/2003
SAP R/3 Idoc
NT/2003
SAP R/3 BAPI
Synchronous Q&A
Web Services
Web Services
SAP R/3
In the pipe...
SQL Server
DB/2
Domino
OTMA
Oracle
PDA
External Firewall
Application
SS
Sandvik Systems Development
SAP R/3
L
Lig
ht
A
.
uth
P
ce
an
orm
erf
Internal
Web Service
Firewall
Sta
s
tic
tis
Centrally placed servers
Lo
gg
ing
SN
MP
External
Web Service
What is iBridge?
iBridge
Control Center
SQL Server
Operators
z/OS
Domino Server
Microsoft
Operations Manager
iSeries
Windows
Server
Sandvik Systems Development
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
Sandvik Systems Development
MQ
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
Sandvik Systems Development
jIntegrator concept overview
BackEnd
System
Mapping
System
model
Message
builder
Business
objects
Business
Façade
Sandvik Systems Development
Any
Consumer
Solution J-Integrator
Integration framework
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
components
Sandvik Systems Development
Façade
A generic adapter to receive/send
messages
Support webservices and Xml-messaging
with MQ or http.
Configuration and generation
TBI current state: service facades
Sandvik Systems Development
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
Sandvik Systems Development
Efforts for the future
Monitoring
Sandvik Systems Development
Ownership
Meta- and Master-data
• <Owner>
• <Business model>
• <Static/common data>
• <Methods>
• <Schemas (contract)>
• <Glossary>
• <Discovery/display>
• <….>
Sandvik Systems Development
History = > Today
Sandvik Systems Development
Process Monitoring
SSD
SIT
Process
Owner
Mainframe QMP
Mainframe QMP
Mainframe QMP
Monitoring
MQ
MQ
App 2
App 1
Sandvik Systems Development
Biztalk
Process Monitoring
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
Monitoring
Mainframe
Mainframe
MQ
MQ
Satin
Tekla
Sandvik Systems Development
Mainframe
Biztalk
Control Center
Master data initiatives
Product master (one BA specific)
Customer/supplier master (all Sandvik)
User/identity (all Sandvik)
Lead
CRM
Customer
Organization (primarily meta data) Customer
User
AD Organization
Company
Cost centre
Mail
Employee
Notes
RACF
Sandvik Systems Development
Finance
PIM
Stock
ERP
Department
MF
Contact
Product
HR
User
Account
Prep
Product
Recipe
Unit
Customer
MLR Product
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
Sandvik Systems Development
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