1. SOA From a Business Centric Perspective
Vladimir Ergovic
Software IT Architect
IBM CEMAAS South East Area

2. Agenda IBM’s view of SOA SOA entry points Business services Summary
the business alignment and enterprise wide trend
SOA entry points
governance and how it impacts many aspects of an organization
Methodologies and products
CBM, SOMA, RUP, GS Method, RUP4SOA
Business services
WebSphere Business Services Fabric
Summary
current and future industry trends

3. Key Takeaways
SOA is one of IBM’s long term strategies to enable innovation that matters
Continuing to deliver SOA centric offerings
IBM’s view of SOA is business centric
How to get started is crucial
People, process and information
Reuse & connectivity is critical
Entry points are accelerated by SOA Foundation products and business insight
new and enhanced products
new service offerings
90,000 GBS skills trained
Best practice customer examples
Enhancements to SOA Standards Roadmap
Many more…
SOA Governance is a key to success
SOA impacts Business and IT…
But that doesn’t mean everything is SOA. This presentation is about how IBM enables customers to take an SOA approach to solving problems across business domains.

4. The business alignment and enterprise wide trend projects snapshot
Web Services Interoperability across Heterogeneous Environments
Service Components
Simplified Composition and Implementation of Services and Data
Business Processes
Business Process Modeling & Management
Enterprise Governance
Aligning business strategy
ESB Mediation of services
Security Federation for Telco Partner Integration
Enterprise SOA Transformation including setup of SOA Governance Organization (large insurance company)
Enterprise Wide SOA Portfolio Management for automotive industry
Container Shipping Company transformation
Airport Ramp Control
Trucks Customer Order process
Electronic Industry Contracts management
Telco “Meet me Service”
Service Registry & Repository
Components for Car Dealers
Service Portfolio for Heavy Industry
Business
Technology
2003
2007
Increase the speed of the decision making
Improve collaboration
Reduce administrative time
Deploy end-to-end business process
Enable Business Flexibility
Easy to enhance reconfigure and maintain
Able to be deployed in incremental steps

5. IBM's View of SOA: Business Centric Built on SOA Lifecycle
Enable human and process interaction with consistent levels of service
Deliver trusted information in business context to enable innovation
Achieve greater efficiency and effectiveness with business model innovation
Recent studies of over 1900 customers showed SOA starting points of people, process, information or a combination of all three

6. Entry Points Based on Real Customers’ Engagement
Pattern
Example
Customer Value
Business Challenge
Information
Rapid project payback from reuse – second interface was delivered within 10 weeks, at 2.5% of the cost of the first interface
Competition and regulatory pressures forced to improve their understanding of and relationships with customers
Process
Harley Davidson Financial Services
Financial Programs that map to Marketing Promotions can be done faster and cheaper
Poor integration between channels and desire to optimize E2E processing
People
Web Services based Infrastructure reduce nearly 50% application deployment and 30% operations cost
Post merger standardization of application development & deployment infrastructure
Reuse
Savings of 4M pounds to date, 1M pounds a quarter
Reduce cost of business with multiple channels
Make data in existing systems available to sales portal
Connectivity:
Standardize application integration estimate saving $720,000 annually and 25% less application development time
Applications in silos, can’t communicate with each other
Routing of requests through multiple data centers 1 2 3 4 5

7. 1
Information Centric Approach – Greater Value through SOA Delivering Information as a Service to People & Processes
Value
Improve business operations and reduce risk with trusted information services delivered in-line and in-context
Why SOA?
Trusted information packaged as services are embedded inline within processes or delivered to people
Start with Discover and understand information sources, relationships & business context– Choose reusable high value data for first services
Next steps
Expand number and scope of services across internal and external processes

8. 2 Value Why SOA? Start with Next steps
Process Centric Approach - Greater Value through SOA Business Process Management for Continuous Innovation
Value
Innovative business models deployed quickly with flexible and optimized processes. Measure performance to drive improvement.
Why SOA?
Modeled processes, converted into services, are re-used, connected and re-deployed more flexibly and quickly with SOA
Start with
A single process – Model an underperforming process. Optimize and deploy as enhanced process.
Next steps
Flexibly link multiple processes across the enterprise & to suppliers / partners. Monitor the process to measure & track performance.

9. 3 Value Why SOA? Start with Next steps
People Centric Approach - Greater Value through SOA Intuitive & Adaptive User Experience
Value
Improve people productivity by aggregating views that deliver information and interaction in the context of a business process
Why SOA?
Composite applications created, deployed, and updated faster with SOA portlets
Start with
Build a view of a key business process by integrating information in front of people to improve decision making
Next steps
Manage performance more tightly with alert-driven dashboards tied to processes

