Workflow automation is all about making processes more efficient, by reducing delays and eliminating waste. Workflow or Process Management systems save time by making sure people only get assigned tasks when they are ready to be worked on. The system can group tasks by type for efficient batch processing, and can highlight repetitive tasks for potential automation. If we can reduce the amount of work it takes to implement workflows, we get a magnifying effect as more workflows means more savings in operational work.
IBM Business Automation Workflow (BAW) has always had a business-friendly process modeler which leverages the Business Process Modeling Notation (BPMN) standard. Implementation of process applications is completed by creating user interfaces for process activities using the coach view framework in BAW. The coach view framework is powerful and extensible and Apex was one of the first partners to develop a Coach Views Toolkit (check out ACV2).
As with all good things, there are trade-offs, and the downside of Coach Views is that with its flexibility comes complexity. In our experience, very few “business-technical” people have been able to get comfortable with coach creation in BAW, and this work usually falls to developers with some knowledge of javascript and CSS. There is often a tight-coupling between the data in the process and the elements of the UI, and developers have to concern themselves with initialization and mapping of variables to make sure everything works just right. UI development can be 50% or more of the total effort in a project because of this complexity.
Another challenge in BAW application development is data storage. By design, BAW process applications are intended to coordinate work where data related to that work is stored in its own systems of record. In reality, almost all process automation projects turn up a few data items that don’t have an existing system of record. Creating and managing data stores and APIs for these items becomes a significant chore for many projects.
It is common that much of the data payload in a given process instance is not used by the process definition, it is simply being transported from one user to the next. When UIs are tightly coupled to process data, the ability to change one without the other is greatly reduced. This becomes extremely important when we get into real-world processes which are constantly evolving to support new business requirements and to accommodate more effective ways of doing things. Product owners become frustrated by the time taken to complete the full testing and deployment cycle that is required even for small UI changes.
Apex Forms is an exciting new approach to automating processes with BAW. A nodejs application, running in a container on-premise or in the cloud, Apex Forms runs “loosely coupled” as a set of micro-services to implement BAW UIs. Data entered in the UIs can be stored automatically in the Forms application, or sent back to the process instance in BAW. The responsive, form-style UIs are implemented with Angular and Material design, and the configuration of the forms, sections and controls is a no-code operation. When data is properly separated into process-relevant data, and payload-only data, the flexibility for the business to modify forms and their associated data payload is massively increased.
Using Apex Forms with BAW results in much simpler Human Services, eliminates much of the business object creation and data-mapping, drastically reduces the need for integration services (for example to support ajax calls from coaches), and accelerates user interface creation. In short, it dramatically reduces development effort for implementing process applications. Apex Forms is in a limited beta release right now, head over to apexforms.io to learn more.
