1. Roadmap to Strategic SOA
David Sprott

2. Agenda
Everware-CBDI?
Baseline SOA Adoption
Assessment Exercise
Applying structure to the change management task
Strategies, Techniques, Framework
A working session, guiding participants through elements of an SOA adoption planning process to illustrate a framework for managing the transition to SOA. The session will commence with an assessment exercise – to help participants understand their current SOA maturity level, and then introduce by example the techniques involved in SOA capability planning

3. Trusted, Independent SOA Advisors
A Newly Merged Company
Specialist firm providing actionable guidance and support to the most profound transformation in the history of business and IT
- Enabling structured, enterprise level SOA
- Facilitating SOA standards
- Research based best practices
Trusted, Independent SOA Advisors

4. PRE-SOA SOA The Challenge Complex change management problem
Introducing architecture driven approach to largely unstructured environment
PRE-SOA
Project driven
Variable approaches and processes
Point to point integration
Low levels of reuse at any level
Loose coupled technology
Tight coupled applications
Low level of business alignment
. . .
SOA
Business/IT convergence
Contract based services
High levels of reuse of coarser grained functionality
Manufacturing and assembly environment
Architecture and policy driven
Repeatable processes
Strong governance to maintain architectural integrity
. . .

5. Current State? Tactical SOA Project and or infrastructure driven
Delivering and using services with little or no structure
Little or no consensus or consistency across the organization
No explicit policies and repeatable processes that permit governance
Recipe for Service Anarchy and limited ROI
Early Learning
Integration
Most enterprises
are “doing” SOA
today in some fashion

6. Future State
Tactical SOA
Project and or infrastructure driven
Delivering and using services with little or no structure
Little or no consensus or consistency across the organization
No explicit policies and repeatable processes that permit governance
Recipe for Service Anarchy and limited ROI
Strategic SOA
Analogous to a manufacturing and assembly environment
Classes of service have appropriate, repeatable processes
Mature architecture and engineering processes and practices
Formality over policy implementation to ensure implementation of both business requirements and architectural policies
Manage outcomes that are fit for purpose, deliver future flexibility, utility and cost.
Service Architecture & Engineering: A comprehensive, defined approach for service architecture together with repeatable service engineering processes that guide the delivery of the agile enterprise.

7. Service Architecture & Engineering Reference Framework
CBDI-SAETM SOA Reference Framework
Model
SOA Principles
Service Life Cycle
SOA Meta Model
Glossary
Architecture
Business
Deployment
Patterns
Policy
Techniques
SOA Views
Organization
Roles & Structure
Funding Models
Project Profiles
Models
Deliverables
SOA Best Practice
Process
Enable
Consume
Manage
Provide
Technology
Standards
Implementation
Specification