10. 4
Connectivity - Greater Value through SOA Underlying Connectivity to Support Business-centric SOA
Value
Deliver services through new business channels for a secure, consistent user experience
Service-based connections with trading partners
Potential savings of 2X-4X over custom-built integration or FTP*
Start with
Messaging backbone leveraging messaging and web services protocols as the foundation for SOA connectivity
Enable mediated exchange between services, by leveraging an ESB
SOA appliances for ESB functions in a hardware form factor
*Software Strategies
“Enterprise Integration Challenge” 2005

11. 5
Creating & Reusing Services - Greater Value through SOA Create Flexible, Service-based Business Applications
Value
Flexibility and elimination of duplication for reduced cycle times
Expanded access to core applications
Consultant studies have found it 5X less expensive to re-use existing applications than to write new applications*
Start with
What services are needed to run your business?
Identify high-value existing IT assets and service-enable them for reuse
Fill in gaps by creating new services for today's business needs and future reuse
Registry/repository to facilitate centralized access and control of reusable services
* Software Productivity Research (SPR)

12. Governance is critical to success with SOA
For business services and composite apps/services to become reused, they must be “trusted”
Trust is enabled by effective governance for compliance to Service Level Agreements, and nonfunctional requirements (e.g. security, reliability, performance, etc.)
Funding
Service Domains
Categorization of Services
Roles and responsibilities
Services Ownership and Domains
Service Oriented Development Lifecycle
Operational Life-cycle Management
Service management
SLA
Capacity and Performance
Security
Monitoring
Identification and Maturity of Services
Service Assembly and Deployment
Change Management
Governance

13. Creating effective SOA governance is challenging
Examples of key questions to address:
What common business services are needed?
What potential applications (service consumers) will reuse these service(s)?
Which policies are common, which are unique?
Can the differences be isolated to maximize consistency?
What services already exist and are candidates for reuse?
Who decides which existing LOB service has the best customer data for the new shared process to be used by all LOBs?
Who owns the shared service(s)?
Who should fund it?
Who is responsible for upgrades?
How to motivate each LOB to reuse the service (rather than their own unique version because they feel they have unique needs)?
Who decides who can use the service and how often?
How to organize the shared services/assets so they can be effectively reused at a later date?
Who is allowed to change a service reused by others?
Who is using a service and what will be impacted by changes to that service?
Who needs to approve any changes?
Who will be responsible for funding upgrades to meet a specific user's requirements?
Key aspects to control:
Service registration
Service versioning
Service ownership
Service funding
Service monitoring
Service auditing
Service diagnostics
Service identification
Service modeling
Service publishing
Service discovery
Service development
Service consumption
Service provisioning
Service access
Service and composite app deployment
Service security

14. Governance impacts many aspects of an organization
Roles
Organization
Compliance
Definition
Communication
Vitality
External Effects
Business & IT Strategies
Architecture Stakeholders
Business Directions
IT Strategies
Key Requirements
Technology Changes
New Requirements &
Options
IT Investments
Compliance Assessment & Impacts
Business Value
Principles
Models
Standards
Plans
Architectural Compliance, Relevance & Value
Service Model
Objectives
The Governance Framework defines the principles, processes, and roles required to manage, use and update the Service Oriented Architecture.
The primary goal is to derive maximum value from the Service Oriented Architecture asset by promoting its implementation, use and evolution.
Defines how the Service Oriented Architecture (and its associated models) should be managed and updated in response to changes in business needs and available technologies.
The Governance processes are fundamental to enabling the business to make conscious decisions about IT, the acquisition of IT assets, and the design and implementation of new IT solutions to meet business needs
In order to achieve these objectives the governance needs to establish 4 distinct processes:
SOA Definition Process – This process specifies the architectural design activities that define, build, and deploy components of the SOA. This process includes modeling of business components, business services, and the design of service components that will enable the business model activities. It also defines the different organizational roles required to support the process.
SOA Vitality Process – This process maintains the applicability and currency of the architecture. This requires the architecture to be current, reflecting the business and IT direction and strategy, as well as anticipated changes in outsourced non-core processes. It must also refine the Architecture Management Process and supporting roles, organization and business functions to ensure its on going usage and relevance. The architectural principles are used to help guide this process
SOA Compliance Process – This process reviews and approves/rejects the design of a solution against the Service Oriented Architecture. This process can be performed at various points during the Business / Project cycle. In many cases, it is an add-on to an existing enterprise architecture review/quality process. This process also allows for projects to appeal the non-compliance of a solution design or an IT investment with the architecture and be granted an exception
SOA Communications Process – This process is aimed at educating and communicating the architecture across the organization. This also includes ensuring that the process is acknowledged within the associated processes as well as setting up environments and tools to allow easy access and use of architectural information
These processes enable the enterprise to maintain alignment of business and IT.
... click action to bring the influence factors into view ....
For example, the Vitality Process ensures that Business Directions and IT Strategies from the enterprise leadership are examined against the backdrop of existing technologies and new trends and define new requirements and changes to the Enterprise Architecture stakeholders (generally in IT) for its implementation and update of the SOA vision
The Compliance Process , as another example, assures that IT Investments required to provide compliance with the enterprise vision are assessed against the impact on other enterprise initiatives.
Finally, a consistent and frequent communication of the Business Value of the SOA and its Principles, Models, Standards, Plans is essential to achieve and maintain the SOA vision and the expected benefits to the business.

15. Service Lifecycle Management Flow
As SOA practices mature, a the “Service Lifecycle” view has emerged
Service lifecycle management is a component of an overall SOA Governance Strategy, and provides control and rigor appropriate to the nature of services
Service Lifecycle Model
Service Reuse / Use
Existing?
Service Creation
(Development Lifecycle)
Service Inception
(Organization Needs) No
Yes
Yes, but...
Service Deploy
Service Availability
Service Variation
Request
Service Versioning
Service Operational Summary
Service Retirement
There is an emergence of SOA tools to drive the complete end-to-end service lifecycle for successful SOA implementations.
As the diagram indicates:
Service inception
Service reuse
Service versioning
Service retirement
are all new phases that are unique to services that need to be effectively managed.
This notion of a “macro” lifecycle that interacts with existing lifecycles, such as:
System/Service Design Life Cycle (SDLC)
Asset management lifecycles
Service release and change management lifecycle
Service operational lifecycle
is increasingly becoming the norm in today’s SOA. Customers need more and more automation and are seeking a single tool to start their successful management of overall service lifecycles (or macro lifecycle).
Service Creation leads into a focused development lifecycle
Service Deploy and Availability focus on change and release mgmt
Service Operational Management focuses on system management

16. Two types of methodology are needed, with different delivery options
Customer Delivery
Services Delivery
The Rational Unified Process (RUP) for SOA, and other RUP methodologies
Very comprehensive methodology for managing the lifecycle of services, both from bottom-up and top-down perspectives
Separate tasks and deliverables provided as in plug-ins
Rational Method Composer hosts the plug-ins, and facilitates tailoring the collection of methodology elements to the specific needs of the enterprise
IBM’s CBM, SOMA, and other GS Method methodologies
GBS and GTS use proprietary intellectual capital and tools, which can be very specific to industry requirements
Methodology for the Identification, Design, Creation, Deployment, and Management of services
The RUP plug-in for SOA Governance
Accessed and customized via the Rational Method Composer
Guides the design and implementation of an end-to-end Governance approach through a series of tasks and deliverables
Leveraged by Rational Portfolio Manager (RPM) to create project templates that are in alignment with the established governance policies and procedures (ensures that all projects are in conformance)
Methodology for the creation of a governance strategy and approach for SOA
Governance aspects of IBM’s SOMA methodology
GBS and GTS use proprietary intellectual capital and tools

17. IBM’s SOA Methodology Organizations Business Modeling Requirements
CBM – Component Business Modeling
SOMA – Service Oriented Modeling and Architecture
RUP for SOA – Rational Unified Process for SOA
domain areas
Organizations
Business Modeling
Requirements
Analysis and Design
Implementation
Test
Deployment
Configuration & Change Mgmt.
Project Management
Environment
Operations
GS Method
CBM
RUP
SOMA
RUP4SOA
INSTRUCTOR:
At this point many people will ask: why are you talking about CBM and SOMA? The answer in slide # 16.
Just defer the answer and take the time to describe the overlap between the various methods.
The items on the list on the left of the slide are called “domain areas” in GSMethod and “disciplines” in RUP (they do not map one-to-one between the two methods).
Note that the scope and applicability of the GSMethod is much wider than RUP, which is primarily a software development set of best practices (methodology).
Question to introduce the next slide:
RUP for SOA is included in RUP
But are these methods (RUP for SOA) and techniques (CBM, SOMA) all what I need for SOA? Obviously not. See next slide.
Remember that the SDCC (Service Design, Creation and Connectivity) STEW focuses on the Analysis and Design of Services, which is the focus of interest of SOMA and RUP4SOA.
IBM Confidential

