Trust us: Use the Coach View Framework

  • August 5, 2013
  • Scott

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:

  1. 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.
  2. 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.
  3. 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:

  1. Making a very costly technology decision
  2. 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.



Related Posts
  • February 14, 2018
  • Ariana

Migration from BP3 on Vimeo. Director of BPLabs, Rico DiMarzio, details BP3's history with migrations and...

  • February 7, 2018
  • Ariana

Process Transformation and Artificial Intelligence from BP3 on Vimeo. Where does artificial intelligence ...

  • January 4, 2018
  • Scott

If you were wondering whether microservices architecture was coming for BPM engines, this post makes it pretty...

  • Gary Samuelson

    The problem goes deeper.

    Without leveraging the benefits of BPM technologies the addition of its infrastructure brings considerable unwarranted overhead to system processing. Furthermore, most technical difficulties on these project are due to the introduction of unmanaged and misapplied BPM systems.

    One may wonder, what benefits are achieved, if any at all….

    And there’s additional risk by continuing down this path as more patchwork is then required and layered on top of previous patchwork. The best metaphor for this predicament is of the lost traveler with nowhere to go but deeper into the woods. The best solution is to get a map and compass – understanding the terrain prior to departure is the best advice.

    • This is so spot on, should have been in the main post. Hopefully we can educate the market and get IBM customers and partners on board with this philosophically!

  • Matthew Corbett

    Hi Scott,

    Great read, thanks for your thoughts. Maybe even more relevant 4 years later as front-end libraries have developed rapidly.

    I have a question around this concept and the new Brazos portal. We recently installed the federated portal, and after ploking around a bit, I can see the application uses some kind Java back-end for federation, authentication, and interacting with process data, and uses AngularJS for much of the front end.

    Why was the Brazos portal developed this way as opposed to using the Coach View framework? I could certainly see the limitations for federation functionality, but is there more to the story? Is the application too extensive to be plausible in the CV framework?


    • Matt, great questions.
      As you can imagine we had a few reasons for this. First, our intent was for Brazos Portal to live outside the context of a single process instance. Those types of UIs are good candidates to consider whether or not they should be built with the coach view framework (often they still should, but this is a good spot-check).
      A second reason, was so that the Portal could be deployed independent of the IBM BPM infrastructure while still connecting to it or leveraging it.
      A third reason is that we wanted Brazos Portal to be available to clients who want to leverage it as a front end for other products’ tasks – Salesforce, custom applications, or BPM tooling.

      Having said that, it isn’t a limitation of the Coach View Framework for the complexity – we can build these kinds of interfaces as Coach Views- but certainly federation is a deal breaker at some level if you build inside the coach view framework. You need some specific back-end implementation to handle that stuff.

      We have some interesting stuff to show you (Brazos Dashboards) that will likely satisfy the need if you need more “in-coach-view-framework” views of tasks and whatnot. It just doesn’t handle the more complex architecture issues like federation!