In Pursuit of Agility - Software AG Registry... · Slide 33 Engineering, Operations & Technology |...

BOEING is a trademark of Boeing Management Company.Copyright © 2010 Boeing. All rights reserved.

In Pursuit of Agility -

BPM and SOA within the Boeing Company

Ahmad R. Yaghoobi

Associate Technical FellowEnterprise [email protected]

Randy WorsechBusiness [email protected]

Engineering, Operations & Technology | Information Technology

Copyright © 2010 Boeing. All rights reserved.

Agenda

• Introduction

• The Boeing Company

• Challenges

• Business Process Management (BPM)

• Service-Oriented Architecture (SOA)

• Looking Ahead

• Questions & Answers



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



Agenda

• Introduction


• Challenges

• BPM

• SOA

• Looking Ahead




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 partnersglobally

• Research, design and technology-development centers and programs in multiple countries

• More than 158,000 Boeing employees in 49 states and 70 countries



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



Agenda

• Introduction


• Challenges

• BPM

• SOA

• Looking Ahead



Challenges

• Systemic/Integrated• Lean• Service Ready• Easy to Find/Easy to Use

• Functional Orientation• Mostly Document Based• Inconsistent level of maturity

in use of methods and tools

BPM

• Leverage complexity into a strength

• Plug-n-Play Production System

• Move Work to People.• Keep our Commitments

• Business Environment• Existing & New Competition• New Business Models• Off-sets• Workforce

Business

To-BeAs-Is



Key Difference Between SOA and Traditional Application Design

Loosely coupled, promote agility and flexibility

Complex, lots of dependencies, not flexible to change

Easy to assemble or configure to solve new problems

Difficult to reuse different parts independently

Reuse of business functionality & data

Code level reuse

Implementation and technology agnostic

Language and technology coupled

Modularized business capabilitiesMonolithic

SOA ApproachTraditional Application Design



Agenda

• Introduction


• Challenges

• BPM

• SOA

• Looking Ahead




Business Process Management

Environment

Enablers

Governance

Infrastructure

StrategyProgram

Management

ArchitectureProcess

Management

Alignment of Business

Initiatives and Leadership

Alignment of Business and BPM

Objectives and

Investments

Organizational

mechanisms to

manage the set of activities to achieve

the strategy

Components,

Relationships, and

Rules

Process Content

(i.e., Components) –

from discovery thru

improvement

Centralized methods, tools,

guidelines, services, etc.

Drivers, Culture, etc.

Larger Context,

Relationships, Influences, etc.



Business Process Management

Environment

Enablers

Governance

Infrastructure

StrategyProgram

Management

ArchitectureProcess

Management

• Compliance• Standing Up New Programs

(new business models)• Escapes

• Executive Sponsorship (Lean+, PPPM)• Enterprise Leadership (Roadmap)

• Enterprise and Business Unit Functional Process Councils

• Policy/Procedure• Design and

Integration emphasis on New Programs

• Command Media• Model-based in

Go-Forward Programs

• Lean in Factory

• Beginning to develop to develop Strategy Maps

• Process Models• Process

Architecture• Meta Model

• Common Repository• Modeling Tools & Guidelines• Job Descriptions/Skill Management• Community Of Practice



Agenda

• Introduction


• Challenges

• BPM

• SOA

• Looking Ahead




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



SOA’s Value to Boeing

Service Governance

Service

Management

Integration

User Interaction

Education &

Training

SOA Infrastructure & Technologies

Approach,

Methods &Tools

Security

Enterprise Service Oriented Architecture

Principles &

Standards

Business

Processes

&

Data

5S

Sort, Simplify, Sweep, Standardize, Self-Discipline

Services

&Applications

SOA @ Boeing



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



Establish Common Reusable Solutions



Governance

Management

Integration

User Interaction

Education

SOA Infrastructure & Technologies

Approach,

Methods

&Tools

Security

Enterprise Service Oriented Architecture

Standards &

Principles

Business

Processes

5S

Sort, Simplify, Sweep, Standardize, Self-Discipline

Services

&

Applications

Service Registry Repository

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

Service Governance:

► Oversight► Portfolio Management► Lifecycle Management► Artifact Management► Execution



Repository Product Considerations

• License Fee

• Maintenance Fee

• Professional Services Costs• Training

• Support Software & Hardware Costs

Cost Assessment

Final Decision:

• Financial Viability• Partnership with other vendors

• Customer Reference

• Company Vision & Strategy

Business Assessment

• Product Functionality

• Product Architecture

• Product Strategy

Technical Assessment



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



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

– …



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



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



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



Agenda

• Introduction


• Challenges

• BPM

• SOA

• Looking Ahead




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



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



QUESTIONS?Ahmad Yaghoobi

[email protected]

Randy Worsech425-736-9218

[email protected]



Imperatives/Principles Behind Service Orientation

Service Loose Coupling

Service Abstraction

Service Composability

Standardized Service Contract

Service Reusability

Service Autonomy

Service Statelessness

Service Discoverability

Modularity Business Agility

Minimize dependencies Minimize availability of meta information

Maximize composability

Implement a standardized contract

Implement generic and reusable logic and contract

Implement independent functional boundary and

runtime environment

Implement adaptive and state management-free

logic

Implement communicative meta information

Primary service design

principles

Supporting service design

principles

Business and IT goals



Example - Service Design Principles, Rationale & Implication



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

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

Service Quality

Assessment Criteria

Service Design

Principles

Best Practices/Guidelines

Standards

Business Value Metrics

Business Goals/

Requirements

Business Domain Models

Patterns



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.

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.

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.



Adhere To Enterprise Guideline for Service Definition and Naming

Service Naming Standards

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

Service Definition

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.

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 should be named using the VerbNounform. For example, a task-centric service may be called GetProfile, if that accurately represents the task's scope.

Entity-Centric Services Rules

Task-Centric Services Rules

Utility-Centric Services Rules



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

In Pursuit of Agility - Software AG Registry... · Slide 33 Engineering, Operations & Technology |...

Documents

Transcript of In Pursuit of Agility - Software AG Registry... · Slide 33 Engineering, Operations & Technology |...