Don't mix models and realization?

Active Endpoints has long experience from process execution environments. In this post, Michael Rowley gives his response to the BPEL vs. BPMN debate. Michael is questioning the relationship between models and its realization. He makes a note about the tiny little details you need to add to your model for making it executable saying - "... and they can’t be fuzzy or imprecise" about the ability to express them in BPMN.

Model-driven design is a hot topic, not just in the BPM space but in all software development domains. Business people have been invited to the round tables when discussing software design, thanks to the modeling approach. Certainly there will be initiatives taking the model too far, but in a couple of years there will probably be a balance between model and realization and we could hopefully work together with a seamless model-to-realization process ;).

Zip-top bags, monkeys, and BPM

I attended and talked at a BPM conference last week, arranged by IDS Scheer in Stockholm. One of the keynote speakers was a guy talking about human behavior and how to step out of the box.

He talked about how we act in front of airport security, when asked to put liquid and gels in a plastic bag, even though we know that bag will not be safe when the bomb goes off. This story relates to all the brainless people and ass-kissers we are put up to cope with during the work hours.

The best story was the one about the monkeys and the bananas. It went like this ...

Start with a cage containing five monkeys.

Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all of the other monkeys with cold water.

After a while, another monkey makes an attempt with the same result - all the other monkeys are sprayed with cold water. Pretty soon, when another monkey tries to climb the stairs, the other monkeys will try to prevent it.

Now, put away the cold water. Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys attack him.

After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.

Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth. Every time the newest monkey takes to the stairs, he is attacked.

Most of the monkeys that are beating him have no idea why they were not permitted to climb the stairs or why they are participating in the beating of the newest monkey.

After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water. Nevertheless, no monkey ever again approaches the stairs to try for the banana. Why not? Because as far as they know that's the way it's always been done round here.

And that, my friends, is how company policies are made.

So how does the monkey story relate to BPM?

Don't beat up the guy trying to improve your business processes with the clear goal of rationalizing you and your collegues?

Platform Evolution and 'Dublin'

Mapped a couple of vendors on to a general platform evolution time line. Process column refers to process execution capabilities, not BPM.

A few weeks ago Microsoft announced 'Dublin', a distributed host for WF/WCF based applications. 'Dublin' is an integrated environment within Windows Server, just like Internet Information Services, COM+, and Windows Sharepoint Services. BizTalk will now be positioned as Microsoft's answer to IBM's, Oracle's and BEA's integration suites. 'Dublin' takes a step up on the platform evolution and aligns to products like WebSphere Process Server, leveraging Workflow Foundation.

The only remaining question now would be - what will be the real product name?

BPM tries to appease process workers

I recently watched a free BPM seminar with Forrester's Connie Moore where the result from an online survey was presented. The question was "What do you see as the primary benefit of BPM efforts?"

1. 24% said Increased productivity for process workers
2. 18% said The ability to provide real-time visibility into key processes
3. 15% said The ability to change processes quickly and easily
4. 13% said The ability to model business processes
5. 12% said Consistent process execution across business units or geographics
6. 12% said Optimization of processes
7. 4% said Decreased reliance on IT for supporting and changing processes
8. 1% said The ability to test work for compliance and remediate problems

I can agree that 2-8 are relevant to BPM, but increasing productivity for process workers I would say has nothing directly to do with BPM. There is an indirect link between BPM and productivity though. BPM should definitively be a driver for IT investments to increase productivity, like ECM, BI, Enterprise Search, Collaboration, Messaging, etc.

I think this result is just a way to appease the process workers who fear BPM. Name one capability of a BPMS that will increase the productivity directly of a process worker.

Prepare for multitenancy

I quote from Wikipedia:

"Multitenancy refers to the architectural principle, where a single instance of the software runs on a software-as-a-service (SaaS) vendor's servers, serving multiple client organizations (tenants). Multitenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations. With a multitenant architecture, a software application is designed to virtually partition its data and configuration so that each client organization works with a customized virtual application instance."

