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]

How should EA be funded?

Alex Cullen of Forrester poses the question and provides the usual expert answer which can be paraphrased as "it depends".

The neat accounting view that there is an ongoing programme of delivery from which subventions can be drawn to pay for necessary evils of CIO, strategic planning in a manner similar to large plant replacement misses the point that you would not need active enterprise architecture people if everything was planned out.

Rather than comparing EA with IT management overheads like the CIO office, "research and development" within the wider enterprise may bear more fruit. In non-productive organisations like government agencies, policy development would be  equivalent to R&D. Then the thinking around EA funding would be closely aligned to the enterprise strategy rather than the current IT problem set. Of course, if you don't do R&D in some way then there is a pretty clear message that you are not interested in strategies so why do EA?

Practically though, if you believe that EA has a benefit for the organisation, you get the money from wherever is feeling the most pain from the lack of whatever EA will deliver.

Google apps are different if you speak American

In a departure from the data management good practice that I learned a while back, Google use the language setting for US English (rather than the proper one :) to determine how there apps work rather than simply the words , spelling, and punctuation used.
I discovered this as I set up a new apps account , accidentally left the default setting for language as US and discovered that I could use Google Voice to dial out to US and Canada for free from New Zealand. Not a big saving over Skype but a demonstration of how things are coming together in a common look and feel and set of services 'in the cloud'. Now your Google contact list is a one stop shop for outbound calling. Of course, there are ways of running a full Google Voice service outside the US but that requires a little more effort than putting up with a few odd spellings :)
The Google Apps dashboard also functions differently with US setting.

I am still a bit concerned that the gung-ho people from Google should misuse the language attribute rather than define a specific setting "Google-Voice-On". What next , identifying Europe by the use of the currency euro? Close enough?

Bob the hero?

Bob (Google Apps Script wizard) the hero?

Is Bob the hero of the company or has his boss and IT governance allowed him to become the biggest risk.
Google Apps scripts were showcased in a strong presentation at Google I/O 2010. In it, "Bob" was portrayed as a hero for great business performance improvement using spreadsheets and scripts. Although the scripting features presented form a sound toolkit for development around the Google Apps, I am concerned that they may simply replicate earlier problems in IT development.
I have reviewed government and commercial organisations and found much of their operations were centred on spreadsheets or MS Access databases and the like that had grown up from a long departed staffer's need to produce a one-off report for the manager. Auditability and indeed what a spreadsheet was intended to calculate had been lost in the mists of time. Do it yourself Business Process Automation as presented by the Google Apps team seems to offer the same opportunity for foul up but with the potential for more far reaching effects.
The example from Motorola in the second part of the presentation was impressive for its achievement of savings and business process improvement but rather had the hallmarks of an IT shop rather than a "Bob". Even with an IT project approach, there needs to be some consideration to the governance issues presented by such adhoc Business Process Automation. This concern was echoed in a question at the end of the video but not answered.
How do we avoid losing sight of key corporate information spread over contact lists, third party solutions and spreadsheets in the cloud?
Alternatively how do we empower the "Bobs" without hampering them with portfolio management, programme directors, project managers, advisory boards and other manifestation of "good" governance?