From bottom up integration towards an information based enterprise architecture

1
From bottom up integration towards an
information based enterprise architecture
SSD/CAT - Jan Nilsson SSD/CAT - Pontus Gagge
2
Agenda

• Sandvik background
• Integration history
• Total Business Integration
• Future focus
• Lessons learned

3

• Sales 2006 SEK 72 billion (USD 10 bn)
• 42,000 employees in 130 countries
• Products with high RD and added value
• Global leader in selected areas

4
Sandviks business philosophy since 1868
Extract from a letter of 2 March 1869 from the
Sandvik agent in France to A H Göransson inSt
Petersburg, on Sandviks first sales tripto
Russia.
5
Global Presence
Market Areas
Asia/Australia
Europe
South America
Africa/ Middle East
NAFTA
6
Sandvik Global leader
Three business areas
SandvikMaterials Technology
SandvikMining and Construction
Sandvik Tooling
Invoiced sales, SEK M
22,500
25,000
19,300
15,100
12,200
8,600
Employees
7
Acquisitions 1996-2006

• Close to 50 companies in 20 countries
• SEK 22 bn in sales
• 15,000 employees

8
Historical view of IT at Sandvik
9
Problems for legacy systems

• Internally developed ERP system (SOPIC v1 early
  70s, current ver. late 80s-gt)
• 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

10
Problems for integration

• Brokers tend to pop-up everywhere
• Almost all supplier deliver a broker
• Without a strategy, back to point-gtpoint (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

11
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

12
IntegrationHistory-gtToday
From point to point
From flat file integration
to a broker scenario
13
IntegrationProblems

• All ERP- and Product-supplier deliver a broker
• a broker requires..CompetenceResources
  (human/machines)LicensesAdaptors MQ FTP HT
  TP SAP

14
IntegrationFuture?
Back to point to point integration?
15
IntegrationRoles
16
Consumer shift
17
Current infrastructure(rough picture)
18
TBI Integration broker BizTalk

• Basic broker functions
• Transport protocols
• Message formats
• Message transformation
• Message routing
• Operational supervision
• Also
• Orchestration
• Business Activity Monitoring
• IAM Credentials vault
• Kitchen sink?

• Version migration adaptor upgrades
• Expensive licenses
• Centrally placed servers

19
What is iBridge?
z/OS
iSeries
Windows Server
20
Distributed

• Decentralized
• Distributed
• Scalable
• Centralized configuration
• Independent operation

21
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

SOAP
BAPI
MQ
22
Monitoring
23
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

24

jIntegrator concept overview

• Message
• builder
• Business
• objects
• Business
• Façade

Mapping System model
25
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 components

Façade
Façade
Façade
26
TBI current state service facades
27
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

28
Efforts for the future
Monitoring
Ownership
29
Meta- and Master-data

• ltOwnergt
• ltBusiness modelgt
• ltStatic/common datagt
• ltMethodsgt
• ltSchemas (contract)gt
• ltGlossarygt
• ltDiscovery/displaygt
• lt.gt

30
History gt Today
31
Process Monitoring
SSD
SIT
Process Owner
Mainframe QMP
Mainframe QMP
Mainframe QMP
MQ
MQ
App 2
Biztalk
App 1
32
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

Control Center
Mainframe
Mainframe
Mainframe
MQ
MQ
Satin
Biztalk
Tekla
33
Master data initiatives

• Product master (one BA specific)
• Customer/supplier master (all Sandvik)
• User/identity (all Sandvik)
• Organization (primarily meta data)

Company
Organization
Cost centre
Department
Unit
34
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

35
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 MAs
• Awareness grows gradually
• the need for architecture
• the key role of information