The reason for this is the technicality of the whole process editing. While the processes themselves can be (more or less) easily  understood, the “getting there” is pretty complicated — at least with current techniques. There are efforts to get people from working inside the processes to working on the processes. This means simplifying design and prototyping abilities of Process Designing Environments (PDE), so the customers can design and try processes for themselves, with only so much support from technical staff.

What level of simplicity would be needed to get IT laymans to start process designing? The processes should be simple with as few syntactical elements as possible, to lower the usage barriers. More elements mean more effort is needed for users to learn the meaning of a process. Graphical languages such as BPEL are not well suited for non-technical use, because they do not hide enough of the inner working of the execution engine. You have to know about way too many concepts to start designing processes in BPEL, which is why in general BPMN is used at design time. But even BPMN is not well suited for designing process at this level. Timers and events are easy to understand in a local context, but keeping the global context in mind with many processes and interaction between them by faciliating events and timers can be quite hard and would have to be simplified to be of use to a non-technical user.

Another problem is the data flow. Most services need to have some sort of input data to work with. But where does it come from? Which service provides the data to use? To weave this kind of information into the “execution flow”-view is hard, and in almost all cases not obvious. All solutions that resemble a mapping of data to global or (even worse for non-technicals) scoped variables require the user to keep an internal model of the data flow in his head. There should be some visualization, but data flow analysis is hard and needs extra information annotated at the services used in the process: Which variables are created, modfied or removed?

Business processes are not complex though, so maybe this is a non-issue. But there has to be some possiblity of semi-automatically procedure to assist the user in (implicitly) modeling the data flow in a process, maybe by analysing input variables and hiding impossible candidates, requiring the user to make some decision, and using this information later for visualization purposes.

Although at the moment there is no tool (at least no tool I know…) really suitable for non-technical users, in my opinion the gap is not that big. The principles are not fundamentlly changed, they only need to be simplified to lessen the amount of work needed to get started and the contextual technical information a user has to keep in mind.

So, the real question remains: Would teaching customers to be process designers be worthwile even for the customers themselves?

The Eclipse core acts as a framework, where plugin software may connect at specific points and add its own functionality and extension points. In my experience, updates to the eclipse core are treated with much caution, at best — because “everything breaks”. So, why does everything break? Every functionality provided by Eclipse is coming from plugins. Although these plugins are loosely coupled and independent, they rely on each other adhering the specifications of the role they fill. Slight changes in the behaviour of one plugin may have a small local impact, but can affect the whole software system. Dependent plugins may fail, leaving extension points unoccupied, which causes other plugins to fail.

This is only one of the possibilites of errors rippling through a whole system of loosely coupled components. It is not easy to avoid those errors — testing all possible combinations is rarely feasible, especially if the possible combinations of components is very large and may not even be known to the component developers. There is no way a component developer can test all interoperability issues in such an environment. It is often hard enough to corner the problems local to his own component.

The question I think about at the moment is: Is it possible to work with facts gathered from local tests and transform them into information about an environment composed of pre-tested components? In general, the answer is probably  (and sadly) “no”. But maybe it is possible to help users tailor their software installation and choose only safe and compatible components, perhaps by limiting the possiblities down to components whose tests are good for the same environments or techniques like “lazy tests”, which are only run when a specific environment should be installed and test this combined environment for local errors.

This may enable soft constraints on the installed environments, where negative results are definitive (“this combination of components won’t work for this component”), but positive results have no real information at all (“may fail in an untested case”).

A “Release” means delivering a software bundle which satisfies pre-defined constraints. Contrary to common agile mechanisms, where only short-term goals are concrete work packages, these constraints define long-term goals for the software. Furthermore, a release of a large software bundle spans the work of many agile teams.  Scrum defines a team as 5 to 9 people working together closely.

The project owner is the one responsible for the outcome of one team’s work. He represents the interests of the stakeholders, and is the one who relays external goals (and priorities) to the team. But, alas, good product owners are hard to find — and release management is not necessarily one of their strengts. Inter-team management is outside of the scope of at least this agile method, leaving the planning of releases to another, non-agile method “above” the team-level.