Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
6/23/2008
Using integration maturity as a guideline when deciding to implement SOA
Key objectives
� Provide some guidelines on how to rate the integration maturity of an
organization
� Provide an overview of the integration environment and high-level
architectural landscape of our logistics client to illustrate the complexity of
the integration space and the obstacles encountered.
Rating the
integration
maturity
The logistics
integration
environment
TOGAF and
SOA
� Using the TOGAF methodology and SOA to decide upon an integration
approach.
Overview of the client architecture landscape
External Principles Internal Configuration – National
Integration Hub
Our client has an international principle base that it needs to deliver world-class services to and requires a sound information management approach
Chain-store X
External Clients National
Webmethods
Integration
Solution
PRIDE
Warehouse
Management
System
WMOS
Warehouse
Management
System
Hub
Principle ‘A’
Principle ‘B’
Principle ‘C’ Principle ‘D’
Chain-store X
3rd party
Distribution
Sales Group Y
Wholesaler Z
Overview of the client architecture landscape
External Principle Systems Internal Configuration – South Africa
Integration Hub
Our client has an international principle base that it needs to deliver world-class services to and requires a sound information management approach
Webmethods
Integration
Solution
PRIDE
Warehouse
Management
System
WMOS
Warehouse
Management
System
Hub
SAP BC
MQ
Series
MFGPro
Gentran
Our client has a complex internal systems design that requires not only transactional, but product, financial, logistical and tracking information.
Internal Client Systems – South Africa
Bu
sin
ess In
form
atio
n
Ap
plic
atio
ns
Infr
astr
uctu
re
The complex technical integration design that facilitates the integration paths, with hardware and fail-over components.
Bu
sin
ess In
form
atio
n
infr
astr
uctu
re
The complex technical integration design that facilitates the integration paths, with hardware and fail-over components.
The Data Architecture depicts the business information flow relevant to our project within the B2B logistics environment
Warehouse System
Principles
FTP
Web service
GS1
AS2
DNS
natting
Database
SQL
Queries
EXAMPLE
WebMethods
Integration Server
WMOS
Warehouse System
Web service
HTTP
Guaranteed
deliveryFTP
FTP
natting
Database
SQL
Queries
Different File Complexities
� Data – file structures
• Flat file
• GS1 XML
• XML
• AS400
• Delimited
• Custom defined
The Business Order Cycle depicts some of the integration services that we support within the B2B logistics environment EXAMPLE
The order process depicts 8 processes (services) that will be orchestrated to link into the
supporting services via the orchestration layer.
This webMethods Service Architecture depicts the orchestration of the services within the integration layer environment EXAMPLE
The outbound message flow diagram depicts the sequence flow (orchestration) of the
services that support the client business process in the integration solution
The following typical questions will be asked to determine the level of integration maturity
� What requirements have been set by business?
� Is there a project plan driven by a PM?
� Is there involvement by business and how do they measure success?
� What protocols are proposed for use?
� What level of data security is required?
� What integration applications exist?
� What current integrations are in place and what have been done?
� What requirements are set and how flexible is the integration layer?
Business Architecture
Application Architecture
Data Architecture� What level of data security is required?
� What mechanisms are used to validate data sent / received?
� What alerting mechanisms are required for message control?
� How experienced is the client development team?
� Who is responsible for the communication medium?
� How advanced is the hardware used in the integration?
� Is there consideration towards DR and fail-over?
� What SLA’s are in place for the physical integration?
Technology Architecture
Data Architecture
Determining the level of integration maturity of the business layer
�Undocumented
processes
�Manual processes
�Limited
standardisation, re-
use and
Level 5:
Optimised
Level 4:
Managed
Level 3:
Disciplined
Level 2: Foundational
Level 1:
Ad-hoc
�Automatic
processes
�Inconsistent
processes
�Basic change/
configuration
�Business process
orientation
�Best practises,
process
standardisation &
documented
Chaotic Need-based Structured Managed Seamless
�High degree of
business process
re-use
�Operational
excellence
�Operational cost
�Seamless business
process integration
�Environmental risk
management
use and
predictability of
processes
�Individual
dependant
processes
�Non-standard
Business
Architecture
configuration
management
�Quality assurance
�Organisational
definition
�Project planning &
tracking
�Estimating
Source: Global Integration Summit - Integration Maturity Model
�Business process
modeling
�Model managed
and stored in a
central repository
�Architectural
Governance
�Advanced change/
configuration
management
�Operational cost
tracking
�Predictable
business results
�Performance
Orientation
Determining the level of integration maturity of the application layer
�Undocumented
applications
�Unpredictable
systems behaviour
�Stove-pipe custom
interfaces
Level 5:
Optimised
Level 4:
Managed
Level 3:
Disciplined
Level 2: Foundational
Level 1:
Ad-hoc
�Point to point
interfaces
�Application
embedded
business rules
�Loosely coupled
�Architectural
Governance
�Hub-spoke, rules
engine
�Training & vendor
management
�High degree of
application re-use
�Applications built to
integrate
�Predictable results
�Standards-based
�SOA
�Use of BPM & BAM
tools
�Repository of
business-level
services
Chaotic Need-based Structured Managed Seamless
interfaces
�Non-standard
Applications
Architecture
�Limited application
re-use
�Loosely coupled
�Error handling and
recovery
�Basic integration
testing
Source: Global Integration Summit - Integration Maturity Model
management
�Business objects
design standards
�Error handling and
recovery
�Systems
monitoring and
alerting
�Managed
Integration testing
�Standards-based
integrations
�Integration Reuse
services
�Integration
maintenance
tracking
Determining the level of integration maturity of the data layer
�Data structures
undocumented
�Data behaviour
unpredictable
�Manual data
�Individual dependant
Level 5:
Optimised
Level 4:
Managed
Level 3:
Disciplined
Level 2: Foundational
Level 1:
Ad-hoc
�Data automation �Data model
managed and
stored in a central
repository
�Architectural
Governance
�Metadata based
strategy
�Repository
management
�High degree of data
re-use
�Seamless
integration
Chaotic Need-based Structured Managed Seamless
�Individual dependant
�Non-standard data
architecture
�Limited re-use
Source: Global Integration Summit - Integration Maturity Model
re-use
�Integration
Competency
Centre
�Predictable results
�Information visibility
Determining the level of integration maturity of the technology layer
�Undocumented
technology
�Unpredictable
�Non-standard
Architecture
Level 5:
Optimised
Level 4:
Managed
Level 3:
Disciplined
Level 2: Foundational
Level 1:
Ad-hoc
�Message-
orientated
middleware
�Defined Technical
Architecture
�Security practices
�Managed Technical
Architecture
�Architectural
Governance
�Repository
management
�High degree of
reuse
�Integration
Competency
�Web-services
standards based
infrastructure
Chaotic Need-based Structured Managed Seamless
�Security practices
�Defined systems
environments
Source: Global Integration Summit - Integration Maturity Model
Competency
Centre
Determining the level of integration maturity requires the assessment of
several key attributes
�Undocumented
�Unpredictable
�Manual
�Individual dependant
Level 5:
Optimised
Level 4:
Managed
Level 3:
Disciplined
Level 2: Foundational
Level 1:
Ad-hoc
�Point to point
interfaces
�Loosely coupled
�Automatic
�Message-
�Best practises,
process
standardisation &
documented
�Business process
modeling
�Model managed
�Metadata based
strategy
�Repository
management
�High degree of
reuse
�Use of BPM & BAM
tools
�Repository of
business-level
services
Chaotic Need-based Structured Managed Seamless
�Individual dependant
�Stove-pipe custom
interfaces
�Non-standard
Architecture
�Limited Reuse
orientated
middleware
�Application
embedded
business rules
�Inconsistent
business processes
Source: Global Integration Summit - Integration Maturity Model
�Model managed
and stored in a
central repository
�Governance
�Hub-spoke, rules
engine
�Training & vendor
management
reuse
�Integration
Competency
Centre
�Hub-spoke, rules
engine
�Training & vendor
management
services
�Web-services
standards based
infrastructure
�Seamless
integration
Secure
AS2
Un-secure
web service
Controlled FTPSimple FTP Secure web
service
Example for Categorizing a client
Level of Maturity �Level 2: Foundational �Level 3: Disciplined �Level 4: Managed
Integration Architecture and
Environment -(Application & Data)
�Defined Technical Architecture
�Security practices
�Defined system environments
�Error handling and recovery
�Point to point interfaces
�Error handling and recovery
�Basic integration testing
�Data automation
�Managed Technical Architecture
�Error Handling and Recovery
�Business Object design
standards
�Architectural Governance
�Systems monitoring and alerting
�Managed Integration testing
�Architectural Governance
�Standards-based integrations
�Metadata
�Information visibility
�High degree of application re-use
�Repository management
�Integration Competency Centre
�Predictable results
Ability to implement Business
�Estimating
�Project planning
�Project tracking
�Basic integration testing
�Architectural Governance
�Business Process Orientation
�Managed Integration testing
�Performance Orientation
�Integration Reuse
Source: Global Integration Summit - Integration Maturity Model
Organisational Business
�Quality assurance
�Organizational definition
�Automatic processes
�Inconsistent processes
�Quality assurance
�Organizational definition
�Training & education
�Integration strategy
�Vendor management
�Knowledge management
�Business process orientation
�Architectural Governance
�High degree of business process
re-use
�Operational excellence
�Operational cost tracking
�Predictable business results
�Performance Orientation
Technology / Infra �Basic change/ configuration
management
�Environmental risk management
�Message-orientated middleware
�Defined Technical Architecture
�Security practices
�Defined systems environments
�Systems monitoring and alerting
�Operations standards and
processes
�Managed Technical Architecture
�Architectural Governance
�Integration maintenance
tracking
�Operational cost tracking
�Repository management
�High degree of reuse
�Integration Competency Centre
Level 1 occurs on an ad-hoc basis
Overview of the client integration maturity landscape
External Principles Internal Configuration – National
Integration Hub
An illustration of the different levels of integration maturity in different sectors.
Principle ‘B’
Webmethods
Integration
Solution
Principle ‘A’
Principle ‘D’Business: Level 2
Application: Level 3
Technical: Level 2
Data: Level 3
Principle ‘C’
Business: Level 3
Application: Level 3
Technical: Level 2
Data: Level 4
Business: Level 3
Application: Level 2
Technical: Level 2
Data: Level 2
Business: Level 4
Application: Level 3
Technical: Level 4
Data: Level 4
TOGAF Architecture Development Methodology (ADM) provides a valid framework for SOA as a whole.
� Enterprise Architecture is the
key to bringing coherence to
an organisation and building a
Service-Oriented Enterprise.
� Enterprise architecture
removes barriers and creates
a more open system.
� It is characterised by an
extensive reuse of common
data and processes, a
The iterative phases of the Architecture Design Methodology (ADM) provides a solid
framework for approaching a Service Oriented Architecture Integration Solution
data and processes, a
process-centric approach with
supervisory process
management, and an
assumption of continuous
change.
Source: TOGAF 8.1.1
Architecture Change Management is reduced because of the agility of SOA
“Modification of the architecture itself is addressed in the Architecture Change Management phase.”
SOA delivers agility. Changes to services and development of new services does not require changes to the architecture, when they are carried out using methods that are part of that architecture.
Reference Architecture: Services orchestration
Source: The Open Group SOA Working Group White Paper - July 2007,
The dividing line between projects that implement the architecture and projects that change it remains; but SOA can move projects across that line by including methods for change within the architecture.
Challenges faced when using an EA approach to integrate
� Key questions that need to be addressed to be able to implement
according to the EA approach.