architecture guappendix a. define a bpm reference architecture guide

7/23/2019 Architecture GuAppendix A. Define a BPM Reference Architecture guide

http://slidepdf.com/reader/full/architecture-guappendix-a-define-a-bpm-reference-architecture-guide 1/14

© Copyright IBM Corp. 2009. All rights reserved. 21

Draft Document for Review October 5, 2009 4:36 am ArchitectureGuide.fm

Appendix A. Define a BPM Reference

Architecture

The goal of this appendix is to provide the reader with a Business Process ReferenceArchitecture. More specifically, this appendix discusses the following:

Explores SOA as fundamentals of BPM solution architecture

Explores a layered architectural approach with application to the Better Healthcare BPMsolution.

The fundamentals of a BPM solution architecture is SOA (Service Oriented Architecture).

SOA is a framework that views software as discrete services so that they can be reused

across the company by a variety of needs across the firm. SOA enables BPM .

In SOA terms for example service “Set Billing Provider” is made available to the whole

company and follows orders received through the Enterprise Service Bus which is thebackbone for communication in an SOA.

Immediately a company such as Better Healthcare Insurance ABC benefits from reduced

costs in terms of time, money and human resources because one application is able to servermore than one line of business.

The SOA approach has several benefits including:

Reusability: The federation of services frees software modules from being redundantlydeployed in different silos of the same firm. By encapsulating business functionality in a

service, SOA allows a software module to be used by any client that wants to use thatfunctionality.

Integration: Each service can be accessed using a standard interface that is outlined in the

service contract. Even legacy components can be presented as services by putting awrapper interface around them. This allows easy integration of modules across disparatesystems.

Agility: Because libraries of well-defined services form the core of the SOA framework,new requirements that need those services can access and reuse them easily, thus

shortening the time-to-market deployment of new applications.



ArchitectureGuide.fm Draft Document for Review October 5, 2009 4:36 am

22 BPM Solution Development Guide

Cost Savings: The flexibility of reusing software components results in both a cost and

time-saving benefit.

Business Process Alignment: SOA is built around services, which are representations ofbusiness processes. It is one of the first times in the history of software architecture thatbusiness processes and software components are so closely aligned, making the

technology a direct solution to a particular business goal.

IBM SOA Reference Architecture

The architectural diagram shown on Figure A-1 on page 22 in depicts an SOA as a set oflogical layers. The IBM SOA Reference Architecture (SOA) provides a roadmap and

guidelines for the architectural, design and implementation decisions. Additionally, it providespatterns and insights for integrating these aspects to enable end-to-end, SOA-based

business solutions.

Figure A-1 IBM Reference Architecture for BPM

Operational Systems

This layer includes all custom or packaged application assets in the application portfoliorunning in an IT operating environment, supporting business activities.

Governance

Data Architecture (meta-data) & Business Intelligence

QoS Layer (Security, Management & Monitoring Infrastructure Services)

Integration (Enterprise Service Bus)

Operational Systems

Service Components

Servicesatomic and composite

Business ProcessComposition; choreography;business state machines

Consumers

Channel B2B IVR

Custom Application

OO Application

Packaged Application

ServiceConsumer

ServiceProvider

http://-/?-

http://-/?-



Appendix A. Define a BPM Reference Architecture23


The operational layer is made up of existing application software systems; thereby, it is used

to leverage existing IT investments in implementing an SOA solution. A number of existingsoftware systems are part of this layer. Those systems include:

Existing custom applications, including J2EE™ applications (such as the Services alreadydeveloped so far)

Legacy applications (to be contacted through TCP/IP)

Existing database systems

Connection to Systems and Sites which are using non-standard protocol (no SOAP)

Service Components

This layer contains software components, each of which provide the implementation for,

realization of, or operation on a service, which is why it's called a service component.

Service components may comply with the Service Component Architecture (SCA) andService Data Objects (SDO) specifications.

Services

This layer consists of all the services defined within the SOA. For the purposes of thisreference architecture, a service is considered to be an abstract specification of a collection of

