Processes and the people that build them

A workflow is not always going to be a business process. To help sort this out we can define a business process as a set of actions required to achieve a business objective, and separately define a workflow as the management of the actions in a business process. Business rules are then used to define the logic of a business process and dictate how process information flows from one individual or system to another.

We will see workflows that are broken into two separate groups. There are the application-centric workflows where the information is not formatted for presentation since there is no requirement for human interaction. These are important and a lot of people are working in this space. Adobe remains more concerned with the document or form-centric (human-to-human) workflows where both the data and the formatting can pass from action to action as a single piece of information.

Forms or documents that are used in our workflows should be created with either Adobe LiveCycle Designer or Adobe Acrobat, but of course the Designer-generated forms saved in XDP (I will blog on XDP later) format provide greater flexibility, easier separation of data and you can embed the schema to help you or others locate data.

Who does all this work? From my perspective you can define a useful set of roles for building out workflows – where outside the normal system administration and management, you need a subject matter expert for things like security, database, web services, and of course the J2EE Application developer, the form developer, perhaps a business analyst and finally the workflow administrator. One person could wear all these hats or you can easily define life cycle procedures to manage the apps, versions, etc as you share and collaborate on building applications.

To do this successfully you are going to need to get your hands on the SDK for LiveCycle Workflow so that you get the QPAC Development Environment. This is just a plug-in for Eclipse that gives you a wizard-like environment to create deployment and design-time dialog boxes. Once you are done the same plug-in lets you test the QPAC and import it directly into the workflow engine. I posted earlier on QPACs (Quick Process Action Components) but they are basically a Java component that is defined by a service class, a dialogue class, some metadata and the necessary application resources.

We enable business processes through workflows, but when it comes to workflows – you still have to build them. In my previous post, I gave some suggestions on places to start learning how.

Comments are closed.