Can we become slaves under the BPMS

At the beginning there were just common sense. Then we turned our common sense into experiences and after that routines and finally processes. People went from processes to process automation where the process were governed by IT-systems.

These systems were called BPMS which gave the impression of agility in terms of process changeability. They managed processes, measured the efficiency, simulated and improved the processes. Each new lap around the BPM cycle took away a part of the original common sense. We gave it a few laps more and then the processes were finally based on everything except common sense.

Could that be a real scenario with BPMS?

Process Orientation and Separation of Concerns

Suppose you have the following sequence of a loan process:

After pre-qualification has been made and if the value is greater than $1000, send an approvement task to a loan approver using email.

When implementing this process sequence, a couple of questions pops up related to Separation of Concerns (SoC):

- What if the approvement rule changes to "if the value is greater than $1000 and age is less then 21"?
- What if email is not enough for notification mechanism and we want to add SMS messages?
- What if loan approvers need help from other roles?

Putting to much information details into a process implementation will not result in a good SoC. Process implementations should only be modified when the process changes, not when rules or services are. Instead of implementing all details directly into a process engine, try to split your process sequence like this:

The When - "After pre-qualification has been made" goes into the process engine
The If - "if the value is greater than $1000" goes into the rules engine
The What - "send an approvment task" goes into the process engine
The Where - "a loan approver" goes into the mediator
The How - "using email" goes into the mediator

Good design often lead to less visability, and this is no exception. If the process says "using email" or "if the value is greater than $1000" then the implementation should say the same to reach good visability. But visability is not that important compared to using the right model (based on processes, rules, and services) and implementing it with a good SoC.

BPEL4People to OASIS

The BPEL4People specification has been submitted to OASIS by a number of vendors including IBM, Oracle, SAP AG, Adobe Systems Inc. and Active Endpoints Inc.

More posters

Here is a WS-* poster I found. Could be nice on the wall beside your bed.

BPMN Poster

Here is a BPMN poster I found at Keith Swanson's.

BPM - Centralized or not?

I attended a panel discussion at BPM in Action virtual conference today. I took the chance to ask whether the panel think BPM will be implemented in an enterprise centralized fashion (orchestrating enterprise services) or as a part of applications.

Kiran Garimella's avatar Dr. Jeffrey Sterllings answered by saying that the future of BPM will be a centralization of process implementations. Traditionally BPM has focused on a cross-functional process level. That means processes integrating applications within different organisational units (such as marketing, sales, finance, etc). But are those cross-functional processes really the most interesting to manage and measure, or is it the processes within a function/application?

For me it feels like a déjà vu, the whole centralization idea. EJB failed big time when trying to be the one and only point of integration to enterprise data. Will the BPMS fail for the same reasons, trying to be the one and only point of integration to enterprise services.

Vendors like PeopleSoft, SAP and other will not stand still watching their applications being disassembled into small services to be orchestrated in a centralized BPMS. They will probably provide BPM support as part of their own applications. And I'm affraid that every custom build application will host their own process implementation with more or less support for BPM. A call centre application would probably implement its own workflow engine, since the whole idea is to manage and measure the sequential activities. Same goes for a CRM and for a lot of other applications in an enterprise.

It will also be interesting to see if other vendors will follow Microsoft and provide a process engine framework for ISVs. Workflow Foundation supports process management and can be hosted in any .NET application.

How, what, when and why SOA?

After taking part in a recent discussion on SOA, I would like to say that SOA doesn't answer the questions How, What or even When in terms of use, but do answer the question Why.

How?
There is a misunderstanding that SOA has something to do with how people should implement their services or group them in types of service behaviors. SOA makes no difference between services implementing master-data, processes, use-cases, entities, identities, rules, or legacy adapters nor does it care. To SOA a service is just a service.

What?
SOA doesn't require a specific message-passing technology but Web Services is preferred for obvious reasons.

When?
SOA is not suitable in all situations - but that isn't up to SOA to decide. The answer here is dependent upon the how and the what described above.

Why?
SOA answer the why-question with - to achieve business agility. Not by how services are implemented or with what technology is used, but with service management - the things that happens between the 2 service endpoints during a call. Things like versioning, routing, filtering, virtualization, en/decryption, en/decoding, monitoring, transformation, logging, translation, billing, validation, etc - all packaged in a nice runtime governance tool.

Why patterns?!

Why can't you find a polymorphic pattern for OOD? Because it's so obvious!

Polymorphism is part of the paradigm and part of the oo-languages. It's not obvious how to use polymorphism, but there are no patterns describing it. Design patterns seems to concern ideas not really aimed for a specific software paradigm. I been thinking why patterns play such an important role today. It's just my believe that where ever there is a pattern, there is a shortcoming in the underlying paradigm/languages to solve a specific problem. I'm joining in criticism of patterns.

Cutting slices from a blob

I liked the way Mats Helander described service-orientation. To understand the good thing about SOA you really need to see it from the business perspective. From a 10000' view, IT really looks like a big blob. On a 1000' view, you can discern smaller blobs which are applications (aka black boxes or silos). The SOA will help breaking up the applications in small services that can be composed into new services based on policies. The selection for how the services will be used in a composition is up to the heart of the SOA - the mediation layer. The mediation layer (such as WCF or Synapse) will make sure that the policies are applied correctly.

Some people claims that service composition (orchestration) is part of the SOA paradigm. I would rather give credit to BPM for techniques related to service composition.

A Business-Oriented Architecture

While some people keep fighting for their knowledge domain, the world change around them. I'm talking about program languages, design tools and runtime engines, still using object-orientation as a model for implementing a business critical system. Since the early 90th object-oriented architectures have been the main technology platform for building solutions for business. What we got with us from those years is that technology driven view point of software development is bad. Whether an object-centric perspective helped the programmers understand the business or not isn't relevant. What we do know is that noone else understood the object model. Lot of initiatives have tried to bridge between the business and the OO model. Most of them have just made it worse, with really high cost as a result for software development.

No, there's a need for a new, better model for designing software. Something that the business can relate to, something that everyone can relate to. Processes and services are keys to this new model. We have all heard all the great stuff we can do with SOA and BPM, but what are the differences and can they play together?



A process-oriented architecture (POA) fits a company that's frequently changing and improving their business processes. This architecture supports a process improvement life cycle where bottle necks and bad design are found and adjusted using analyzis tools. A POA is a platform using a transparent model for business processes that aligns the business with IT very well.

A service-oriented architecture (SOA) on the other hand suites a company reorganizing their business structure frequently (such as out-sourcing, mergers and acquisitions, internal reorginization, etc). The main goal with a SOA is to control the services based on policies. These policies are defined in the service management framework. A SOA gives the agility in a business where services easily can be controlled from using service governance. A SOA will provide the virtual service mediation layer between the service consumer and the service producer where loosely coupling is crucial.

Normally a company would agree that both transparency and agility is important for their business. The only way to achieve this is by taking the road from OOA to a business-oriented architecture (BOA). This is a platform where the best from BPM and SOA is combined. People from the BPM community call this platform BPM 2.0, while some call it SOA 2.0. I think something neutral as BOA is more diplomatic.

The next question would be to ask which way is more natural to go from OOA to BOA, the red or the blue road. I would say the red because SOA is the foundation for a successfull POA.