I could be completely wrong about this -- but I'm just going to make some bold and disparaging remarks about the whole existence of workflow software and see what happens.

Here we go.

A state machine is about the most basic electronic circuit you can make. You can throw one together with a couple of transistors.

And in software, writing a state machine is so simple that it's hard not to write one.

But simple ideas leave room for big inflation. Sales people know that the best things to sell are inflated big ideas.

So the field of Enterprise-Level Workflow Software was born.

And businesses buy them, happy to take a short-term hit in productivity, since it will lead to long-term benefits. But when you buy an expensive wrapper around a five dollar piece of softeware, the long term effects are confusion, complexity and further cost.

Business are universally worse off because of the advent of 'work flow' products.

I hear the response "Oh but workflow has a lot of value-add over rolling your own solution. You get persistence of long running processes, for one thing."

Persistence? Persistence? Don't we have these thing called databases? Isn't that our usual, and fairly well understood persistence mechanism?

Also there's value-added services such as logging and reporting.

Logging? reporting? I'm still thinking 'database.'

Ah, but here's the super-answer:

Workflow products include graphical tools for letting business analysts design their business processes without involving coders.

Without... without... You're kidding right? You ought to smell what you're shovelling.

Show me a working 'business analyst' -- one, who is not now nor has ever been a coder -- who successfully designs 'business workflows' using an off the shelf tool, and who didn't require any expensive training, and who achieves their task in less time and with more precision than a coder. And who doesn't need to call technical support for help at the time.

Show me just one.

World wide.

I can wait. I give you one month. Nah, screw it. I give you eternity.

Whenever I get too saddened by these things, i think of my big idea for a whole new class of enterprise component:

The 'IF' server.

Here's the general pitch.

(switch to the kind of voice-talent they use when advertising john grisham films)

Business today is complex. You need to make decisions. But every decision will take you down a certain path. Who can you count on to get you there?

Business needs alignment.

Business processes need to work together to guarantee that decisions are made for the greater good. Or evil, if that's the business you're in. We don't discriminate against evil.

Consider a difficult decision. It may be hard to make, but with an IF server, we can serve up either a true or a false, whichever you prefer.

You can have the most complex business scenarios in the world, and if you tell us to return true, we will. Every time.

Your IT department is a complex and challenging part of your business. They control a complex array of applications, of all sizes and across many platforms. Custom software is never dependable. But an IF server, can be relied upon.

Imagine... A single standard for IF processing, accessible from across the entire organisation.

Using proven open standards, like XML -- the Lingua Franca that powers today's fortune 500 businesses -- every application can link to the same powerhouse of decision making excellence: Your IF server.

Now you know: no matter what software your team is writing, they can connect to the IF server and be given one standard result. Monday? Then it's true.

Tuesday? Then it's false.

You run the business. You decide.

No more doubt. No more incompatabilities. No more missed deadlines and lost opportunities.

You can crush the competition. You can destroy them all.

IF only you purchase now.

The IF Platform Server One Million and One. A revolution in business processing solutions.

Microsoft 3 years ago:

We noticed that a lot of our products contain overlapping workflow components, so we've decided to consolidate that into a single product, Workflow Foundation

Microsoft today...

those same products still have their own workflow components.

In its defence though, at least WF is free.

