Don't Let Your Architecture BRP...

My projects and architecture activities center around health care (care providers and health insurers) and state/federal government agencies. With health care reform is still in place at this moment in the US, there is plenty of architecture and implementation work yet to do. In particular, Electronic Health Records (EHR) replacing paper-and-chart folders with patient clinical information and diagnoses are touted as a major driver to hold down the cost of heath care and, in the words of the truly faithful, increase the quality of care given. How that is specifically accomplished continues to have open issues at this moment in many major aspects.

I was purusing health care IT blogs recently and came across a very interesting post on EHR by Paul Roemer. First, he sets the stage about health care workflows - which are part-and-parcel of Business Process Management and optimization deliverables which in turn eventually become a part of Enterprise Architectures. Paul writes:

"Let’s agree for the moment that workflows can be parsed into two groups—Easily Repeatable Processes (ERPs) and Barely Repeatable Processes (BRPs). (I read about this concept online via Sigurd Rinde.)

An example of an ERP industry is manufacturing. Healthcare, in many respects, is a BRP industry. BRPs are characterized by collaborative events, exception handling, ad-hoc activities, extensive loss of information, little knowledge acquired and reused, and untrustworthy processes. They involve unplanned events, knowledge work, and creative work.

ERPs are the easy ones to map, model, and structure. They are perfect for large enterprise software vendors like Oracle and SAP whose products include offerings like ERP, SCM, PLM, SRM, CRM. How can you tell what type of process you are trying to incorporate in your EHR? Here’s one way. If the person standing next to you at Starbucks could watch you work and accurately describe the process, it’s probably an ERP."

And BRPs appear wherever there is non-linear, non-transaction-based workflow, not only in health care, but also in education, consulting, support, and government, to name a few. So, while it appears that ERP pretty much nails predictable, transaction-oriented business processes down well, how do we address the BRPs?

This presents a real conundrum for enterprise and business architects because of the uncertainty of the work. Enterprise and business architecture methods do everything possible to create and/or document defined, repeatable processes, and that isn't surprising given the mandate to provide comprehensive architecture gleaned at the base level from the organization's strategy. But in a lot of cases, that's only going to get us part of the way to the finish line.

There are no pat answers available to address the issues BRPs represent in our organizations, and their impact on them from business and architectural perspectives. Architects can begin to address BRPs by getting a boots-on-the-ground, in-depth understanding about how work actually gets accomplished on a daily basis in their organizations, and forget for a time what vendors claim is or can be achieved with any off-the-shelf ERP-centric system (and obviously, architecture). I would use the list that Paul outlines above to sort through and categorize what is discovered, and outcomes from such study - positive and negative - are also noted. The essence of what you have after this are BRPs that occur frequently enough to warrant further study - we aren't going to make much difference with BRPs that occur (very) occasionally unless a negative outcome of a BRP leads to large-scale catastrophe and we must address it in some manner.

Next, it must be realized that a portion of what is discovered will remain BRPs for various reasons because they cannot be consistently and reliably modeled and dealt with. However, I would wager that a sizable percentage of discovered BRPs can be addressed architecturally in some fashion in a consistent manner - most likely not by an ERP-centric approach but by other methods that can bring some consistency of process and measurement to those particular situations - and thus, integration (of sorts) into mainstream business and enterprise architectures -at least the recognition of them in architectures in any event.

There will always be BRPs in our organizations, and trying to make them go away, particularly by decree, is largely a futile and often expensive exercise. Understanding and addressing them, and eventually integrating them into the context of our architectures is what matters more. If BRPs can be optimized somehow, that's great, but recognition and integration of them into our architectures, even with a 'placeholder' to start, is the first step. Ignoring or minimizing them carries very significant risks to organizations.