8. A Clutch of SOA Maturity Models
SEI CMMI
Service Maturity Model from AmberPoint, Bearing Point, Sonic Software and Systinet
BEA Systems
IBM - Service Integration Maturity Model
Silo (data integration)
Integrated (application integration)
Componentized (functional integration)
Simple services (process integration)
Composite services (supply-chain integration)
Virtualized services ( virtual infrastructure)
Dynamically reconfigurable services (eco-system integration)
A Clutch of Maturity Models!
I am not sure what the collective noun is for maturity models, but given the recent spate of activity, it seems we need some way to describe the phenomenon.
In the IT world the CMMI[1] Capability Maturity Model Integration is well known as a frame of reference for IT process improvement and variants have been developed for many disciplines such as software engineering, systems engineering, software acquisition, systems security and more. Not surprisingly therefore some of the published maturity models reuse the CMMI ideas.
The CMMI maturity levels, illustrated in Figure 1, are very useful insofar as they provide a reference model of mature practices in a specified discipline. But as yet the CMMI has not addressed architecture. While there is guidance in moving processes from a project focus to an organization focus, there is no coverage (yet) of architectural control and governance. This certainly raises some interesting questions because architectural process integration is an area of considerable importance and complexity.
[1] Capability Maturity Model® Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes.
Vendor Collaboration
In September the vendors AmberPoint, BearingPoint, Sonic Software and Systinet announced[1] the publication of a collaborative effort to define the SOA Maturity Model reproduced in Figure 2. This model is based on the CMMI framework. I like what the group has done in relating the CMMI based levels to SOA benefits - Functionality, Cost Effectiveness, Responsiveness, Transformation and Optimization. This is a nice way to characterize the evolving interest areas. In the early stages SOA activity is driven by project functionality, and cost effectiveness. Then at Level 3 the focus on business and collaborative services enables responsiveness. However at Level 4 it comes clear that Transformation is not about business transformation but about process measurement and Business Activity Monitoring in particular. This is further reflected in Level 5 where Optimization is defined as automatic response to events.
This is all good stuff but essentially it is a maturity model about types of services, and not altogether surprisingly, focused on the technical infrastructure and management tools capability in particular, to deliver services with different characteristics. This is a perfectly valid perspective but represents merely one strand of a broader enterprise maturity model. So this model should perhaps be renamed a Service Maturity Model.
[1] AmberPoint, BearingPoint, Sonic Software and Systinet Collaborate on Model to Assess, Guide and Establish Vision for Maximizing the Strategic Benefits of SOA investments;
IBM
Also in September IBM published a report on DeveloperWorks describing their Service Integration Maturity Model[1] (SIMM). The SIMM describes seven stages of maturity on the path to SOA adoption:
Silo (data integration)
Integrated (application integration)
Componentized (functional integration)
Simple services (process integration)
Composite services (supply-chain integration)
Virtualized services ( virtual infrastructure)
Dynamically reconfigurable services (eco-system integration)
This list attempts to do something similar to the platform vendors’ model, it provides a maturity model for types of services, which spans silo based data integration and proprietary application integration in Levels 1 and 2, then legacy transformation at Level 3, with what the authors refer to as embarking on the early stages of SOA at Level 4. This makes sense in context with IBM’s customer base that spans a wide range of technologies and architectures.
Interestingly the IBM authors suggest that at level 3 the organization componentizes and modularizes major or critical parts of its application portfolio. This is a little different to what I normally expect. In my experience componentization generally happens after a functional integration stage based on wrapping and harvesting existing systems, because in the early stages there is generally little justification for this major effort. The IBM maturity model therefore doesn’t help us to understand the dependencies between the capabilities at the various stages of maturity. In this example the capability to componentize depends on the capability to cost-justify componentization which in turn depends on the size and success of the previous harvesting effort.
The IBM paper then goes on to describe their experience that “the process of adopting Web services and SOA starts in many cases at the ad hoc stage on projects. This gradually evolves into a general technology adoption . . , Once the technology adoption stage achieves some level of maturity, the results start trickling into the lines of business. They see the value in sharing services across lines of business to eliminate redundancy and having a single point of access to existing functionality that reduces complexity and cost and increases flexibility.”
BEA Systems
Believe it or not, in September BEA also published a nice article by David Groves[1] which includes a maturity model. BEA has some excellent advice which is summarized here:
Think strategically, execute tactically
Think from the top down.
Think from the bottom up.
Consider infrastructure services: Identify common supporting functionality requirements.
Expand slowly.
Build an Application Catalog: On a project-by-project basis, harvest and reuse service modules.
Focus on benefits: Phase projects in order of ROI

9. SOA Capability/Maturity Model
Management
Architecture
Operational Infrastructure
Delivery Infrastructure
Organization
Process
Projects
CAPABILITY
WORK
PACKAGE
STRATEGY
MATURITY
LEVEL
OUTCOME
Narrow path
Tactical. . .
Domain
. . .
Early Learning
Applied
Integrated
Enterprise
Ecosystem

