SOA Governance Methodologies

Transcription

1 Agenda SOA Governance Methodologies Brent Carlson, Founder and CTO LogicLibrary, Inc. Agenda Governance is Essential to SOA Trying to implement SOA without governance is like trying to build a house without blueprints and building codes: Substandard implementations Redundant implementations Parts that just don t fit together properly Net result: A Bunch Of (ABOS) rather than SOA Project-centric services implemented inconsistently and with no thought towards the broader needs of the enterprise Why Service Lifecycle Governance? The SOA Governance Matrix SOA is not sequential, it is iterative and fluid Consequence: The traditional lines between design-time and runtime environments have blurred and overlapped For enterprises to successfully migrate to an SOA requires: a firm understanding of and access to, legacy assets and artifacts that span the SDLC Mid-level architectural governance that ties business priorities and portfolio-level decisions to project-specific service dev/consumption activities Effective coordination between service producers and consumers, allowing services to be expressed in both role-centric (human) as well as machine-centric (automation and integration) contexts Design-time vs. runtime governance Design-time governance platform characteristics: Guides production and consumption of services from initial inception to selection for use in end-user applications Involves broad set of asset types components, legacy APIs, design patterns, etc. beyond services and schemas Must present information to multiple roles in their preferred views browser, IDE integration, reports, etc. Must integrate with heterogeneous development tools SCM systems, document management systems, defect tracking systems, etc.

2 The SOA Governance Matrix (cont.) Runtime governance platform characteristics: Deals with how a service behaves when called, how various policies (e.g., security) are enforced, how behavior is validated, and how services are replaced and retired Dynamically supports runtime access and behavior of deployed services high throughput and responsiveness required Focused on service interfaces/implementations and deployment policy configurations limited information set Minimal end user interaction required Design-time Governance Drilldown Portfolio Governance what initiatives, projects, and deliverables (both services and applications consuming those services) get funded and the tracking of those projects' progress against funding and timeline objectives. Architectural governance ensuring that the services and applications developed under SOA initiatives conform to the organization's business and technical architectures and best practices. SDLC governance the day-in day-out application of SDLC best practices (e.g., unit test before code promotion, peer review of code changes, establish an SCM system with code promotion levels) when developing services. Pulling the Governance Matrix Together Portfolio Governance Service Lifecycle Rep/Reg Architectural provides SOA Governance Governance anchor/hub Runtime Governance SDLC Governance Agenda Governance Effectiveness Depends Upon Connecting: Governance -> IT Governance -> Arch Governance -> IT Project Mgmt Architectural Working Contexts Imperatives IT Imperatives And Roadblocks BPM Tools Requirements BUSINESS DRIVERS Technical Requirements Portfolio Management Tools Operational Governance Tools IT GOVERNANCE IT Governance Processes, Budgeting, Oversight, PMO, Projects/Initiatives Prioritization INITIATIVES Regulatory Compliance Time to Market SOA Etc. ARCH ORG. MODEL IT Architecture Disciplines, Practices, Solution Activities, Roles EAM Tools SDA Reg/Rep IDEs SDLC point tools ARCH GOVERNANCE Arch Governance Model, Policies Organization, Processes, IT Dev Project Mgmt / SDA Development SDAs need to be managed simultaneously from three primary working contexts Application/integration context: core patterns and reference implementations to be used in assembling enterprise application capabilities to support the business architecture Technical context: underlying technology stacks to be used in implementing and deploying enterprise applications context: business process modeling -> functional service and component identification and normalization These contexts are best described with a combination of models and taxonomy specs

3 Application/Integration Context Technical Context:.NET Application Amount of application Application- Specific Layer Domain- Dependent Layer Intel App#1 Intel App#2 Microprocessor Citicorp App#1 Citicorp App#2 Financial Allstate App#1 Allstate App#2 Insurance 100% up to 85% CurrEx Technical CurrEx Domain- Independent Layer General-purpose utilities, APIs, Abstract Data Types, System Service 15-20% 0% * Technical Context: J2EE Context * Intercepting Filter Core J2EE Pattern CurrEx Axis Apache Open Source For Web services Technical context is only part of the story It s just as important to align your reusable asset development work with your company s business context What is a business context? The overarching business requirements driving development projects New component/service development, application integration, new/reworked application development In other words: What business processes really matter to our company? And what business functions are demanded by those business processes? Context Example: e-commerce Agenda Shipping System ShippingStatus ShippingMethod Management OrderMaintanance ShippingRequest Quote Import Order System SalesTaxCalculation Reporting Analytical System SalesTaxCalculator Payments CreditCard Handler Verification Financial Accounting Sales Transaction FinancialReporting Prediction Currency Exchange Sy stem Conversion CurrencyMaintanance