(one or more) business-aligned IT functions. The specification provides consumers withsufficient detail to invoke the business functions exposed by a provider of the service; ideally

this is done in a platform-independent manner. The service specification includes adescription of the abstract functionality offered by the service similar to the abstract stage of a

Web Services Definition Language (WSDL) description.

Exposed services reside in this layer; they can be discovered and invoked or possibly

choreographed to create a composite service.

This layer contains the contracts (service descriptions) that bind the provider and consumer.

Services and their underlying building blocks are defined according to the serviceidentification activities like SOMA or can be based on reusable industry assets like theWebsphere Fabrics Telecom Content Pack.

Business processes

Compositions and choreographies of services exposed in layer 3 are defined in this layer.

One use service composition to combine groups of services into flows, or we choreographservices into flows, thereby establishing applications out of services. These applications

support specific use cases and business processes. To do this, visual flow composition toolslike Websphere Business Modeler can be used for design of application flows. The figure

below shows how a business process P can be implemented using services A, B, C, and Dfrom the services layer. Process P contains the logic for the sequence in which the servicesneed to be invoked and executed. The services that are aggregated as a business process, or

flow, can be individual services or composite services made up of individual services.





Consumers

The consumer layer, or the presentation layer, provides the capabilities required to deliver ITfunctions and data to end users to meet specific usage preferences. This layer can alsoprovide an interface for application to application communication.

Integration capability

The integration layer is a key enabler for an SOA because it provides the capability to

mediate, route, and transport service requests from the service requester to the correctservice provider and between layers.

These include modest point-to-point capabilities for tightly coupled endpoint integration aswell as more intelligent routing, protocol mediation, and other transformation mechanisms

often provided by an enterprise service bus (ESB). Web Services Description Language(WSDL) specifies a binding, which implies the location where a service is provided. An ESB,

on the other hand, provides a location-independent mechanism for integration.

The integration that occurs here is primarily the integration of layers 2 through 4. This is for

example the layer that provides the binding between a service definition and the serviceimplementation by a service Component on layer 2.

Quality of service capability

This layer provides the means of ensuring that an SOA meets its requirements with respect to

reliability, availability, manageability, scalability, and security

Information architecture and business intelligence capability

This layer captures cross-industry and industry-specific data structures, XML-based

metadata architectures (that is, XML schema), and business protocols of exchangingbusiness data. For example the NGOSS SID implementation in the Websphere FabricsContent pack.

Governance capability

The governance layer covers all aspects of business operational life-cycle management inSOA.

Logical architecture

In more detail, and more concretely, the logical architecture diagram depicted in Figure A-2

on page 25 includes from top to bottom, the consumer layer, business process layer(Business Process Management Engine), service layer (Enterprise Service Bus), servicecomponent layer (Enterprise Service Bus), operational layer (CRM systems, Billing

Systems,...).

http://-/?-

http://-/?-

http://-/?-

http://-/?-





From top to bottom, we are going to show the meaning of each of the components of figureFigure A-2 on page 25. The section will describe:

1. Consumer components

2. Business Process components

3. Corporate Services

4. Service Components

5. Governance Services

Figure A-2 Logical architecture diagram for Better Healthcare Insurance ABC

1. Consumer components

Consumer components include a model, a view and a controller.

A model is an object representing data or even activity, e.g. datamodel represented usingXML Schema.

A view is some form of visualization of the state of the model.

Note: The logical architecture diagram will help you to find a common understanding onthe architecture. All logical components described in the section below can be

implemented by IBM products. This considerably gives the capability to accelerate thedevelopment of such as solution.

Frontend SpecificData Model

BusinessProcess SpecificMediation Layer (Industry Specific)

Industry SpecificBusiness Process

Data Model

Industry DataModel andServices

CorporateService

Mediation Layer (Industry Specific)

Backend SpecificData Model

BackendSpecific

Mediation Layer (Provider Specific)

WebSphereBusiness Process

Management Engine

Third Party BusinessProcess Management

Engine

Third Party ERPSystems

Application Enterprise Service Bus Application Enterprise Service Bus Application Enterprise Service Bus

