The Process Centric vs. Information Centric approach to SOA
of my recent articles I
stated: "it is questionable whether enterprises can actually maintain
a focused strategy long enough to align their core business processes
with IT". The point: software needs to become more flexible in
order to adapt to the fast changing business environments of today’s
To make software more flexible we need
to move from an application-centric architecture to a Service-Oriented
Architecture (SOA). Nice sentence… but what are the building
blocks of such a SOA? Business process engines? Business rules engines? Service-Oriented Business
In this article I want to analyze how
we can create a SOA landscape truly aligned with the business processes
it needs to support. How to model processes and how to create services
implementing these processes?
- A business process is user-centric.
- The process-centric approach
to building SOAs delivers flexibility, but also has some serious disadvantages
like state synchronization issues, ignoring resource transformations,
and not enough focus on the system architecture perspective.
- The information centric
approach to building SOAs is stateless, flexible, and mirrors the nature
of organizations. The downside is complexity.
What is a business
If we talk about SOA and Business Process
Management (BPM), the first question which comes to mind is: what do
we exactly mean by ‘business process’? Thanks to the Business Process
Execution Language (BPEL) a lot of people see service orchestrations
as business processes, but are they?
A business process is modeled from
a user point of view. A business process model should instruct the user
what to do, it should visualize how actors in the organization collaborate
and communicate. It never models the response of the systems to the
user input (see Dubray,
The Seven Fallacies of Business Process Execution, 2007). A good rule-of-thumb I often use is that
in a business process each consecutive activity is executed by a different
actor. The two pitfalls are:
- Multiple consecutive activities
are executed by the same actor. In this way you are creating work instructions
instead of a business process.
- One activity contains a
series of activities executed by multiple actors. Now the abstraction
level of your process is too high.
So, a business process is NOT a service
orchestration, it describes the activities of actors in an organization.
Actors can be ‘implemented’ by humans or by IT systems. Within an
organization a distinction can be made between different types of actors,
based on different human abilities (see Modeling
an organization using Enterprise Ontology).
Some actors can be implemented by IT systems, some can only be supported
by IT systems. The central question for this article is how we can support
a business process with IT by either implementing or supporting actors
with IT systems.
When we talk about implementing business
processes the terms BPM and SOA are often used. In a process centric
approach to SOA the business process is translated into a service orchestration
(mostly in BPEL) and executed with a business process engine (BPEL engine).
This service orchestration calls services which need to be provided
by IT applications.
1 – Process payload and application interaction in a process centric
As visualized in Figure 1 the service
orchestration, or process for short, retrieves data from applications
via the service layer. During the execution of the process the so-called
process payload will grow. This process payload represents the state
of the process. The process engine maintains this state and for flexibility
reasons this state is saved in the process engine, not in the back-end
applications. After the execution of the process is finished, the result
of the process is written back to the applications via the service layer.
In this context it is possible to make
a distinction between two kinds of data: master data objects and process
objects. Process objects only exist for the duration a process (for
example quotations, job applications, etc.). Master data objects life
much longer (examples: customer, product, etc.).
on the previous we can conclude that at least the following layers are
needed to constitute a process centric SOA:
- Process layer: orchestration
of services, registration of process payload.
- Service layer: service
registry, mappings, adapters.
- Application layer:
(transactional) applications, databases, etc.
This process centric approach to SOA
offers quite some advantages. While all process logic is separated from
the application logic it can be changed without having impact on the
application code. This means it is faster to change, leading to a higher
flexibility and lower costs.
However, there’s also a downside.
This way of automating your business processes can lead to the following
- It is not flexible enough.
You need to know each possible path in your process at design time.
In reality however, in lots of situations the process flow is only determined
during the execution itself.
- The use of a central process
engine maintaining the process payload can lead to synchronization issues
between the process state and the applications. For example due to errors
during service calls.
- This way of executing /
automating business processes is mainly based on representing a business
process with a service orchestration. As Jean-Jacques
Dubray showed this is not
trivial and it ignores the nature of business processes: transforming
- Closely related to the previous
point: a process centric approach doesn’t automatically lead to the
right services, business objects, and messages. I do not say it is impossible
to define the right IT architecture when using process engines. It’s
just an easy pitfall to just focus on the process and define services
for it, instead of looking at these concepts from a systems point of
An alternative for the previously presented
process centric approach to SOA is, what I like to call, the information
centric approach to SOA. This approach attempts to solve some of the
problems of the process centric approach. Instead of supporting business
processes by defining service orchestrations as fixed flows, the information
centric approach supports business processes by defining activities
with pre and post conditions. Simply said: each activity in a business
process is represented by an implementation of that activity and a pre
and post condition for this implementation.
An example definition for a create
invoice activity can be:
- Order or exists
- or.customer has been
- or.status is delivered
- Activity: create invoice
- Invoice in exists
- in.amount is or.amount
By implementing business processes
in this way the implementation is very flexible and stateless. The state
of a process is based on (derived from) the state of the business objects.
Services are not orchestrated by a central process engine but react
on events. The example above should listen to events send when the status
of an Order changes. Once it is set to “delivered” (and the other
pre conditions are met) the service will execute its implementation.
Due to the central notion of events the information centric approach
to SOA is often called an Event-Driven
2 – Components in an information centric SOA
Figure 2 shows an overview of the elements
of an information centric SOA. There are two of them: components and
an event engine.
Components publish services and provide
the implementation of the published services (see the Service Component Architecture
– SCA). Components can
be legacy applications with a service layer on top, or the building
blocks of newly build Service-Oriented
Business Applications (SOBA).
Components contain the implementations of activities, subscribe to events
for checking the pre conditions, and publish events for fulfilled post
The event engine manages all the events
exchanged between the components. It provides channels to publish and
subscribe to. Think about a channel for the status updates of a certain
object type for example. I am just calling it an event engine, the actual
implementation depends on wishes around complexity, analytics, etc.
In some cases it can probably be a business rules engine; in other cases
you will need something like Complex
Event Processing (CEP)
(more information on business
rules vs. CEP). The event
engine is not necessarily a single, central component. You can also
think about it as a set of infrastructure services providing the facilities
for application services to communicate and exchange events.
If you want to read more about implementing
components based on object states, events, and loosely coupled services
you can read:
requirements for Service-Oriented Business Applications: one of my previous articles explaining the
why of SOA and how to implement SOBA’s with different types of services
and (modeling) languages.
Seven Fallacies of Business Process Execution:
excellent article pointing at the fallacies of BPM and providing an
example of how to implement a business process with resource lifecycles
and event / message based service implementations.
Based on the previous we can conclude
that at least the following layers are needed to constitute an information
- Event layer: event
channels, rules, CEP.
- Service layer: service
registry, publish / subscribe events.
- Application layer:
(transactional) applications / components, databases, etc.
An information centric approach to
SOA can lead to the following advantages:
- Processes are stateless:
no state synchronization between processes and transaction systems.
State is (re)constructed based on pre and post conditions.
- Very flexible: you
can just model every possible situation. With rule inference and CEP
you can handle very complex scenarios. Runtime flexibility is also possible.
- Mirrors the nature of
organization consists of actors collaborating and having social interaction. Business processes in organizations are about
transforming resources to create more value. An information centric
approach to SOA mirrors this with interactions among autonomous components
and the focus on business object states.
The main downside of this approach
is complexity. Having a bunch of activities with pre and post conditions
is not the same as simply reading a sequential service orchestration.
And it can become far more complex if rule inference and CEP come to
stage… Besides, designing the needed components, service, and their
interactions for a given process isn’t trivial too.
I think the information centric approach
to SOA is unavoidable in the long term. It is needed to mirror the complexity
of real life, to deliver the flexibility dynamic organizations need
The success of information centric
SOA implementations will depend on the tooling to design, analyze, and
simulate these implementations. We will need declarative, domain-specific
languages and central model
What do you think about process centric
vs. information centric SOA? What are your experiences with process
engines, rule engines, and/or event engines?
Photo by bocavermelha-l.b.