Dave Gardner

Trading Systems and Binomial Coefficients

One of the not-so-obvious things about commerce is that trading organizations generally have a history. By necessity this history becomes the starting point for the development of automation. As a designer, it's easy to think of 'better' ways to do things when you first walk into a new project, but it ain't necessarily so.

This was the case in my latest contract developing a trading system for fresh fruit and vegetables. There were many differences between this industry and anything I'd experienced before. Most of the differences were to do with pricing. I was used to the price being part of the sale contract, but this is not the case in FF&V where prices may be negotiated up front (not always) but are subject to change even after the goods have been supplied.

What added spice to the mix was the need to support different workflows for different combinations of trading partners. This is relatively easy when a trading system belongs to one of the trading partners, but a universal trading system must be able to (potentially) provide a custom workflow for every combination of trading partners. That is, not n but the binomial coefficient (n 2). Given, say, 50 trading partners trading directly with each other that's 1,225 potential workflows. Unmaintainable is the first word that pops to mind.

I have not fully solved this problem but I think the best solution lies in providing standard workflow templates , factoring workflows, and allowing trading partners to make their own workflow agreements.

Stateful Thinking

My latest work is a Credit Management system. This small workflow project is built around a database-oriented state machine and doesn't use any third-party 'workflow' products or libraries.

I started with a classic flowchart and a description of each activity, and ended up with a responsive, robust and easily-maintained system.

It proves that you can build effective workflow systems with nothing more than basic development tools. The key is stateful thinking!

 

Workflow Manifesto

This is a personal manifesto around business software development and workflow.

---

---

SubSonic

I try not to talk about tools here but I am so impressed by this Data Access Layer generator that I want to give it a plug. My hat is off to Rob Conery and the team (http://www.codeplex.com/actionpack) for a really well thought out and productive tool.

Though it's intended for web development you can use it to eliminate the drudgery of DAL development for any .NET app. Just set it up, press a couple of buttons, and your DAL is ready to use. Sounds too good to be true? Download it and see (it's free).

Why Workflow

In a nutshell, workflow is a better way of looking at business software systems. Object oriented languages and designs delivered expressiveness and abstraction, and CORBA/COM eventually delivered binary reusability, but workflow takes software design in a different direction entirely.

Software development is about communication. You cannot develop successful interactive software systems in isolation. I know because I've tried. It's a battle to keep the communications flowing when you're under pressure and buried in detail. In a business context, a workflow approach helps because the framework you use to communicate with clients, business managers and other stake-holders is the same framework your software is built on. No translation required. While details can still get lost, your implementation is guaranteed to be a lot closer to your client's expectations.

In the early 90's I worked on an event correlation system for a large international software company. The team who shared the same floor were developing a workflow system. The workflow project imploded for a number of reasons, but there must have been something in the tea because I acquired a fascination with workflow, even though I wasn't directly involved in that project.

A couple of years later I joined a startup developing a Business Process Management system. The company went belly-up after a valiant effort and some wonderful successes that just weren't enough to survive the dot com bust.

Now Microsoft are releasing Windows Workflow Foundation -- every developer's workflow toolkit. Whether it sinks or swims, the effect it will have is to boost workflow techniques further.

BPM or Workflow?

Strictly speaking, Workflow is what happens in every company when it processes an order, for example. Workflow isn't sexy. Workflow Systems, as the name suggests, facilitate and automate some or all of the flow of work. On the other hand, BPM (Business Process Management) is a fancy acronym thought up by brainy types to help design and implement both better workflows and better workflow systems. BPM is meta-workflow in the sense that it describes workflow and provides ways for the cognoscenti to talk about it. I use the term workflow casually to cover all of the above.

Dave Gardner.