18. Component Business Modeling
CBM
CBM is a business consultancy method used by IBM Global Business Services
CBM is a technique to decompose an Enterprise into its constituent building blocks (business components)
A component is a logical grouping of people, technology, and resources that delivers specific business value, and can operate independently
The output of a CBM engagement can be the input to an SOA engagement
RUP for BM/SOA
Component Business
Model
CBM
INSTRUCTOR: Slides are annotated in the top right corner with the methodology under discussion, e.g. CBM in this case. Point this out to students so they can always follow which methodology is being covered.
An IT Architect would not typically use CBM, but the output of a CBM engagement can be the input to an SOA engagement.
Heat Map
SOMA
To-Be Business
Process Model

19. Enterprise Architecture
Enterprise Architecture embraces both Business and
IT Architectures, providing the “city plan” for “building projects”
Strategy
Business
Opportunity
Technology
Availability
Business
Strategy
Information
Technology
Strategy
Enterprise Architecture
“the city plan”
Enterprise Architecture
Enterprise wide focus
Business
Architecture
SOA Reference
Architecture
Planning
Processes
Information
People
Locations
Applications
Data
Technology
Business
Map
Application
Map
Domain Architectures
“regions of the city plan”
Transition Plan
Business Operating Environment
and IT Infrastructure
Project focus
Design and
Delivery
Solution Architecture
functional aspects
operational aspects “the infrastructure and Single building design”
Infrastructure
Map
IT Solutions

20. Strategic Capabilities Network (SCN)
The SCN is created and developed in Strategy engagements and Enterprise Architecture engagements. In each of these, the focus is slightly different.
Strategy Engagement: During strategy activities the focus is on understanding the client’s existing capabilities, evaluating their strengths and weaknesses and identifying new capabilities required.
Strategic Capabilities Network (SCN) V V V C C C C C C
EA Engagement: During enterprise architecture activities, we focus on refining the needed capabilities and identifying the resources (capability enablers) the client needs to meet its strategic objectives. C C R R R R R R R R R R R R R R R R R

21. How does an SOA engagement use CBM work products?
CBM can identify where to focus attention in an SOA engagement – e.g. areas of key strategic value (heat map)
CBM gives a loosely coupled architecture – an SOA should not bind the business components in a way that compromises the business architecture.
If CBM has identified business services, these can be analyzed to identify the software services needed to support them
If CBM has identified business processes then these act as requirements on the functionality that must be offered by a service-oriented solution
Speaker notes not required for this chart.  Contact content owner listed on title page if you need assistance or additional details.

22. SOMA Service-Oriented Modeling and Architecture
It is a method with roles and activities that produces artifacts (workproducts) relating to the identification, specification and realization of services, components and flows (processes)
Domain
Decomposition
Subsystem
Analysis
Service
Specification
message
& event
specification
component flow
service flow
Realization Decisions
Goal-Service
Modeling
Existing Asset
Component
information
service
allocation
to components
component
layering
technical
feasibility
exploration
Realization
Decisions
Specification
of Services, Components, and Flows
Identification
of Candidate Services and Flows
Speaker notes not required for this chart.  Contact content owner listed on title page if you need assistance or additional details.

23. More about SOMA
SOMA
SOMA is aimed at enabling target business processes through the identification, specification and realization of business-aligned services that form the SOA foundation.
It introduces new and innovative techniques where gaps exist in existing techniques, in order to specifically address SOA needs. SOMA enables creation of composable services.
It creates continuity between the business intent and IT implementation by extending business characteristics (e.g. goals and key performance indicators) into the IT analysis and architectural decisions.
Analysis and modeling performed during SOMA does not impose any product, but establishes a context for making technology and product specific decisions in later phases of the lifecycle.
Its goal is to provide guidance in the modeling (analysis and design) of SOA.
Speaker notes not required for this chart.  Contact content owner listed on title page if you need assistance or additional details.

24. SOMA Activities
SOMA
Domain
Decomposition
Subsystem
Analysis
Service
Specification
message
& event
specification
component flow
service flow
Realization Decisions
Goal-Service
Modeling
Existing Asset
Component
information
service
allocation
to components
component
layering
technical
feasibility
exploration
Realization
Decisions
Specification
of Services, Components, and Flows
Identification
of Candidate Services and Flows
3 major activities (on the left) - set of steps for each activity (right)
SOMA activities are grouped into 3 major steps: Identification, Specification, and Realization decisions. At the heart of SOMA are identification and specification of services, service components and flows (or processes).
As many other architectural activities, SOMA activities are performed iteratively.
The steps apply one or more complementary techniques, that can be done in parallel.
The first major SOMA step identifies candidate services and flows. In this lecture, we will be focusing on this step. The second step selects and specifies the services that will be exposed and service components that will realize them. The third step captures realization decisions.
SOMA activities are grouped into three major steps: Identification, Specification, and Realization
At the heart of SOMA is the identification and specification of flows, services, and components
SOMA activities are performed iteratively. Each step is carried out by applying one or more complementary techniques.

25. Service Identification
SOMA
A combination of three strategies is used
Goal-Service Modeling
Domain Decomposition (Top down Analysis)
Existing Asset Analysis (Bottom-up Analysis)
Top-down
Analysis
Align Services
with Business Goals
Domain
Decomposition
Goal-Service
Modeling
Existing Asset
Analysis
Speaker notes not required for this chart.  Contact content owner listed on title page if you need assistance or additional details.
Bottom-up
Analysis
next step:
Service Specification

26. Service Specification
SOMA
Service Specification
Elaborates the Service Model. For example: service dependencies, composition, non-functional requirements, service message specifications, design decisions, etc.
Includes Service Litmus Test that “gate” service exposure decisions
Subsystem Analysis
Partitioning into service components that will be responsible for service realization
Component Specification
Detailed component modeling, flow, information architecture, and messages
component flow specification
service flow specification
Subsystem Analysis
Service Specification
Service Specification
- Elaborates the Service Model, for example, service dependencies, composition, non-functional requirements, service message specifications, design decisions, and so on
- Includes Service Litmus Test that “gate” service exposure decisions
Subsystem Analysis
- Partitioning into service components that will be responsible for service realization
Component Specification
- Detailed component modeling, flow, information architecture, and messages
Component Specification
information specification
message & event specification
next step:
Service Realization

27. Service Realization
SOMA
Review the Service Model to determine how each Service is realized
Decide how Services are Realized: buy, build, integrate, transform, subscribe, outsource
Document the Service Realization Decisions
Realization Decisions
service allocation to components
technical feasibility exploration
component layering
Speaker notes not required for this chart.  Contact content owner listed on title page if you need assistance or additional details.
next step:
Service Implementation

28. SOMA delivery
SOMA
SOMA is intended to be used by IBMers (especially IGS) working on client engagements
Can be left with customers provided contracts and licenses are in place
Note that there is SOMA content for RMC available – IBM internal only.
Note: The proprietary nature of SOMA may make it inappropriate for use in SWG Services engagements where the client must follow the same method as IBM consultants
IBM Confidential

29. Rational Unified Process
RUP
It’s a set of software development best practices collected over twenty years of client engagements
It’s an IBM Product
RUP is iterative
executable releases at each iteration (risk reduction)
RUP is Use Case based
business or system use cases
use cases are used to define scope, plan, test and documentation
RUP is Architecture driven
RUP is modular
plug-ins for SOA, Systems Engineering, etc.
Rational learned what works and what does not work from over twenty years of consulting experience in software development projects with clients.
Use Case driven: many people have a limited knowledge of Use Cases, and think that Uses Cases apply only at the System level.
On the contrary, RUP best practices start at the Business Modeling Level, where Business Use Cases (otherwise known as business processes, or business components) are used to define the very early business requirements, associated with business objectives.
Go to developerWorks to find the available RUP plug-ins
for RMC:
and for RUP 2003:
RUP always needs to be tailored to the specific project

30. RUP for SOA Refine the Architecture Design Services
Top-Down, Business Process Driven
Top-Down, Use Case Driven
Data Driven
Rule Driven
Bottom-Up, Exposing Existing Assets
It’s a RUP plug-in, available in Rational Method Composer 7.0
Focuses on the Analysis and Design of Services
Activities in all the RUP disciplines have been updated with Service-Oriented content
Shares many concepts, activities and artifacts with SOMA
FROM: RUP in RMC, search: “Activity Refine the Architecture”, select Work Breakdown Structure
FROM: RUP in RMC, search: “Activity Design Services”, select Work Breakdown Structure
An example of the detailed steps inside one of the main activities that the Architect is responsible for (Identify Services) is expanded in the box:
notice the similarity of the steps in RUP “Identify Services” with the related steps in SOMA (Service Identification).
In parallel changes are being made to the RUP Business Modeling discipline that would make the connection between BM and SOA stronger, however it was decided not to wait for the BM changes before completing the SOA plug-in. The integration of both sets of changes will be made for the commercial release.

31. RUP for SOA – Some key elements
We can’t go through RUP for SOA in detail in this lecture. These are a few of the most important elements in RUP for SOA, but there is lots more.
Artifacts are a kind of RUP work product [IGS term].

