MWD’s Assessment Framework for Process Application Platforms

RESEARCH REPORT // FREE
 
Process Application Platforms are collections of software tools, servers and services that organisations use to build, deliver and change business process applications. What technology capabilities are important? Which vendors are making real efforts to provide those capabilities, and which are simply re-naming or re-positioning their existing technology? This report explains the analytical framework we use to shape our series of Process Application Platform assessment reports, which provide up-to-date independent analyses of the capabilities of key suppliers in this area.

Top takeaways

The capabilities of Process Application Platforms should be looked at from multiple perspectives

When assessing Process Application Platform offerings, it’s tempting to simply consider the functional capabilities of a product or product suite. However, a functional view that looks at support for different phases of a business process application lifecycle (mapping, design, deployment, monitoring etc.) is only one perspective among multiple that are important.

It’s also important to consider how well Process Application Platform offerings support common kinds of work management scenarios (automated, transactional and exploratory), each of which has its own particular requirements and challenges.

Our Process Application Platform assessment reports clearly analyse not only the core functionality on offer, but also the capabilities that are provided in support of automated work, transactional work and exploratory work scenarios.

Take time to understand the relative importance of core functionality and other issues

When considering technology to support a business process application delivery initiative, you need to think carefully about the relative importance of capabilities and attributes that are important in your own situation.

It’s easy to be seduced into concentrating on the facilities on show to support (for example) mobile and social styles of engagement, but in your own situation, for example, it might be that change management capabilities are much more important.

Requirements for Process Application Platform offerings

The key capabilities of Process Application Platforms

The world is not short of technology tools that purport to enable business software solutions to be built, deployed and changed quickly. Neither is it short of tools that purport to enable non-technologists in business to build software. The promise of Process Application Platforms may on the surface appear similar to both of these ideas, but there’s more to it than that.

When you take a broader perspective of Process Application Platform technology the differences become clear. The ability to co-ordinate work through software, at scale, is a transformational tool for a business. If organisations are going to realise the potential business value of a business process application delivery initiative, technology tools to support it must have some key characteristics that take them beyond clichéd concepts like “business-driven development”.

To maximise the value of business process application delivery initiatives, processes have to be able to drive and co-ordinate activity across many teams, departments, and automated systems throughout the organisation – it’s simply not enough for them to be limited to working within one department. Process Application Platforms have to bake analysis, monitoring and measurement of business activity right into the act of automating work co-ordination. And they have to actively promote the involvement of business specialists in the whole lifecycle of initiatives – from initial business process discovery and analysis, through process application design, to administration, monitoring and optimisation. All these characteristics are just ‘table stakes’ for Process Application Platforms.

The figure below provides an overview of the key capabilities that need to be provided by Process Application Platforms.

Core implementation cycle functionality

As the figure below illustrates, there are three broad categories of functionality that a Process Application Platform should support in the context of the project implementation cycle: process mapping, modeling and design; process operation and execution; and process monitoring and improvement.

2016_pap_af_fig1

Key Process Automation Platform technology capabilities

The sections below highlight the core lifecycle-supporting capabilities we expect Process Application Platforms to be able to deliver.

Mapping, modeling and design

Mapping and modeling capabilities help business analysts, business decision makers and other ‘non-IT’ project stakeholders work together to analyse high-level business process automation opportunities, challenges and priorities. Of course, in many organisations, there are other architecture and analysis activities progressing independently of process automation efforts that should influence how projects should proceed; at the same time, though, there are useful tools and approaches available to business process application delivery initiatives that your other architecture and analysis work streams are probably not using.

We look for Process Application Platforms to exhibit the following capabilities in this area:

  • Visualisation and high-level modeling tools that are easy for non-specialists to use. Ideally, tools should allow users to create multiple alternative process improvement scenarios, carry out high-level modeling against those, and compare and contrast these models side-by-side.
  • Tools which not only capture requirements concerning processes and high level business process model ideas, but also business process “context” information concerning concepts such as organisation, goals, key performance indicators (KPIs).
  • The ability to easily import or access models and documentation that have been created in other tools, to help provide context for your work.

These capabilities help customers model ‘current state’ processes, and design ‘future state’ processes. This is perhaps the most mature area of business process application delivery technology, because for a long time the extent of most organisations’ process management ambition was to document existing processes and then statically design new or changed processes.

