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