32. Rational Method Composer
RMC is an Eclipse-based tool for creating and customising development processes
RMC includes RUP and several RUP plug-ins including RUP for SOA
Processes are deployed (“published”) as HTML and Java applet web sites
Reference:

33. RUP for SOA Governance Plug-in (IBM SOA Governance and Management Method)

34. IBM’s foundation SOA technology provides support for governance
Development Sub-Process
Rational Tools, enforcing a defined development process as defined during the governance process
ClearCase, ClearQuest, Requisite Pro, RAM, BuildForge
Development workflow managed by Process Server
WebSphere Portal
UI Interface for decision rights
Authentication and Authorization for workflow and checkpoints
WebSphere Business Modeler
Define and document the governed processes
Roles, Decision Rights, Process
WebSphere Process Server
Execution runtime for governance workflow
Manages the SOA Lifecycle through enforced workflow
IT Service Mgmt Sub-Process
Tivoli Management products, enforcing defined ITSM processes as defined during the governance process
CCMDB, TPM, ITCAM
Systems Management workflow managed by Process Server
WebSphere Integration Developer
Enable the governed process as executable business process
Lifecycle state machine
Once the governance process is defined, it can be implemented as a BPEL workflow by rewriting it using WebSphere Business Modeler. Once in WBI Modeler, it is then imported into WID as a staging environment for WebSphere Process Server.
WebSphere Registry and Repository
Definitive source of state for services as they progress through governed workflow
WebSphere Monitor
Monitor results and KPIs of the governed process

35. WebSphere Business Services Fabric
Composition Studio
A visual modeling environment where domain-experienced software architects can easily create and manage industry specific service meta-data models and policies.
Subscriber Manager
Controls and automates entitlement of Business Services for subscribers.
Enables creation, control, and management of service packages to subscribers across the ecosystem.
Governance Manager
Provides powerful visual zooming and panning models of hierarchies and service dependencies so that technical and business users can monitor business SLAs & performance.
Business Services Repository
A standards-based, enterprise SOA metadata repository to manage ontologies, service descriptions and policies.
Enables developers to publish, reuse, & manage services.
Dynamic Assembler
A highly scalable, semantic services broker that enables dynamic service assembly and provides service behavior personalization based on content, context, and contract.
Performance Manager
Provides visibility and monitoring of service oriented processes and applications. It includes multi-perspective views and enables drill-down analysis of events and exceptions.

36. WBSF leverages and extends WSRR
WBSF and WSRR provide differentiated and comprehensive registry/repository capabilities through the runtime use and management of both business and technical metadata
BSR
Business Services Repository (BSR)
Focus on business service metadata, policies, and subscribers
Foundation for "housekeeping of business services" throughout their lifecycle
Spans design-time to run-time and manage-time usage scenarios
Federation framework for scalable/extensible SOA that supports other authoritative data sources; WSRR, LDAP, and others
Websphere Service Registry & Repository
Focus on Web service technical artifacts
System of record repository to physically store assets such as WSDL, XSD, BPELs, etc
Metadata classifications to enable easy search and storage
Business Service
Metadata
Business Policies
Subscription Policies
Industry Ontologies
CBS Metamodels
Web Service Details
Discovery WSRR API
WSRR
Federation framework to support WSRR, LDAP, UDDI, etc. Maintain Referential integrity – through 2-way replication(?)
OWL differences:
WSRR: OWL-taxonomy only (basically Metadata classifications only (although OWL-based))
BSR: OWL full indsutry ontologies
Governance. Must differentiate. Governance of what? (SOBAs vs. ws)
UDDI differences:
BSR - does Discovery API.
WSRR - Scripts to do a one-time dump
Fabric Bundled with WPS, WID, WSRR
This Year: Basic Bluewash
Next Year: Integrated Bluewash
Web Service
Technical Artifacts
.wsdl
.xsd
Bpel
Metadata Classifications

37. The Need: A simple and reusable process

38. The Reality: Different variations are needed in the process
Channels A B C D E

39. Option 1: Write many different processes (low reuse)
Channels A B C D E

40. Option 2: Write processes with complex decision paths (difficult process creation and management)
Channels A B C D E

41. Option 2: Write processes with complex decision paths (difficult process creation and management)
Channels A B C D E

42. The Best Option: Dynamic Assembly
Repository for Policies, Rules, etc. A B C D E

