Coach Views vs. Custom UI Development
A 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?
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.
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.