4 ShippingStatus Reporting Prediction Shipping System ShippingMethod Management Analytical System CurrencyMaintanance OrderMaintanance ShippingRequest Quote Import Currency Exchange Sy stem Order System SalesTaxCalculation SalesTaxCalculator Conversion Sales Transaction Payments CreditCard Handler Financial Accounting Verification FinancialReporting Production Best Practice: Pragmatic Service Modeling/Definition within an SOA cannot be developed in a bottom-up, ad-hoc manner Become YALOT (yet another layer of technology) More spaghetti code of a different form But services also cannot be defined solely in a top-down manner, which leads to either: Analysis paralysis: continual refinement of a model hoping to reach perfection (which never comes), or Big-Bang projects: trying to implement everything at once, usually with disastrous consequences Balancing Top-Down and Bottom-Up Service Definition Objective: striking a pragmatic balance between where the business is and where it needs to go Where the business is: Current set of strategic applications Usually implemented on different technologies Often locked into rigid business processes Where the business needs to go: Loosely-coupled business services Exposed via a common technical infrastructure Supporting flexible business process definition Top-Down Analysis Bottom-up Analysis Establish a coarsegrained business model Driven by key business processes Laying out a roadmap for prioritized service definition and development Use the coarse-grained, top-down business model to prioritize service development Formalize service definition roadmap for prioritized services Evaluate prioritized business project needs against this roadmap Assess current set of production applications to understand which aspects of those applications are candidates to support required services Combine and re-factor application capabilities by implementing adapters Adapters provide necessary glue and compensation logic Production Best Practice: Review Points and Teams Recommended Review Points Best practice recommendation: virtual/matrixed SDA architectural review team Team members: Team leader dedicated to SDA reuse program Matrixed team members drawn from project teams Lead designer/developer skills required 10%-20% job responsibility Team objectives/responsibilities: Identify candidate reusable SDAs active discovery Review proposed reusable SDAs asset hardening Adherence to architecture Necessary functionality implemented and supported Mandatory artifacts provided Publish approved SDAs into SDA library for consumption Recommend future resource allocation for key reusable SDAs Expanded funding for key SDAs Transfer of key SDAs to common SDA support group At a minimum, organizations should review services under development at these points in the SDLC: Requirements complete: all business requirements documented and initial service definition specified (ideally as WSDL), allowing reviewers to validate service against business context Design complete: Implementation approach defined with sufficient documentation (e.g., UML design models completed, relevant legacy APIs identified) to allow reviewers to validate design against technical and application/integration contexts Implementation complete: Service implemented and deployed in a test environment, with sufficient supporting documentation (e.g., sample client code, automated test cases, usage guide) to enable a potential consumer to understand the service Other review points may also be appropriate based on organizational needs and objectives

5 Requirements Complete Production Governance Example End Inform Submitter of failure Notify Architects for tech review Inform Submitter of rejection SDA Submitted by Lead Designer Asset Owner (gatekeeper) Confirms SDA meets Minimum compliance stds no no Approve? yes parallel Approve? Notify Analysts for functional review yes Auto-publish SDA Production Best Practice: Managing as Products Service producers need to treat their services as products Regular and well-defined release cycle Often enough to meet consumer needs on a timely basis But not so often as to churn existing consumers Backward compatibility wherever possible Give existing consumers time to migrate off of deprecated operations n-1 version support at a minimum Requirements gathering mechanisms from current and potential customers Consider establishing a product manager role that manages the aggregate set of business requirements for the service and works to prioritize requirements with its current and potential consumers Service as Product Impacts on SDLC Tools Version Control Repository Establish a baseline whenever a new version of a service is released into production must be able to simultaneously maintain production service while developing next version of that service Requirements Management / Defect Tracking Manage your requirements and defects at a version basis both originating version and target version for resolution SDA Management Maintain all valid versions of a service within your SDA library Under Development available for requirements gathering and application development team planning purposes Production mainline version for use in new development Retired still in use by existing apps but not allowed for use by new apps Obsolete all apps should be migrated off this version; version metadata is maintained for traceability / audit purposes only Distribution Best Practice: Integrated SDA Registry/Repository Ad-hoc distribution schemes are sufficient for two or three services used by a small community, but don t scale Spreadsheets and static websites get out of date Call the architect turns the architect into an information bottleneck UDDI registries are not suited for development use Limited service metadata Often difficult search UI Not well suited to managing other SDA types Best practice recommendation: SDA reg/rep (e.g., Logidex) to distribute assets Important SDA Reg/Rep Features Consider these important features when evaluating SDA registry/repositories: Governed and configurable asset metadata assembly and validation Standardized metadata definition Per-asset-type metadata validation and enforcement Configurable (manual vs. automatic) asset publication Newly defined SDAs Updated SDAs New versions of existing SDAs Passive and active distribution modes User-based SDA subscriptions Automated search notifications during asset creation/update Multiple search modes Multiple UI options Thin-client Deep IDE integration API-based integration Example: Logidex Deep IDE Integration Standalone Or tightly integrated with: IBM RAD, WSAD Eclipse Microsoft Visual Studio SAP NetWeaver Borland JBuilder BEA Workshop Compuware Optimal J Keeping users in their own development environment improves their productivity and increases effective usage of the SDA reg/rep

