The Process Centric vs. Information Centric approach to SOA

FlexibilityIn one
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
enterprises.

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
Applications (SOBA)
?

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?

Article highlights:

  • 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
process?

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.

Process centric
SOA

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.

Business process payload and application interaction in a process centric SOA

 

Figure
1 – Process payload and application interaction in a process centric
SOA

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.).

Based
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
problems:

  • 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
    resources.
  • 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
    view.

Information centric
SOA

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:

  • Pre:
    • Order or exists
    • or.customer has been
      defined
    • or.status is delivered
  • Activity: create invoice
  • Post:
    • Invoice in exists
    • in.accountholder
      is or.customer
    • 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
Architecture (EDA)
.

Components in an information centric SOA

 

Figure
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
conditions.

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:

Based on the previous we can conclude
that at least the following layers are needed to constitute an information
centric SOA:

  • 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
    organizations
    : an
    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.

Conclusion

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
nowadays.

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
repositories.

I am convinced that we need to build a SOA in a model-driven
way
to be and
stay
flexible. In order to do so we need a framework for Model-Driven
SOA
.

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.

16 Comments Added

Join Discussion
  1. Val January 15, 2010 | Reply
    Amazingly, it looks a lot like Transaction Script vs Domain Model design patterns. From that perspective the "info-centric" SOA is unavoidable once the complexity grows beyond a certain level.
  2. Eric Jan Malotaux January 15, 2010 | Reply
    Interesting! The "stateless processes" reminds me of the "Separation of States" theorem of "Normalized Systems" by Herwig Mannaert and Jan Verelst. The Event-Driven Architecture evokes an association with CQRS (http://elegantcode.com/2009/11/11/cqrs-la-greg-young/). A lot of tasty food for thought! How does it all fit together?
  3. Johan den Haan January 19, 2010 | Reply
    Val, Eric Jan, thanks for the useful additions! For the patterns mentioned by Val see: http://martinfowler.com/eaaCatalog/
  4. Johan den Haan January 19, 2010 | Reply
    Do not miss the comments in the SOA SIG on LinkedIn: http://www.linkedin.com/newsArticle?viewDiscussion=&articleID=103347936&gid=36604 In short: it's not an either/or choice, you should combine process-centric and information-centric SOA. This can be done by using different types of services.
  5. Iyigun Cevik January 22, 2010 | Reply
    As Johan also mentioned this is not an either/or choice. Moreover I think you're talking about two different ways of implementing business processes. First way is using an orchestration service and second using process manager pattern (EIP), roughly speaking, by moving the process definition to the bus. Both ways has some advantages and one must consider both of them and choose the one which fits more. Most important point is the entity (resource) lifecycles (transition rules etc). As I understand, you are suggesting the "information centric" approach for exactly that reason. If someone gives enough attention to the entity lifecycles, which approach is chosen for implementing the business process.
  6. Jacob Ukelson February 15, 2010 | Reply
    This approach fits very nicely with human processes - where flows are impossible to model and emerge from the interactions of the participants. The participants each have a set of results that are expected of them, but the flow for each instance is emergent - based on participants and context. Since I always have assumed humans as the main actors, the composition of the emergent process is done by human skill and expertise, and our system focuses on tracking and management. What I find interesting in your approach is that you treat systems the same - describing what they can do, and based on each specific process instance, a flow emerges. Google Wave robots could be an interesting metaphor for this - having a robot waiting for specific annotations as its pre conditions, and annotating its modifications as post conditions. It would be an interesting experiment and could generate some surprising results - but it would be difficult to debug.
  7. Johan den Haan February 15, 2010 | Reply
    Hi Jacob, It's interesting to see how you handle the same kind of problems within a different context. Thanks for describing it so clearly, really an add-on to this article!
  8. Mohammad February 16, 2010 | Reply
    Hi Johan I need a business process model that a machine could process and understand it. Which of the approaches that you mentioned here is better for this exercise? Which books and subjects I supposed to study to get my answer? With business process I don't mean a business process which its activities are the operations of some services; I mean a business process that models the nature of the organization. Can I use Enterprise ontology that has been proposed by Dietz and you’ve used in your thesis?
  9. Johan den Haan February 16, 2010 | Reply
    Hi Mohammad, In my opinion the best way to model the nature of an organization in a manageable way is to use Enterprise Ontology. See http://www.theenterprisearchitect.eu/archive/2009/10/10/modeling-an-organization-using-enterprise-ontology
  10. PeterPaul February 22, 2010 | Reply
    Interesting read! Thanks. The downsides of the process centric approach you mention where not that convincing to me: * Some business actually need to know "each possible path in your process". This could be due to legislation, and requirements for managing and monitoring. Besides that the process flow can partially be derived during the execution using eg a rules engine to determine this. * Still wondering whether or not this can be solved by a solid design and implementation (based on guidelines to prevent this). * It could just be that the best way to solve a non-trivial task is not to implement a solution that adds complexity... A good modelling approach, like the one you mention, containing pre- postconditions for the transforming activities could help solve this. * I'm living under the assumption that there is no approach that does automatically lead to the right services. This goes imo for both mentioned approaches. Oh, by the way I think we agree that the Information Centric approach is the best way to go for a fair deal of domains.
  11. Johan den Haan February 23, 2010 | Reply
    Hi Peter Paul, You are right: in some situations and/or domains the process centric approach is necessary or better than the information centric approach. Adding complexity isn't smart indeed if we want to handle complex situations. That's why we need excellent tools to support the information centric approach to SOA. I think the information centric approach seems more complex from a helicopter point of view. However, while the processes are emergent and the activities autonomous, you can design / reason / think about activities in a context independent way. >I'm living under the assumption that there is no approach that does automatically lead to the right services. This goes imo for both mentioned approaches. Agreed! However, there are structured approaches helping you a lot. For example by using a formal organization model. See http://www.theenterprisearchitect.eu/archive/2009/10/15/an-enterprise-ontology-based-approach-to-model-driven-engineering
  12. Marcin Stefaniuk May 17, 2010 | Reply
    Very refreshing post! I think that idea expressed in your article can be called Inversion of Control in SOA. Extracting service launching rules from process to service itself is not only a matter of software architecture. It also moves such application toward knowledge driven. Main requirement in that case is to write pre- and postconditions in business readable language. Second is to store them in a form when they can be semantically queried and organized. The latter allows to manage complexity you mentioned.
  13. Parameswaran August 19, 2010 | Reply
    Nice post. One major advantage of the process-centric approach is taking the abstraction of the system closer to the business. This provides more control to the business in changing the process that the system supports. In the information centric model which is primarily event-processing based, gap could still exist between the business and the IT system and the process is not explicit to the business folks - this has been a perennial problem with the conventional architectures. The book "Process-Centric Architecture for Enterprise Software Systems" covers process-centric architecture style (PCA) in detail. Link is http://www.amazon.com/Process-Centric-Architecture-Enterprise-Software-Systems/dp/143981628X.
  14. Ian Ramsay July 10, 2012 | Reply
    I think quite the contrary ... It's time we took abstraction of the process data to the business, using Information-Centric methods. After all businesses currently process forms, documents, emails, phone calls and more. These information entities are much more tangible than "work" and, with a simple methodology, also prove simpler to define state life cycles. Valid (value-adding) entity states lead naturally to the Tasks required to change those underlying data states. In services this data state change IS the product the customer buys. Across the service sector we have blindly adopted a sequential process-centric design concept derived from manufacturing. (We have also adopted other techniques without much consideration, such as LEAN and 6-Sigma.) Procedural thinking is OK in manufacturing, as one is simply transforming the somewhat linear state changes of physical goods. Apart from rework this is generally a pattern of converging straight line flow of control & goods, including information about goods. In services our product to be processed is data and the lifecycle of a process entity is much more complex. Even the same logical data object can exist in multiple physical locations, contexts and formats, it may even be recorded on physical paper. In fact, Tasks are only ever sequenced (in any process) to align with the underlying data state changes. Think about it. In my experience, ALL real-world business processes are best be modelled, defined and automated using the Information Centric approach. Even the simplest flow or Process Centric looking business processes can chain pre & post conditions to form a local flow if necessary. It's never easy to meld technology design with business reality and engagement but apart from the simplest 20% of an organisation's processes the other 80% deliver the greatest business value and are definitely best modelled, defined and automated using an Information-Centric approach. There's quite some momentum developing in this area and the following may be of interest ... http://en.wikipedia.org/wiki/Artifact-centric_business_process_model http://www.acsi-project.eu/ http://bpm2012.ut.ee/
  15. Johan den Haan July 11, 2012 | Reply
    Hi Ian, Thanks for adding this valuable information to the thread!
  16. Jim Pennington July 14, 2012 | Reply
    I agree with Ian that process representation as information is the way to go. As architects I believe we have to move to being Pattern Centric to make the next big advance. There is an engineering master pattern by which we stitch information, process,rules and services together. There are patterns for forming information, and process, and rules and services as building blocks within the master pattern. Then, there are micro patterns for the elements of each of these. This engineering pattern is applied within the Enterprise Ontology. This also has enterprise patterns by which both behavior (process/production) and information can be defined. Holistic architecture of these patterns will be the future.

Leave a Reply