10. SOA Capability Maturity Model
Ecosystem
Common ecosystem services eliminate organizational boundaries and enable broader economic activity
Service concepts standardized across industry sectors and or LOBs
Enterprise
Enterprise level shared services create enterprise adaptability and consistency
SOA enables enterprise wide consistency of business information and processes
Integrated
Shared services integrate silos, rationalize EAI contracts
Integrated approach reduces complexity, cost and increases adaptability
Applied
Project based SOA activity
Service architecture enables business adaptability for limited scope
Early Learning
Initial SOA activity
Experimental

11. SOA Roadmap Streams Early Learning Applied Integrated Enterprise
Management
Management tools including vision, strategy, funding, charging, measurement and monitoring
Creation and ongoing management of the service architecture and portfolio
Service
Architecture
Operational Infrastructure
Single logical operational infrastructure with common policy implementation and management tools
LifeCycle Infrastructure
Consistent reference architecture for tools and platforms to deliver and manage the requirements to retirement life cycle
The architectural framework and repeatable processes enabling consistency, trust and governance in federated activity.
Framework and Process
Roles and responsibilities to execute on federated, specialized, utility based solutions environment.
Organization
Project strategy and planning to enable very high levels of reusable services in a manufacturing and assembly environment
Projects &
Programs
Early Learning
Applied
Integrated
Enterprise
Ecosystem
Maturity Level

12. Outline SOA Maturity Level Assessment
Stream
Early Learning
Applied
Integrated
Enterprise
Ecosystem
SOA Management
Funding for pilot/PoC projects
Services are managed as an IT architecture concept
Funding systems facilitate provisioning of shared services
Services are managed as business assets.
Services facilitate inter business collaborations
Service Architecture
Architecture is fragmentary & experimental
Project architectures are service oriented
There is a standard for rich service specification
The Enterprise has a Service Portfolio Plan
There are agreed business process and data architectures for business collaborations
Operational Infrastructure
ESB pilot or PoC
Project ESB
Common ESB framework
Common framework for enterprise service management and security
Services are managed as federated resources
Life Cycle Infrastructure
Services are not managed assets
Services are project level deliverables
Enterprise level registry and repository provides consistent life cycle governance of the run time service asset
Enterprise registry and repository provides design AND runtime service asset life cycle governance and asset dependency horizon analysis
Ecosystem registries provide governance over collaborative business processes
Framework and Process
Frameworks and practices extended in ad hoc manner
Project specific architecture frameworks
Common SOA reference architecture and process (defined concepts, principles, policies and patterns)
Convergence of business and IT practices around service concept
Collaboration reference architecture (defined points of collaboration)
Organization
IT architects sponsor SOA
SOA is a project level responsibility
There is single point of accountability for integration
Services are owned by the business
Services defined and managed on inter business collaborative basis (vertical, supply chain etc)
Projects & Programs
Pilot and PoC projects
Service delivery and usage integrated into LoB projects
Specialization of Service provisioning, implementation and assembly projects
Service product management
Collaborating parties act as provider and consumer

13. SOA Maturity Assessment
Current, 1 year and Target State Views
The graph below indicates the initial maturity assessment of the SOA with respect to:
Current state assessment
Situation after in-flight initiatives have run (a 1 year time horizon)
A target state proposed for the enterprise (a 3-5 year time horizon)
Maturity Levels
0: Zero base
1: Early learning
2: Integration
3: Reengineering
4: Cultural Integration
Sample

14. Current State Assessment: Architecture
0: Zero base
1: Early Learning
2: Integration
3: Reengineering
4: Cultural Integration
Current initiatives
Gap
NOW
1 year outlook
Target state
Current State
1 year outlook
Target State (3-5 yrs)
No consistent enterprise wide reference architecture for re-use exists although different elements are being developed in different parts
Work is planned on taxonomy over the next year
See next slide
Evidence for Maturity
Some definition of terms locally
Recognition that architecture is more than just IT
Reference architecture defined in parts
Canonical data models exist
Have some automatic enforcement of architectural rules
Some policy definitions written
Recognition of need for service contracts
Evidence for Immaturity
Lack of awareness of a reference architecture and doubts about its usability expressed
Confusion about terminology e.g. no unified definition of a service
Architectures weren’t consistent across SOA domains
No single semantic model in place
Service contract definitions not written or implemented
Policy definitions not written at business governance level or consistently enforced
Low visibility of links between business drivers and architectural plans
Interview Quote: “Have 5 different capability managers who are doing their interfaces in 5 different ways!” 1
CBDI Comment: Architectural maturity is key in order to lead the overall direction.
Sample

