Workflow is becoming more and more popular within larger organisations trying to improve internal processes or integrate operations between various internal and external systems, but what exactly is it ? There are many systems on the market with the word 'workflow' within the title and all offering different features and solutions. So, can they all really solve the workflow problem.

I guess a good starting point is to decide on what we mean by workflow. Lets start by looking at this from a business perspective. Within any large organisation, there are various departments involved in processes designed to meet a business objective. Along the way there are many systems (I.T. and others) designed to make the process faster, with the ultimate business aim of needing the fewest number of people to carry out a business objective. These processes can be specific to a department/role or may involve many different departments and staff to achieve a single end to end process.

As described earlier, there are lots of supporting tools available to make the work easier depending upon the business type. Ranging from simple word processors to help produce documents/correspondence through to custom applications to perform a specific business service.

For me, the idea of workflow is to manage these individual business processes ensuring that work is moved through the organisation as efficiently as possible. For any workflow system there are going to be two types of operations that can take place.The first is an activity that is managed automatically by I.T. based systems, the second is an activity that required a member of staff's involvement.

If you have a clearly defined and simple process, you can probably achieve everything you need in a single application, however, as the business becomes more complex and fluid, this definition becomes more and more fuzzy. Additionally, investment in legacy and custom applications cannot simply be thrown away just because the system cannot participate with these disperate business processes.

So the perfect workflow solution needs to be able to support the following:

• Define end to end business processes quickly and simply.
• Allow integration with various internal and external systems and process source/targets.
• Provide for Human interaction within the process.
• Provide information on how processes are performing to measure the effectiveness of a business process.
• Must be reliable, perfromant and scalable. If your business is relying on this this is a must have.

Ok, thats my starter for 10 on what we need from workflow. Now, how to acheive all this quickly, simply and preferably without massive investment.....

Sharepoint, Biztalk & K2

I recently was involved in the constuction of a large workflow based environment. The underlying technologies used were:

• Biztalk, to provide the integration with various internal and external systems.
• Sharepoint providing front-end services and document management.
• K2 Blackpearl providing the Workflow design and hosting.

This system should have been perfect. Biztalk is a fantastic tool to transfer pocess requests between back end and remote systems, its scalable, extremely flexible and you can get really complex systems working really quickly. Sharepoint is a really great portal for collaboration, document management and housing custom data capture forms and applications. K2 Blackpearl is a little less familiar, but provides a workflow engine that easily integrates with both Sharepoint and Biztalk and as it is hosted seperately is very flexible.

So, did it work ? well, yes and no. The technology was sound, the overall architecture was sound. As a platform, this would be a great basis for providing a general purpose workflow solutions. However, where things went wrong on this particular project was a lack of understanding of both workflow and the tools by the management and analysts signing off the requirements. Once you start to break the workflow model to shoe-horn badly fitting requirements in, then you will start to hit problems. Alongside this, many developers on the project had come from standard ASP.NET web site development into Sharepoint with no real grasp of the differences. As such a lot of the Sharepoint development did not take advantage of the power of Sharepoint as the underlying code was simply traditional ASP.NET dropped into a Sharepoint site.

Amazingly, these same people who had effectively mis-used the tools, started trying to blame the tools. I guess this is pretty standard behaviour (thus the old adage), but does present a real problem for anyone wanting to implement real workflow. I guess the real lessons are:

• Ensure you have a good understanding of the Business Objectives before coming up with the product set.
• Ensure that the designers of the system fully understand the underlying products  - at a detailed level.
• Ensure you have good change management and keep you business and managers up to date with the product sets.
• Ensure your developers are fully conversant with the tools before letting them loose....Or have a really good technical lead.