43. Pre-Built Industry-Specific SOA Assets
Categories of SOA assets that speed time-to-market and instill industry standards and best practices
Categories of Pre-Built Industry SOA Content
Business Processes
Executable processes and workflows
Visio/WBI modeler-based, BPEL compliant
Business Services
Data, process, visibility, optimization services
Pre-built semantic mediation services
Business Rule Assets
Configurable business rule templates
By line of business, product and state
Industry Message Sets
ACORD and IAA-based (insurance example)
Configurable, XML-based schemas
Ontology and Data Models
Pre-built SOA meta models
OWL-based configurable ACORD and IAA models
Policies and Assertions
Multi-tier PRISM policies
WS-Policy based models
3rd Party and BPO Service Interfaces
Insurance interfaces to key services
MVR, CLUE, Credit, Locations, and others
Legacy Adaptors
300+ adaptors to legacy and ERP systems
Sourced within Business Services Catalog
<<Get this from Bill C. – rich speaker notes>>
Many of these assets are going over to GBS.
Global Software Solutions Centers will tasked with cranking these out for multiple industries. Consulting service will become more “asset based”.

44. Benefits of the Business Services Fabric
Storage of business services, subscribers and policies to enable assembly of composite business services
Central repository for business service meta-data, domain ontologies, policies, and subscribers
OWL/RDF-based, meta-model, which allows for capturing semantics and easy extensibility
Ontology-driven semantic mediation and interoperability
Ability to federate meta-data from other repositories such as LDAP systems and WebSphere Service Registry and Repository
Conflict detection during collaborative development
Powerful search, dependency, and impact analysis
Source and syndicate ISV and third-party IT assets into the catalog
Role-based, context and namespace level security that leverages existing access control systems
Support for entire meta-data life cycle including comprehensive versioning, change tracking, and collaborative governance of service meta-data

45. Benefits of the Business Services Fabric (cont.)
Comprehensive business service governance
Governs and manages the set of services, policies, and processes that drive reuse of business services, define and enforce policies, control proliferation of services, provide composite business service visibility, and manage the life cycle of business services
Leverages components of WebSphere Business Services Fabric to govern life-cycle changes, particularly for design-time promotion of services to run-time and for recording service performance and changes
Governs all aspects of business services: performance, reliability, interoperability, security, and management
Manages life-cycle changes to business services
Controls meta-data promotion between environments
Validates meta-models to ensure accuracy and correctness before publishing
Ensures meta-data integrity while modeling composite business services in a multi-authoring environment
Defines policies for meta-data visibility in collaborative development environments
Notifies users when changes are made
Offers change management process for service versioning, validation, and performance management
Includes open APIs for integration with change management systems, such as IBM Rational ClearCase®

46. Benefits of the Business Services Fabric (cont.)
Meta-data-driven assembly of composite business services
Enables publishing and managing service models, policies, and service portfolios
Designed to work with WebSphere Integration Developer and tools such as IBM Rational® Software Architect, providing architects, developers, and system integrators with a common meta-data life-cycle management fabric for connecting services, exchanging meta-data, and aligning context across different applications and domains
Achieves rapid and secure assembly of disparate IT assets into composite business services
Supports both top-down business domain decomposition and bottom-up analysis of underlying IT systems
Creates and enforces design-time, runtime, and change-time policies
Composes unique multi-channel services that power multiple access modes such as Web, business-to-business (B2B), IVR and fax
Delivers model and manage meta-information about business services including WSDL-, WS-Policy- and BPEL-defined declarations, and actual behavior of services
Includes model policies as a basis for dynamic discovery, matching, and binding of services based on content, context, and contract
Simulates service behavior based on different usage scenarios
Manages run-time meta-information for matching service requestors and service providers using policies
Applies policies at various levels; for example, business ecosystem, application, business service, or service end point
Assembles policies in a unified, flexible and extensible grammar to express the capabilities, requirements, and characteristics of entities within an SOA

47. Benefits of the Business Services Fabric (cont.)
Dynamic business service personalization and delivery
A highly optimized semantic mediation engine enabling meta-data-driven service discovery, matching, and interoperability during both design-time and run-time.
Leverages business service policies to replace hard-coded service bindings in enterprise service bus, Business Process Execution Language (BPEL), and B2B connections with dynamic end-point selection based on content, context and contract of the service request
Dynamic service behavior adaptation that is based on business context, content, and contract
Policy-based customization across multiple domains, business processes, and service end points
Policy enforcement that is based on performance, reliability, interoperability, security, and manageability of business services
Dynamic business service and process customization without affecting larger subscriber base
Elimination/reduction of hard-coded binding changes with policy-based process customization
Reduced integration complexity through ontology-based classification and data transformation rules
Multi-protocol support for HTTP and JMS, and can be extended to other protocols
Multi-message support, for example, ACORD, HIPAA, HL7
Out of the box support for SOAP, Java™ Messaging Service (JMS) topics, Remote Method Invocation, and MQ

