Business Intellegence

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.

Many business users have felt that the solution to this was to eliminate the IT dependency and develop applications themselves. Of course few business people have the skills or time to develop a modern application, but there have been a few breakthrough computing platforms which allowed ordinary business people to develop their own tools, without IT support. This gave them the freedom to implement exactly what they wanted and to modify at will as circumstances changed. In this article, we consider whether BPM tools can provide another step in satisfying this desire.

The first breakthrough in end user programming was Visicalc, the original spreadsheet. More than any other category of application, spreadsheets made the PC an indispensable business tool. Today nearly all businesses have spreadsheets which they use to model and manage their businesses. Most could not imagine life without them. For the first time, ordinary business people could create exactly the tools they needed. The next breakthrough was 4GL database tools such as PowerBuilder. These allowed non-programmers to access corporate databases and create quality user interfaces and reports. They could quickly develop and deploy new applications to meet new demands. They represented a big step up from spreadsheets, since they provided access to the assets in existing databases. Of course, these required a little cooperation from IT for database access, but functionality and schedule were completely in the end user’s control. Unfortunately nearly 20 years have passed with no significant additional progress. If anything the barriers have been raised by the internet and the expectation for browser based access from any location. The PC is no longer a suitable platform for hosting most business applications.

Business Process Management Suites have evolved as a powerful platform for enterprise change. One of the primary advantages of BPM platforms over other forms of application development is the very high level of abstraction. BPM systems model the solution directly in terms of the business activities, not programming constructs. This allows non-technical business people to understand, and even develop process solutions.

There are several necessary requirements which a platform must satisfy to be viable for end-user programming. Perhaps the most important is that it must work directly with concepts from the business domain, and hide computer implementation details. Business users will not invest the time required to master low-level programming constructs. Spreadsheets were immediately accepted because users were accustomed to using paper based tabular calculations. Visicalc made those activities both more powerful and productive. The 4GL development tools used graphical layout and declarative definitions to allow construction of rich user interfaces without knowledge of the underlying event model and graphics sub-systems. Users defined the result, rather than the process for achieving the result.

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.

Modern BPM suites can score well on all of the above criteria. The primary programming element is the process. This is a graphical representation of the flow of activities and information through an organization. It is represented directly in business terms, and typically configured by filling in a few properties in a dialog box. The user does not realize that they are actually programming. Supporting elements such as users, groups and documents also directly correspond to real world artifacts that business people use to describe their work. They also score well on expressiveness. They have evolved over many years and the current generation of systems include a sufficient set of standard activities to support a wide range of applications. The support and cost issues will be addressed shortly, but more context is required.

BPM platforms have been primarily designed to support enterprise wide, mission-critical applications. Clearly these are not candidates for end-user development. However, one of the central tenets of the BPM community is that everything that a business does should be thought of, and if possible implemented, as an explicit process. For an organization to fully achieve a process-centric culture, process modeling tools must be available for any legitimate business purpose, not just strategic initiatives.

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
Glenn Smith is a Principal Consultant with Appian. He has more than 20 years of software development experience including more than 10 years implementing enterprise BPM solutions. He can be contacted at glenn.smith-at-appian.com