6 Consumption Best Practice: Project-based SDA Usage Tracking Best practice recommendation: named user consumption Project-scoped interactions/tracking Enables reporting and management of asset consumption SDA acquisition Configurable approval signoffs based on organization s process Project and asset-specific collaboration Discussion forums Persistent searches Asset notifications Access alternative: anonymous consumption Suitable for lightweight/casual users Read-only interaction with SDA reg/rep Restricted tracking and collaboration activities Financial Incentives for SOA: ROI Metrics Consumption-side traceability enables SOA ROI calculation Initial survey results of SOA ROI as compared with reusable components Survey created and interpreted by LogicLibrary and Dr. Jeffrey Poulin, author of Measuring Software Reuse Compared to component reuse, SOA projects: Survey Results from LL customers and summarized in SOA ROI Whitepaper The ROI of SOA Relative to Traditional Component Reuse by Dr. Jeffrey Poulin and Alan Himler, August 2006 whitepaper available at Example Report: Repository Savings Logidex Case Study: Needs Software asset reuse initiative for integration projects Integrated tool to enable and encourage the reuse process Solution Implemented Logidex for a consolidated metadata asset catalog Controlled submission, review, approval cycle Proven Success Registered reuse has produced an estimated cost savings of $13.4 M over 18 months Increased use/reuse of software assets with ability to track and report reuse 46 AD teams are active in Logidex across the organization 250 users defined 128 Institutional projects are defined 266 assets are registered 321 reuses have been acquired in the library Logidex Case Study: Health Care Provider Needs Software asset reuse initiative for SOA projects Solution Implemented Logidex for a consolidated metadata asset catalog Logidex as a central repository for reuse and architectural governance Proven Success Agenda Increased reuse of assets. Significant, immediate time and cost savings ROI of 264% in less than 6 months Established Reuse Council Implementation of reuse activity in all ASM divisions.

