Will work for knowledge

Blog about ... things.

Business Processes: Program or Design?

Process Dri­ven Devel­op­ment has its advan­tages, clar­i­fy­ing implicit or already explic­itly doc­u­mented work­flows and using them as a direct base for the devel­op­ment of busi­ness soft­ware. The cus­tomers them­selves are only super­fi­cially involved in the cre­ation of the spe­cific processes, which will later be deployed at their site.

The rea­son for this is the tech­ni­cal­ity of the whole process edit­ing. While the processes them­selves can be (more or less) eas­ily  under­stood, the “get­ting there” is pretty com­pli­cated — at least with cur­rent tech­niques. There are efforts to get peo­ple from work­ing inside the processes to work­ing on the processes. This means sim­pli­fy­ing design and pro­to­typ­ing abil­i­ties of Process Design­ing Envi­ron­ments (PDE), so the cus­tomers can design and try processes for them­selves, with only so much sup­port from tech­ni­cal staff.

What level of sim­plic­ity would be needed to get IT lay­mans to start process design­ing? The processes should be sim­ple with as few syn­tac­ti­cal ele­ments as pos­si­ble, to lower the usage bar­ri­ers. More ele­ments mean more effort is needed for users to learn the mean­ing of a process. Graph­i­cal lan­guages such as BPEL are not well suited for non-technical use, because they do not hide enough of the inner work­ing of the exe­cu­tion engine. You have to know about way too many con­cepts to start design­ing processes in BPEL, which is why in gen­eral BPMN is used at design time. But even BPMN is not well suited for design­ing process at this level. Timers and events are easy to under­stand in a local con­text, but keep­ing the global con­text in mind with many processes and inter­ac­tion between them by facil­i­at­ing events and timers can be quite hard and would have to be sim­pli­fied to be of use to a non-technical user.

Another prob­lem is the data flow. Most ser­vices need to have some sort of input data to work with. But where does it come from? Which ser­vice pro­vides the data to use? To weave this kind of infor­ma­tion into the “exe­cu­tion flow”-view is hard, and in almost all cases not obvi­ous. All solu­tions that resem­ble a map­ping of data to global or (even worse for non-technicals) scoped vari­ables require the user to keep an inter­nal model of the data flow in his head. There should be some visu­al­iza­tion, but data flow analy­sis is hard and needs extra infor­ma­tion anno­tated at the ser­vices used in the process: Which vari­ables are cre­ated, mod­fied or removed?

Busi­ness processes are not com­plex though, so maybe this is a non-issue. But there has to be some pos­si­b­lity of semi-automatically pro­ce­dure to assist the user in (implic­itly) mod­el­ing the data flow in a process, maybe by analysing input vari­ables and hid­ing impos­si­ble can­di­dates, requir­ing the user to make some deci­sion, and using this infor­ma­tion later for visu­al­iza­tion purposes.

Although at the moment there is no tool (at least no tool I know…) really suit­able for non-technical users, in my opin­ion the gap is not that big. The prin­ci­ples are not fun­da­mentlly changed, they only need to be sim­pli­fied to lessen the amount of work needed to get started and the con­tex­tual tech­ni­cal infor­ma­tion a user has to keep in mind.

So, the real ques­tion remains: Would teach­ing cus­tomers to be process design­ers be worth­wile even for the cus­tomers themselves?

Components and Compatibility

Soft­ware com­po­nents should be com­pletely inde­pen­dent, with no (exter­nally vis­i­ble) state, no implicit links to other com­po­nents besides the spec­i­fied depen­den­cies. But soft­ware sys­tems may be sur­pris­ingly frag­ile when it comes down to mix­ing com­po­nents into an instal­la­tion of the prod­uct. This is no prob­lem for prod­ucts with “sta­tic” release poli­cies, where every instal­la­tion is the same. But this fragility is highly vis­i­ble in plu­gin envi­ron­ments like Eclipse, where every user tai­lors the instal­la­tion directly to his needs.

