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

Appendix A.

ArchitectureGuide.fm

Define a BPM Reference

Architecture
The goal of this appendix is to provide the reader with a Business Process Reference
Architecture. 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 BPM
solution.
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 the
backbone 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 server
more than one line of business.
The SOA approach has several benefits including:
Reusability: The federation of services frees software modules from being redundantly
deployed 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 that
functionality.
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 a
wrapper interface around them. This allows easy integration of modules across disparate
systems.
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.

Copyright IBM Corp. 2009. All rights reserved.

21

ArchitectureGuide.fm

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

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 of
business processes. It is one of the first times in the history of software architecture that
business 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 of
logical layers. The IBM SOA Reference Architecture (SOA) provides a roadmap and
guidelines for the architectural, design and implementation decisions. Additionally, it provides
patterns and insights for integrating these aspects to enable end-to-end, SOA-based
business solutions.

Channel

B2B

IVR

Consumers

Business Process
Composition; choreography;
business state machines

Service
Consumer

Services
atomic and composite

Service
Provider

Service Components

Operational Systems

Packaged
Application

Custom
Application

OO
Application

Integration (Enterprise Service Bus)

QoS Layer (Security, Management & Monitoring Infrastructure Services)
Data Architecture (meta-data) & Business Intelligence
Governance

Figure A-1 IBM Reference Architecture for BPM

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

22

BPM Solution Development Guide

ArchitectureGuide.fm

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

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 existing
software systems are part of this layer. Those systems include:
Existing custom applications, including J2EE applications (such as the Services already
developed 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) and
Service Data Objects (SDO) specifications.

Services
This layer consists of all the services defined within the SOA. For the purposes of this
reference 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 with
sufficient 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 a
description 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 service
identification activities like SOMA or can be based on reusable industry assets like the
Websphere 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 choreograph
services into flows, thereby establishing applications out of services. These applications
support specific use cases and business processes. To do this, visual flow composition tools
like 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 D
from the services layer. Process P contains the logic for the sequence in which the services
need 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.

Appendix A. Define a BPM Reference Architecture

23

ArchitectureGuide.fm

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

Consumers
The consumer layer, or the presentation layer, provides the capabilities required to deliver IT
functions and data to end users to meet specific usage preferences. This layer can also
provide 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 correct
service provider and between layers.
These include modest point-to-point capabilities for tightly coupled endpoint integration as
well 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 service
implementation 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 exchanging
business data. For example the NGOSS SID implementation in the Websphere Fabrics
Content pack.

Governance capability
The governance layer covers all aspects of business operational life-cycle management in
SOA.

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), service
component layer (Enterprise Service Bus), operational layer (CRM systems, Billing
Systems,...).

24

BPM Solution Development Guide

ArchitectureGuide.fm

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

Note: The logical architecture diagram will help you to find a common understanding on
the architecture. All logical components described in the section below can be
implemented by IBM products. This considerably gives the capability to accelerate the
development of such as solution.
From top to bottom, we are going to show the meaning of each of the components of figure
Figure 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

Frontend Specific
Data Model

Industry Specific
Business Process
Data Model

WebSphere
Business Process
Management Engine

Business
Process Specific
Mediation Layer
(Industry Specific)

Application Enterprise Service Bus

Third Party Business

Process Management
Engine

Application Enterprise Service Bus

Third Party ERP

Systems

Application Enterprise Service Bus

Corporate Enterprise Service Bus

Industry Data
Model and
Services
Application Enterprise Service Bus

Services
Registry
and
Repository

Application Enterprise Service Bus

Corporate
Service
Mediation Layer
(Industry Specific)

Backend Specific
Data Model

Backend
Specific
Mediation Layer
(Provider Specific)

CRM System

Billing System

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 using
XML Schema.
A view is some form of visualization of the state of the model.

Appendix A. Define a BPM Reference Architecture

25

ArchitectureGuide.fm

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

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

Controller

Model

View

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 the
datamodel 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 generator
provided 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 a
separate completely decoupled layer.
Note: It is not recommended to outsource controller logic from the GUI into the underlying
Business Process components. Logic between pages (pageflow) needs to stay in the GUI
to avoid performance and synchronization issues.
The datamodel depicted in Figure A-4 used by the consumer components includes specific
information, 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 components
should be directly embedded into the GUI itself.

Frontend Specific
Data Model

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 underlying
business process specific datamodel. Differences are required as soon as the GUI includes

26

BPM Solution Development Guide

ArchitectureGuide.fm

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

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 technologies
which can be used to implement the GUI. Examples are JSF, Struts, WebSphere Portal
Server, Lotus Forms, WebSphere Business Space,....
Note: WebSphere Business Space is delivered as a component of the IBM BPM suite. It
includes Lotus Forms technologies to communicate with underlying processes. It has
strong capabilities to accelerate GUI development on the Front End side.
Out-of-the box tools such as the WebSphere Business Space or the Business Process
Explorer act directly on the underlying Business Process datamodel and do not permit an
abstraction on that level.
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.
2. Business process components
The business process components include orchestration logic, a datamodel and mediation
logic.
The orchestration or choreography logic is expressed in form of BPEL (Business Process
Execution language for WebServices). This logic is usually imported from a more high
level 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 the
Business Process such as conditions, necessary input to retrieve information from
backend services, (e.g customer id, order id,...), measurable metrics, input for Key
Performance 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 Business
Processes. The executable processes, each a choreography of Activities, have to be defined
prior to execution in a process Definition or a Process Template.

