You are here

End User Programming Part 2

BPM The next stage of End-useer Programming Part 2

By: Glenn Smith

This article originally appeared on


In our previous article, we examined the idea of using commercial BPM systems as a platform for end-user programming.  That article focused on the feasibility of the idea; this one will focus on the desirability.  In the previous article, we concluded that in some circumstances, BPM systems could be a viable platform for end user application development.  The primary characteristic which makes BPM attractive is that most development is done using familiar business concepts in a graphical environment which disguises the fact that it is programming.  In the previous article, we suggested several criteria for user-developed BPM solutions.  Most important, of course is economic; the expected return is too small to justify a major IT initiative.  The functional characteristics which favored end user programming were:

  • Human centric applications, minimal system integration
  • Limited organizational scope, typically a single department
  • Geographically localized to minimize network security requirements
  • Not the system of record for any critical data.  Typically these applications will be pre-processors automating current manual processes which create data for existing enterprise systems.

There are many common business processes in most organizations which meet all of the above criteria.  Some examples are discussed next.

Document or decision approval is possibly the most ubiquitous process type in all organizations.  Most business decisions must be captured in a document, and one or more managers must approve the decision before its actual implementation.  High volume approval processes such as expense reports often have the approval processes integrated into the accounting applications, and high impact approvals, such as engineering change notices, are often implemented in ERP systems or custom solutions.  Between these extremes, there are many, often departmental, decisions which must be documented and approved.  The final repository is often a general purpose document management system, and once the document is approved, only the final result and a “signature sheet” are required as persistent artifacts.  These do not have sufficient enterprise value for IT solutions, but can still represent a significant cost to the individual department, relative to its budget.  These are potential candidates for end-user developed process solutions.

Along with approval, another universal process type is case management.  This is the coordination of a set of activities related to the organization’s interaction with an outside party.  It is often a customer or supplier, but other relationships, including internal ones are possible.  As with approval processes, high value case management processes such as loan application or insurance claim processing are typically implemented either within enterprise solutions or as custom applications.  In addition to these strategic solutions, there are many routine interactions which would benefit from automation, but are either too infrequent or low impact to justify typical IT solution development.  The interaction is tracked and managed by paper and email, and once completed, there is no coherent record of the process.  As above, the final result is often a document or entries into an existing system, but a BPM based solution allows, in addition, a complete record of the process.

Most BPM suites have some document management capabilities, and provide easy means to define standard routings as well as support ad-hoc routing.  They have integrated user interface builders, and provide some dashboards in a portal.  They can send email notifications.  These are the essential facilities required to implement basic departmental processes.  It would not be realistic for end users to develop such an application using J2EE or .net, but the high level business objects make it feasible.

In both of these scenarios, the BPM solution acts as a facilitator of existing manual processes.  It is not the system of record for the final work products, and if it were unavailable, the users could easily go back to the old manual processes.  These last two points are critical in selecting applications to allow end-user solutions to be deployed.

Before we jump into development, it is appropriate to consider the risks of end user application development.

  • Under-estimating the magnitude of the impact on their real job.   Time spent developing a custom solution is typically not budgeted, and reduces the short-term productivity of the team.
  • Failing to manage complexity leading to solutions that don’t really work.  BPM platforms provide a high level of abstraction, but it is still application development.  Most real-world problems are messy with many exceptions and special cases.
  • Creeping into critical solutions without adequate infrastructure.  An application that started as a simple departmental solution can, over time, grow into a mission critical role.  Since it was developed outside of the normal IT organization, it will probably lack the supporting procedures which are appropriate for its growing role.
  • Dependence on the original developer.  Most end-user applications are developed by a single person, and have little supporting design or implementation documentation.  If that person leaves the company, it can be difficult to maintain the solution.
  • Negative ROI, tackling too small projects.  This is one of the most common failure modes for all custom software development.  For solutions developed outside the traditional IT methodologies, it is common to fail to identify and properly allocate all of the costs.  This is particularly true in an organization’s initial projects.
  • Violating corporate IT governance policies.  It is almost certain that applications developed outside IT will not conform to governance policies.  This risk can be mitigated by considering whether the new solution has any more liability than the manual process it is replacing.

The above considerations must be balanced against the potential benefits of being able to automate processes which would otherwise remain manual.  In many respects the benefits of departmental BPM are exactly the same as for enterprise BPM:

  • Improved consistency in following best practices
  • Increased understanding of current processes
  • Documentation of actual practices
  • Greatly increased visibility into the status of work in progress
  • Automatically captured audit trail
  • Measurements to support process improvement
  • Easier integration of new team members

Perhaps more significant than these typical BPM benefits, is the fact that by allowing development to take place in familiar business terms, rather than low level programming, solutions which would otherwise be impossible become reasonable.   This is, of course, one of the primary arguments in favor of BPM as a development platform at any scale, but it is a critical factor if business users who are not professional programmers are to succeed.

In these two articles we have considered the notion that BPM platforms might provide a useful platform for end-user application development.  At their current state of development, the case is not nearly as clear as it was for spreadsheets or 4GL platforms, but we must remember that the early products in these categories were less capable, harder to use and relatively more expensive than their current versions.  BPM today is at a stage where for some organizations and some applications it can be a cost effective tool for business led development.  Several current trends are moving in the directions to facilitate this:

  • Several vendors now offer hosted software-as-a-Service (SaaS) BPM platforms.  This is one of the fastest growing trends in all enterprise computing.  Its biggest benefit for end user BPM is outsourcing of the infrastructure and support.  SaaS also can offer lower initial pricing based on users, rather than the server based pricing typical in standard enterprise software contracts
  • BPM platform costs continue to fall
  • The tools are becoming both richer in functionality and easier to use.  Ten years ago, developing a BPM solution was primarily coding to the vendor’s API.  With the best of today’s systems, low level programming is rarely required; solutions are configured from standard components
  • Businesses are becoming more aware of the benefits of BPM.  In many companies that implement traditional BPM for strategic solutions, the business people see dozens of smaller opportunities where the same technology can be applied to their department’s problems.  Most of these die in the IT budgeting process

For the foreseeable future the gap between business desires and IT deliverables will remain.  Some business users will seek to close this gap by building custom solutions with whatever tools are available to them.  Because BPM systems work directly with familiar business concepts and largely hide the programming details, they offer an attractive platform for business people to implement their own solutions to their unique problems.

Based on the above considerations, we believe that it is inevitable that at the same time that BPM moves towards the peak of the strategic enterprise pyramid, it will also migrate toward the vast number of small opportunities at the base of the pyramid.  These solutions will be developed by end users to satisfy their specific needs.  The unique advantages of BPM over traditional development will facilitate a new category of solutions which could not be developed otherwise.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer