freshidea - Fotolia
Business process management has evolved as a standout strategy for guiding transformation through the easy composition of IT processes that support business activity. While the mission of BPM hasn't really changed, BPM methods and mechanisms are evolving quickly to meet the new requirements of business and the new features of IT. BPM governance has to change with BPM, of course. To get a handle on how to address new-age governance, track the major patterns of change in BPM itself, address both business and technical dynamism in governance planning, be mindful of BPM trends in selecting governance approaches and be prepared to change tools and approaches when major enterprise and technology changes are expected.
The most obvious issue for BPM, and for BPM governance, is the need to make business processes more dynamic and responsive. This need fundamentally changes the notion of "workflow" to a model that is more event-driven, and most BPM tools are workflow-driven. Governance that's based on the notion that some business process language will guide work and thus define process relationships isn't applicable to an event-driven system.
It's widely accepted that the impact of this shift is that BPM has to rely more on monitoring activity than on coordinating or directing it. The challenge is that, in a cloud event-driven world, you don't know where processes are or what they're doing unless you somehow connect with the processes themselves. This is done traditionally in three ways: fixing the processes to a specific resource that can be monitored, providing a dynamic link to the assigned resources or getting the processes to report their activity. All of these solutions are workable, but it's easy to lose the flow of activity when looking at processes in isolation.
A more modern approach is to presume that event-driven systems have to have policy-based steering of some sort, or nothing could be done except by a giant monolithic application. Cloud providers, like Amazon, are providing contextual steering of work, and the policies that control this steering can be used to identify how information moves through applications and processes. This can then be used to identify the specific hosting points. In many ways, it is similar to what's done with service buses and business process languages, but the steering policies in the cloud are likely to be distributed, making it harder to find even the policies. The best approach is to rely on the specific tools used for policy steering of events to provide information on workflow.
Another BPM governance trend arises from the growing trend to treat data as a cohesive element of IT, subject to its own governance. Traditional BPM often doesn't treat data as anything at all, something that users have long found could be problematic. There is growing interest in entity-relationship (ER) modeling for building business process-to-data connections. The enterprise value jury is still out on the extent to which data governance and ER modeling can be truly integrated with BPM; it may be easier to do if there's a tie-in between traditional business process models in enterprise architecture (EA) and ER modeling. Keep the BPM/ER relationship in mind; we'll come back to it.
Even discounting any BPM linkage with ER, many enterprise architects believe that governance is better focused on data than on business processes. It's often the data that has to be controlled, and by framing governance around data, enterprise architects can use the ER models to identify specific processes that expose or alter the data. This can be a backdoor mechanism for linking governance practices to business processes.
The reference to EA here is particularly relevant because advances in BPM driven by business needs are focusing more attention on the "business process" piece, linking BPM to both current and evolving business processes. What seems to be emerging here is a conviction that absent formal, effective EA, it may not be possible to generate effective BPM governance to suit the dynamism of current business processes. That's because enterprises are focusing increasingly on enhancing worker productivity through new applications, and these new applications are increasingly event- or context-driven, meaning that the worker effectively drives the processes rather than the traditional process-defining-workflow ways of the past.
To account for business agility in BPM, there are two pathways to consider. One is to quickly define shell processes to represent the structure of your developing event/context-driven applications so you can lay out a governance model for them. Shell processes represent fully implemented software elements and are used to visualize component relationships and relationship changes in applications. These changes are normally what changes governance requirements.
The other is to use ER modeling to achieve that same goal. While few non-IT personnel can effectively visualize what a future application might look like, it's much easier for operating unit personnel to identify the data elements that a new tool to improve worker productivity might use. The ER models could then be used to map data usage changes to new BPM processes.
While the process details of future event-driven enhancements to your business process may not be clear, the likely data elements are more easily identified. Using ER modeling, you can then identify the new worker-to-data relationships emerging and, from that, get better detail on your shell processes. In any event, much of governance really relates to the data rather than the process, so you could prototype a governance model entirely from the ER picture.
BPM governance is driven by changes in the business process-to-IT role but also by the way that modeling processes work. That can lead to linear thinking at a time when workers are increasingly event-driven. It's that shift that BPM must accommodate, or the industry may find a different model.
Best practices for BPM lifecycle
DevOps adopts BPM for apps
Converging AI and BPM