Shaping The Organization in Institutionalizing SOA October 17

Shaping The Organization in Institutionalizing SOA October 17, 2006

Shaping The Organization in Institutionalizing SOA • Understand SOA as a foundation for a technology simplification strategy • Learn the SOA Maturity Model • Manage change in an SOA environment • Learn organizational alignment challenges with SOA 2

What is a Service Oriented Architecture? • SOA is a business planning method and software architecture approach that encourages sharing and reuse of application functions throughout networks • Key focal point is the “business process” • Evolves based on existing system investments – does not require a full-scale system re-write • Benefits – Increased productivity – Accelerated delivery – Reduced cost and risk Focus on Business Process is key to SOA 3

Evolution, not revolution… • SOA is evolutionary – Existing applications and environment remain intact – Key business processes are redeployed as ‘services’, and key user interfaces as ‘portlets’ that can then be reused by other applications • SOA is cumulative, speeds time to market – As ‘services’ and ‘portlets’ accumulate, applications can be built more quickly and incrementally by re-using existing assets • SOA is a way of doing more with less – Fosters code reuse, increases productivity: build a business process or user interface once, use many times – Reduces costs and risks: build / test once, use many times 4

SOA is catching on fast! • The Global 2000 Once implemented, their SOAs will be used for: – 68% were engaged in SOA projects in 2005 – 98% will be engaged in SOA projects in 2007 – Development costs will be reduced by 25%, or $53 B over 5 years – Aberdeen Group, 2006 • A survey of 306 US organizations found that 100% had started or planned to start SOA initiatives within 2 years – Yankee Group, Nov 2005 • By 2008, 80% of enterprise development projects will be based on SOA – Gartner, Mar 2005 5 44% Integrating applications internally 28% Providing services directly to customers or consumers 21% Connecting with external apps provided by partners 53% All of the above The top 5 factors influencing companies adopting an SOA: 1 Greater degree of business flexibility 2 Lower cost of integrating existing applications 3 Lower cost of developing new applications 4 Less time required to develop new applications 5 Less time required to maintain existing applications Source: Computerworld / CIO Survey, Feb 2006

Key SOA Concepts • Service Provider – Provides a “Service Contract” for a reusable service for business functions via an open interface implementation like Web Services • e. g. Credit Card Payment Web Service – Can Provide reusable UI Services via a embeddable User Interface with implementation like Portlets • e. g. Web Order Management Flow process to capture orders for Retail and Resellers can be a centralized reusable service built as a Portlet • Service Consumer (a. k. a SOA Composite Application) – Consuming Applications – consume the services from the Providers to realize localized needs for Business Units and geographies Providers and Consumers are the building blocks of an SOA footprint 6

SOA for Simplification 7

IT Simplification Challenge • Multiple applications with duplicate business process platforms and related features e. g. – – – • Order Management Provisioning Billing and Payment Marketing Customer Support Security Business Unit specific features duplicate business process features across business Units and Geographies e. g. – Web ordering for Retail and Reseller in global geographies developed and maintained with several applications duplicating features across the globe • e. g. No consideration of the core Web ordering process as an enterprise level process • Difficult to identify reuse and redundancy due to mixing of global process (plumbing) and localized Business Unit/Geography specific features – e. g. Cross-sell up-sell feature embedded only in a certain US based retail application and cannot be leveraged for resellers or global needs 8

SOA Feature Management • Provider features (Platform) – Business Process Related Provider features e. g. Ordering, Marketing, Product Provisioning, Security, Billing & Payment – Provider features for consumption to be localized for business units and geographies • e. g. global order life cycle configuration different for UK & US, but the service provider can be same – Majority of the order management life cycle features are sane for the globe – Localization specific to geographies or Business Units via configuration or composite application development – SOA targets should identify majority of the reuse features and make available for composite application development/configuration for localization of geographies and business units • Consumer Features (Business Units & Geographies) – Consume Platform features and localize them for realizing Business Unit specific needs • e. g. Web order capture process localized for US and UK geography • e. g. Call center ordering process localized for direct sales and resellers – Consumes provider features by configuration or composite SOA application development Application Feature Identification and Categorization is Key to Rationalize and drive buy in for SOA Implementations 9

Simplification Rationalization Approach – An Application Software “Asset Feature Management Repository” (AFMR) • Identify global feature base • Identify and derive “As Is” Application Asset to Feature Linkage • Leverage industry standard toolsets like Rational, Accept 360 to implement the Repository • Goals – Reusable features as targets for SOA exposure • If a system provides a reusable feature e. g. credit card payment used by multiple applications via a language dependant API, consider that as an exposure for a Service with a Web Services wrapper to enable other technology applications to integrate and reuse – Redundant features as targets for technology simplification consolidation and SOA enablement • If multiple systems provide the same features e. g. credit card payment then identify the one system which can extract the feature easily and expose as a service – Promotes an evergreen Requirements Management Process for Service features and consuming SOA composite Applications 10

