Simulation not in the BPMS please

The efforts of BPMS vendors to deliver simulation of processes have not been impressive ... even the best is more like a visualisation of the assumptions made in the process design rather than a model  that can usefully explore the real world factors that may influence future process design.
Bruce Silver has been able to consider this from the perspective of the process designer and concludes , among other things, that "Simulation should not be embedded in a BPMS". 
I agree and have argued before that the simulation should be handled by a dedicated simulation tool (after all these have been around longer than BPMS). see this post.
Fortunately we now have a formalised model of the business process in BPMN 2 that can be transformed into elements useful for a simulation engine. Similarly, the control blocks and flows that characterise a simulation model could be transformed into the starting point of a BPMN. The relationship between the simulation and the process model is 2-way.
Choose your BPMS toolset on its ability to delivery process design and implementation. Choose your simulation tool for its ability to support the analysis of the real world process under investigation.
Although I sympathise with Bruce's view that "Simulation should not require programming",  there will be occasions when the complexity and value of the model will merit more effort and experience. I suggest that the ideal simulation tool should have full logic development capability (programming) in addition to a simple wiring diagram approach.

User Interface to BPM

In Tips for the Business Process Developer - Human Interfaces to Business Processes, John Reynolds points out where the real work is in delivering a managed business process.... getting the appropriate attention of real people. Making it harder are the BPM suite providers who, in an attempt to grab the lion's share of the market claim to be providing a complete solution with hastily nailed on use transactions that take no account of how real people work - only what is needed by the BPM engine to get to its next bit of well-defined (read as simple) execution. What is needed is a well-defined interface - and John identifies the important stuff. For example ...

"To Do List" interfaces have three goals:

• Make sure the participant knows what tasks they are responsible for

• Make sure the participant knows when each task is due

• Help the participant prioritize which task to work on next

That last bullet is (of course) the hard one to implement. ...

One trouble is that the implementation keeps getting left to the BPM guys. Equally bad is the suggestion that everything the important people in the business have to do is some mysterious "knowledge work" and knowing where you are in the production of business value is trivia. The big snags for everyone in the BPM implementation are

• not everything, that people have to do, is controlled by the documented and managed business processes.
• real people have different ways of visualising their 'to-dos' and delivering a one-size fits all mechanism is likely to be counter-productive

If we are to reduce the implementation cost of BPM we need a formal interface defined at the UI boundary and look at how the vast number of personal productivity tools can be used to but a familiar face to the interface. There are probably as many people who would react favorably to IM and Twitter-like presentation as those happy to log on a refresh a screen of activities awaiting action.

More on standards for presentation layer

Encouraged by the steps that have been made with SVG, I turned for another look at XFORMS, a specification that I thought had some promise a few years back. Sadly, native browser support has not miraculously appeared and requiring browser plugins or extensions is not going to sit well with corporate IT.
With the increasing power available in the browser engine, javascript solutions are now practical. XSLTForms is a great piece of work and provides cross-browser support through the standard XSL transform approach.
So, for fans of declarative language solutions,  the next challenge is to mix SVG with XFORMS. The wiki here shows a starting point but your milage may differ when you try this. My effort is here and shows some limitation in the size of image in chrome and firefox 4.
The simplistic view is that we should be able to bind the attributes/properties that describe the graphic elements in SVG to instance data in the XFORMS representation.
Starting with a simple svg element:

 <circle r="50" cx="100" cy="100" fill="grey"/>

We could manipulate the colour by including the SVG as instance data :
<xf:model> <xf:instance id="inlinesvg" src="svg/simple.svg" /> </xf:model>

and then referencing the fill parameter in an XFORMS element:
<xf:input id="myInput" ref="//svg:circle@fill"/>

I am glad to see that this actually works for me in Chrome and IE8! Cross-browser SVG is relatively new in XSLTForms so there are some wrinkles to be ironed out. I suspect that there are improvements that could be made to my simple example here as the last serious coding I did was in Fortran 4.

SVG coming back, or getting there?

I am a fan of standards as a means of presenting information and having the wide audience seeing the same thing. I was encouraged by Kurt Cagle’s post  that “SVG has made it's way to the web” but I am not sure we are quite there. Of course, SVG has been used to present graphics on the web  for some time but seeing the results has required some  fancy footwork of plugins and careful selection of browser. I think Kurt is being a little premature in his announcement that “every single major browser on the desktop” will render  even specific examples of SVG consistently.
I actually wondered what Kurt was talking about as I viewed his post in the stable Firefox 3.6.10 because the SVG was not rendered at all, but I was sufficiently interested to switch on my laptop with its standard Chrome browser.
Kurt used this artwork http://www.openclipart.org/people/jhnri4/Glass_cup_with_saucer.svg demonstrating one problem with using SVG as a standard graphic ..., I can’t include this image in my Google Doc directly. But a bit of cutting and pasting gets us this.

Kurt provides it scaled to a 240 pixel square in the blog and on my FireFox 4 display it looked like this …

On Chrome however the picture is scaled differently to give you a whole cup.


The SVG word art  example in Kurt's blog was less successful, only appearing in Chrome. The scripting to change the word art did not work in Chrome or Firefox.
All this suggests that we have a way to go with our standards rendering.

[UPDATE : Came back to this later in the day and found that the word art scripting worked in FF4 and Chrome but that the wordart itself only rendered in Chrome]