A normal situation today would be a company cutting out a functional unit within in the organization to make it autonomous and reusable for new customers (Pict 1). This is the way companies do controlled out-sourcing. Another out-sourcing scenario would be to cut off the function and replace it with something total new on the market.



Picture 1: Cut-off-and-reuse scenario.

In the cut-off-and-reuse scenario the new company will most often be required to work with multiple customers. As wikipedia describes it, you can do it in several ways from a system perspective.

1) Hardware Virtualization (multiple OS-instances on the same hardware running the same application)
2) Application Virtualization (multiple application instances on the same OS running the same application)
3) Access Virtualization (multiple remote desktop users one the same OS/application instance)

These three alternatives are all shortcuts to be able to host multiple clients in the same system. The good side with this is all the operational support you get from infrastructure support like Microsoft Virtual Machine Manager and Citrix. But the bad thing is the lack of reusability and flexibility you get from these solutions.

Going from one client to multiple clients would most often result in a new architectural dimension. This new dimension will not just require more or extended database schemas, but also different UIs, different rules, processes and an open architecture where services can be composed, reused and differentiated for different customers. The fourth alternative calls for multitenancy.

4) Multitenancy (design for multiple users on the same application)

Q: How do you design a system to be prepared for multitenancy?

A: The book is not yet written, but the author who does will be rich and famous. I put my money on Full SOA Applications.

SOA is just an enabler

Enablers are things that realize the potential of something else. That something use the enabler as a foundation for its own success. An enabler is by it self not worth too much.

Drivers are things that see the potential in other things. A driver can be something that makes use of that other thing, and makes it interesting.

When a driver and an enabler come into a direct relationship, you got a strong pair. Let's take XML and Web Service for example. XML is an enabler for Web Services and Web Services is the biggest driver for XML. XML and Web Services is a strong pair.

Another example is SOA. SOA without Web Services is not an option in this millennium and what would Web Services be without a good organized and managed SOA?

So why are we building an SOA? What drives an SOA? Lot's of things, but the most obvious one is Business Process Management (BPM). BPM is a good driver for SOA where services are used to build up end-to-end process implementations. One could argue if BPM has a value without enabled by a SOA, and I strongly agree. A BPM should be leveraging a SOA.

Building cross-functional process implementations is interesting for a couple reasons like, visibility, agility, etc. But the one with most business value is Performance Management (CPM). CPM will definitely be enabled by BPM since process implementations are fastest way to produce accurate performance values on demand.

ODE graduated from incubation

I've only been following ODE from using Intalio but now I downloaded the bits to try it out. Together with Eclipse BPEL Editor you can build your orchestrations pretty easy. Not as a nice as ActiveBPEL and ActiveEndpoints's BPEL Designer. I will try out in more depth another time.

Read more here.

Let the bus go

Any Enterprise Services Bus on the market is capable of doing application integration from native adapters. Some ESBs are built on a service bus topology and some on a hub and spoke. Some are modified EAI products with web services support. Almost everyone can manage routing, transformation, logging, and other mediation services. Some have integrated rules support, but should all those features be managed as one single unit as in this picture?



Let's separate things out into a better logical architecture. First, a EAI product mainly support publish and subscribe funtonallity, which is not part of a true SOA. Let the EAI product do what it's supposed to do (i.e. integrate applications natively) and expose required functions as web services.

Secondly, break out rules, process, and service registry and make them accessable through web services. Expose web services from the master data and use a common mediation layer in between all enterprise services and the consumer layer. This way you will virtualize any application (including your EAI product) and keep all physical services under one umbrella.



Using mediation will get rid of the service bus architecture, which really is a questionable topology. With mediation, agents will not be necessary because the physical service will need no management. The mediation controls all traffic and will be the place for manage versioning, enrichment, etc.

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.