ServicesRegistry

andRepository

Application Enterprise Service Bus


Corporate Enterprise Service Bus

CRM System Billing System

http://-/?-

http://-/?-





A controller offers facilities to change the state of the model.

Figure A-3 Model view controller for graphical user interfaces

In many cases the datamodel of the data used by the consumer components is equal to thedatamodel of the underlying business process components. This is the case when the

consumer components do not include pageflow information disconnected from the business

process layer. In this case it is recommended to make use of the out-of-the-box generatorprovided by the IBM BPM suite:

A Lotus Forms Generator given by WebSphere Business Modeler and WebSphere

Integration Developer

A JSF (Java Service Faces) generator included in WebSphere Integration Developer

A Dojo generator included in WebSphere Integration Developer.

In other cases especially when the logic of the controller is getting more complex and

including proper pageflow, it is recommended to implement the consumer components as aseparate completely decoupled layer.

The datamodel depicted in Figure A-4 used by the consumer components includes specificinformation, such as specific information to navigate from wizard page to wizard page. It could

also include localization information, such as the language. Orchestration of GUI componentsshould be directly embedded into the GUI itself.

Figure A-4 Consumer datamodel

It is understandable and maintained by graphical specialists

It is ideally based on XML Schema to easy mapping to the underlying layer.

In a lot of cases there is no difference between the consumer datamodel and the underlyingbusiness process specific datamodel. Differences are required as soon as the GUI includes

Note: It is not recommended to outsource controller logic from the GUI into the underlyingBusiness Process components. Logic between pages (pageflow) needs to stay in the GUIto avoid performance and synchronization issues.

Controller

Model View

Frontend Specific

Data Model

http://-/?-

http://-/?-





advanced pageflow capabilities (wizard like navigation for example), which is not tightly

coupled with the underlying Business process layer.

As of the implementation of a GUI, there are various possible implementation technologieswhich can be used to implement the GUI. Examples are JSF, Struts, WebSphere Portal

Server, Lotus Forms, WebSphere Business Space,....

Out-of-the box tools such as the WebSphere Business Space or the Business ProcessExplorer act directly on the underlying Business Process datamodel and do not permit anabstraction on that level.

2. Business process components

The business process components include orchestration logic, a datamodel and mediationlogic.

The orchestration or choreography logic is expressed in form of BPEL (Business ProcessExecution language for WebServices). This logic is usually imported from a more highlevel Business Process design tool such as WebSphere Business Modeler. Within

WebSphere Business Modeler the logic would ideally be expressed in BPMN2.0.

The business process datamodel includes all information necessary to navigate theBusiness Process such as conditions, necessary input to retrieve information from

backend services, (e.g customer id, order id,...), measurable metrics, input for KeyPerformance Indicators. It is very important to leave this Data Model understandable by a

Business Analyst. It should not contain technical information.

The mediation layer mediates between the business process datamodel and the

underlying layer (Corporate Services components).

More details about the orchestration or choreography logic

The Business Process Management concentrates itself on the execution of BusinessProcesses. The executable processes, each a choreography of Activities, have to be defined

prior to execution in a process Definition or a Process Template.

Figure A-5 Business Process Management Engine

Concretely for Better Healthcare Insurance ABC, the Business Process Engine will have the

following capabilities:

Execution of the Business Processes

Note: WebSphere Business Space is delivered as a component of the IBM BPM suite. Itincludes Lotus Forms technologies to communicate with underlying processes. It has

strong capabilities to accelerate GUI development on the Front End side.

Note: In some cases, and only when a particular consumer specific datamodel has been

implemented, a mediation layer towards the lower level Business Process layer is required.This mediation layer is then responsible to map data between the models. It is most often

implemented directly into the graphical layer.


Management Engine





Emitting of events which can be captured by a Business Monitor tool.

A large number of Non Functional characteristics such as the integration capabilities,

compensation, correlation, transactional integrity...

Figure A-6 shows the responsibilities of the business process component datamodel.

Figure A-6 Business process components data model

It includes all information necessary to display KPI's, alerts, metrics to the Business