Asset Feature Management Repository • Requirements Discipline • Derive Service Provider Asset Features duplication to identify consolidation targets • Identify potential reusable Service Provider features 11

AFMR Governance Guidelines • Establish an AFMR Council to govern the change management of the AFMR • Standard Feature Group / Feature / Sub Feature library • The Feature Group / Feature / Sub Feature are generalized and do not reference localized requirements Use Cases, Business Rules or other specifications • The AFMR council will govern the distribution of AFMR library changes to constituent groups with a standard asset version management and release schedule for Service and SOA Composite Application assets. 12

Example: Identified Enterprise Feature Needs for leveraging SOA ID Customer Management Feature Groups Feature Count 1 Customer Account Management 70 2 Order Management 150 3 Work Queue Management 75 4 Problem Ticket Management 25 5 Call Center Management 22 6 e. Mail Campaign Management 36 7 Product Catalog Management 47 Asset 1 Asset 2 Asset 3 Asset 4 Asset 5 Legend – Application Provides % of total features 25% 0% 50% 75% 100% Significant overlap of Providers of Customer Management Features across Software Application Assets Identifying the Need for Service Oriented Reuse and Consolidation for Simplification 13 Asset 6

SOA Maturity Model 14

SOA Maturity Model By putting SOA into a framework similar to the Capability Maturity Model®, goals, characteristics, and prerequisites to SOA’s business impact progressing through levels can be demonstrated as follows: SOA - CMMi Level alignment allows for organizations to set same goal targets for CMMi and SOA Maturity Levels 15 Source: Sonic Software, Actional, Data Direct Technologies, Progress Software, © 2006

Service Oriented Architecture Maturity Model: An approach to evolve to an SOA Maturity Level Business Benefits Scope Critical Success Factors Key Goals 1 Initial Services • New functional ity • Proof of concept • Pilot projects • Portal • Custom integrations • Small # of services • Standards • Legacy integration • Learn SOA in pilots • Apply SOA to immediate needs • Define/implement initial ROI metrics 2 Architected Services • IT cost reduction & control • Multiple integrated applications • Heterogeneity & distributed systems support • Reliable messaging • Database integration • Versioning • Internal security • Performance management • Institutionalize use of SOA • Put in place SOA architecture leadership • Prove returns 16 Source: Sonic Software, Actional, Data Direct Technologies, Progress Software, © 2006

Service Oriented Architecture Maturity Model: An approach to evolve to an SOA Maturity Level Business Benefits Scope 3 a Business Services • Business responsive ness – change business processes quickly and effectively • Business • Reuse processes • Business process across business rules unit or • Composite enterprise applications • Create ongoing partnership between business and technology for SOA Governance • Support full business processes via SOA • Prove returns from reuse of services and responsiveness to change 3 b Collabora tive Services • Business responsive ness – with business and partners • Services available to external partners • Cross enterprise • Create ongoing partnership between business and technology for SOA Governance • Extend SOA business processes to external organizations • Prove returns from use of services for collaboration 17 Critical Success Factors • External services enablement • Cross-enterprise security • Long-running transactions Key Goals Source: Sonic Software, Actional, Data Direct Technologies, Progress Software, © 2006

Service Oriented Architecture Maturity Model: An approach to evolve to an SOA Maturity Level Business Benefits Scope Critical Success Factors Key Goals 4 Measured Business Services • Business transformation from reactive to real-time • Business unit or enterprise • Cross enterprise • Business Activity Monitoring • Transformation from reactive to real-time business processes • Define and meet businessoriented performance metrics 5 Optimized Business Services • Business optimization – react & respond automatica-lly • Business unit or enterprise • Cross enterprise • Event-driven automation for optimization • Enterprise-wide leadership for business and SOA Governance • Prove returns from SOAsupported continuous improvements 18 Source: Sonic Software, Actional, Data Direct Technologies, Progress Software, © 2006

Manage Change with SOA Governance 19

Manage Change With SOA Governance • SOA increases the level of cooperation and coordination required between business and information technology, as well as among IT departments and teams • SOA Governance – Establishes decision-making rights associated with IT governance focused on the life cycle of services to ensure the business value of SOA – Establishes mechanisms and policies used to measure and control the way IT decisions are made and carried out regarding monitoring, definition, and authorization to change existing services within an enterprise SOA Governance is key to SOA adoption and optimal execution 20