We also look for Process Application Platforms to provide the following capabilities:

  • Tools that allow many different types of both simple and complex processes to be modeled, while at the same time enabling different audiences (specialist and non-specialist audiences; internal and external audiences) to see specialised views of models.
  • Tools that enable modelers to easily specify, as far as possible without coding using procedural scripts, not only business processes but also other design artefacts that drive process application functionality – including application data, application user interface elements, events, instrumentation points, error handling tasks and flows, deadlines and timers, organisational information (process participant roles, responsibilities, delegation and escalation policies and calendars), and integration adapters that help applications connect to and share data with external systems.

Operation and execution

Business process operation and execution capabilities are delivered by implementation tools and runtime platforms that take application designs and deploy and run them as process applications in the context of customers’ own existing systems of record, identity directories and so on.

Process application engines need to be able to scale efficiently in demanding scenarios, while at the same time working efficiently when executing process instances that have lifetimes measured in months and years. Process engines should also act as robust and scalable event and data sources themselves, driving information into monitoring and optimisation tools, as well as acting as a consumer of other software systems.

We look for Process Application Platforms to exhibit the following capabilities in this area:

  • Tools that compile process and other models to executable forms that can then be straightforwardly provisioned onto running process servers. A debugging mode, where technical staff can step through processes and inspect variables to detect potential problems, is a bonus.
  • A process engine that can handle the simultaneous deployment of multiple versions of one process, as well as being able to execute individual tasks or steps within a given process in isolation (for example, to support optional tasks in dynamic processes). We also look for the ability for process engine infrastructure to be federated and distributed, so (for example) making it possible for workers to continue executing tasks whilst not connected to the central process engine (an important prerequisite for true mobile working support).
  • An administration tool that makes it easy to carry out administration tasks on process instances / cases – for example, to start and stop processes, reassign tasks, change task priorities and due dates, and ‘back out’ process steps if an employee leaves while working on an instance.

Monitoring and improvement

Core monitoring and improvement capabilities enable users to monitor operational business process instances / cases, gather metrics, and then provide visualisation capabilities to help users observe the performance of work in line with operational goals and KPIs. They also help analysts improve processes over time by providing tools that analysts can use to dig into historical performance.

We look for Process Application Platforms to provide the following capabilities in this area:

  • Dashboarding functionality (which ideally can be delivered through customers’ existing portal infrastructure where required) that can be simply configured, by non-technical business people, to present monitoring data from running process instances, in context with other relevant external business data for technical and non-technical audiences.
  • Tools that can trigger alerts when events occur, thresholds are exceeded or KPIs are missed. Ideally, tools should be able to perform a degree of predictive alerting. The definition of alerts, KPIs and alerting thresholds should be able to be carried out by non-technical business people.
  • Visualisation functionality to present aggregated historical performance data for technical and non-technical audiences – ideally in the context of modeled processes and organisational structures, making it easy to uncover and drill into performance hotspots and bottlenecks.

Rapid prototyping / quick start

In the age of digital transformation, it’s increasingly difficult to make the case for investing in a platform that needs to be worked on for 6-12 months before any tangible value is delivered. We know from our research community that modern expectations of Process Application Platform value delivery range between 1-3 months.

We look for Process Application Platforms to provide targeted tools, wizards or interfaces that help teams very quickly construct simple ‘first-cut’ process applications – for use in rapid prototyping sessions and proof-of-concept exercises (or perhaps to serve low-complexity, small-scale departmental use cases). We expect the output of these tools to be not obscure generated code, but models and easy-to-understand specifications that can subsequently refined and further developed to create more sophisticated process applications for operational deployment.

Change management

One of the key promises of Process Application Platform technology is that by providing modeling and code generation tools that make it comparatively easy for non-specialists to specify business process and related application behaviour, and then providing tools for technical people to elaborate logical models to include technical details, processes can be changed almost instantaneously. However, change without control can be dangerous.

Rapid change has to be managed to ensure that unintended effects don’t creep in, and tools need to provide appropriate change management facilities if the promise of Process Application Platforms is to be fulfilled.