The Eclipse core acts as a frame­work, where plu­gin soft­ware may con­nect at spe­cific points and add its own func­tion­al­ity and exten­sion points. In my expe­ri­ence, updates to the eclipse core are treated with much cau­tion, at best — because “every­thing breaks”. So, why does every­thing break? Every func­tion­al­ity pro­vided by Eclipse is com­ing from plu­g­ins. Although these plu­g­ins are loosely cou­pled and inde­pen­dent, they rely on each other adher­ing the spec­i­fi­ca­tions of the role they fill. Slight changes in the behav­iour of one plu­gin may have a small local impact, but can affect the whole soft­ware sys­tem. Depen­dent plu­g­ins may fail, leav­ing exten­sion points unoc­cu­pied, which causes other plu­g­ins to fail.

This is only one of the pos­si­bilites of errors rip­pling through a whole sys­tem of loosely cou­pled com­po­nents. It is not easy to avoid those errors — test­ing all pos­si­ble com­bi­na­tions is rarely fea­si­ble, espe­cially if the pos­si­ble com­bi­na­tions of com­po­nents is very large and may not even be known to the com­po­nent devel­op­ers. There is no way a com­po­nent devel­oper can test all inter­op­er­abil­ity issues in such an envi­ron­ment. It is often hard enough to cor­ner the prob­lems local to his own component.

The ques­tion I think about at the moment is: Is it pos­si­ble to work with facts gath­ered from local tests and trans­form them into infor­ma­tion about an envi­ron­ment com­posed of pre-tested com­po­nents? In gen­eral, the answer is prob­a­bly  (and sadly) “no”. But maybe it is pos­si­ble to help users tai­lor their soft­ware instal­la­tion and choose only safe and com­pat­i­ble com­po­nents, per­haps by lim­it­ing the pos­si­b­li­ties down to com­po­nents whose tests are good for the same envi­ron­ments or tech­niques like “lazy tests”, which are only run when a spe­cific envi­ron­ment should be installed and test this com­bined envi­ron­ment for local errors.

This may enable soft con­straints on the installed envi­ron­ments, where neg­a­tive results are defin­i­tive (“this com­bi­na­tion of com­po­nents won’t work for this com­po­nent”), but pos­i­tive results have no real infor­ma­tion at all (“may fail in an untested case”).

Software Release != Agile?

Agile Soft­ware Devel­op­ment is all about pri­or­i­ties and iter­a­tive work. You pri­or­itze your task list and start work­ing on the top tasks, break­ing them down to small bits which can be han­dled in a short time. The goal is to enhance the respon­siv­ness to chang­ing require­ments. There are many meth­ods that describe how agile soft­ware devel­op­ment is imple­mented suc­cess­fully (Scrum, for exam­ple, proves to be vastly suc­cess­ful). Release Man­age­ment is one of the duties in a soft­ware devel­op­ment cycle which is not eas­ily imple­mented in an agile way. In my opin­ion, this is because the con­cept of a “release” in itself is not agile.

A “Release” means deliv­er­ing a soft­ware bun­dle which sat­is­fies pre-defined con­straints. Con­trary to com­mon agile mech­a­nisms, where only short-term goals are con­crete work pack­ages, these con­straints define long-term goals for the soft­ware. Fur­ther­more, a release of a large soft­ware bun­dle spans the work of many agile teams.  Scrum defines a team as 5 to 9 peo­ple work­ing together closely.

The project owner is the one respon­si­ble for the out­come of one team’s work. He rep­re­sents the inter­ests of the stake­hold­ers, and is the one who relays exter­nal goals (and pri­or­i­ties) to the team. But, alas, good prod­uct own­ers are hard to find — and release man­age­ment is not nec­es­sar­ily one of their strengts. Inter-team man­age­ment is out­side of the scope of at least this agile method, leav­ing the plan­ning of releases to another, non-agile method “above” the team-level.