From my time on the Metastorm forums one thing is obvious, most people implementing Metastorm solutions are not business people. Mostly they are technical people, with a few not so technical people. And it’s generally the not so technical people who are having the biggest problems getting to grips with the product. Is that a failing of the software? I’d say not, although it could arguably be a failing of the marketing of the software, which like most BPM products suggests a non technical person can use it from start to finish to produce a working system.
This situation reminds me of other areas of software development, like the development of websites, or application development. A while ago, people thought anyone with a copy of FrontPage could develop their own website or anyone with a copy of VB could knock together a working application. But these other areas have matured enough to recognise that actually those pesky developers are still required (or to put it another way, designers can’t code and coders can’t design) and the development environments are now set up in such a way that the designers can work with the coders to produce a working system. For a website, the designer can produce a HTML layout that looks good and then the coder can add the required code so it does something. In the world of Windows development we are moving to WPF and other technologies where the layout is separated from the code, so the designer can produce the pretty screens and the coder can then add code to do stuff without both sides stepping on each others toes too much.
And for me, that’s the approach that BPM will have to take at some point, realising that the business people can’t code and the coders don’t understand the business, so trying to put only one of these people in charge of the BPM system will never fly. I think Windows Workflow is a step in the right direction with its ability to create custom activities. The coder can create all the required custom activities and then the business person can plug these together like Lego as required. Or this could work in the opposite direction, where the business user produces their process and adds dummy activities where they need functionality to be implemented and the coder goes off and creates the required activities.
With that in mind, I created a simple PrototypeActivity that can be added to a workflow and lets the user specify the inputs and outputs that will be need to be implemented. The screenshot shows how it looks in operation (although a proper implementation would probably provide a better user interface). The code is below.
public enum PropertyDirection
{
In,
Out,
InOut
}
public class ActivityProperty
{
private string propertyName = "";
public string PropertyName
{
get { return propertyName; }
set { propertyName = value; }
}
private string description;
public string Description
{
get { return description; }
set { description = value; }
}
private PropertyDirection direction;
public PropertyDirection Direction
{
get { return direction; }
set { direction = value; }
}
public override string ToString()
{
return direction.ToString() + " - " + propertyName.ToString();
}
}
public class PrototypeActivity: Activity
{
public static DependencyProperty PropertiesProperty =
DependencyProperty.Register("Properties", typeof(ActivityProperty[]), typeof(PrototypeActivity));
[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
[Browsable(true)]
[Description("The properties the activity requires")]
public ActivityProperty[] Properties
{
get
{
return ((ActivityProperty[])(base.GetValue(PrototypeActivity.PropertiesProperty)));
}
set
{
base.SetValue(PrototypeActivity.PropertiesProperty, value);
}
}
}
