Coach Views vs. Custom UI Development

Next Post
Previous Post

vs2A question that we encounter at a number of customers that have a decent amount of internal development expertise is “Should we create our user interface for our process in IBM BPM or in another technology”.  The answer to this, as in most things IT related is “it depends”.

Each customer is unique

Generally when faced with a decision about what technology to follow there are tradeoffs between the technologies under consideration.  This is a multi-dimensional problem, and where any given technology choice lies on a given axis is dependent not only on that technology, but on the sophistication of the delivery team using it.  This means that the answer for each customer will be different, even if 2 customers are comparing the same exact technologies.

For example regardless of what UI technology you are contemplating using instead of Coach Views, the answers may be different if the UI team follows a waterfall vs. iterative development approach.  Also, each company will have different levels of skill on the UI team.  And then there is their level of comfort and understanding in integrating to an enterprise system.  These are just a few of the areas you will want to consider.  There are also items that are more dependent on your IT environment, such as what is the availability of that team, and how much work do they currently have?  What is their comfort level with your underlying requirements?  Will your solution be their top priority?

As I said, it is a multi-dimensional problem

What are you optimizing?

Or perhaps “What is important to you”?

This is the big question.  Painting with broad strokes, nearly all UI creation tools that follow a drag and drop paradigm for creating a web UI are going to wind up with a heavier weight result than a custom crafted web UI that was created by a knowledgeable engineer who understood that one of your primary measures was going to be how many bits need to be delivered to the web browser.  And if the most important requirement you have is to minimize those bits, then you have essentially made your decision.  Is that the most important requirement?

Most enterprise solutions I have seen are much more nuanced than this.  Even if the speed with which the UI renders is the most important metric, (hint:  in modern web UI it isn’t or we would still be looking at plain, boring, mostly static text websites) it is likely that there are other things that may be causing a larger delay than how the HTML/Javascript/CSS used to render your UI was created.  Things like the responsiveness of back end systems to requests, or manipulation of those responses into a format that can be used by the Web UI engine.  Until we know what these are and how they perform we can easily focus on the wrong part of the solution.

When to use CoachViews

Now, going back to CoachViews, if you are optimizing around rapid development, the ability to quickly iterate on designs, you want to use CoachViews.  Likewise if you are following an iterative development model where the data presented and gathered on the UI is in flux for a significant portion of the development timeline, CoachViews would be preferred as they tie the changing data model more closely to the UI and make modifications of both easier.

If the user interface is either process-driven or process-oriented, you’re likely to get more effective results from CoachViews – because changes to process and the associated user interface are highly correlated in these scenarios.  It will be easier to maintain them together, as a unit.

If the process is likely to change, think about the impact on your custom UI – what part of the UI will change to accommodate the process change?  Not a new data element, mind you, but a new process flow that leaves the control of the present user?  What parts of the UI will need to be re-tested?  Will the UI support multiple versions of the same process definition?  Will the process support multiple versions of the UI?

If the UI changes, can you easily map those changes to create an impact or dependency graph with the affected parts of the process?  Will the process break as a result of those changes? Will it need to be updated?  Is a UI change an implicit process change?

All of these process-and-UI-changes are more clear when the UI is built in the context of a part of the process, rather than built in a separate technology stack.

When to go with custom UI

Looking at custom UI development, if you already have “locked down” all of the data elements and know exactly what needs to be presented in the UI and what data needs to be gathered, then the advantages of rapid iteration and prototyping aren’t going to help you much.  And if maximum control over the UI components is important, and you have the time to spend on the additional overhead of developing and deploying a separate UI technology in conjunction with your BPM roll out (and don’t forget BPM’s ability to have multiple versions of the process at the same time!) then perhaps custom UI is the right choice for you.

On the other hand, if you’re building a management interface, or an interface for examining a set of processes or the state of work in general, it is reasonable to build it outside of a process.  There’s an argument for building a management process definition and addressing that with CoachView UI’s – but it depends upon whether you actually define a process or just provide a data-maintenance app for the manager to view and edit process instance data.

Other Measures

It is important to understand that these are only 2 measures for “optimization” of your UI.  Is the look and feel important?  Or adherence to a larger corporate UI approach?  Or perhaps modern responsive UI accommodating various devices is an important consideration (although, this argument doesn’t make your choice easier, as Brazos is both a CoachView and a responsive UI).  The weighing of each of these and many other aspects will cause different customers (and even different processes at the same customer) to chose different UI approaches.

 

 

  • Harimohan

    To the Point. “… Looking at custom UI development, if you already have “locked down” all of the data elements and know exactly what needs to be presented in the UI and what data needs to be gathered, then the advantages of rapid iteration and prototyping aren’t going to help you much….”

    Most or all of the Data elements must be already locked down (as Data Dictionary or Activity I/O) during the Discovery of existing processes for one or more milestones. If it is not locked down, my assumption is that Business is still in Discovery process and processes are not yet ready to be realized and in this case there is no point even building any UI with or without coaches. It is waste of time.

    In my opinion, Coaches are only and mostly helpful where complex IT integration is not required or a decent IT integration does not exists within that organization and/or User Interface/Experience is not that complex.

    Please share your thoughts.

    • In a typical waterfall development model, you would lock down all the data before doing UI development. And if people need new data, too bad (which is why you see so many overloaded uses of data fields in IT systems that have been around a long time – budgets for changes to the data never materialized, or the risk of change was deemed too great).

      In an typical, agile/iterative BPM project, you have a back and forth between data and UI- often the building of the UI exposes additional requirements on the data model (either runtime or relational or both), as well as exposing where the UI isn’t taking advantage of available data in the system.

      As to UI – I’d frame it differently: coaches are only useful if you have people involved in your business processes… Do you have people involved in your business?

      • Harimohan

        Francis, Thanks. Yes, people are involved the process. On point : “As to UI – I’d frame it differently: coaches are only useful if you have people involved in your business processes”.

        I was thinking differently on this. What if we use the Java UI (say JSP, JSF etc) for the same even though the human involvement is there. We already have a UI pattern implemented and the change is just to the data and associated object being exchanged.

        So when we change the data elements, instead of adding/updatng data fields in Coache(s), we are changing it in Java based UI, but ‘mechanism’ of exchanging the information stays the same.

        So this should not be big impact using either Coache or External-UI. I may be wrong but would be glad to know your thoughts.

        Regards

      • I think, historically, people under-estimate the effort involved in integrating UI with back-end data structures. UI builders within BPM tooling make process data “just work” in terms of integrating with the UI. In more typical UI development approaches, the models for the data are not the same – the UI has its model of data, and the server has its model, and then there is a third model that is the transport model (supported by json or REST or whatever).

        In theory “should not be a big impact” – but any time data is translated by hand-built code in more than one place, you introduce lots of opportunities for error. In the case of coaches, the translation isn’t hand-built.