Presentation is loading. Please wait.

Presentation is loading. Please wait.

SOA From a Business Centric Perspective

Similar presentations


Presentation on theme: "SOA From a Business Centric Perspective"— Presentation transcript:

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


Download ppt "SOA From a Business Centric Perspective"

Similar presentations


Ads by Google