The Process Centric vs. Information Centric approach to SOA
| 13 January 2010 |
In 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.
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).
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:
- Architecture 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.
- The 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 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.
|
|
|
Tweet |
16 comments
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.
Val - 15 01 10 - 03:19
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?
Eric Jan Malotaux () - 15 01 10 - 10:07
Val, Eric Jan, thanks for the useful additions!
For the patterns mentioned by Val see: http://martinfowler.com/eaaCatalog/
Johan den Haan () (URL) - 19 01 10 - 10:01
Do not miss the comments in the SOA SIG on LinkedIn: http://www.linkedin.com/newsArticle?view..
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.
Johan den Haan () (URL) - 19 01 10 - 10:11
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.
Iyigun Cevik () - 22 01 10 - 14:33
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.
Jacob Ukelson () (URL) - 15 02 10 - 12:19
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!
Johan den Haan () (URL) - 15 02 10 - 20:21
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?
Mohammad () - 16 02 10 - 02:16
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/arc..
Johan den Haan () (URL) - 16 02 10 - 19:56
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.
- 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.
Besides that the process flow can partially be derived during the execution using eg a rules engine to determine this.
PeterPaul () (URL) - 22 02 10 - 11:17
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/arc..
Johan den Haan () (URL) - 23 02 10 - 19:33
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.
Marcin Stefaniuk (URL) - 17 05 10 - 16:57
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-Ar...
Parameswaran - 19 08 10 - 18:31
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-ce..
http://www.acsi-project.eu/
http://bpm2012.ut.ee/
Ian Ramsay () (URL) - 10 07 12 - 11:44
Hi Ian,
Thanks for adding this valuable information to the thread!
Johan den Haan () (URL) - 11 07 12 - 17:13
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.
Jim Pennington () (URL) - 14 07 12 - 21:28
Be nice. Keep it clean. Stay on topic. No spam.
