Two architects from IBM published an interesting article about “[Taking] advantage of Web 2.0 for next-generation BPM 2.0“. In summary, this is how the authors define BPM 2.0
- Leverage the entire Web for process collaboration (mashups, SaaS)
- Convergence of BPM, SOA, and Web 2.0
- Web 2.0 as a driving force in BPM
- Allowing for the involvement of more business process analysts
- Faster development and content creation
Here is how they justify the first point (mashup, SaaS)
[it] means reaching out to the entire Web and encouraging collaboration to solve issues. In the context of the enterprise, it means using Web 2.0 technology cost-effectively in the underserved part of the enterprise, which couldn’t previously justify the expense.
You bet, the biggest impediment to BPM has been cost and skills required to deploy managed processes. Not to mention that most products have been built by developers for developers. This creates an overall environment that makes business-IT alignment difficult if not impossible. The key driver behind a BPM solution is serve the business and being able to adapt to its (unvoidable changes). This is really how you can reach “the underserved” parts of the enterprise. If you have to spend $1 Million (licence + hardware + technical consulting + …, nonewithstanding the ususal outrageous maintenance fees) and wait 1 or 2 years before you can deliver any value to the business, your BPM initiative will not go very far and will be seen as a major risk to the business… and it is indeed a major risk to business: it’s got no plausible return on investment.
The Convergence between SOA and BPM is nothing new. They are really the two faces of the same coin like many have said before: it is not really a “convergence”. To make a long story short, processes are high services when looked from “far away” (black box perspective on the process), processes make use of lower level services, and lastly looked at from “clse enough” services are lower processes (white box perspective on the service). It is that layered view that brings value and re-use in a BPM+SOA approach. Speaking about “convergence” of the two is somehow a misunderstanding of the whole picture.
For Web 2.0, the authors explain :
you can use Web 2.0 to bring in rich Internet interfaces and a robust user experience using Asynchronous JavaScript + XML (Ajax) and Adobe Flex
Yes, we thought a little bit (:-) about that. We also thought about faster development and content creation, as a matter of fact our tool is one of the easiest to use in the industry: we are not not using “proprietary notation”, and yes, we also thought how “Easy-to-use Web-based technology” makes it a lot easier to involve the business and business analyst during the design of the process. Since our tool can be used from any browser, anyone who is authorized to login can see the process, possibly modify it or look at the analytics reports.
The Features of BPM 2.0
- Rich user experience
- Process tagging
- Lightweight integration model
- BPMN and BPEL
- Zero code
- Dynamic process optimization
- Business performance optimization
- Industry flavour in BPM
We just commented on the rich user experience, which is critical both during design and performing task (we recently added an integration with Frevvo ). We also commented on “process tagging” and how people can collaborate on process design because RunMyProcess makes them always available to anyone that need to draft, comment or design something. Our engine also offers Web 2.0 integration points via RSS and REST services to make it easy for users to perform tasks in their favorite environment.
We also believe in the lightweight integration model. RunMyProcess can easily implement integration scenarios as subprocesses, it comes also with a large set of connectors for leading Cloud Computing Platforms like Amazon Web Services, Zoho, Coghead…
BPEL or not BPEL? If we strongly believe in BPMN, we have quite a few doubts for BPEL as an business process execution language. First we do not believe in portability, simply because there are too many issues other than the “code” to port such as integration with back end systems, or alignment of the organizations’ structures, change manageent and so on. BPEL as an execution language itself offers no compelling reasons to be used at the core of our platform. It’s missing features that we find important, such as a proper handling of human interactions, which is “only” critical; and most of all, there is no easy transformation between a business oriented notation and BPEL. If we were to use BPEL actually, we believe we could not reach the objective of “Zero Code” which is very important to us. Zero Code is the key to bring users, analysts and developers to work in the same environment. It does not mean that developers will be out of the loop one day, they probably will always be around but they’ll be able to deliver far greater value to the business. Finally BPEL or not BPEL? Well, the technical language in use is just not the point of business process management. (incidentally, for picky techies, yes we are compatible with BPEL, any XML description of the same thing forming a “class of equivalence” ;-))
“Dynamic Process Optimization” is one of our strongest point at RunMyProcess. We are totally in line with Business Process Improvement initiatives and the approaches they use. Our tool is one of the better suited to achieve that.
“Industry Flavour in BPM” is something we have been thinking for quite some time. We are preparing industry accelerators to help you get started with your BPM initiatives and further diminish the time to ROI while reducing the risk. Most SaaS Solutions are “customizable” but the most critical aspect of customization, processes, is absent from their model.
The real problem that BPM 2.0 needs to tackle is to put an end to endless IT projects. BPM 2.0 is about promoting an agile implementation to Business Process Management and go back to very short iterations, perfectly aligned with Business Process Improvement. Why? because by definition, business needs evolve over time and are influenced themselves by the solutions that were built to support them. So, we do think the authors have forgotten a couple of items on their BPM 2.0 list:
- The Form Factor of process engines.
- Ubiquity
RunMyProcess changes dramatically the form factor of traditional Business Process Engines. You no longer need a large budget to get started, you no longer need to take risk in deploying a large and unfamiliar piece of infrastructure in your organization in several environments (development, test, production…). We have done all of that for you already. You can be up and running with your first process in 2 weeks or less, including training and with a small monthly subscription, you can probably reach the point of ROI within 3 to 6 months.
For us, 2.0 also means “ubiquity”, tools and activities need to be accessible from anywhere. Collaboration is not just for employees of your organization, it must also support collaboration with your customers and your business partners as well. With RunMyProcess, you no longer need arcane tools deployed on powerful laptops that only a few people can use.
So, this article couldn’t provide a stronger justification for RunMyProcess, our BPM-as-a-Service model and our use of Web 2.0 technologies.
Matthieu Hug