Roadmap to Strategic SOA David Sprott

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

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

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 . . .

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

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.

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

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. http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-overview05.pdf 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; http://www.systinet.com/pr/145 http://www.sonicsoftware.com/solutions/learning_center/soa_insights/movin_soa_on_up/index.ssp 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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

Independent Guidance for Service Architecture and Engineering www.cbdiforum.com Independent Guidance for Service Architecture and Engineering www.everware-cbdi.com