7 Logidex and Service Lifecycle Governance No one product or suite can adequately address all perspectives of Service Lifecycle Governance With the market leading design-time governance solution, LogicLibrary s strategy is to integrate with key best of breed SOA products to deliver a service lifecycle governance solution These product integrations include: PPM (HP PPM, IBM RPM, CA Clarity, etc.) Run-time governance (HP SOA Systinet, IBM WSRR, other UDDI registries) Develop tools and platforms (IBM ClearCase, Serena Dimensions, Microsoft Team Foundation Server, CVS, etc.) Quality management (HP SOA Systinet Policy Manager, MindReef SOAPScope, WebLayers, etc.) LogicLibrary s strategy is to partner with leading vendors in the SOA Governance space to execute this vision The Service Governance Matrix Portfolio Governance Architectural Governance SDLC Governance Runtime Governance Mapping Design-time Logidex s Governance Asset to SOA Activities Relationship Visualization aids Portfolio Governance decision makers in IT Transformation what initiatives, understanding projects, deliverables upstream/downstream (both services and applications impact consuming to proposed those services) get funded changes and the tracking Guiding the organization through the decision making process to establish a prioritized series of optimization steps to improve to IT of those projects' progress against connectedness Logidex s SOA patentpending is the preferred funding and timeline objectives. approach to such Smart optimization Controls Logidex s patented Architectural governance reference models automates and makes SOA Core Architecture auditable and SOA Process ensuring that the graphically services and portray applications architectural developed under guidance SOA Identification governance of core services activities required by the business (top-down initiatives conform to the architectural Logidex s guidance) plug-in based organization's business and technical deep IDE integration Logidex reflects portfolio Prioritization of formalized service architectures and best practices. delivers services to prioritization decisions via definition and development based on consumers in their asset and project creation portfolio analysis (bottom-up Logidex SOA Governance preferred working and management prioritization) environment Logidex feeds results of SDLC governance SOA Governance, Reuse, and SOA activities to C-level Implementation the day-in decision day-out makers application via built-in of SDLC best practices reports and (e.g., planned unit test before code integration promotion, with peer PPM review tools of code changes, (e.g., establish RPM) an SCM system with code promotion levels) when developing services. Applying architectural guidance through defined SDLC review checkpoints, ensuring services are both correct and complete, and exposing produced services to consumers for reuse. Logidex, SCM and Run-time Registry Integration Enables Service Lifecycle Governance Smart Controls process manages assetlevel promotion gov processes, validating services against Policy Manager ASAA auto creates/updates asset based on XML-driven CC/CQ parsing and navigation ASAA invoked via trigger resulting from CC creation or promotion of a baseline (i.e., service is promoted) Design-time Smart Controls design-time governance Logidex Design-time SOA reg/rep SDAs Logidex ASAA SCM Systems: IBM ClearCase/ClearQuest Serena Dimensions, PVCS Microsoft VSS, TFVC CVS, Subversion CA Harvest Smart Controls automatically publishes service to Reg/Rep QOS updates fed via run-time reg/rep events into Smart Controls for design-time processing Run-time Repository Registry Policy Manager Data Store QOS Feeds from WSM, ESB, etc. What is Logidex SOA FastPath? What is Logidex SOA FastPath? SOA FastPath leverages the knowledge that LogicLibrary Professional has acquired over multiple years of guiding organizations with their SOA deployments s can immediately implement an out-of-the box SOA solution with predefined governance policies, user roles and asset metadata A special SOA FastPath appliance can delivered to further accelerate the deployment SOA FastPath contains the following Logidex templates and configurations to support an SOA project: Asset Types Sharing Assets / Library Structure Governance Organizational Structure Users and Roles Reference Models

8 What does Logidex SOA FastPath Contain? SOA FastPath includes: (25) Logidex named user licenses (1) Logidex server license Preloaded Sun Core J2EE Patterns Preloaded Microsoft.NET Framework, Solution Patterns and Library Preconfigured production and consumption governance Preconfigured user roles and profiles Preloaded SOA ROI reports based on Dr. Jeffrey Poulin s industry-leading reuse ROI metrics research Logidex FastPath Governance Example Elaine: Architect Ron: Repository Administrator Alice: Architect Alex: ACE, Asset Owner Tom: Technical Lead Bob: Analyst Consumption Organization (i.e., Application Development) Delivery Channels Customer Applications Customer On-line Shopping V2R2 ABC IT Peter: Project Manager, ACE Ann: Project Participant Common Elaine: Architect Technology Office Architecture Elaine: ACE, Technical Lead Logidex FastPath Governance Example Production Organization (i.e., Service Development) Logidex FastPath Governance Example Production Governance Elaine: Architect Ron: Repository Administrator ABC IT Elaine: Architect Ron: Repository Administrator ABC IT Elaine: Architect Elaine: Architect Alice: Architect Delivery Channels Technology Office Alice: Architect Delivery Channels Technology Office Alex: ACE, Asset Owner Tom: Technical Lead Bob: Analyst Customer Applications Common Architecture Alex: ACE, Asset Owner Tom: Technical Lead Bob: Analyst Customer Applications Common Architecture Customer On-line Shopping V2R2 Elaine: ACE, Technical Lead Customer On-line Shopping V2R2 Elaine: ACE, Technical Lead Peter: Project Manager, ACE Ann: Project Participant Peter: Project Manager, ACE Ann: Project Participant Logidex FastPath Governance Example Elaine: Architect Ron: Repository Administrator Alice: Architect Alex: ACE, Asset Owner Tom: Technical Lead Bob: Analyst Delivery Channels Customer Applications Consumption Governance Customer On-line Shopping V2R2 ABC IT Peter: Project Manager, ACE Ann: Project Participant Common Elaine: Architect Technology Office Architecture Elaine: ACE, Technical Lead Summary Governance is essential to keep your SOA from becoming ABOS Architectural governance is the glue that ties portfolio decisions to service and application development Defining and enforcing architectural contexts keeps your SOA in order Asset management and governance tools (like Logidex) enable your SOA initiative to scale