Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm new to Workflow developement, and I don't think I'm really getting the "big picture". Or perhaps to put it differently, these tools don't currently "click" in my head.

So it seems that companies like to create business drawings to describe processes, and at some point someone decided that they could use a state machine like program to actually control processes from a line and boxes like diagram. Ten years later, these tools are huge, extremely complicated (my company is currently playing around with WebSphere, and I've attended some of the training, its a monster, even the so called "minimalist" versions of these workflow tools like Activiti are huge and complicated although not nearly as complicated as the beast that is WebSphere afaict).

What is the great benefit in doing it this way? I can kind of understand the simple lines and boxes diagrams being useful, but these things, as far as I can tell, are visual programming languages at this point, complete with conditionals and loops. Programmers here appear to be doing a significant amount of work in the lines and boxes layer, which to me just looks like a really crappy, really basic visual programming language.

If you're going to go that far, why not just use some sort of scripting language? Have people thrown the baby out with the bathwater on this? Has the lines and boxes thing been taken to an absurd level, or am I just not understanding the value in all this?

I'd really like to see arguments in defense of this by people that have worked with this technology and understand why its useful. I don't see the value in it, but I recognize that I'm new to this as well and may not quite get it yet.

share|improve this question

3 Answers 3

Years ago, before most of us were born, software developers had to write their own code to store data. If you needed to save program state, well, that was seen as part of the function of the code, so many software developers ended up writing code to organize data and save and read it and so forth.

And then someone realized that this was something that happened a lot -- that, the logic to save, organize, read and search data was actually a component that was so commonly used that it should be it's own component. And we got databases.

In the last 10 to 15 years, IT departments have been realizing that the logic to choreograph and/or orchestrate business processes is so common that it should also be it's own component, which has lead to all sorts of different workflow tools.

There are 3 primary benefits of a workflow tool:

  1. Time needed to make and deploy changes: you can develop and change the logic of a workflow without the same technical risks that you have with changing a piece of code.
  2. Transparency: the business logic in a BPM based system is immediately available to and readable by the business analyst, whereas only developers will be able to read the business logic in "code-based" systems.
  3. Reuse of technical components: BPM tools are often used in conjunction with systems that have a Service Oriented Architecture. By separating the business logic from the technical components -- especially for enterprise systems which must implement hundreds or thousands of different business processes -- you're able to reuse the technical components while spending relatively little time on developing the business logic (with a workflow tool).

However, one of the most common problem that I run into with workflow and BPM tool usage, is that developers still try to "bury" business logic in non-transparent code.

What I see, all the time, is developers still trying to add the business logic in the most technical ways possible, instead of the most transparent way possible. This is natural, because developers are, by there very nature, much more comfortable with code than with a workflow tool. Furthermore, the more logic you keep in a technical way, the more you'll be needed as a developer. Unfortunately, this is the worst thing a developer can do to a BPM system because he or she is undercutting the primary benefits of using BPM.

Lastly, most BPM tools aren't far enough that business analysts can develop the workflows themselves: however, that's what the goal is. Ideally, business analysts would develop the workflows/business process diagrams and developers would only work on the technical components that are called by the workflow engine.

share|improve this answer
    
Thank you for your reply. So, afaik, there are basic workflow tools based around directly graphs, and there are complex workflow tools, that are essentially visual representations of Turing complete programming languages. What I don't understand, is if you need a Turing complete programming language... why not do it with a real general purpose programming language? If you're using loops and conditionals, why aren't you doing it in say... Python? –  user16549 Nov 18 '13 at 18:31
    
Because visual representations of Turing complete programming languages are accessible to a vastly larger audience than developers, which means that companies using these tools only have to hire developers for technical components and can let domain experts do the rest (with the workflow tool). Also, visual representations are immediately transparent, unlike code of any kind. –  Marco Nov 18 '13 at 19:56

From a developer's point of view, you are right in saying that these "visual" environments are really hard to work with. SharePoint 2010 Workflows, which I use, throws out every best practice around creating good enterprise software - no automated testing, no code reuse, unreadable software... Anything more complex than an out-of-the-box template can be painful to maintain, as you are experiencing.

But from the business' point of view, workflows have massive benefits. To quote from this white paper, the Efficiency, Accountability, Control and Ease of use of an automated workflow provide huge productivity gains. Imagine how much more inefficient a simple approval or on-boarding process would be without this automation. Also, the very act of defining a workflow is valuable to an organization that is trying to get control over their business processes.

The current state of workflow software is not the business' fault. They just want to make their lives easier, and workflows are great for that. I would mostly blame us, the IT department:

  1. For not being more transparent with the business about how complex and fragile the system really is. We hide all the complexity.
  2. For not being able to "scratch our itch" with intuitive, simple workflow solutions. This is probably more of a rant against large enterprise packages like SharePoint and SAP, but they are better than the custom solutions out there
share|improve this answer

It is not very clear which tool you are using. I guess you may be referring to the general set of tools called Business Process Modeling tools. There is a good reason for using such tools. Any quality business define its functions in terms of processes and analyst as well as business experts can draw such processes comfortably (until you tie them with standards...). You can create such processes at the conceptual level without any knowledge of web programming and if you have the right tool, you may be able to convert the process into a working application too (experienced people must come on board for this magic to go into production of course). So the idea is good.

The objective of the visual tools is not just documentation of the processes. The use of the tools is meant to help professional re-engineer processes and, in times, run simulations to discover points where the processes are less efficient than desired so that plans can be put in place to remove the bottlenecks.

There is a standard way that many companies use today called BPMN 2.0 (Business Process Modeling Notation). I do recommend that you get into understanding this notation if your tool is using it.

The Business Process Management Body of Knowledge is a famous resource, that you may want to consider as well.

The above covers the business side. The technical side requires SOA and BPEL, I am not sure I can provide advice on those here and now though.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.