Why Zero Code Matters
Monday, May 1st 2006 | Ismael Ghalimi
This is the eighth edition of our weekly BPM 2.0 post. Today, I will try to explain why Zero Code matters. Most BPM solutions require users to manually write code behind boxes and arrows used to depict a process. There is nothing wrong about software code, but code is one of these things for which less is more, and there is more than one reason for it to be true.
First, BPM needs the participation of business analysts, but business analysts cannot read nor write code. Granted, technical people could write the code behind the boxes and arrows that business analysts would draw, but it would not really help bridge the business-IT divide, would it? BPM 2.0 advocates a model where executable processes are implemented by process analysts, and these could write code if they really have to, but they tend to prefer using graphical tools instead. There are 8 million Visual Basic programmers today — it’s the largest developer community ever built — and there must be a reason why Microsoft called its BASIC development tool Visual. If no business logic can hide behind the boxes, business analysts are more likely to understand what process analysts have done, and this is a sure way to bridge the business-IT divide, if not obliterate it entirely.
Second, human beings make mistakes, and the exercise of writing code is an error-prone one. In average, one BPMN process shape leads to 10 lines of BPEL code, and one line of BPEL code replaces approximately 10 lines of J2EE code. What this means is that 100 lines of nasty J2EE code would have to be written if BPEL generation tools did not exist. If your process has hundreds or thousands of steps (or 250,000 like the one Intalio built for the Dutch Government), that’s tenths of thousands or hundreths of thousands of lines of code. Commercial code typically has anywhere from one to seven bugs per 1000 lines of code according to a report from the National Cyber Security Partnership’s Working Group on the Software Lifecycle (Source: ZDNet). What this means is that your average BPM project will have hundreths, if not thousands of bugs in it, which will have to be fixed manually, one by one. If you let a Zero Code BPM tool generate the code for you, you do not have to worry about these bugs anymore. Granted, the BPM tool’s code generator could have some bugs, but it’s likely that they’ll be fixed by the vendor before you could catch the bugs you’ll create yourself by writing code manually. Furthermore, once the tool’s bugs are fixed, they produce valid code anyone using it.
Finally, software code is usually imperative, while Zero Code design-driven development tends to be much more declarative in nature. What this means is that information contained within BPMN diagrams is much more explicit that equivalent information embedded into J2EE or C# code. The more explicit the information, the easier it gets for the BPM platform to provide simulation, debugging, reporting and optimization capabilities. To make a long story short, code is better written by the vendor and customers should focus their efforts on improving their business processes rather than code is used to support them.
Entry filed under: BPM 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It turns out that bugs per line of code (B/LC) is linear. And bugs are a big part of where you spend developing and maintaining software. The way to scale is to pick languages that require less lines of code by an order of magnitude.
You scale going from Assembly to C, from C to Java (with C++ in between), from static to dynamic. But eventually you hit the scalability wall. You just can’t make a better language, or a better API. Which is where we turn to meta-programming. It’s a generic name for a lot of different things, but the one we have most experience with are domain specific languages.
Domain specific languages don’t apply well to all problems, but they’re easier to use in one specific domain. And it turns out that people have a large number of problems that can be solved well by one specific language. You still need to learn that language, but domain specific languages happen to be simple so the learning curve is short. And you save so much in developing, testing, maintaining to break even on the first project and gain with any subsequent one.
Assaf,
I agree. BPEL is one such domain specific language, for business process automation and web service orchestration. You gain one order of magnitude going from Java to BPEL. Then an other one by using a BPMN designer that will produce the BPEL code for you. Two orders of magnitudes make for a very significant gain that should help us push the scalability boundaries far beyond what most customers need today.
Nice post, and I agree on all points. See comments here. In general I think we’re only just beginning to see all the benefits of model-driven design and architecture.
Links for 2006-05-10…
Ismael Ghalimi on the advantage of BPMS that allow creating executable processes without coding…
The Zero Code Knife…
So, when will BPEL/AJAX BPEL editors and universal, transparent native semantic data storage merge?…
BPM is the way to go due to a number of reasons:
- Increasing Speed to market for software products.
- Decreasing Go-Live cycles for business software.
- General pace of IT accelerating with increasing levels of automation.
Cheers
Very nice post. Its something the BPX have always been dreaming of. It seems that SAP has some designs for the same and it will be interesting to watch what they do with their ARIS and Visual Composer tools.
[…] For simple things, simpler frameworks such as Ruby on Rails will be used. And for the more complex tasks, developers will turn to bottoms-up or middle-out BPM solutions, using a BPEL editor or a BPMN designer to model fully executable processes in a Zero Code manner. […]
Codeless development would be the holy grail. I think CASE tools started it. Then we had various UI designers. Business process modeling tools that can generate the process logic code automatically are another step in the direction.
In any case, however, we still need the coding done for individual services that are behind the steps and activities in a business process, or a composite application.
If the services are already available for re-use, then things get simpler. If not, best case you have to “generate” business logic and/or UI, to be plugged into the process, and worst case you have to write every line of code in Java, PL/SQL, ABAP, or what have you.
When we have access to a BPM tool that can generate 100% of the process logic (in BPEL let’s say since it’s the standard today), and have access to an unlimited repository of services, I think the concern would be, are the “business analysts” properly skilled to do development now? The best forms guys are not usually the best functions guys. So I think business-IT still need to sit together.
Ye,
I agree with you. But take a look at Intalio. Most of the business logic can be generated without having to write code, and you can use it to build reusable services that way. Also, the skillset required for technical people is less than the one required for J2EE development.
[…] 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. […]
It is just a dream to write code with “zero code”. How do you debug, merge, refactor? How about these software engineering practices?
Bo,
We support them through graphical artifacts.
The dream became reality.
Hello Ismael,
We share the same dream (see link), although I haven’t looked carefully at your product. To be honest, I wasn’t aware of it, which is my loss, one which I hope to rectify. From what I can see, it looks nice. Cudos.
These ideas are not new. What we see now, that has allowed folks to dream, is the advent of new domain specific languages that bridge the gap between visual programming and declarative (C# and Java) programming. A number of large commercial products have been available for many years that attempt to make this same leap, including some open source packages. I’m glad to see another solid OSS member join the fray.
Beware of making the statement that visual programming eradicates defects. It does not. Logic defects still remain. Visual programming paradigms still allow humans to be creative, and creativity leaves room for flaws. By leaving room for mistakes, we leave room for intelligent and elegant solutions. We cannot have one without the other.
So in addition to an environment for coding visually, we also need environments for testing visually. I’m sure your environment includes testing, as you mention producing a very large process map for the Dutch Government. One area that is becoming more common these days is process simulation. Think of it as automated testing for BPEL.
Also, since we are attempting to allow process developers to do the work of coding, we need all of the tasks that declarative developers once did to move over, including deployment of the solution to a production environment, code control, and configuration management, to be part of the paradigm.
Visual programming doesn’t get rid of bugs. Oh, and the comment about defects per line of code being linear does not hold up when shifting paradigms. Your rate of defects will depend on your environment, and may be less than the average or greater, depending on how clear and simple your visual language and debugging tools are.
Process developers have not be trained in the fine art of debugging or deploying. That is a human change that may be the biggest challenge to full adoption of the paradigm. Making those tasks as simple and apparent as the programming itself will be a serious challenge for many years to come.
Good Luck and thank you for your efforts and contributions to moving all of us forward.
-Nick Malik, SOA and BPM Architect, Microsoft IT
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment