What steps do you take when writing a really large business processes?

Question

I was given this really long flow chart (8 pages) of how we process our financial transactions. The most critical piece of our application. I'm sure you can imagine lots of squares and diamons with lines drawn all over the place, and then separate detail sheets describing which fields in the database to update, calculate, retrieve, store, etc. etc. etc.

Does anyone have any tips/tricks/suggestions as to the best approach to coding this thing? Do you start with 5 billion if statements just like the flow chart does and then refactor from there?

Any thoughts are appreciated.

Answer 1

I like to extract some business object out of the mess first. Try to come up with some classes to separate the responsibilities using the typical low coupling, high cohesion guidelines. After that, look for duplication in the flow and think of ways to keep that duplication out of the code.

Answer 2

Personally, I look for patterns that I can turn into reusable functions. Often I'll find several different areas that I can create very generic functions that can handle multiple tasks, depending on the parameters I pass in.

Answer 3

You have my sympathy.

That being said, look for anything you can abstract away. Look for similarities. Take more or less coherent sections and write functions out of them.

Then, when you've done your best, be prepared to spend a lot of time refactoring.

Then, since I don't believe humans can write accurate 8-page flow charts, be prepared for people blaming you for stuff that doesn't work right. Ideally, you should be able to trace your logic back to the flow chart, and at least divert the blame. Unfortunately, this is not really compatible with refactoring it to something sane.

Answer 4

For something that large, you'd better have a good model in place. Look at your business process and identify the actors, the acted-upon, etc. Once you have that model in place, start to flesh it out - work out what a given step means in terms of the actors and the acted upon, determine whether the actor or the acted upon is the best place to handle that part of the interaction, and so on.

This will translate your big long flow chart into more of a Sequence Diagram which will help you turn the flow chart into code, by identifying the methods you'll need on your objects (and potentially identify more objects that you overlooked in the first place).

Granted, this assumes an OO perspective, so if you're doing this in COBOL it may not help much.

Answer 5

First off, don't do it. Seriously, don't.

You are going to take ownership of a few hundred processes that not only are not your job, they aren't your specialty either. More so, you won't do it right ( trust me ) and you will be creating a full time job ( or 6! ) fixing and maintaining a system that never works right.

If you are in an environment that can generate such a large business process, I hope you are in an environment where you can get reasonable funding. What you want to look into is BPM software, meaning Business Process Management. Companies like Captaris, K2 and Ultimus all develop products, as do big boys like IBM and the like. These tools allow you to give the tools to business experts, so the people in the process that actually know what they are doing, then you have domain experts controlling their own domains, generally in a very excel like environment, but sometimes using tools that look alot like Visio ( or.. that are visio! ). You as a developer then, provide the transport between departments, and specialized logic to tie your various business systems together ( or to pull data from various sources.

Granted, BPM software start in about the 20K range, and the sky is the limit from there. Plus, as you expand you will probably want a document repository like Sharepoint ( which can start from as low as free and up to 100K+$ ) and a forms system like Adobe or Infopath, but all told, you can build a scalable end to end system starting around 30 - 40 grand, depending on the number of users you have.

That might sound like an obscene amount, but truly it isn't. Factor in you labour costs, all the labour costs of the various people you will have to meet with, the fact your are probably creating a full time job for a few people and creating a system that probably will never really be 100%... the money is well spent.

Keep domain specific knowledge in the knowledge experts hands, and keep IT specific tasks in IT's hands. This is an area where I see IT department after department screw up and end up with highly valuable employees getting paid high salaries to baby sit report generation. Honestly, I say again, don't do it! This is one of those areas where off the shelf products will be vastly superior than anything you can create.

(Note, most of my examples betray my most recent background. I am from a Windows shop with a .Net centric development team. You can just as easily find BPM solutions for Unix, Linux, whatever, including a few open source options with Java as the back end instead. )

EDIT: Oh, and for the record, if you absolutely can't buy off the shelf, if your budget is zero $, you will find most commercial BPMs implement a state based machine, with a gated flow chart-eqsue structure with a database ( or even spreadsheet ) driven back end. If you need to do it yourself, you would still be well served trying a demo from any of the various BPM providers and emulating their approach.

EDIT2: Links. Captaris

Ultimus

Open Source (ProcessMaker)

There are tons more, but these will get you started. BPM software is one of those things that can go from thousands to millions of dollars, and potentially free. I can only speak towards Captaris, which I choose about 3 years ago and worked as advertised.

Answer 6

If the process requires any human interaction (i.e. decision making) and is long running or there are lots of similar business processes, then a workflow (BPM) product like K2 or ProcessMaker might be appropriate. If your business process is largely orchestrating data flows then a product like BizTalk might be appropriate.

Note that there is a significant learning curve for workflow programming (generally due to poor debugging support). So, if you aren't already familiar with workflow programming and quick turnaround is required, you probably don't want to go down this path.

If your task is to implement a relatively fast process (meaning it runs from beginning to end without pause and does not require human interaction), then I would tackle it in the following manner:

1. identify the process steps
2. Code a runnable shell of the process without implementing any of process step details, along with (failing) unit tests for each process step and for the overall process.
3. identify the subsystems the process interacts with
4. identify the business objects each process step interacts with
5. identify the data flows to and from each subsystem
6. identify the contracts for interacting with the business objects
7. if necessary, code the business objects, with unit tests for functionality required in the final product
8. implement the process steps one by one until all the unit tests pass.
9. debug the overall process (add unit tests if necessary)
10. integration testing (add unit tests if necessary)
11. deployment

Answer 7

I totally agree with David T - no human can create an 8 page flow-chart and have it be a solid-bullet proof set of steps. I would change to a state diagram (http://en.wikipedia.org/wiki/State_diagram) basically describing the life cycle of the financial transaction - from conception to final state. This would probably help with the overall approach you take to the design and implementation of the process and greatly reduce the nested if statements (each nesting exponentially increases the complexity and brittleness of the code). If each step in the life cycle is clearly decoupled you can then easily modify as needed (yes - business needs change - ha ha) without impacting the other steps. Keep in mind testing needs and logging to ensure each step is clearly recorded for traceability and debugging.