“There are no guarantees that you’ll actually do SOA right.  On the contrary, it’s actually quite easy to build a bad SOA -- an architecture that may technically be Service-oriented, but will not solve the business problems that led you to make an architectural change in the first place.” -Jason Bloomberg, Zapthink, 3/1/2005

Experience building and implementing Services-Oriented Architectures clearly shows that SOA implementation evolves in phases to meet business needs.  Each SOA implementation phase brings a new set of management issues and challenges.

Roadmap to SOA Success: A Manager's Guide shows how to prepare for each SOA implementation phase.  This 2-day Manager’s Guide identifies & explains what the management team responsible for SOA application and architecture projects must know and must do to get ready for the increasingly complex SOA projects that they undertake.

Roadmap to SOA Success: A Manager's Guide focuses on planning how to address the methodology and sociology issues imposed by SOA.  This comprehensive and no-frills Manager’s Guide will help all SOA team members, whether from the Business Areas or IT, prepare to tackle the management questions that all SOA teams must address…

• What do you need to know?

• What decisions do you need to make?

• What issues and challenges will you face?

• What options will you have?

• What are the 6 or 8 or 10 things that can ruin your entire day?

Roadmap to SOA Success: A Manager's Guide uses a business-scenario and multi-dimensional approach to introduce, explain and explore the methods, practices, culture and structures that together characterize “SOA Management.”

• What business scenarios drive SOA evolution?

• What business and IT policies and processes do you need to put into place or change at each SOA implementation phase?

• What organizational structures, alliances, partnerships and cultures do you need to put into place or change at each SOA phase?

• How do you evolve “SOA Management” as the complexity of your SOA environment grows to span first internal, and then external, political boundaries?

Who Should Attend

• Project Managers…The Business Area and IT leaders who plan, direct and have responsibility for the SOA infrastructure and application projects

• Business Area Leaders…The SOA champions who define requirements and provide justification and funding

• IT Leaders…The CIOs and Directors who plan application architectures & strategies and allocate technical resources

• CTOs & Architects…The SOA infrastructure planners who define and design the SOA environment and SOA composite application structures

• EAI & Middleware teams…The SOA “plumbers” who build and implement the SOA technical environment and SOA composite application structures

What You Will Learn

• Where are you on the SOA roadmap…SOA project by SOA project?

• What do you need to do to prepare for SOA projects at each roadmap phase?

• How do you combine business process & IT architecture approaches to achieve SOA success?

• What “players” participate in planning & developing a SOA?

• What roles must each player perform to achieve SOA success?

• How do you identify & define the SOA champions - IT & Business Areas?

• What are the top SOA inhibitors? Success factors?

• How do you achieve SOA project success? … Think Enterprise/Work Local

Seminar Outline

Part 1: Building Simple SOAs…Legacy Wrappers & Data Manifolds

• Progressive Case Study: Hospital Example

  • Many complex relationships

  • 1st functional requirement: Using a Web Service to reserve a hospital room

• Project Success Factors: All SOA Projects

  • Define business processes…Need same understanding that we have of data

  • Start with architecture

• The First SOA Project: Success Guidelines

  • Choose a simple, but important business process

  • Restrict scope to single service

  • Set project goals

• Management issues

  • Exposure to SOA benefits and costs

  • SOA as a disruptive technology

  • Who takes the lead? Business Area/IT Role Inversion & Governance Issues

  • Organizational issues: How will SOA disrupt my organizational hierarchy?

• Technical Issues Business Managers Must Deal With

  • Models for SOA: Data model, Process model, Semantic model

    • Service: Relationship to business process

    • Service opacity: Service substitution, change implementation, flexibility

    • The interface: Business focus, granularity & the services facade

  • SOA wrapping or new applications: When wrapping is (and isn’t) a good tactic

  • QoS (Quality of Service) Issues: Security, Policy, Metadata, Discovery

  • Specifications: Open, International, Non-Proprietary via OASIS, W3C & IETF

• Vendor issues

  • Are you a single vendor or a multi-vendor shop?

  • Don’t try to use all their capabilities

  • Be wary of lock-in

• Project Evaluation

  • Did the project meet schedule, cost and purpose goals?

  • Did it accomplish the chosen business process?

  • Can it be used as an example of what a SOA can accomplish?

Part 2: Advanced SOA…Inter-Division Workflow & Shared Services

• Hospital Example Revisited

  • Increasing complexity : Multiple services & crossing political boundaries

  • Increasing sophistication: Composite services & Choreography/Orchestration

• Complex SOA Project Initiation

  • Build on Simple SOA success

  • Obtain Management commitment

  • Education & Training: Learn how to design, implement and support a SOA

• Management Issues

  • Differences from legacy & single service SOA

  • Crossing Political Boundaries

  • The need for effective Change Preparation & Change Management

  • Services recursive and portable

• Technical Issues that Managers Must Deal With

  • Enterprise view of Data model, Process model & Semantic model

  • Dynamic services: Discovery and advertisement, opacity, flexibility

  • Discovery across business units: UDDI verses informal methods

  • Long lived services: Asynchronous, Compensation, Intermediate data transfer

  • Advanced policy definition: Governance hierarchy & policy subsuming semantics

  • Importance and difficulty of fault recovery: ACID & Compensation

  • Orchestration via Business Process Execution Language (BPEL)

  • Coordination service: Who controls it? How does it interact with orchestration?

  • Potential constraints of your vendor’s products

  • Critical importance of the middle-tier: Enterprise Service Bus Pattern

Part 3: Cross-Enterprise B2B SOA

• Hospital Example Revisited: Getting a medial specialist

• Business Scenario: Moving beyond the Corporation

  • Business Relationships: Low intensity vs. Casual vs. Permanent B2B

  • SOA ROI realized

  • Towards the virtual corporation

  • Do what you do best & using the expertise of partners

• Management Issues - New levels of Sophistication

  • NOW who’s in charge?

  • Beyond the technology: Contracts, Legal responsibilities, Establishing trust

  • SOA contracts

  • Exchange of meta data

  • Legal issues

• Technical Issues that Managers Must Deal With - New levels of Complexity

  • Changing services: Service opacity, Addressing policy, Security, On-the-fly contracts

  • Increased importance of semantics: Vertical & Cross-Vertical Vocabularies

  • Federated security: Legal responsibility, Trusted third party, Negotiating responsibility

  • Defining a multi-ownership SOA

  • Discovery and advertising: Failure of UDDI & using a replacement registry

  • Dynamic services: Ease of change & Policy based change of partners

  • Transactions: Context, Addressing, Policy

  • Human management: Strategic planning, Tactical decisions, Knowledge worker skills

• Dynamic Multi-Company Business Processes… SOA’s True Potential

  • Root service

  • Customer facing service

  • Designing an end-to-end business process

  • Asynchronous messaging

  • Need for strong semantic metadata

  • Flexible services: Business requirements trump technical prerogatives

  • Dynamic advertising

  • Negotiation on the fly

  • Just in time services

  • Service management: Preplanned vs. Dynamic vs. Policy based

Part 4: SOA of the Future…On-demand, Dynamic & Adaptive

• Just in time shared services

  • Grid computing

  • Utility computing

• Services for hire when needed

  • Discover and use

  • Automated payment for use

• Self managed systems

  • High semantic content

  • Automatic error recovery

  • Self defining semantic policy