(Okay, maybe the 'total cost of ownership' isn't zero)

THANK YOU!

I've been saying this for years, after watching more than one project get boat-anchored by BizTalk.

The whole idea of using a GUI to design a piece of critical business software is, as you say, insane. And one wonders why on earth a developer would choose to use it. The answer is, *they don't*.

I came to the realization a while back that workflow software is exclusivley sold in *boardrooms*, not in labs. When an big enterprise project is on the table, the *executive* team meets with the senior sales manager of the vendor. It demos very well. They're reassured by the fact that they can actually understand what they're looking at, instead of being baffled by mumbo-jumbo like "object oriented" and "atomic transactions".

No one with any concept of the actual development process is present. They nod their heads, sign the million dollar check, and *after that* they inform the development team of how lucky they are and how much time they'll save now that they get to use BizTalk.

I agree with you to a certain extent, there's certainly a lot of snake oil salesmen out there selling workflow systems. And the whole idea of a business analyst being able to produce a working system is laughable.

That all said, I still think there is a lot of merit in workflow systems. BAs can still use the graphical tools to produce a prototype system, which can then be handed over to developers to flesh out. And a decent workflow system will be able to execute directly from the process map. Cool, self documenting applications...

Yes you can implement persistence yourself, but it's a whole lot easier to deal with if someone else has solved the problem, rather than having to think 'how do I persist this object then wake it up in a days time and start working on it again'.

Whether these benefits are worth the 6 figure costs associated with purchasing workflow software is certainly arguable but I hope we'll see cheaper stuff coming out soon

I think Windows Workflow is actually fantastic. I'd argue it's not workflow as most people understand the term but it still offers some of the benefits and the price is great. I built myself an automated build tool with a graphical designer in about 2 hours using it.

Isn't an accounting system just a database? Isn't an ERP system just a database?

Is your rant regarding worflow Designers (apps) or workflow principles.

I find forming a domain model with clients produces the best solutions. And how are all the domain entity relationships modelled and executed? Workflow.

You'd think it'd be simple: if all jobs are moving to require computer skills, then add a computer programmer to the team.

All of a sudden you're able to negotiate and evaluate software tools because you have someone you trust on the team who understands them.

A hearty golf-clap for you for using the Lego Mindstorms/NXT graphical programming language example.

Great post. Absolutely cracked me up.

And I agree with Casey - where I've seen such products used, and most other big so called flexible software, the decisions have been made by "senior executives" being schmoozed by salesmen: a good demo, a few nice meals and perhaps a jolly abroad, sorry, I do of course mean in depth training course.

While I agree with most of your argument, I think you missed the one main benefit of workflow engines over code. Workflow is configuration.

When designing a workflow solution, you are forced to break your business problem down into reusable components. But you don't code the business rules into the components themselves. Instead, you put those business rules into a workflow and have it invoke your components at the appropriate times.

Business rules change frequently, while the components that they fire change infrequently. If you use a workflow engine, you can respond to those changes without writing, testing, and deploying code.

>When designing a workflow solution, you
>are forced to break your business problem
>down into reusable components

Okay -- i'll concede this as a possible benefit. But it's incidental, so i don't quite rate it.

Oh it is worse than you think...

Workflow systems encourage business analysts to write code, live in production, with absolutely no unit testing.

If a junior developer did that, they'd be shot.

But a senior executive will pay big dollars for the privilege.

great post. but great things can happen when developers use tools such as biztalk to model business process. retries? all taken care of. persistence? automatic. protocol adaption? abstracted. dont throw the baby out with the bathwater :-)

Maybe but, a CMS its all about a easy-to-delivery content (no techies jmmm maybe) but really usefull in certain scenarios (I met at leat a good one), a BPM is something like SmartJelly you shouldn´t use a CMS for transaction software as much as a BPM for other propouses than a formal a configurable platform for collecting massive forms.

Good post. I am also very skeptical of the diagram approach.

By the way, there are at least 2 other "drivers" for the diagram-based approach, as follows:

(a) Ability for users to see what they workflow will do (i.e. "if I start this workflow, what will happen?") It's hard to answer that when the workflow is written in code by programmers. (But, will it really be any easier if the workflow is written in diagrams by non-programmers? ;-)

(b)Ability to handle long pauses. I suspect this has been a major driver to diagram-based tools for workflows. As far as I know, code-based alternatives have never handled this well. However, I've discovered that long pauses can be accomodated just fine in C#, using a technique I've documented here: http://dotnet.agilekiwi.com/blog/2007/05/implementing-workflow-with-persistent.html

The most recent argument I heard for WF was "you can host WCF services on it".
Didn't make more sense than the rest of the PR for this tool.

You know, I have had the "privilege" of working with both roll your own workflow solutions and the enterprise, whiz-bang drag n drop sort... The difference? One is constraining and the other one you can make do what you want.
I have seen many off the shelf solutions (not just workflow) become a nightmare by the time its modified enough for the customer.
Heep it simple.
(BTW, where can I download the IF server, I think you are onto something!)

I feel your pain.

I had the pleasure of maintaining the billing and provisioning system of one of the UK's largest telecoms companies. During my time there the management decided to move the application to an ESB architecture using Biztalk. It was a nightmare. They had a team of three (or four) guys nursing this monster day and night plus another team of Microsoft consultants to help them, maybe ten people in all. They were smart guys too.

