BPM, reinventing the UI every time?

Published Thu, Nov 10 2005 8:19 AM

I'm currently involved in introducing a workflow package within my customer's organization. The last couple of weeks I had numerous discussions with various persons inside this company about the way end users would interact within these processes.

The point that arose everytime around is they certainly don't want to rebuild interfaces they already have. SAP screens, Oracle Forms, etc. On the other hand they want to give users an integrated experience. A user executes a task within a workflow and he shouldn't take aditional steps to inform the workflow itself on what they did. Ideally he is presented the right screen when he selects the task at hand and information about the task done flows automatically between the workflow and the user screen.

Everytime these requirements come up, my brain start to run overtime ;-). It doesn't fit my view on architecture. I don't know of any technology that would allow me do this and when I look around in the service oriented world I don't see any discussions about reusing existing UI. You see a lot of samples with InfoPath and portals, but then I do start running down the path of rebuilding the UI for the processes.

What do you think, should I start discussing the fact with the customer that in a message oriented, workflow enabled world I should accept the fact that I can't reuse existing UI's? Or do you see alternatives I missed? Or should the customer and I drastically change views on the subject? Do you know of workflow tools that can reuse UI's more or less seamlessly?

On the last question, I do think the problem lies in the fact that we now view the workflow as the dominator, the initiator, in the process. The problem would shift if it would be viewed as more of a coordinator (which doesn't fits the products view, but that might be a different question). However, in that case the question would arise how the coordinator knows what is happening without requiring the user to enter 'workflow ids' all over the place. Interesting food for thought I think. Anxiously awaiting your reactions.

by Carlo Poli

Comments

# Obiwan Jacobi said on Thursday, November 10, 2005 12:28 AM

In my view the portal should be the place were all enterprise information comes together. That would be the starting point to initiate workflow processes. But like you said: there is no technology available to really make it work across different vendors and platforms.

The paradigm shift that is currently taking place (SOA) in the business-end of software could also be applied to the UI. "UI services" like normal (web) services should only agree on a protocol and a basic communication model. The problem with UI is that it tends to have dependencies to business services and to other "UI services". Also UI comes in two shapes: forms (windows) and pages (web) with different programming and state models.

If you look at the architecture proposed by the Microsoft Pattern and Practices group, you can see a UI process layer. That is were your UI-workflow lives (in my view) and in that sense I agree that workflow should be regarded as a coordinator. A workflow process has got have some knowledge of the logic contained in its instance, because its job is flow management, which is usually governed by conditions that are tied to the business logic inside the workflow process (components).

Well, long story, no real answers. Sorry ;-)

# Gerke Geurts said on Friday, November 11, 2005 5:34 PM

The first wave of workflow consisted of packages tried to perform workflow steps by invoking existing applications. This was still mostly pre-web times.

The trouble with this approach is that it is not possibly to make the coordination of the workflow engine completely transparant without modifying the apps that are invoked. Typically the applications involved required modifications to notify the workflow engine of activity completion. Another issue is that the UI is often the least stable part of an application, which means that the often tight coupling between the workflow engine and the applications is pretty brittle too.

The architectural change nowadays is that workflow is no longer layered on top of the UI, but in between UI and lower layers such as information management services. If you define workflow in a narrow way - coordination of tasks that involve human interaction - the workflow layer sits between the UI and the process management layer (which coordinates both automated and manual activities): it is the interface between people and the process management system (typically a glorified inbox/task list).

If you go for workflow in the middle, you need to decouple UI more from the backend. At the very least the UI should be workflow engine aware. For every possible task in the workflow engine (i.e. any atomic piece of manual work that is requested by the underlying process management layer) there must be a chunk of UI (I like the term dialog in this context) that obtains the requested info from the end user.