BPM 2.0 is Middle-Out
Saturday, June 3rd 2006 | Ismael Ghalimi
Christopher Koch recently wrote a great article on CIO Blogs, which greatly contributed to fuel the BPM vs. SOA war that has been raging in the blogosphere recently. BPM is presented as a top-down approach, while SOA would be a bottom-up one, and promoters of both approaches do not seem to be able to resolve their disagreements. Thing is, BPM — or rather BPM 2.0 — should not be a top-down approach, for we know that it does not work. Instead, I would characterize it as a middle-out one.
Whether you go top-down or bottom-up to cross the business-IT divide, the gap remains the same. There is nothing magic in this, it’s just called Euclidian geometry. The main idea behind the promotion of a new type of developer known as Process Analyst is to provide a way to bridge that gap, in a middle-out fashion. Start from a middle ground that both business and IT can understand — I believe that BPMN is as good as it gets for this, then reach out to the business side through business metrics that business types love to play with, and to the IT side through BPEL as a way to embrace its newfound love for all things SOA.
BPM and SOA are the two sides of the same BPM 2.0 coin. BPM is SOA’s killer application, while SOA is BPM’s enabling infrastructure. Try using BPM without SOA, and all you get is Business Process Reengineering or traditional workflow. Deploy SOA without BPM, and you’ll find it difficult to justify any Return on Investment to a business buyer. If there is a BPM vs. SOA war, it is fought by BPM vendors who cannot embrace SOA for they do not natively support BPEL, or SOA vendors who cannot embrace BPM for their products will always require coding. Take your pick!
Entry filed under: BPM 2.0, SOA
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ismael,
It’s funny how two people with basically similar outlook can view the same post so differently. I thought the Koch column was off-base and totally counterproductive. And you even say that BPM and SOA are 2 sides to the same coin. Hmmm…
Anyway, I’m totally with you on the value of BPMN as the shared tool/notation for modeling and implementation design, whether it’s done by one role (Process Analyst) or split between business and IT. But the methodology of getting it right being “middle out” makes no sense to me. It seems like that’s where top down should rule. When you say we all know top-down does not work, can you back that up? I guess I didn’t know that.
Bruce,
Here is a challenge. Please identify three customers sharing this profile:
- Significant-enough project (the process map has more than 100 steps)
- Integration with transactional systems through WSDL
- Human workflow through web-based interfaces
- Process design done by pure business analysts using BPMN
- Implementation done by IT people without writing code
- No technical support from the BPM vendor
And let’s clarify our definition of a business analyst: the candidate cannot explain the difference between DO-WHILE, WHILE-DO, and FOR-EACH loops, even when promised a free trip to Hawaii with friends and family.
If you can point us to three such customers, I’ll gladly admit that a top-down approach could work. And if you cannot, I’ll spend some more time explaining why it does not, for I’m sure many would benefit from the clarification.
And I’ll throw a free trip to Hawaii for you and your loved ones as well.
Deal?
[…] Ismael Ghalimi, on his IT|Redux blog recently posted that BPM 2.0 is Middle-Out. This was in response to another blog from Christopher Koch at CIO Blogs. […]
Ismael,
The reason you say “middle out” is your scenario starts from the middle, i.e. design, not the beginning, which is modeling. They’re not the same. The purpose of modeling is business-IT alignment, definition of the performance metrics, and projection of those metrics by simulation and analysis… before implementation begins.
In the model, activities are not specified in technical details; that’s layered on after in the design phase. IT calls that “abstract.” A better word is “descriptive.” We agree (I think), that BPMN can be used as a shared tool for both my notion of modeling and executable design.
So let’s take another look at your list:
- Significant-enough project (the process map has more than 100 steps)
OK
- Integration with transactional systems through WSDL
Not part of modeling, but a downstream design function. Strike this one.
- Human workflow through web-based interfaces
OK. Some BPMS include basic task UI layout in the modeling phase, others put it in the downstream design, especially if it has customized layout, scripting, screenflow, etc.
- Process design done by pure business analysts using BPMN
I think you mean “modeling.” (Don’t you?)
- Implementation done by IT people without writing code
Of course!
- No technical support from the BPM vendor
To do the modeling? Of course none is needed!
Now about that trip to Hawaii. Do I have to go to the timeshare pitch?
Bruce,
You can separate modeling from design in your top-down approach if you want (the middle-out approach I advocate merges the two together though), but the whole thing, including implementation, must address integration with transactional systems through WSDL in order to qualify as SOA-compliant. Furthermore, the whole thing, including implementation and deployment, has to be done without support from the BPM vendor, without having to write any code. Also, with respect to the workflow component, customized layout and pageflow should be supported in a Zero Code manner as well.
Are you still on? If not, you might have to go to the timeshare pitch…
OK, I’m on it. WSDL for integration with transaction systems. We’ll quibble in the end about what “vendor support” means. And we’ll make it a dinner bet instead of a timeshare hunt in Hawaii.
Rock on!
[…] Don’t ask me how, but Ismael turned the hubbub over BPM vs SOA into a discussion of top-down vs “middle-out.” Both threads (including comments) are semi-instructive, but somehow in the course of things he challenged me to come up with proof that top-down (i.e. BPM implementation driven from the business model) has ever worked. The challenge came in the form of a double-dog dare, with the promise of a trip to Hawaii tacked on if I could come up with 3 top-down implementations that met his “BPM 2.0″ qualifiiers. Doubting he was good for the Maui deal, I reduced it to a simple dinner bet, so now we both have some skin in the game. […]
This will soon be a familiar quote. Well done!
“BPM is SOA’s killer application, while SOA is BPM’s enabling infrastructure.”
Jonas,
Thanks! Much appreciated.
[…] "BPM is SOA’s killer application, while SOA is BPM’s enabling infrastructure." - Ismael Ghalimi Published Monday, July 17, 2006 6:49 PM by alexh […]
[…] BPM is SOA’s killer application, SOA is BPM’s enabling infrastructure. […]
Ismael, Bruce:
Do you think maybe it’s time for experts such as yourselves to get together and establish a standard model for BPM 2.0 in simple, concise and hopefuly universally applicable terms that can be ported throughout various functions and industries?
My work is in the supply chain arena, where about 10-15 years ago there was a similar debate regarding what constitutes a supply chain, which business function was responsible for what portion of the chain, what were some characteristics unique to the supply chain, but standard enough that could be used across all industries, etc… you get my point.
On that background, a number of experts and major clients in the supply chain arena got together and formed the Supply Chain Council, with the mission of developing a standard model, performance metrics and best in class practice, which they called the Supply Chain Refernce Model, or SCOR.
This maybe be to a certain extent what BPM 2.0 needs — a standard model, the basic tenets of which all experts agree on. A model that is relevant to all parties (Business and IT), yet simple enough that it can be easily understood by all involved, so that its use is being promoted by the debate, and BPM’s adoption rapidly expanded.
SCOR is such a model in my area of expertise, and I can tell you that by its development and use modern supply chain concepts were easily and widely adopted by practitioners.
Just a thought.
Auf den ersten Blick sieht es aus wie ein typischer Marketingsatz: “BPM is SOA’s killer application, while SOA is BPM’s enabling infrastructure”. In diesem Beitrag versuche ich zu klären, ob da vielleicht doch mehr dahinter steckt…
[…] Ultimately, a stack emerged. WSDL for packaging services, BPMN for designing processes, and BPEL for executing processes built out of packaged services. All of a sudden, true BPM — what some call BPM 2.0 — became possible. It worked in a Zero Code manner, supported One Click Deploy for the most complex processes, and enabled a groundbreaking middle-out approach that empowered business analysts and less technical folks — called process analysts today — to work together on the same process, using the same tool. […]
[…] Ismael Ghalimi knows a lot about BPM and wrote this great article […]
I agree that it is middle out. Most people forego a formal design process and just start playing with the workflow system for the company I work for. While they start building at the higher level, they are constantly moving across all levels while they build, deploy, and iteratively rework.
[…] Last week, I challenged my friend and industry analyst Bruce Silver to point me to a BPM vendor that could identify three customers who successfully managed to use its product to build a complex business process that would leverge a Service Oriented Architecture, and managed to do it without writing code and with no technical support from the vendor. If you read the comments that followed Bruce’s post on the challenge, it looks like not all BPM vendors like the idea. I’ll be honest with you, this did not really come as a surprise. […]
I would like to ask all of you how to use a top-down approach for BPM?
Tak,
You could model an abstract process using a process modeling tool, then give the model to software engineers who will write a lot of code to get it implemented. That’s typically what a first-generation top-down approach for BPM leads to. Or you could give Intalio|Designer to business analysts and process analysts, and let them work together on an executable process.
Best regards
-Ismael
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment