IBM Business Automation Workflow (BAW), the successor to BPM, has been gradually overhauling its web-based UIs over the past few releases. Despite the changes, the coach view framework can suffer from Goldilocks syndrome, being a little too complex for citizen developers to use, but a little too constraining for skilled web developers.

In the past, some BAW customers have implemented so-called “headless” BPM, with human activities in processes implemented through a completely separate UI layer. Generally speaking, this was done to adhere to existing enterprise architecture or UI standards, or to leverage a different UI framework. The headless approach requires coordination of development milestones between the front-end team and the back-end team and makes it harder to incorporate feedback on the fly. In many cases, the implementation time of headless projects increased, and the agility of the team was reduced.

An Apex Form running in BAW Process Portal

Now a new form of headless implementation is available. Apex Forms leverages a modern, open-source application stack and a loosely-coupled architecture to bring no-code UI creation to IBM BAW. Apex Forms implements fully responsive form-style UIs for BAW tasks. It was built using Angular and Material Design so it is fast, responsive and built to be usable on any device. Yet its interface is simple and intuitive, designed with business users in mind. Apex Forms brings no-code interface design to the people who will use it most.

Forms can be generated from BAW process models and/or created and modified with no code. Apex Forms has pre-built libraries of common fields and validation patterns.

Data entered in the forms can be stored in the forms app or sent to the process instance in BAW. By separating data into process-relevant data, and payload-only data, the flexibility for business users to modify forms without affecting the process model is massively increased, and changes to forms can be made and published instantly. Apex Forms is a node.js application, running in a container on-premise or in the cloud, and takes advantage of BAW’s built-in REST APIs to communicate changes to data, task status, and ownership.

Why Headless No-Code?

This all sounds great, but why would an organization want to implement this pattern?

  1. It's a great way to provide citizen developers with a no-code UI creation tool to allow them to quickly implement processes in IBM BAW. This brings a new development paradigm but leverages existing IBM BAW infrastructure.
  2. It can increase the productivity of BPM teams, by offloading UI work to the citizen developers who know best how they want the UIs to look.
  3. It increases agility for UI changes in a process app. Decoupling the UIs from the process means that citizen developers can make and deploy UI changes in minutes without risk to the process app.
  4. It gives a simple, clean, consistent, responsive (mobile-ready) look and feel to process UIs, underpinned by a modern architecture based on an open-source stack.
  5. It can reduce the load on BAW servers by offloading UI work. Depending on the type of license you have, this can lead to more process automation with the same amount of BAW licensing.
  6. It leverages container-based deployment, meaning scalability is handled out of the box.

Apex Forms is currently in limited beta release. To find out more, head over to apexforms.io.