The piece I looked after, the Digital TV provisioning, was the only bit that managed to escape Biztalkization, it had been written with POCO (Plain Old C# Objects) by a guy who had long since left. It just worked, day in, day out. So much so, that I was able to spend much of my time helping out the Biztalk team.

As for the Biztalk orchestration's graphical programming tools, the team soon learned not to use them and do delegate all business logic to helper assemblies.

Mike

Leon, you inspired me to a full on rant on visual tools in general:

http://mikehadlow.blogspot.com/2008/04/visual-tools-marketing-dream-programmer.html

In a pre-VS 2008 launch event, I sat through a presentation on Workflow Foundation.
I can't remember the last time I've heard so many words that meant so very little to me, but I do thank Microsoft for putting out at least one or two giant technological stacks that I can very, very safely ignore. I'm running out of hours in the day as it is.

Yes. These tools make simple things simple -- no gain. But, people who won't learn simple code will use them, which is a gain for simple things. However, these environments make difficult things more difficult or even impossible -- a loss. Like huge, linked Excel spreadsheets that contain massive errors and are not debug-able. The problem is they are sold as being scalable to difficult problems, and they are not.

Labview is a highly specialized environment for data acquisition. It's users are specialists. I don't think it is comparable to general workflow tools.

I agree with this post 100%. I have to interact with filenet workflow at my current job and it is a pain. There are several people that you have to go and talk to depending on what area of the system you need to deal with.
Why has nobody mentioned some of the open source workflow systems coming out of the java world? Jboss is doing something with JBpm. There are good ideas in workflow. The problem is that this is something a second year university coder should be able to knock out in a semester.

I really loved this post. Dead on! I've been thinking about this too lately. Also see my post:

http://elegantcode.com/2008/04/04/on-windows-workflow-and-biztalk/

I've been asked to look into WWF for a project, and I have to admit my brain is not handling it as well as I would like. Sort of like learning OOP all over again, but this is even less intuitive.

One thing I've noticed in trying to learn this stuff is the lack of examples that link business objects with workflow. All the of samples I've seen embed properties onto workflow classes which get written as nice pretty blobs to the database. In real life, I am going to have to track actual information about stuff, not just what state it is in. Where and how this coupling takes place, and gets maintained, is in no way obvious to me in this framework.

Theoretically, an advantage I can see with this type of stack is that if you are able to divide up processes into discrete units (activities); management can change their mind on how things flow and you can accommodate (or more easily delegate) implementing such a shift in logic. In practice, though, I'm not sure how this all is going to work out. The lack of a decent-sized sample application, and Microsoft's reticence to use it in their own enterprise platforms, is a bit disconcerting. I don't want to end up with a bunch of code (the way I did with RDO) that I have to refactor a year or two from now when Microsoft shifts its focus.

Hmmm. First of all, lets get one thing clear. Biztalk is not a Workflow solution, nor a Workflow Server. Just an orchestrator of components, that allow you to transform the information in a somehow "easy" way from one schema to other schema.
Serious Workflow engine provides a lot more than that. Even, the real Workflow Engine is just a part of it. Have you ever heard of FileNet? BPM? I have been implementing successful workflow solutions since 10 years ago. We have business designers. They are consultants that only take care of desiging the workflow solution, and maybe some stored procedures.
Every application has a way to persist their information, so, whoever told you Workflow is a way to easily persist your objects, they lied to you.
A serious production workflow solution (lets call it <a href="http://en.wikipedia.org/wiki/Business_Process_Management">BPM solution</a>) is more than just a state machine. That is Workflow Foundation concept. Real workflow vendors have a Business Process Manager, Business Process Framework, some kind of Electronic form feature, with electronic signatures, a Business Process Analyzer, a Business Process Simulator, a Business Activity Monitor. And all integrates with the Enterprise Content Management system. And yes. you can deploy really fast, an integrated solution that gives a user the functionallity they need. Insurance Claims, Account Payables and I could be hours talking of successful implementations.
I am already hearing you laughing while you are reading it. It's OK, sometimes people laught of the unknown, by ingenuity, lack of confidence, lack of experience on the field. Its OK. It happens to all. But, don't let yourself base your thoughts only on one product. Have you heard of <A HREF="http://www.emc.com/products/category/subcategory/business-process-management.htm">EMC BPM</A>, <A HREF="http://www-306.ibm.com/software/data/content-management/">FileNet P8</A>, (ex)Fuego, now <A HREF="http://www.bea.com/framework.jsp?CNT=index.jsp&FP=/content/solutions/bpm&WT.ac=hp_wwd_bpm">BEA BPM</A>. As you started, yes, you may be wrong, I may be wrong. But I can give your business designer. I can give you successful BPM implementations. And I invite you to visit those links. And I even invite you to watch for a demo. And I am not a sales man. I have coded in assembler, pascal, C, C++, Smalltalk, VB 4,5,6, VB.NET, C#, Prolog. So, please, don't get me wrong. Its just like everything. You could do that all from scratch, yes, of course. You could code from the start to the beginning. But this field is really mature, provides with complete frameworks to work with them. Easily. Productive. Its a proven solution. And its not just bluffing. Its for real. Respectfully, Luis Lobo Borobia

Hi Luis --
I just wanted to let you know that I really aprreciate your input on this.

Biztalk is not the kind of product I had in mind when I wrote this, and in fact windows WF is not either. It's some of the third party offerings (and particularly the way they are 'sold') that annoys me.

lb

Luis is right.

I'd just like to add an observation that a workflow engine is more like a framework than a library. Since one state can transition into simultaneous new states, and you are essentially coding transitions and call backs, while the framework handles persistence, logging, timeouts etc.. It requires a different kind of DSL compared to scripting languages that we are already familiar with. I've often wondered whether we can subvert BASIC (with line numbers) to build a reasonable workflow engine, using GOTO to jump to new states, and perhaps introduce

GOTOALL 100, 200

where two states have to be created.

Workflow software: I'm calling the bluff.

The 'IF' server.

Articles

Downloads

Recommended Reading

Recommended blogs

Aggregated Links

Human Link Machines