WebSphere
Business Process
Management Engine

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
Appendix A. Define a BPM Reference Architecture

27

ArchitectureGuide.fm

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

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.

Industry Specific
Business Process
Data Model

WebSphere
Business Process
Management Engine

Third Party Business

Process Management
Engine

Third Party ERP

Systems

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.

Business
Process Specific
Mediation Layer
(Industry Specific)

Application Enterprise Service Bus

Application Enterprise Service Bus

Application Enterprise Service Bus

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.
Note: WebSphere Process Server includes an own Enterprise Service Bus named
WebSphere Enterprise Service Bus which can be used to mediate between the business
process components and the corporate services components.
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:

28

BPM Solution Development Guide

ArchitectureGuide.fm

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

This datamodel guarantees the Business Process Alignment of encapsulated software

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

Corporate Enterprise Service Bus

Industry Data
Model and
Services

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 underlying
service components should be ideally be non-transactional, slim and concentrate on high
performance transformation and dynamic routing (cross-company).

Corporate Enterprise Service Bus

Corporate
Service
Mediation Layer
(Industry Specific)

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 ESBs. (very often
application ESBs are in different departments).
Note: This layer can for example be implemented on WebSphere Datapower XS50. It
should be slim and highly performant.

Appendix A. Define a BPM Reference Architecture

29

ArchitectureGuide.fm

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

4. Service components
Important: Do not confuse service components with Service Component Architecture.
Service components is a layer in the layered IBM reference approach and has nothing to
do with the SCA framework.
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 (xml
schema). For email communication it would for example to, from, cc and subject
information.
Protocol conversion layer (adapters) capable to transform legacy protocols into xml
standardized protocols.
Mapping layer to map between legacy dataformats into standardized (xml) dataformats.

Application Enterprise Service Bus

Application Enterprise Service Bus

Backend Specific
Data Model

CRM System

Billing System

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 mediation
between 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 legacy
systems
WebSphere Enterprise Service Bus or WebSphere Message Broker for communication
with JCA adapters which are available for Email, FTP, Flat File, Siebel, SAP and many
others.
ERP specific ESBs 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.
Note: Please find information on Adapters at the following link : IM Information Server,
CICS and WebSphere ESB.
5. Governance services

30

BPM Solution Development Guide

ArchitectureGuide.fm

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

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 in
combination with a central repository. WIthout a Services Registry and Repository, the
corporate IT Services governance could quickly out of control. It is therefore a very important
component within an SOA.

Services
Registry
and
Repository

Figure A-11 Services Registry and Repository

Its characteristics are :

Enable SOA governance of your services throughout the service lifecycle.
Promote reuse and eliminate redundancies by increasing visibility of services, applications
and processes.
Enhance connectivity by increasing runtime flexibility of applications integrated using the
Enterprise 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.
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 to
be completed to design a BPM solution. There are yet other ways to do this, however we
have chosen this way to be particularly adapted to the needs of the Better Healthcare
Approach..

Implementation approach
Process Models, Key performance indicators, Business Process Datamodels and Screen
Mockups are designed top-down. All decisions for on these artefacts are being taken by
Business directly. For example datamodels are created in a tabulator such as Excel and
then imported into WebSphere Business Modeler. No advanced IT tooling required to
model 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. The
Service layer above needs to accomodate and map to this layer.

Appendix A. Define a BPM Reference Architecture

31

ArchitectureGuide.fm

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

Process
Models

Organizations

Policies

Business
Rules

Top-down implementation effort

Business Team

End User
Experience

BPM
Engine

SOA Steering
and governance
team (Business,
Integration and
IT teams)

Business
Rules
Engine

Services
Registry and
Repository
(Policies)

Meet-in-the-middle implementation effort

ESB
Corporate
Service
Components

Corporate
Service
Components

JCA
Adapters
Bottom-up implementation effort

Integration Team

Existing
Services

IT Team
Exposed
CRUD service
components

JCA Adapters

Generated
interfaces from
underlying
applications

Existing APIs
to legacy
applications

Figure A-12 BPM implementation solution guide assumptions

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 dependencies
between the datamodels and considerably reduce the capabilities of the solution layers to
be loosely-coupled.
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 with
underlying systems and services.

BPM Layer

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.

32

BPM Solution Development Guide

ArchitectureGuide.fm

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

Important: Definition of a mediation layer between corporate service layer and BPM
layer 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 acts
as an integration contract between the BPM layer (and other layers) respectively the
Service Components (Backend systems). The canonical datamodel should be designed
independently from the efforts in the BPM layer and service component layer.

BPM Layer
Includes a
canonical
data model and Corporate Services Mediation and Mapping Layer
services

Corporate
services
mediation
layer

Corporate Services Layer

Corporate Services Mediation and Mapping Layer

Represents
backend
services

Service Component Layer / Operational Services

Figure A-14 Corporate services and datamodel

Appendix A. Define a BPM Reference Architecture

33

ArchitectureGuide.fm

34

BPM Solution Development Guide

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