|Written by Glenn Smith|
For as long as businesses have used computers, there has been a continual tension between the business end users and the IT application providers. End users are rarely satisfied that the available applications fully meet their needs. If they contract for custom development, it is often no better. By the time a custom application is deployed, the business has evolved and the new application is less than satisfactory. The major cause of this is the understanding gap between business users and IT developers. Neither fully understands the other’s domain. Users don’t completely understand technology capabilities and constraints, resulting in sub-optimal requirements and specifications and developers don’t completely understand the business.
A second requirement is that it be sufficiently expressive. It should include in a single package, tools for all of the required components of a complete application. Traditional programming tools are general purpose, and able to solve problems from many different domains, but their richness creates a large barrier to learning them. On the other extreme, tools with too little functionality fail to solve many important problems and become applications rather than development platforms. A platform for end-user programming should be targeted at a specific class of problems. Domain specific tools can achieve sufficient expressiveness while remaining accessible to non-experts.
A third requirement is that it be able to be developed, deployed and managed with little or no IT support. Most IT departments are reluctant to take support responsibility for applications developed by people that they consider to be amateurs. IT may help install Excell, but they are not expected to debug the business formulas. Finally, it must be cost effective. It is not possible to justify a million dollar enterprise platform for personal productivity.
Just as it is not appropriate for end users to develop enterprise solutions, it is often not cost effective for IT to develop departmental level solutions. One of the most common failure modes of BPM solutions is the negative ROI that results from applying enterprise level tools and development methodologies to small local problems. In most organizations, these problems are never addressed. Individually, the value of each solution is too small to justify automation, but collectively they present huge opportunities for improvement.
There appear to be several characteristics which make a problem a candidate for a user developed BPM solution. First, it must be a human-centric problem. Solutions which require system integrations require professional developers. SOA tools have made integration much easier, but it still remains in the domain of professional programmers. Second, the organizational and geographical scope should be limited. The ideal case is that all actors are in a single department at a single location. Although all current BPM systems have web based interfaces, deployment across multiple locations will require involvement of the network and security experts. In most organizations, it would not be allowed for any application not owned by IT. A third desirable characteristic is that it not be expected to be the system of record for any regulated data. It is good to automate a current manual document approval process, but the result should still be maintained in the same repository as with the current manual process. Finally, there should always be the possibility of reverting to the previous procedures if the system fails or is not available. It is not acceptable to put the enterprise at risk based on an end-user built solution.
Having narrowed the problem scope, it is now appropriate to revisit the key platform obstacles, support and cost. Process applications, are by definition, multi-user solutions. The activities within a process need to flow from one participant to the next. This suggests that some type of server based solution with a web interface is necessary. The typical BPM suite is a multi-tier application with a database, a BPM server and a web server. For enterprise solutions, they are typically deployed on different servers. None of these are things that a typical business user can or wants to support. Because of the operational complexity, many BPM platforms are clearly not appropriate for small scale projects.
A better alternative is a SaaS solution such as Appian Anywhere. With this model, the platform support is outsourced to professionals, without involving corporate IT. Support and availability will match traditional IT supported applications. This completely mitigates the third and fourth constraints listed above. With a SAAS model, there is no up-front cost, and the monthly fee can be much lower than the cost of owning a system. As more solutions are deployed and more users added, it can scale seamlessly and at a cost directly proportional to the benefits.
In this article, we have explored the possibility of using BPM suites for development of local solutions by end users without IT involvement. We have demonstrated that at least in some cases it can be both technically and economically feasible. In a follow-up article we will consider whether or not it should be done.
About the Author