We look for Process Application Platforms to provide the following capabilities in this area:

  • A repository for models and design artefacts that provides shared but controlled access to multiple analysts, designers and developers. As a bonus, it should be straightforward to implement federation of repositories so that different teams and projects can share and reuse assets between each other or from some central design authority (like a centre of excellence).
  • Tools that can maintain a version history of changes to models under management. Ideally, these tools should provide version control functionality that can be applied across all design artefacts (such as processes, rules, calendars, events, goals, and KPIs), and should also provide impact analysis functionality that can allow users to carry out ‘what if’ analysis to highlight the impact of potential changes.
  • Tools that allow administrators to identify individuals (or roles) responsible for enacting process change, and then ensure that only authorised individuals can make changes to deployed processes. Ideally, tools should work seamlessly in environments where users want to configure one or more process testing/staging areas, and should provide support for workflows to be put in place to enforce any relevant management approvals.
  • Tools that make it straightforward to define multiple target environments and deploy process applications seamlessly regardless of target; and that make it easy for administrators to manage upgrades of process models and other related specification models ‘in flight’ without having to stop and restart servers.
  • A library-level reuse mechanism that makes it easy to create multiple variants of models and other application components that can inherit behaviour from ‘parent’ models/components – so that changes made to parent assets are seamlessly inherited across all children.

User experience choices

10-15 years ago, early BPM technology platforms were largely deployed to manage the work of teams of ‘heads-down’ employees, specialised in processing specific tasks. However the value of a modern Process Application Platform is potentially much, much broader – and platforms should not place artificial constraints on the ways that co-ordinating services can assist not only specialised task workers, but also customers, partners, suppliers, prospects, managers, executives and other stakeholders.

We look for Process Application Platforms to provide choices to implementation teams, so that you’re not locked into a particular way of linking people and business processes together in operation (for example, via a web-based task list – which might be fine for ‘heads-down’ task workers, but a very poor fit for a mobile field worker). Ideally, as well as a table-stakes responsive web user interface framework for your process applications, we look for Process Applications to offer:

  • A runtime platform that makes it easy to share work-related events such as status updates, performance / escalation alerts, tasks via an accessible ‘activity stream’ and capture and share updates from process participants from within that. The ability to integrate events from external business systems and updates from work participants in one activity stream environment is a bonus.
  • A runtime platform that can easily expose key work management features (event monitoring via activity streams, task acceptance and completion, work initiation and so on) across a range of popular mobile devices using a choice of native and web-based clients.
  • A rich server API that presents all key work distribution and task management functions, making it straightforward to ‘hook’ platform functionality into completely custom front-end applications.
  • A runtime platform that can deliver key work management features within email environments (including offline task completion support).

Support for different types of work

We commonly see three different types of work to which Process Application Platforms are applied:

  • Automated work. In automated work scenarios (sometimes called straight-through processing scenarios) the Process Application Platform is responsible for automating not only the co-ordination of work, but also as many individual tasks as possible. Human involvement in this kind of work is limited to exception handling.
  • Transactional work. In transactional work scenarios, processes tend to be focused on orchestrating and routing clerical or administrative work. The Process Application Platform is responsible for automating the co-ordination of work, but tends to automate only a portion of tasks – many tasks are claimed and enacted by individuals. Process structure is very likely to be explicitly modeled prior to implementation. Even when processes need iterative optimisation over time, those optimisations can be very comfortably designed “up front” by a specialised team, encoded and compiled in some way, and then deployed as fixed process descriptions for use by others.
  • Exploratory work. In exploratory work scenarios, the set and sequence of actions needing to be performed, and the people or roles needing to perform them, are very unlikely to be known ahead of time. There may be some high-level waypoints or milestones that are common to a particular type of exploratory work (perhaps to ensure consistent quality control, or resolution approval, or archiving) but they provide a very loose, rather than tight, structure. In exploratory work, as the label suggests, the overall experience for both the work participants and the customer is that of a set of possibilities being explored rather than a recipe being followed.

As you might imagine, these scenarios place different requirements on Process Application Platforms, both from a functional perspective and an architectural perspective. In our assessments, we analyse the degree to which vendors’ offerings can support these scenarios. We reach our conclusions by assessing particular scenario-specific functional capabilities that relate to each scenario. The sections below summarise the capabilities that we look for in our assessments.

Automated work

