A Practical Guide to SOA
October 2008 Clive Hatton clive.hatton@realirm.com li h tt @ li www.realirm.com
Real IRM
Specialises in Enterprise Architecture
Consulting Training (TOGAF & SOA certification) Technical Services
Represents The Open Group in South Africa p Key contributors to TOGAF development Hosts the Enterprise Architecture Practitioners Conference in South Africa
Agenda
Part 1
The Open Group
Architecture Forum TOGAF SOA Work Group p
Part 2
SOA Practical Guide
Slide 3
SOA / TOGAF Practical Guide
The Open Group. . .
Global Operation Cross-Industry Vendor Neutral Technology Neutral Brings k B i key constituents together in an open process Industry Consortium Not for profit Not-for-profit operations Operates the industry’s premier certification service
www.opengroup.org
Quick Facts
Consortium > 25 years Over 7,800 participants from 314 member enterprises Vendor neutral
1 member – 1 vote
250 225 325 300 275
Technology neutral A trusted partnership between end user enterprises (Customers) and suppliers of IT products and services (Suppliers) Driven by what members want to work on
200 175 150
05 04 07 2Q 05 04 00 2Q 06 06 4Q 4Q 2Q 2Q 4Q 4Q 07 4
5
1 /1
/2
Members – sample
6
The Open Group South Africa
Analytix Holdings LTD y g Armscor Business Connexion Datamine Digiterra (Pty) Ltd Eskom Investec Limited South Africa Knotion Consulting Letsema Consulting Lonmin Promis Solutions Real IRM Solutions (Pty) Ltd ( y) SASOL SDT State Information Technology Agency (Pty) Ltd Telkom SA Ltd triVector (Pty) Ltd ( y) Tshwane University of Technology University of Johannesburg University of Pretoria UNISA
7
A Shared Vision
Boundaryless I f B d l Information Flow™ ti Fl ™
achieved through global interoperability in a secure, reliable and timely manner
Boundaryless does not mean there are no boundaries – it means that boundaries are permeable to b d bl enable business. Vision
8 (C) The Open Group 2008
Realizing the Vision
Key Areas of Participation
Enterprise Architecture
TOGAF®) – the de facto standard for doing enterprise architecture
SOA
A style of architecture
IT Specialist and IT Architect
Skills and experience certification
Security
In the Boundaryless environment
Identity Management
Objects as well as people
Semantic Interoperability
Universal D U i l Data El Element Framework (UDEF)
Key Deliverables
Standards – API’s, Protocols etc Frameworks and Best Practices Certification of conformance to standards Conferences and events – global and local
Real-time and Embedded Systems
9
The Open Group Architecture Forum
Forum Spotlight
Architecture Forum Chair
Chris Forde – Chief Architect for American Express p US Card Customer Service
11
SOA / TOGAF Practical Guide
Architecture Forum – Vision
An effective open framework and method for architecture
Target g ADM TRM SIB BBIB Resource Base
TOGAF
Architecture as a professional discipline
Adequate “Commercial Off-TheShelf” architecture tools
Slide 12
Architecture Forum Key Accomplishments
TOGAF Downloads
TOGAF Certifications
40000
4,000 3,000 2,000 1,000
30000 20000 10000 0
Pre05 3Q05 2Q06 1Q07 4Q07
Fortune Top 50 Downloads
Forbes Global Top 50 Downloads
Haves Have nots
Haves Have nots
13
The TOGAF Story
• Customer members demand architecture standards … • Customer members select TAFIM as preferred starting point point… • DoD Information Systems Agency (DISA) donate TAFIM as base • TOGAF first published • TOGAF 7 – Technical Edition • TOGAF 8 Enterprise Edition ‘93
‘94 ‘95 ‘01 ‘02 ‘04 ‘08
• The Interoperable Enterprise Business Scenario first published • First TOGAF Certification Program Launched
14
• TOGAF 9 In Progress
Supporting industry integration
H
Prelim: Framework and Principles
A
Architecture Vision
TOGAF
G
Architecture Change Management
B
Business Architecture
C Requirements
Information System Architecture s
2 Consider Views
Implementation Governance
Support or Guidance
Zachman Framework
F
Migration Planning
E
Opportunities and Solutions
1 Create Baseline Technology
D
Architecture
8 Conduct Gap Analysis
3 Create Architectur e Model 4 Select Services
D Technology Architecture
7 Define Architectur e
6 Determine Criteria
5 Confirm Business Objs.
TOGAF ADM
Federal Enterprise Architecture Framework A hit t F k
15
Architecture Development Method
Other Frameworks
16
TOGAF Overview
What is TOGAF? TOGAF = The Open Group Architecture Framework Framework. An architecture framework that enables you to design, evaluate, and build the right architecture for your organization. What architecture style does it support? TOGAF doesn’t specify the architecture style – it is a generic framework TOGAF can be used in developing architecture based on SOA style. What does it contain? TOGAF consists of three main parts: The TOGAF Architecture Development Method (ADM) The Enterprise Continuum The TOGAF Resource Base
H: Establish procedures for managing change to new architecture
H. Architecture Change Management
Prelim: Framework and Principles
Define p c p es, e e principles, Adapt framework
A. Architecture A hi Vision
A: Define scope; create vision; obtain approvals
B. Business Architecture
B: Develop a business architecture
G: Provide G. architectural Implementation oversight of the Governance implementation
F. F Migration Planning
Requirements Management
C. Information Systems Architecture
C: Develop data and application architecture
F: Prioritize, select major work packages, develop migration plan
E. Opportunities and Solutions E: Check point suitability
D. D Technology Architecture
D: Develop a technology architecture
for implementation
Enterprise Continuum TOGAF Resource Base Solution Continuum Architecture Continuum
The Open Group SOA Work Group
Work Group Spotlight
The SOA Work Group Mission
To develop and foster common understanding of Service-Oriented Architecture in order to facilitate alignment between the business and information technology communities. It does this by conducting a work program which will produce definitions analyses definitions, analyses, recommendations, reference models, and standards to assist business and information technology professionals within and outside of the Open Group to understand and adopt SOA.
www.opengroup.org/projects/soa
19 (C) The Open Group 2008
Completed SOA Projects
1Q06 2Q06 3Q06 4Q06 1Q07
Completed
Initial Review Review Complete
Definition of SOA
Initial Review Review Review Complete
SOA Case Studies Evaluation of what Unique Value The Op Group Open G p can add to the Evolution of SOA
Initial Review Complete
20
(C) The Open Group 2008
SOA Project Forward Roadmap
1Q08 2Q08 3Q08 4Q08 1Q09 2Q09 3Q09 4Q09
Work In Process Ontologies f O t l i for SOA SOA Governance SOA/TOGAF Guide Reference Architecture S-O Infrastructure SOA and Security Legacy Evolution to SOA
Review Review Review Review Review Review Review Review Review Review Review Review Finalize Review Review Review Review Review Review Finalize Review Review Review Review Review Review Finalize Review Review Finalize Review Finalize Finalize
21
(C) The Open Group 2008
SOA Features and Benefits
Feature Service Benefits Improved information flow Ability to expose internal functionality Organizational flexibility Lower software development and management costs Improved manageability Business intelligence: Performance monitoring Improved security Information mediation Ability to develop new function combinations rapidly Ability to integrate existing assets Ability to l t Abilit t select component services d t i dynamically t optimize performance, i ll to ti i f functionality, and cost. Easier introduction of system upgrades Improved reliability. Ability to scale operations to meet different demand levels Ability to develop new functions rapidly Simplification of software structure The Open Group 2008 (C) Ability to adapt quickly to different external environments
22
Required Infrastructure
Service re-use Messaging Message monitoring Message control Message transformation Service Composition Service Componentization Service Discovery S i Di Service Virtualization Model-Driven Implementation Complex Event Processing
Service registry Service Bus Activity monitor PDPs and PEPs Semantic mediator Composition engine
Service S i registry it
MDA environment Event processor
Other SOA Activities
SOA Maturity Model Board level project The Open Group Service Integration Maturity M d l (OSIMM) is the industry’s M i Model i h i d ’ first collaborative maturity model for SOA adoption SOA Source Book
Open Group book to describe overall framework for SOA Not a project – simply a joint work by authors Using material from SOA projects To be published end 2008
23 (C) The Open Group 2008
The Open Group s Definition of SOA Group’s
Service-Oriented Architecture (SOA) is an architectural style that supports service orientation orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services. A service Is a repeatable activity that has a specified g outcome – e.g.
check customer credit, provide weather data, consolidate drilling reports
Is self-contained May be composed of other services Is a “black box” to consumers of the service
Definition of SOA Style
An architectural style is the combination of distinctive features in which architecture is performed or expressed. expressed The SOA architectural style has the following distinctive features:
It is based on the design of the services – which mirror real-world activities – comprising the enterprise (or interp ) processes. enterprise) business p
Definition of SOA Style
Service representation utilises p business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, interface and service component) and implements services using service orchestration. It places unique requirements l i i t on the infrastructure – it is recommended that p p implementations use open standards to realise interoperability and location transparency.
Definition of SOA Style
Implementations are p environment-specific – they are constrained or enabled by context and must be described within that context. It requires strong governance of service representation and implementation. It requires a “Litmus Test", which determines a “ “good service”.
The Open Group SOA / TOGAF Practical Guide
Project Spotlight
The SOA/TOGAF Practical Guide Project
Joint project of the SOA Work Group and the Architecture Forum Will deliver a practical guide to enable a trained TOGAF practitioner to use TOGAF 8 and the SOA adjustments 'out of the box' to develop a SOA Phases A-D are main focus Current state
No barriers to use of TOGAF for SOA discovered Strategic, Strategic segment and solution architectures must be explored separately Good understanding of strategic and segment, more work needed on solution level
29 (C) The Open Group 2008 7 November 2008
Why the need to enhance TOGAF to support SOA?
Prelim A. H. G. F. D. B. C.
E.
TOGAF is a mature EA y framework that is widely adopted
SOA is an architecture style g y p that is being widely adopted
Enterprises have adopted both TOGAF and SOA Struggling to bring the EA work and SOA together TOGAF practitioners should be able to use TOGAF to deliver SOA Need to stop looking at the two as separate activities
Adapting the ADM
Generic methodology intended for variable: gy
Geographies Vertical sectors Industry types Architecture styles
Usable with deliverables of other frameworks such as Zachman, DODAF, TEAF, … It is usual to modify or extend the ADM to suit specific needs Such as the Service Oriented style of Architecture
Slide 31
Adapting the ADM for SOA
Prelim
SOA specific Objectives
A. H. G. F. F D. D B. C.
E.
SOA Specific Inputs p
SOA Specific Steps
SOA Specific Outputs
Preliminary Phase
Prelim
A. H. B.
G.
C.
F. E.
D.
33
(C) The Open Group 2008
7 November 2008
What Happens in the Preliminary Phase
Prelim
The TOGAF Preliminary Phase is concerned with preparing an architecture team to do architecture for a particular enterprise ti l t i The preliminary phase is used to set up the architecture practice The Preliminary phase allows for customization of the TOGAF ADM to meet particular needs of the enterprise and the architecture team
34 (C) The Open Group 2008 7 November 2008
A. H. G. F. F D. D B. C.
E.
Preliminary Phase: Objectives
Confirm stakeholders’ commitment
H. Prelim A. B. C. F. F D. D
Define principles and constraints Identify organization’s “architecture footprint” p Define the scope and assumptions Define framework and detailed methodologies
G.
E.
Continued…
continued… continued Preliminary
Phase: Objectives
Prelim A. H. G. F. F D. D B. C.
Set up and monitor framework’s fitness for purpose Define evaluation criteria for:
Tools Architecture Repositories Repository and repository management processes to:
Capture Publish Maintain
E.
Architecture Principles
Prelim
The preliminary phase includes definition of Architecture Principles The TOGAF resource base includes a generic set of architecture principles. These are reviewed, and a subset appropriate for the organisation is identified Further principles for service orientation are added. For example:
Service abstraction Service reusability Loose coupling
37 (C) The Open Group 2008 7 November 2008
A. H. G. F. F D. D B. C.
E.
Governance Framework
The Preliminary phase includes a review of the governance framework to ensure th t an that appropriate framework is in place prior to Phase G The preliminary phase recommends that a proper governance framework including SOA governance is created.
38 (C) The Open Group 2008 7 November 2008
Reference Architecture
Prelim
The Preliminary phase includes the establishment of an architecture repository with an initial collection of p y material. An SOA Reference Architecture is included in the initial architecture repository collection. (The Open Group is developing a standard SOA Reference Architecture)
39 (C) The Open Group 2008 7 November 2008
A. H. G. F. F D. D B. C.
E.
SOA Guidelines
To support governance and allow for compliance assessment, guidelines are developed b d l d based on a d reference architecture. Usually, these guidelines are identified based on known patterns that the enterprise develops in support of the reference architecture description.
SOA / TOGAF Practical Guide
SOA Maturity Model
Prelim
Enterprise needs to have some sort of maturity model against which it can measure it maturity level its t it l l The selection or adoption of SOA maturity model is best done at this phase (The Open Group is developing a y ) SOA Maturity Model – OSIMM)
SOA / TOGAF Practical Guide
A. H. G. F. F D. D B. C.
E.
Deliverables/ artifacts identified
Prelim
1. 1 2. 3. 3
4.
5. 6. 7.
SOA principles doc SOA readiness assessment report SOA statement of direction with adoption plan Customised / adopted SOA maturity model SOA reference architecture SOA Guidelines G id li SOA Governance team and process
A. H. G. F. F D. D B. C.
E.
Phase A: Architecture Vision
Prelim
A. H. B.
G.
C.
F. E.
D.
43
(C) The Open Group 2008
7 November 2008
What Happens in the Architecture Vision Phase
Prelim
This phase of TOGAF is concerned with: p
Understanding the requirement Identifying stakeholders and their areas of concern Agreeing the scope of the architecture work Creating an initial (“Version 0.1”) description of the architecture Developing a Vision Statement to “sell” the architecture
H. G. F.
A. B. C. D.
E.
The architecture team conducts a business scenario to understand the requirements, identify the stakeholders, and create an overview of an architecture that will meet th requirements hit t th t ill t the i t On the basis of this, it develops the initial description and the vision statement
44
(C) The Open Group 2008
7 November 2008
Phase A – Architecture Vision: Stakeholders Analysis
Definitions from TOGAF
A view i a representation of a whole system f i is t ti f h l t from the perspective th ti of a related set of concerns. A viewpoint defines the perspective from which a view is taken.
H. G. F. D. Prelim A. B. C.
As per TOGAF, the minimum set of stakeholders
Users System and Software Engineers Operators, Administrators, and Managers Acquirers
E.
SOA related stakeholders
SOA Business Stakeholders SOA centre of excellence f ll SOA governance body Information security group Implementers (service designers and service integrators)
Phase A – Architecture Vision: Views & Viewpoints Enhancement
Prelim
TOGAF specifies the following common set of p g architectural views Business Architecture views Data Architecture views Applications Architecture views Technology Architecture views Views identified as important for SOA using TOGAF Vi id tifi d i t tf i Service model view Policy/Guidelines/Standards/processes view Maturity model view Service Portfolio view Information view
G.
A. H. B. C. F. D.
E.
Architecture Vision - Example
Prelim
The new enterprise architecture will deliver improved profitability and ROI b i fi bili d by improving customer satisfaction i i f i and process efficiency, leading to more sales without a corresponding increase in operating costs. The improved customer satisfaction will result from improved ease of dealing with the organisation, better and more reliable delivery times, and visibility of delivery schedules. Product price and quality will be maintained. The improved process efficiency will result from y elimination of paperwork and better internal information visibility, leading to more efficient operation and realistic planning. The IT systems introduced will be easy to use and y y manage. The improvements in process efficiency, together with system usability and manageability, will contribute to staff satisfaction.
47 (C) The Open Group 2008 7 November 2008
A. H. G. F. D. B. C.
E.
Phase B: Business Architecture
Prelim
A. H. B.
G.
C.
F. E.
D.
48
(C) The Open Group 2008
7 November 2008
What Happens in the Business Architecture Phase
Prelim
The Business Architecture aligns the enterprise's business processes, people, operations and projects with its overall strategy providing a strategy, foundation on which to build the Information Systems Architectures and the Technology Architecture The architecture team develops a set of models of business aspects of the enterprise and performs a gap t i d f analysis of the baseline and target versions of these models
49 (C) The Open Group 2008 7 November 2008
A. H. G. F. D. B. C.
E.
Business Models Developed – Example
Prelim
Costs and Benefits Model Business Function Analysis Business Process Analysis y Order Fulfilment Model High-Level Business Vocabulary Business Rules Catalog Business Roles Model Business P B i Processes b G by Geography h Organization Charts Correlation of organization and functions
50 (C) The Open Group 2008 7 November 2008
A. H. G. F. D. B. C.
E.
Business Process Analysis Example
Tax & regulation information Tax and Regulation (Gov’t) Financial Fi i l information Banking (Bank) Order Delivery (Supplier) Operation events Product – related Processes Component Source (Customer) Order events Contractual information
51 (C) The Open Group 2008 7 November 2008
Product information
H.
Prelim A. B. C. F. F D. D
Operation
G.
Management information Product design
E.
Building Design (Customer)
Materials events
Phase B – Business Architecture: SOA Enhancements
Prelim
Key business requirements and constraints Business architecture
Business Services model – a model that specifies what services the enterprise provide to its consumers along with their relationships. relationships Business process model – a process model that supports the execution/delivery of the business services services. Business terms and semantics – Business information and semantics model that are required for identified business services services.
A. H. G. F. D. B. C.
E.
Phase C: Information Systems Architectures
Prelim
A. H. B.
G.
C.
F. E.
D.
53
(C) The Open Group 2008
7 November 2008
What Happens in the Information Systems Architectures Phase
Prelim
Data Architecture
Define the major types and sources of data necessary to support the business
G.
A. H. B. C. F. D.
E.
Applications Architecture pp
Define the major kinds of application system necessary to process the data and support the business d t th b i
54
(C) The Open Group 2008
7 November 2008
Applications Architecture for SOA
Prelim
Traditional software applications are replaced by sets of loosely-coupled services Existing applications should still be described, as should any new y applications of a traditional kind that you decide should be added Areas of application functionality that are covered by services should be identified id tifi d
55 (C) The Open Group 2008 7 November 2008
A. H. G. F. D. B. C.
E.
Information Systems Models Developed – Example
Prelim
Logical data model Data usage model (CRUD) Application/Services Portfolio Catalog pp g Use of services by business processes Service consumers model Service contract and policy model Service access control model Service loading S i l di model d l Service “ownership” catalog Cost model
56 (C) The Open Group 2008 7 November 2008
A. H. G. F. D. B. C.
E.
Application Gap Analysis Example
Baseline Sales Accounts CAD Product Configurator Order Processing Production P d ti Materials Various
Keep Delete New N
57
Wrap
(C) The Open Group 2008
Target Customer M C t Management t Order Management Product configuration g Design Delivery Management Production Materials Management Planning Accounts A t HR Management information
7 November 2008
Application Gap Analysis Example
Baseline Sales Accounts CAD Product Configurator Order Processing Production P d ti Materials Various
Keep Delete New N
58
Wrap
(C) The Open Group 2008
Target Customer M C t Management t Order Management Product configuration g Design Delivery Management Production Materials Management Planning Accounts A t HR Management information
7 November 2008
Phase C : Application Architecture or Service Architecture or Both?
A look back at TOGAF Application Architecture objective: pp j What TOGAF says about the objective of Application Architecture:
The effort is not concerned with applications systems design Applications are not described as computer systems They are described as logical groups of capabilities that
manage the data objects in the Data Architecture support the business functions in the Business Architecture.
H. G. F. D. Prelim A. B. C.
E.
The applications are defined without reference to particular technologies
What this means in SOA terms: Data services – manage the data objects in the data architecture SOA Business services – support business functions in the business architecture Applications are implemented by composing or orchestrating services
Phase C – Service / Application Architecture Enhancements
Prelim
Application Architecture needs to be aligned with Service Architecture Applications are delivered as services => thi means services are composed > this i d or orchestrated to implement business applications.
A. H. G. F. D. B. C.
E.
Slide 60
SOA / TOGAF Practical Guide
Phase C – Data Architecture Enhancements
Prelim
Service data schema and data semantics model is done in phase C: Data architecture. The semantics part of the data may require an extension of the data q architecture of TOGAF phase C. Data Schema and Semantics clearly defines the structure of the data used by services at a logical level
Slide 61 SOA / TOGAF Practical Guide
A. H. G. F. D. B. C.
E.
Phase D: Technology Architecture
Prelim P li
A. H. B.
G.
C.
F. E.
D.
62
(C) The Open Group 2008
7 November 2008
What Happens in the Technology Architecture Phase
Prelim
The Technology Architecture phase seeks to map application components defined in the Application Architecture phase into a set of technology components, which represent ft h l t hi h t software and hardware components, available from the market or configured within the organization into technology platforms For SOA, this means defining SOA
The software and hardware infrastructure needed to support the services The service standards
63 (C) The Open Group 2008 7 November 2008
A. H. G. F. D. B. C.
E.
Technology Models Developed Example
Prelim
Technology building blocks and standards Geographical location of systems Use of systems by services Performance model Cost model
A. H. G. F. D. B. C.
E.
64
(C) The Open Group 2008
7 November 2008
FBI Analysis – Example
Feature
Service
Benefits
Improved information flow Ability to expose internal functionality Organizational flexibility Lower software development and management costs Ability to develop new function combinations rapidly
Infrastructure
Service Re-use Composition
Service repository Composition engine
65 (C) The Open Group 2008
7 November 2008
SOA Standards – Example
Prelim
WSDL SOAP WS-Messaging WS Messaging
A. H. G. F. D. B. C.
E.
66
(C) The Open Group 2008
7 November 2008
Phase D: Technology Architecture SOA Enhancements
Prelim
Objectives
Support for service implementation and deployment Identify technology to support and enable SOA
H. G. F.
A. B. C. D.
E.
Inputs
SOA reference architecture Baseline / reusable services Target services
Outputs
Comply with guidelines as per reference architecture
Slide 67 SOA / TOGAF Practical Guide
Using the TOGAF ADM for SOA Overview
Define business vocabulary and service context Identify functions Learn the lessons to be performed by services Oversee the
implementation Set up the architecture process Understand the problem, agree the scope and set the vision Model the business Model the data and data processing Model the Technology Identify implementation projects
7 November 2008
Define service standards and Plan the implementation infrastructure
68 (C) The Open Group 2008
Benefits of the SOA /TOGAF Practical Guide
Prelim
Architected approach to SOA
H. G.
A. B. C. F. F D. D
Covers full scope of the SOA lifecycle Standard St d d method = reduction of risk th d d ti f i k Better li B tt alignment with b i t ith business
E.
69
(C) The Open Group 2008
www.opengroup.org/projects/soa-togaf
Acknowledgements
The Open Group Forum Director for SOA
Chris Harding
The Open Group SOA / TOGAF Practical Guide project leaders
Steve Bennett Awel Dico Dave Hornford
71
SOA / TOGAF Practical Guide
Thank You Get Certified in SOA!
Expand your SOA Skills and Opportunities: Become a Licensed ZapThink Architect (LZA)! p ( )
Register Now!
10-13 November 2008 in Johannesburg 17-20 November 2008 in Cape Town www.realirm.com/scheduled-courses
Slide 72
SOA / TOGAF Practical Guide