In Pursuit of Agility - BPM and SOA within the Boeing Company Ahmad R. Yaghoobi Associate Technical Fellow Enterprise Architect ahmad.r.yaghoobi@boeing.com Randy Worsech Business Architect Randall.a.worsech@boeing.com BOEING is a trademark of Boeing Management Company. Slide 1
Agenda Introduction The Boeing Company Challenges Business Process Management (BPM) Service-Oriented Architecture (SOA) Looking Ahead Questions & Answers Slide 2
In Pursuit of Agility - BPM and SOA within the Boeing Company A journey of a thousand miles must begin with a single step. --Lao-Tsu, The Way of Lao-Tsu Slide 3
Agenda Introduction The Boeing Company Challenges BPM SOA Looking Ahead Questions & Answers Slide 4
The Boeing Company Founded in 1916 Commercial Jetliners, Defense Systems, Satellites and Launch Vehicles, Integrate Large Scale Systems, Financing, and Technology. Customers in more than 90 countries Total revenue in 2009: $68.3 billion 70 percent of commercial airplane revenue historically from customers outside the United States Manufacturing, service and technology partnerships with companies around the world Contracts with 22,000 active suppliers and partners globally Research, design and technology-development centers and programs in multiple countries More than 158,000 Boeing employees in 49 states and 70 countries Slide 5
The Boeing Company Over 240 Programs (8 Commercial) Multiple Sites throughout the world Over 1200 Processes Over 40,000 Process Documents Over 23,000 Process Products Over 14,500 Roles Over 13,500 Systems Lots & lots & lots of Data 100s of thousands Computing Devices Slide 6
Agenda Introduction The Boeing Company Challenges BPM SOA Looking Ahead Slide 7
Challenges Business As-Is Business Environment Existing & New Competition New Business Models Off-sets Workforce To-Be Leverage complexity into a strength Plug-n-Play Production System Move Work to People. Keep our Commitments BPM Functional Orientation Mostly Document Based Inconsistent level of maturity in use of methods and tools Systemic/Integrated Lean Service Ready Easy to Find/Easy to Use Slide 8
Key Difference Between SOA and Traditional Application Design Traditional Application Design Monolithic Language and technology coupled Code level reuse Difficult to reuse different parts independently Complex, lots of dependencies, not flexible to change SOA Approach Modularized business capabilities Implementation and technology agnostic Reuse of business functionality & data Easy to assemble or configure to solve new problems Loosely coupled, promote agility and flexibility Slide 9
Agenda Introduction The Boeing Company Challenges BPM SOA Looking Ahead Questions & Answers Slide 10
Business Process Management Environment Larger Context, Relationships, Influences, etc. Alignment of Business Initiatives and Leadership Alignment of Business and BPM Objectives and Investments Components, Relationships, and Rules Strategy Architecture Governance Enablers Drivers, Culture, etc. Infrastructure Centralized methods, tools, guidelines, services, etc. Program Management Process Management Organizational mechanisms to manage the set of activities to achieve the strategy Process Content (i.e., Components) from discovery thru improvement Slide 11
Business Process Management Environment Compliance Standing Up New Programs (new business models) Escapes Beginning to develop to develop Strategy Maps Strategy Architecture Executive Sponsorship (Lean+, PPPM) Enterprise Leadership (Roadmap) Governance Enablers Program Management Process Management Enterprise and Business Unit Functional Process Councils Policy/Procedure Design and Integration emphasis on New Programs Process Models Process Architecture Meta Model Infrastructure Common Repository Modeling Tools & Guidelines Job Descriptions/Skill Management Community Of Practice Command Media Model-based in Go-Forward Programs Lean in Factory Slide 12
Agenda Introduction The Boeing Company Challenges BPM SOA Looking Ahead Questions & Answers Slide 13
Background Boeing SOA initiative was initiated in 2005 Boeing IT executive leadership team direction is to focus on flexibility and lowering cost by leveraging holistic use of SOA. The purpose is to reduce variation and focus on business value of SOA through establishing a consistent approach for adoption of Service-Orientation across Boeing. SOA concepts are being used for architecting and designing business capabilities and IT solutions Slide 14
SOA s Value to Boeing SOA @ Boeing Enterprise Service Oriented Architecture User Interaction Principles & Standards Approach, Methods &Tools Business Processes & Data Service Management Security Services & Applications Integration Education & Training SOA Infrastructure & Technologies Service Governance 5S Sort, Simplify, Sweep, Standardize, Self-Discipline Slide 15
SOA Deployment Strategies and Tactics Strategy 1: Measure SOA success on reduced cost and increased flexibility Establish Boeing SOA approach leveraging lessons learned from strategic vendors, metrics for measuring SOA success, enterprise-wide best practices, criteria and specification for assessing services. Strategy 2: Educate and knowledge transfer service-orientation Establish foundational and comprehensive education & training for managers and architects (Wikis, blogs, communication forum, workshops, and certified trainings), build hands-on experience, form SOA Center of Excellence (CoE). Strategy 3: Incorporate SOA concepts into the overall governance Create inter-domain Service governance advisory board, establish policies for life-cycle management, governance, provisioning, security policies, enable & enforce governance Strategy 4: Design "To-be" execution architecture Establish "to-be" SOA architecture blueprint and evaluate and recommend other enabling infrastructure capabilities (e.g. Registry/Repository, Enterprise Service Bus, Service Management infrastructure, etc) Strategy 5: Prioritize, mine, and build business services Establish a roadmap to create the service inventory, identify and develop common reusable business services, leverage services available to Boeing from the aerospace and IT industry Slide 16
Establish Common Reusable Solutions Slide 17
Service Registry Repository Service Governance: Oversight Portfolio Management Lifecycle Management Artifact Management Execution Business Processes Enterprise Service Oriented Architecture Standards & Principles Management Integration User Interaction Governance Approach, Methods &Tools Security Education SOA Infrastructure & Technologies 5S Sort, Simplify, Sweep, Standardize, Self-Discipline Services & Applications Service Assets: Services & definitions Service contracts Service profiles (composition relationships, SLA, etc) Service policies (security, governance) Need for Service Repository-Registry: Library of service assets Facilitate service discovery and reuse Support design/build and runtime usages Enable life-cycle management Enable the enforcement of policies and governance Slide 18
Repository Product Considerations Technical Assessment Product Functionality Product Architecture Product Strategy Business Assessment Financial Viability Partnership with other vendors Customer Reference Company Vision & Strategy Cost Assessment License Fee Maintenance Fee Professional Services Costs Training Support Software & Hardware Costs Final Decision: Slide 19
Common Guidelines & Specifications to Enable Integration Service-Orientation principles Service Taxonomy Quality criteria for promotion of Services through each stage of the lifecycle Governance requirements & processes Roles & responsibilities Standards (naming, namespace, security, ) Lifecycle stages from concept to Implementation and beyond Review checkpoints throughout the lifecycle stages Design and run-time policies (e.g. change & version management, lifecycle promotions, security, and ) Metrics and Measurements SOA Platform Architecture Slide 20
Service Registry/Repository Deployment Phased deployment approach: Phase 1 Design-Time & Change-Time Service metadata management Discovery & reuse Lifecycle management Policy definition Phase 2 Run-Time Integration with run-time monitoring service Policy enforcement Slide 21
Lessons Learned (cont.) Organizational Funding the procurement and operational support of the registry repository at the enterprise-level Different functional organizations wanting to deploy their own solution and be in control of their destiny Metrics - measuring the benefits or a plan for measuring the benefits Establishing the SOA CoE early in the process Establishing governance structure and policies prior to deployment Slide 22
Lessons Learned (cont.) Education, Training, and Knowledge Transfer Varying levels of "Education" and "Training of Management & Technical resources Funding issues as well as availability of resources to participate in training events Knowledge Transfer repetition is important and key for successful transfer of knowledge Utilizing both formal and informal means of providing training Slide 23
Lessons Learned Technical & Operational Utilize vendor support and services to configure and customize the product Get hands on experience with the product at the earliest possible time Evaluate the vendor s preferred hardware environment and try to use it exceptions mean less testing done in that situation Establish a great relationship with key personnel in the vendor s support technical and aftermarket sales support teams it s invaluable when needed Join a community of users, if there s one available and if not, start one learning from others and knowing you are not alone in a problem is of great help Be ready to apply fixes and patches: every product will have them, so get to know the best way to procure them (i.e. accounts, web sites, downloads) how to do installations of fixes for your specific environment (e.g. clustered servers) make sure you get immediate visibility into new fixes, etc.) Slide 24
Agenda Introduction The Boeing Company Challenges BPM SOA Looking Ahead Questions & Answers Slide 25
Looking Ahead BPM Business-centered design of BPM efforts. Transition from a Document to Model Based Paradigm User-centered design at the Delivery Point of content. Incorporate Collaboration, Knowledge Management, Analytics to help connect people to content and people to people in the context of one s assignments/processes. SOA (Registry Repository) Integration with BPM environment Integration with IT infrastructure and services Ability to model data at business, IT architecture, and implementation level what if analysis from BPM all the way to Service & Application Stronger lifecycle management and flexible notification and subscription model Slide 26
References Thomas Erl What is SOA? SOA Principles SOA Glossary SOA Magazine SOA Methodology Boeing Internal Workshops with IBM, Microsoft, and Oracle Burton Group Forrester Gartner Slide 27
QUESTIONS? Ahmad Yaghoobi 425-830-1032 ahmad.r.yaghoobi@boeing.com Randy Worsech 425-736-9218 Randall.a.worsech@boeing.com Slide 28
Imperatives/Principles Behind Service Orientation Business and IT goals Modularity Business Agility Primary service design principles Service Loose Coupling Minimize dependencies Service Abstraction Minimize availability of meta information Service Composability Maximize composability Supporting service design principles Standardized Service Contract Implement a standardized contract Service Reusability Implement generic and reusable logic and contract Service Autonomy Implement independent functional boundary and runtime environment Service Discoverability Service Statelessness Implement communicative meta information Implement adaptive and state management-free logic Slide 29
Example - Service Design Principles, Rationale & Implication Slide 30
Use Service Quality Attributes Criteria During the Design Process 15 criteria to assess service quality Use quality assessment criteria during compliance reviews or checkpoints Use quality criteria to assess deployable services prior to their inclusion in the enterprise registry/repository Business Value Metrics Business Domain Models Business Goals/ Requirements Service Design Principles Service Quality Assessment Criteria Best Practices/ Guidelines Standards Patterns Quality Criteria Topics Service Design Adhere to service design principles Follow best practices and guidelines Follow established patterns if applicable Compliance with stated standards Design for security Business Values Capture business value metrics Making sure that services are derived from business process and are solving business priorities Slide 31
Example - Service Quality Criteria ID Criteria Mandatory/C onditional Gate Review or Checkpoint Metrics for Assessment Criteria 1 Statement: A service shall have a well defined and standard service contract. Service contract shall include: - Standard data definition - Standardized interface with well defined inputs and/or outputs for each service capability - Standard policy definitions For web services implementation, the definition shall follow WSDL, XML Schema, and WS-Policy definitions. Mandatory AD&S - CDR Met - Service Contract contains standard data definition, standardized interface definition, and standard policy definition. For web services implementation, the definition follows WSDL, XML Schema, and WS-Policy definitions. Rationale: A standard service contract increases discovery and reuse of the service. Standard service definition will result in commonality of data definition and simplification of integrations where needed. Implication: Service designers/developers are bound by established contract standards. Following established contract standards will ensure that services meet consumer expectations; therefore, reducing the potential for issues related to performance, reliability, etc. Slide 32
Adhere To Enterprise Guideline for Service Definition and Naming Service Naming Standards Utility-Centric Services Rules Utility-centric services need to be labeled according to a specific processing context, agnostic in terms of any particular solution environment verbs are commonly used. For example, a utility service might be named Notify or Log. Entity-Centric Services Rules Labeling of entity-centric business services is often predetermined by the entity name. Entity-centric services are commonly named using nouns. For example, a service may simply be named Invoice, Customer, or Employer. Task-Centric Services Rules Task-centric services should be named using the VerbNoun form. For example, a task-centric service may be called GetProfile, if that accurately represents the task's scope. Service Definition Service Name - Business name of the service Purpose Description (Short) - One sentence description of the service context and purpose Purpose Description (Detailed) - A full explanation of the service context and its functional boundary with as many details as necessary Service Model - Entity, Utility, Task, Orchestrated Task, or a custom variation QoS Requirements - This field captures various anticipated quality of service requirements, characteristics, or limitations that affect the service as a whole. Capabilities - The profile should document capabilities that exist and are in development, as well as those that are only planned and tentatively defined. Version - The version number of the service currently being documented. Status - The development status of the service (or service version). Custodian - Details on how to reach the official service custodian or owner. Slide 33
Metrics & Measurements Revenue Per Service Service-oriented Return On Investment (ROI) Number of New Services Generated and Used as a Percentage of Total Services Mean Time to Service Development Mean Time to Service Change Service Reliability Service Reuse Service Availability Slide 34