15. Target State: Architecture
0: Zero base
1: Early Learning
2: Integration
3: Reengineering
4: Cultural Integration
Target State Justification
A defined and stable state for the architecture is considered be optimal. The more mature state – mandated – may be inflexible given the enterprise’s disparate businesses
Target state
Target State Characteristics
Outcomes
Reference Architecture: consistent, layered architectures across SOA domains enforced in a consistent manner and widely adopted
Consistent approach enables reuse and drives productivity through standard approach to solving complex problems. Layered architecture reduces dependency and increases adaptability
Taxonomy/Canonical Data Models: consistent use of service-based terminology across areas. Architectural classifications and Functional classifications in place. A single semantic model, against which all services are mapped
Allows management of complexity; easier and faster to construct compatible end-to-end solutions
Service Contracts: Rich service specifications and contracts implemented including SLAs. Procurement agreements include architectural constraints and obligations
Reduced testing costs. Consumers have guaranteed service levels.
Greater agility due to ability to modify, extend and improve services independently if contracts are unaffected
Modularity: Well-defined boundaries between products and capabilities. Legacy applications reengineered and componentised
Increased speed of change (due to reduced horizon of change), easier to manage complexity and better accountability
Sample

16. SOA Capability Maturity Levels CAPABILITY STREAM CAPABILITY CAPABILITY
EARLY ADOPTION
CAPABILITY
STREAM
APPLIED
CAPABILITY
CAPABILITY
AREA
INTEGRATED
CAPABILITY
ENTERPRISE
CAPABILITY
ECOSYSTEM
CAPABILITY

17. Scenario Example Key: Long term Architectural Framework Scenario
Scoped Manifest Business Type Model
Detail Manifest Architecture
Key:
Long term
Architectural Framework
Scenario
Map Manifest BTM to LDM (Transformation Architecture)
Candidate Reference Architecture
Service Portfolio Planning
High Level Manifest Service Model
Manifesting Project
Programs & Projects
Manifest Rich Service Specification
Delivery Process and Infrastructure
Rich Service Specification Standards
Service Registry
Service Acquisition Contract Modifications
Service Acquisition Governance Process
Define Test Bed Processes for Services
Consumer Support Process
Change Management and Communication Policies
Common Service Security Architecture for Manifest (Limited)
Runtime Infrastructure
Common Policies for Service Runtime Operation
Effective Service Infrastructure
Differentiated Security with Message Level Profiles
Common Service Security Architecture for Manifest (Potential)
Roles and Responsibilities
Assign Manifesting Service Portfolio Manager
Establish Manifesting Service Community of Interest
Management of the Adoption Process
Definition of Scope and Business Case for Manifesting

18. Capability Dependency Diagram – Example
Basic Level
of Governance
Reference
Implementation
Delivery
Team Charter
Service Asset Automation
Skills
Development
Basic
SOA Policy
Formal Specification Standard
SOA Reference Process
SOA Reference Architecture

19. Capability Plan – Example Fragment
Recommendations
Maturity Level
Outcome
Central or federated coordination of integration activity.
Integration activities are consolidated and centrally co-ordinated and managed to reduce proliferation of point-to-point communications, and proliferation of products and disparate technologies.
Integrated
Rationalization of existing EAI contracts; governance over integration activity, transformation to services
Architecturally-driven acquisition
Procurement should exert greater architectural control and obligation over 3rd parties.
Integrated/Enterprise
The outsourcing contract needs to specify the requirements for flexibility.
Architecturally driven SOA policies and standards
The architecture organization establishes policies and standards for enterprise wide adoption of SOA
Early learning
Enterprise level standards and policy development
Balancing short-term and longer-term requirements
Business analyst/architect function have responsibility for short and long term demand for business process change
Requirements for shared services are established on the basis of forecast business needs.
Architectural governance
Establish architectural community of interest.
Enterprise
Collaboration and learning between architecture groups.

