Trust us: Use the Coach View Framework
- August 5, 2013
- 4 Comments
Since early days at Lombardi, the company made it possible to build an “external” user interface for its BPM offering. In Teamworks 5, however, the coach framework was introduced, which made it much easier to build user interfaces rapidly inside the authoring environment. The coach framework was built to support two basic goals:
- First, to support the methodology of rapid playbacks, which had been instituted across the professional services organization and through our partners at Lombardi
- Second, to support the technical business analyst being able to prototype UIs that actually work inside Lombardi BPM.
Both objectives were largely met by the coach framework. However, there were three trade-offs incurred:
- First, was that over time, the interface acquired a “dated” look – the look-and-feel of the UI was not updated every year, even as what was considered state-of-the-art in web UI continued to evolve.
- Second, the coach framework also wasn’t sufficiently extensible. While custom controls could be built, they couldn’t be adequately abstracted as components for re-use.
- Third, it wasn’t possible to completely change the look-and-feel of the UI without abandoning the coach framework and building an “external UI”.
The good news was that external UI capability existed – exposed through APIs – if you truly needed a custom UI or technical approach. The bad news is, building an external UI required you to essentially reverse-engineer many of the capabilities baked in the the coach framework – data marshaling, state management with the BPM engine, understanding of “next steps.” Otherwise, you risked building a brittle application UI shell on top of a flexible BPM engine and modeling environment.
In the first major release (8.0) after the IBM acquisition of Lombardi, IBM introduced a new Coach Framework – called the Coach View Framework. This framework, conceptually, addresses all the shortcomings of the old coach framework – the interface can be updated, the framework is incredibly extensible and supports components, and it is possible to completely customize the UI – all while in the safety of the IBM BPM Process Designer.
BP3’s Brazos UI Toolkit is a great example of the extensibility, the advanced look-and-feel, the ability to support mobile and touch natively, and the ability to do all of this within the auspices of the Process Designer, rather than externally.
Conceptually, the IBM BPM 8.0 release completely eliminated the need for an external UI. Why? Because all of the reasons for building your BPM UI outside of IBM BPM have been effectively eliminated. While you still might have a use case for incorporating process into a small portion of an existing application framework, if you’re building a process solution, you’re going to want to produce it in the Process Designer.
So you can imagine my dismay when a major IBM BPM customer, at the advice of a big consulting firm, chose to pursue building the UI in Java Server Faces. The consequences to the project in terms of cost, time, and agility are probably fatal to any reasonable measure of success.
Unfortunately, this is also a classic case of a consulting firm not understanding the technologies their responsible for deploying. Because the firm is a generalist, they don’t have anyone on staff with significant IBM BPM experience. In fact, there isn’t anyone on the project with a single previous deployment of IBM BPM under their belt. So they’re dismissing technology decisions that could save tens of millions of dollars for the customer over time. And they’re making decisions that increase the risk of project failure rather than reducing risk.
So we have a situation that highlights two dangerous risks of embarking on a big BPM effort:
- Making a very costly technology decision
- Trusting technology decisions and implementation to generalist consulting firms – rather than BPM specialists.
I’m not sure why large generalist name-brand consultancies are trusted with specialist technology projects. Time and again, their projects are higher cost and higher-failure-rate. But we continue to see these kinds of mistakes play out in our market. It is really unfortunate because it has impact not only on the specific customers impacted, but on the overall health of IT and BPM projects. We’ve written many times about the value of pure-play BPM consulting firms – but educating the marketplace isn’t easy – analysts and customers are always willing to give the big players another chance to fail on the customer dollar, and are always going to put the pure-play vendors under a special microscope before doing work with them.
No serious technical observer could look at the kind of interfaces we can build for IBM BPM using the Brazos UI toolkit, and think that they could turn around the same kind of product using Java Server Faces in less than 3x the work effort – and they still wouldn’t be addressing responsive mobile and touch-interface scenarios. Worse yet, they’re creating artificial barriers between the Process Design and the UI Design that will cause requirements impedance mismatch throughout the project.