SOA Governance in Practice • Guides the development of reusable services – Establishes how services will be designed and developed and how those services will change over time • Establishes agreements between the providers of services and the consumers of those services – Tells consumers what they can expect, and providers what they are obligated to provide • Ensures that everyone is working together and that separate efforts are not contradicting each other • Enacted by a Center of Excellence (COE) – Establishes policies for identification and development of services, SLAs, management of registries – Puts SOA policies into practice, mentors and assists teams with developing services and composite applications 21

SOA Tools Needed to Support Key aspects of SOA Development & Governance through the maturity life cycle Service definition Identification of a service, description of functionality, behavior scoped, design of interfaces Service deployment life cycle Planned – a new service identified and in designed, but not implemented Test – integration, beta, pre-production, production Active – service available for use Deprecated – service still active, but sunset date set Sunsetted – removal of the service from the registry and enterprise service bus Service versioning (version compatibility) Enables users to continue using an existing service, yet allows the service to evolve to meet the needs of users with new requirements Service migration Management technique for planned, periodic migration to new versions of a service Service registries Acts as a listing of available services, with addresses for invoking them. Also helps coordinate versions of a service Service message model Agreement upon a common message format between consumers and providers of services Service Level monitoring and Usage Monitoring of services to ensure compliance with Service Level Agreements and capture of service usage by different clients for chargeback purposes Service ownership Agreement on who in the organization is responsible for enhancements, updates and maintenance of a service Service testing Definition of the approach to and amount of service testing Service security Implementation of controlled access to services, based on security policies and authorization Service Policy Management Definition, enforcement, and audit policies throughout the SOA lifecycle Tool vendors like IBM, BEA, Tibco, Sun, Progress Software, Weblayers, Web. Methods provide for key areas of SOA Development and Governance 22

Organization Alignment 23

Traditional IT Organization Structure Business Unit / P&L Relationship Leader App Dev Groups Business Internal IT App Dev Groups Enterprise Arch. Enterprise IT Security. Central Operations Group (DBA, Network, Sys Admin, Infrastructure Operations and Support IT Infrastructure Senior Level IT Steering Committee PMO No Shared Development Organizations in traditional Business Unit Aligned IT Organization 24

Organizational Challenge for Traditional IT Organizations Source: Tibco Service Oriented Organization Design Best Practices 25

An Approach for a Service Oriented IT Organization Business /IT Hybrid Business Unit / P&L Relationship Leader Business Solutions Development Center of Excellence Business Process Architects Composite Application Developers/Configurators Internal IT SOA Center of Excellence or Integration Competency Center Enterprise Arch. Enterprise IT Security. System Architects, Service Developers IT Infrastructure Central Operations Group (DBA, Network, Sys Admin, Infrastructure Operations and Support) Program Management Office Senior Level IT Steering Committee Shared Horizontal Development Organizations are key to enable SOA 26 Source: Gartner, 2006 © , Tibco Service Oriented Organization Design Best Practices

Key Role Change – Relationship Leader Old Relationship Leader • Sits at the strategy table with business unit leaders and influence their decisions for technology needs with an Business Unit specific View • Builds technology solutions for Business Unit with ownership of Application Development and Technology solution teams • Incented to develop and deliver Applications for Business Unit localized needs • Empowered to build everything for Business Unit with owned Application Development Teams New Relationship Leader • Sits at the strategy table with business unit leaders and influence their decisions for technology needs with an Enterprise View • Incented to Leverage Shared Enterprise Application development backbone to serve the business unit • Influences business partners to rationalize features for their business Unit which with Enterprise reuse applicability • Drives the Enterprise application delivery backbone with Service Levels to manage Business Unit expectations Driving Business Unit technology Strategy with an Enterprise View and holding Shared Organizations Accountable are Key traits of a successful New Relationship Leader 27

Organizational Change Considerations • There is no “one size fits all” prescribed formula for Service Oriented Organizational Change • Radical change needs to be planned and road mapped with the organization’s SOA implementation Maturity • Requires Top Down “Buy In” • Needs to be phased to mitigate risk of cultural “rate of change” absorption by an organization – Pilot Organization in an existing Business Unit or SILO – Conduct Maturity Level Self Assesments and Implement a Continuous Process Improvement Program (CPI) to attain Maturity Goals – Benchmark and measure Success Criteria – Phase Other Business Units into similar model over time One Size does not fit All – Evolve though a journey of Maturity 28

SOA@Equifax • Services Catalog – Credit Monitoring Services • Consumed Externally by Microsoft into their Microsoft Office Accounting 2007 Software Package – Enterprise Verification Service • Customer Verification (includes Registration) • Customer Authentication (Single Sign-On) • Customer Authorization (Role Based Access to Application Resources) – e. Commerce Services for Order Management and Product Provisioning • Consumed by US & UK retail and reseller websites • Consumed by external US regulated Consumer Support websites 29

Questions? Please contact Rashid. Desai@equifax. com if you have any questions 30