Components + Context + Abstraction <= Workflow

I have been doing a lot of presentations on the new Adobe LiveCycle Workflow for developers, technical press, partners and others. In these presentations most of the discussion turns to the benefits for the application developer. Since the primary focus is on the build scenarios, change management and other topics roll up into these discussions around building applications using a services-oriented approach and then delivering final applications as workflows, or composite applications. What are the benefits of a workflow-driven application and how does Adobe provide some leadership in this area with our new server products?

When we look at code that has been written by another developer it can be very difficult to comprehend, especially if we are not aware of the model that the developer used and do not have insight into some documentation relative to the code. This latter best practice is just not practiced enough. Once code is compiled or actually executed, the code itself is lost. So even if the best documentation standards are practiced, large applications that are generally written by several developers would compound this complexity and make it more difficult to understand.

Large applications are broken into many objects or procedures. When executed, this is encapsulated, along with data usually, and then delivered up to the end user as interface or data. But if we look inside the applications, it would be no surprise to see data being handed off from object to object, dependencies frequently in a variety of .java files, and more and more now, applications being composed of many different java components, either vendor supplied and extended or hand coded, or potentially deployed as components.

If we can disassemble the entire application, step through all of the lines of code – we can usually determine the original intent, identify the objects and dependencies and then begin to make changes as required.

There has to be an easier way. IMHO, workflow design and development, and let me plug Adobe LiveCycle Workflow Server, is what provides that better way.

Components: We both suppy components and provide a plug-in environment into Eclipse for building these components that we call QPACs (Quick Process Action Components). A QPAC may contain several code objects but they should be deliberately grouped around one physical object – a user, a database connection or perhaps a service provided by a separate server product and accessed through Web Services or RMI. Several developers can work on one project, each providing QPACs and when another developer comes along and works with these components, it is much easier to fathom the intent of the original application.

Context: In the LiveCycle Workflow Designer, we have a visual view of all of these components in context, generally with self-explanatory iconography. This visual view is akin to the original architecture renderings that would have been built for the application. This intuitive approach is not only great for building applications, but also makes it very easy to understand what other developers intended. I have opened workflow diagrams from other developers and within minutes I can describe the intent of the application, how the code is being executed and most importantly, I can easily determine where to go and what I will need to do in order to customize the application.

Abstraction: When I look at a component within a workflow at the code level, I am generally looking for a few things – the objects, the variables, strings, etc. With QPACs I do not need to go to the code unless I want access to the object. I can change the variables, strings, etc and the actual data that is returned to these variables all from within the interface. In some cases it would require going to the actual code, but if I can step through the process, modify queries, generate XPath expressions and more all from within a visual environment, then that is much more productive.

These are just some of the examples of how using a workflow paradigm can help us in our development, but I think we can benefit from this kind of approach in all of our applications. SOA is not BPM, but BPM with SOA can be a better way to build an application and it should help a lot when others need to modify or change elements of the app itself.

2 Responses to Components + Context + Abstraction <= Workflow

  1. the strategy is great. its working. makes sense. but the name QPAC, in my opinion is very poor. how gorpy do you want to sound?

  2. Ben says:

    The name QPAC (Quick Process Action Component) came from Adobe’s acquisition of Q-Link, which is where the workflow engine originated. Q-Link begat QPAC, and so on…The name aside, QPACs rock (IMHO)