In support of automated work scenarios, we look for Process Application Platforms to provide the following capabilities:

  • A flexible range of application and information integration technologies, using standards where possible.
  • Tools that allow designers to define exception processing both at the “business” level (there’s a problem with the process) and at the “system” level (there’s been some kind of technical problem) with the ability to pass exceptions to humans for remediation.
  • Tools that allow designers to group work steps together within distributed transaction control boundaries and have the process engine manage transaction integrity, and that enable the definition of compensating transactions where distributed transaction control isn’t possible (for remediating exceptions in long-running processes, for example).
  • Tools that enable the definition and execution of business rules that separate policy decisions from flows, seamlessly linking process information models to rule dictionaries.
  • Tools that enable designers to script against defined integration services to enable processes to exchange information with external data sources and applications, and that enable the specification of data transformations to assist integration services, without coding.
  • A runtime environment that makes it easy to have process instances started or influenced on occurrence of external events (or event patterns) without the need for coding.
  • A runtime environment that makes it possible to deploy processes so that instances are transparently executed across pools of servers without complex configuration.

Transactional work

In support of transactional work scenarios, we look for Process Application Platforms to provide the following capabilities:

  • Tools that enable designers to specify sophisticated (multi-part) user interface forms and related elements that present all of the context necessary to complete tasks, and distribute these to participants through centrally controlled “work lists”.
  • The ability to define roles flexibly so that work doesn’t have to be assigned to specific individuals at design time.
  • The ability to specify abstract organisational models comprising groups and roles that can dictate work assignment, escalation and delegation schemes. The ability to model multi-dimensional organisational structures (where roles can individuals can be related to other individuals in multiple ways) is a bonus.
  • The ability to distribute tasks to individuals or groups based on abstract specifications and logical constraints (i.e. not only based on organisational model queries, but also on calendar queries, and with reference to common workflow patterns).
  • The ability to define goals, constraints and variants that shape how work may be selected and/or ordered to deliver on goals within constraints, and the ability to have administrators make on-the-fly prioritisation changes between process instances, to ensure that goals/commitments are reached.
  • Design tools that enable modelers to specify that a set of tasks should be ‘chained’ together so that all tasks are conducted by one individual without control being passed to and from the process runtime with each task.
  • A runtime work management platform that enables task owners to create subtasks on the fly and create collaborative contexts for task completion at runtime.
  • Design tools and a runtime platform that seamlessly integrate with content/document management systems, or that work with inbuilt CM/DM systems to seamlessly retrieve, store and update documentation relevant to work in progress.
  • Operational analytics tools that can act on relevant historical process and contextual information to make decision recommendations to individuals working on tasks.
  • Analytics tools that enable analysts to explore historical work performance from an organisational perspective (enabling, for example, the performance of different groups of individuals to be compared), as well as from a process perspective.

Exploratory work

In support of exploratory work scenarios, we look for Process Application Platforms to provide the following capabilities:

  • Design tools that enable designers to specify sets of tasks, process fragments and selection rules that can be grouped together and associated with an application, so that at runtime work participants can select from the task and fragment set according to the information presented and the selection rules specified.
  • Design tools that enable work progress to be modeled in the abstract through a set of steps or states with associated milestones, with different selection rules applying in each work state.
  • A runtime platform that can dynamically create and manage tasks, data objects and flow definitions at runtime and associate them with individual instances of the overall work context (so that individual instances can be structured very differently according to the situation at hand).
  • Design tools and a runtime platform that seamlessly integrate with content/document management systems, or that work with inbuilt CM/DM systems to seamlessly retrieve, store and update documentation relevant to work in progress.
  • A runtime platform that enables completed work to be archived for later inspection – either for improvement or auditing purposes.
  • A runtime environment that makes it straightforward to link work contexts of multiple types together (so that, for example, an insurance claim context could be associated with another claim, as well as a fraud investigation context).
  • A runtime environment that makes it easy for work participants to search for personnel with appropriate expertise, associate them with a work context and collaborate with them to complete tasks.
  • Operational analytics tools that can act on features of work context (for example the segment that a particular customer is part of when looking at a customer complaint), histories and relevant contextual information to augment work decisions, highlight case similarities, and recommend courses of action.
  • Monitoring and improvement tools that can report on the progress of work against goals, by context type and/or by feature(s) – for example by customer segment – the analysis of which might require aggregation of data across multiple related process and task instances.
  • Monitoring tools that can report on work performance in relation to dynamic deadlines that are recalculated based on the way work unfolds in the exploration of a particular work context.
  • Improvement tools that analysts or work owners can use to take completed patterns of work and store them as templates for future use within new work contexts.
Download PDF version
RESEARCH REPORT // FREE