Monitor It includes necessary information to identify context in the layer below (the Industry

Specific Services Data Model) It is understandable and maintained by Business Specialists, Business Analysts

It is specified as an XML Schema.

Figure A-7 shows the responsibilities of the business process mediation layer.

The Business process logic (choreography) guarantees the mediation between the Business

Process Layer and the underlying Corporate ESB.

Figure A-7 Business Process ESB

This layer is concretely responsible:

Aggregation and Service Composition of the underlying Services Layer.

This layer guarantees the transactional integrity for the underlying services Layer.

Dynamic endpoint lookup in the Services Registry and Repository.

3. Corporate services

The corporate services include:

A datamodel

A service composition layer defined in a meta-language

Maps to underlying service component

More details about the corporate service datamodel:

Industry SpecificBusiness Process

Data Model


Management Engine

Third Party BusinessProcess Management

Engine

Third Party ERPSystems

BusinessProcess SpecificMediation Layer (Industry Specific)

Application Enterprise Service Bus Application Enterprise Service Bus Application Enterprise Service Bus

Note: WebSphere Process Server includes an own Enterprise Service Bus namedWebSphere Enterprise Service Bus which can be used to mediate between the businessprocess components and the corporate services components.

http://-/?-

http://-/?-

http://-/?-

http://-/?-





This datamodel guarantees the Business Process Alignment of encapsulated software

programs. It is usually IT specific and represents all necessary information to access thesoftware logic of the underlying services. It has the following characteristics:

Figure A-8 Industry or Corporate Data Model and Services

It is understandable and maintained by SOA Integration Specialists. These are clearly IT

roles in the corporation. It is specified by XML Schema.

It can be an extension of an existing DataModel. Such as Telecommunications Operations

and Content Pack Data Model named SID.

More details about the corporate Service mapping and composition

The mapping and composition between the corporate service components and the underlyingservice components should be ideally be non-transactional, slim and concentrate on high

performance transformation and dynamic routing (cross-company).

Figure A-9 Corporate Enterprise Service Bus

The main tasks of this mediation layer consist of :

Message transformation between corporate services layer and underlying service

component layer.

Dynamic lookup of service components.

Legal logging

In some cases encryption and decryption between department ESB’s. (very oftenapplication ESB’s are in different departments).

Industry DataModel andServices


CorporateService

Mediation Layer (Industry Specific)


Note: This layer can for example be implemented on WebSphere Datapower XS50. Itshould be slim and highly performant.





4. Service components

Service components include :

A datamodel used to expose the underlying backend systems as a common service

component architecture. The datamodel is specific to the backend but standardized (xmlschema). For email communication it would for example to, from, cc and subjectinformation.

Protocol conversion layer (adapters) capable to transform legacy protocols into xmlstandardized protocols.

Mapping layer to map between legacy dataformats into standardized (xml) dataformats.

Figure A-10 Backend Specific Data Model and Services

Examples of these service components are JCA adapters or CRUD services (Create, Read,Update, Delete services).

The protocol conversion layer (often implemented as an ESB) guarantees the mediationbetween the Backend Specific DataModel and the Underlying Backend Protocol. It also

includes specific mapping. The nature of this Bus is usually strongly dependent on the

underlying backend system. It may be for example implemented as :

WebSphere Message Broker for communication with WebSphere MQ based legacysystems

WebSphere Enterprise Service Bus or WebSphere Message Broker for communication

with JCA adapters which are available for Email, FTP, Flat File, Siebel, SAP and manyothers.

ERP specific ESB’s such as SAP XI or Oracle ERP specific systems.

Data Access Services implemented on Information Management Information Server

WebSphere Message Broker, DataPower ESB (high performance needs)

WebSphere Enterprise Service Bus or WebSphere Message Broker and CICS adapter

jointly with CICS Transaction Gateway.

5. Governance services

Important: Do not confuse service components with “Service Component Architecture”.Service components is a layer in the layered IBM reference approach and has nothing todo with the SCA framework.

Note: Please find information on Adapters at the following link : IM Information Server,CICS and WebSphere ESB.

Backend SpecificData Model



CRM System Billing System





One of the success factors of an SOA is the Governance of its comonents such as services,

processes and policies. Effective Governance is assured thourhg a central Registry incombination with a central repository. WIthout a Services Registry and Repository, thecorporate IT Services governance could quickly out of control. It is therefore a very important

component within an SOA.

Figure A-11 Services Registry and Repository

It’s characteristics are :

Enable SOA governance of your services throughout the service lifecycle.

Promote reuse and eliminate redundancies by increasing visibility of services, applicationsand processes.

Enhance connectivity by increasing runtime flexibility of applications integrated using theEnterprise Service Bus (ESB).

Optimize the use of services in SOA by exchanging rich service information with runtime

monitoring tools and operational data stores.

Enable policy management across the SOA lifecycle spanning all categories of policy.

Implementation approach

Process Models, Key performance indicators, Business Process Datamodels and ScreenMockups are designed top-down. All decisions for on these artefacts are being taken byBusiness directly. For example datamodels are created in a tabulator such as Excel and

then imported into WebSphere Business Modeler. No advanced IT tooling required tomodel this datamodels.

Service interfaces and Service datamodels are designed in a “meet-in-the-middle” way.The corporate Service layer acts as an agreement layer between business processes and

the operational layer exposed through service components. Backend systems such as a Billing System or an E-Mail Server, respectively database

accesses (CRUD services) are exposed using application specific interfaces. These

interfaces are generated in a “bottom-up” way and exposed as service components. TheService layer above needs to accomodate and map to this layer.

Important: Designing a full Service Oriented Architecture from scratch is out of scope for

this redpaper. The sections below show a step-by-step highlevel guide on what needs tobe completed to design a BPM solution. There are yet other ways to do this, however wehave chosen this way to be particularly adapted to the needs of the Better Healthcare

Approach..

ServicesRegistry

andRepository





Figure A-12 BPM implementation solution guide assumptions

The outcome of the 4 phases of the Prescriptive Guide Approach generates a BPM solution

which is ready to execute within an SOA Sandbox.

The question in the “Deployment” phase consists to map this generated BPM layer withunderlying systems and services.

Figure A-13 BPM Layer

To make this mapping as smooth as possible, creation of mediation layer between the BPM

layer and the underlying corporate services layer is necessary.

ExposedCRUD servicecomponents

IT Team

JCA Adapters

Existing APIsto legacy

applications

Generatedinterfaces from

underlyingapplications

BusinessRules

Engine

BPMEngine

ServicesRegistry andRepository(Policies)

SOA – Steeringand governance

team (Business,Integration and

IT teams)End User Experience

BusinessRules

Policies

ProcessModels Organizations

Business Team

CorporateService

Components

CorporateService

Components

Integration Team

ESB

JCA Adapters

ExistingServices

Meet-in-the-middle implementation effort

B o t t om- u pi m pl em en t a t i on ef f or t

T o p- d owni m pl em en t a t i on ef f or t

Important: The corporate service datamodel and interfaces always need to be defined in a

meet-in-the-middle way. Bottom-up and top-down would cause strict dependenciesbetween the datamodels and considerably reduce the capabilities of the solution layers to

be loosely-coupled.

BPM Layer





Figure A-14 Corporate services and datamodel

Important: Definition of a “mediation” layer between corporate service layer and BPMlayer permits both layers to evolve at their pace and guarantees the solution to be

loosely-coupled.

Important: The canonical datamodel is very important in a BPM solution. This layer actsas an “integration contract” between the BPM layer (and other layers) respectively the

Service Components (Backend systems). The canonical datamodel should be designedindependently from the efforts in the BPM layer and service component layer.

Service Component Layer / Operational Services

BPM Layer

Corporate Services Layer

Corporate Services Mediation and Mapping Layer

Corporate Services Mediation and Mapping Layer

Includes a

canonical

data model andservices

Corporate

services

mediationlayer

Represents

backend

services




BPM Solution Development Guide

architecture guappendix a. define a bpm reference architecture guide

Documents