20. CBDI SOA CAPABILITY ROADMAP
Levels
Streams
Early Learning
Integration
Enterprise
Ecosystem
Management
Reuse metrics
Product and Process contribution
Business IT convergence
R&D Funding
Central investment in core business and utility services
Product and Process contribution
Planned time and cost of business change based on service product architecture
Project ROI
Flexibility metrics
Architectural Recovery & Reconstruction
Service
Architecture
Reference Architecture and policies for Domain & Utility Services – Mostly advisory policies
Defined taxonomy & classification systems
Reference Architecture and policies for all classes of services defined, mandated, stable – enable standard approaches to complex problems
Reference Architecture and policies for all classes of services Many mandatory policies
Componentization of core applications
Canonical model is integrated with business strategy supporting many TO BE scenarios
Architectural fragments used in attempt to stabilize and future proof early services
Core Service Portfolio Plan
Completed Service Portfolio Plan = ongoing management mechanism
Adaptability policy & patterns
Operational
Infrastructure
Federated ESB
Project ESB
Enterprise ESB
Many common infrastructure services
Federated Service management
Virtualization of resources
Service management
Registry with automated Lifecycle governance
Supporting runtime as well as design time discovery
Dynamic Business Activity Management
Resources are utility
Business Activity Monitoring
Life Cycle
Infrastructure
Enterprise Registry
Exploratory Life Cycle Reference Architecture
Simple DIY Service Catalogue
Change planned using automated simulation and forecasting systems linked to process management
Policy Management
Reference and Implementation Life Cycle Architecture completed
Assembly environment
Asset Management
Process
SOA Knowledge management
Change Management for main classes of service – focus on stability
Rich Service Contracts
Service Based Procurement Agreement and SOA obligations on 3rd parties
Change Management policy integrated across business and IT planning
Institutionalized knowledge management
Service supply/demand system in place
Defined, common life cycle process
Key governance requirements
defined
Certification for defined classes of service
Business signoff on adaptability requirements
Organization
Cross organization architecture board
Centralized Integration
Federated Service Ownership
Service Product Management
Federated Service provisioning replaced centralized integration
Cross organization
mechanisms
Separation of core business & utility service provisioning
Modified reward/recognition systems
Projects
Process oriented services pattern
Façades; single component services; multi-channel patterns
Collaborative process patterns; Joined up business processes; metadata driven assembly
Real time mediation; differentiated service; commodity service patterns
Industry standard services
Reference Implementation
CBDI SOA
CAPABILITY
ROADMAP
Copyright Everware-CBDI Inc. 2006
Proof of Concept
Initial exploratory SOA activity
Repeatable processes deployed to create basic shared services capabilities
Shared service platform allows wider collaboration and reengineering of IT and business
Service concept embedded in mature enterprise practices

21. SOA Excellence Process
SOA Readiness Assessment
= SOA Roadmap Preparation
Initial Capability Assessment
Status Assessment
Gap Analysis
SOA Adoption Planning
Adoption Strategy
Scenario Planning
Capability Planning
Role/Organization Planning
Resourcing
& Action Planning
SOA Adoption Management
= SOA Management
Leadership & Governance
Architecture
Process
Infrastructure
Organization
Projects & Programs
SOA Maturity Assessment
= SOA Roadmap Review
Ongoing Capability Assessment

22. Summary
SOA adoption is a complex change management problem
Introducing broadly based change
Into loosely coupled organizations
That may not immediately recognize the value of the change
Formal approach required
Maturity Model
Streams
Capabilities
Performance Measurement
Governance
High correlation with quality initiatives

23. Independent Guidance for Service Architecture and Engineering
Independent Guidance for Service Architecture and Engineering