48. Benefits of the Business Services Fabric (cont.)
Real-time business service visibility and control
Business visibility and monitoring of composite business services and service oriented processes for business analysts and IT administrators
Multi-perspective views and drill-down analysis of events and exceptions with respect to business context in a loosely coupled, service-oriented business ecosystem
Subscriber- and role-based drill-down performance visibility against business goals and service level agreements
Business service support for billing and metering of composite business services at business service level
Central performance monitoring console customizable by business need
Domain, subscriber, and service-based performance and Service Level Agreement (SLA) reporting
Business content monitoring and alert notification
Context specific error handling across multiple messages and protocols
Configurable audit trails on service invocations for security, SLA, and compliance monitoring
Real-time monitoring of aggregate or individual level traffic including faults, throughput response, and availability

49. Summary IBM’s view of SOA is business centric
Governance is critical to success with SOA
Various methods, future improvement
Alignment between Enterprise Architecture and SOA
Business Services are in focus for the next generations of SOA project

50. Questions ?

51. Backup

52. WebSphere Business Services Fabric complements IBM’s foundation SOA technology
WebSphere Business Modeler
Process &/or Flow Models
Composeable Business Services
Web Service or JMS Connections
1. Composition Studio
Eclipse
WebSphere Integration Developer
BPEL Editor, WSDLs, and Deployment
Tooling
3. Governance Manager
4. Subscriber Manager
5. Performance Manager
Local Test Instance Fabric
Common or Core Services
Performance Data, Usage Data and Extensions
Business Policy Data
Subscription Data
2. Business Services Repository
6. Semantic Mediation
Plug-in (Dynamic Assembler)
WebSphere Process Server
Ontologies
WebSphere Service Registry & Repository
Business Service Repository is loosely coupled with WSRR to consume service metadata and policies

53. WBSF Design-Time Perspective
Design Tools
WebSphere Business Modeler
Process &/or Flow Models
Business Services Definition Tooling:
Composeable Business Service-based
3. Governance Manager
Publish Business Service adds, changes and deactivations
4. Subscriber Manager
Add, Change, Deactivate Business Service subscribers
5. Performance Manager
View existing performance metrics
1. Composition Studio
Access to the
Business Services
Repository
Create Business Service assembly definition
Eclipse
WebSphere Integration Developer
BPEL Editor, WSDLs, and Deployment
Local Test Instance Fabric
Usage Extensions
Business Policy Data
Subscription Data
2. Business Services Repository
6. Semantic Mediation
Plug-in (Dynamic Assembler)
WebSphere Process Server
Ontologies
WebSphere Service Registry & Repository
Business Service Repository is loosely coupled with WSRR to consume service metadata and policies
WebSphere Process Server is required to run the web-based tooling

54. WBSF Run-Time Perspective
Fabric Common Services
Common Industry Services
Usage data with Performance Manager
LDAP Services
Web Service or JMS Connections
Composeable Business Services
Common or Core Services
Exposed Business Services
Run-time Tools
Business Policy Data
Subscription Data
Performance & Usage Data
2. Business Services Repository
6. Semantic Mediation
Plug-in (Dynamic Assembler)
WebSphere Process Server
Ontologies
WebSphere Service Registry & Repository
Business Service Repository is loosely coupled with WSRR to collect service metadata and policies
Industry Fabric Runtime:
WebSphere Process Server includes WAS, BPEL Engine and WESB
Loosely Coupled using JMS

55. WBSF Manage-Time Perspective
Management Tools
Business Services Definition Tooling:
Composeable Business Service-based
3. Governance Manager
Publish Business Service change lists
Manage Business Service Lifecycle approval/rejections
Track and Audit Change history
5. Performance Manager
View existing performance and utilization metrics
View Billing and Metering information
1. Composition Studio
Access to the
Business Services
Repository
View Business
Service assembly
definitions
Eclipse
WebSphere Service Registry & Repository
User
Interface
Loosely connected through the Eclipse IDE using plug-ins
Performance & Usage Data
Business Policy Data
Subscription Data
2. Business Services Repository
6. Semantic Mediation
Plug-in (Dynamic Assembler)
WebSphere Process Server
Ontologies
WebSphere Service Registry & Repository
Business Service Repository is loosely coupled with WSRR to consume service metadata and policies
WebSphere Process Server is required to run the web-based tooling