Dec
5
Riva’s Process Architecture
December 5, 2006 |
Riva
What is a process architecture? It’s a definition of what processes an organization needs to conduct its business, how those processes interact, and how they are managed and modified over time. A process architecture should be something that can remain fairly intact even as the details of the process execution change.
Riva’s creator, Martyn Ould, claims that it allows analysts to define a process architecture based solely on the business an organization is in, without reference to how it actually does that business, corporate culture, values, or anything else. If true, this is a very nice thing to be able to do, as it means that two analysts of differing skill levels and backgrounds should be able to go into an organization and derive identical process architectures. For me, this promise is a pretty big deal. I’ve been looking for a way to help less experienced analysts figure out how to define a process without relying on the customer’s (often fuzzy) ideas of the work done or on me to tell them what it should look like.
Does Riva deliver? Sort of. It doesn’t succeed in reducing process architecture to pure craft, with no judgment or skill required, but it will provide a greater consistency in the definitions and help get people started. It also accomplishes one of the things I look for in a methodology, in that following Riva will help analysts ensure that they’ve fully examined the domain and corrected possible mistakes.
The first step in Riva is to generate a list of Units of Work (UoWs). These are supposed to be the fundamental items that the business produces. A auto company makes a Car, for instance. Once you have a list of UoWs, you need to define which of them are created as the result of the creation of other UoWs. See the example below:
For each unit of work, you need to create a process to handle it, a process to manage the production of UoWs, and then connect them together. The connections are placed in a set form based on the “generates” connections. It sounds pretty simple, and it almost is that simple. Here’s the architecture that resulted from the UoWs above:
The creation of the processes above is very “mechanical”, to use Ould’s term. What that means is that any analyst who selected the same units of work that I did will get the same process architecture. And once I’d been over Ould’s book a couple of times, the architecture above looked pretty good. It needed some small manual tweaking and the merger of one or two processes, but overall not bad. Even better, the whole effort only took a few hours, and because the derivation of the process architecture is mechanical, you can focus user efforts on the units of work (which are really simple, right)?
Not quite.
Here’s the problem: Ould’s process is really dependent on getting the “right” units of work.
It took me a number of tries to get an architecture that I was happy with. At first I had way too many units of work and produced interactions that were far too complex. From that, I learned that you have to define UoWs at the 30,000 foot level–just the ones that the people at the top of the organization care about, rather than things that might be critical along the way. Ould says that the “level” at which you work is a matter of choice and it doesn’t really matter, but I’ve found that doesn’t seem to be true. For instance, an earlier cut had authors producing tasks rather than contributing to knowledge areas. Both are true, but using tasks made the process architecture look all wrong and not correspond to what we’re doing.
With more experience it’s probably easier to spot this problem, which may be why Ould never discusses it. “When it doubt, throw it out” seems to be a good rule for UoW definition.
A second problem is that the “generates” relationship is a little fuzzy. For instance, here are some candidate UoWs from my current consulting job:
- Investigation
- Committee Review
- Decision
- Hearing
An Investigation is sent to a Committee Meeting, which renders a Decision. The Decision may result in a Hearing. So what is generating what? Does the Investigation, the Committee Meeting, or both generate the Decision? Does the Decision or the Committee Meeting generate the Hearing? These relationships will determine what your process architecture looks like, and no matter what Ould says, it’s not obvious based on his definitions what the correct answer is. Again, when I derived an architecture using his methods, I was able to come up with an answer based on which set of process interactions produced a result that looked most “right”, but again we’re back to experience and judgment.
The third problem is that what this produces is a Riva process architecture. While the interaction and the definitions look good, there is nothing that guarantees that they’ll look very much like the way your customers conceive of their business. For instance, the one I drew up to reflect the client I mentioned above ended up with some significant differences from what they do today. Between that, and the need to be ruthless with UoWs mentioned above, I can easily see how you could get very bogged down with SMEs trying to convince them that everything important is captured in the architecture, or at least will be when you finish defining the process.
Even given that, I’m reasonably pleased with this part of Riva. Even though the process architecture is only quasi-objective (rather than fully objective), that’s better than most. At the very least, all involved in modelling the process will be speaking the same language and can focus their debate on correctly defining the UoWs, which are less ambiguous than a “process”.
The other challenge is that there’s no “mechanical” way to define the actual flow of a process from a process diagram. You have a pretty good idea of where a process should begin and end, and where it should get and receive information from other processes. It’s actually not a bad start. However, the internals of each process have to be defined the old fashioned way.
More on that later.
Comments
1 Comment so far
What I'm Reading- Do You really Believe in What you Do?Requirements Defined - Seilevel's Software Requirements Blog
- C.R.A.C.K. Requirements managersBetter Projects
- ‘IT has no inherent value’IT Project Failures
- Business Analysis in an Uncertain EconomyJonathan Babcock
- Why We Lost Focus on Development PracticesAgile Management Blog
- Talking about what we doRequirements Defined - Seilevel's Software Requirements Blog
- BPM is not Software EngineeringGo Flow
- 3 Big CaliberRM Gotchas And How To Fix Them Part 1Requirements Defined - Seilevel's Software Requirements Blog
- Project World and World Congress of Business Analysts (PW&WCBA)Better Projects
- Troubled ProjectsHerding Cats
I have a great deal of difficulty with Riva generally and role activity diagrams (RADs) specifically. When I look at a RAD all I see is a an activity diagram with swim lanes. To me there is nothing new here. Ould’s emphasis in process modeling seems to be the role. I do not understand why anyone would emphasize role which is probably the most artificial and least intrinsic element (and, therefore, the most susceptible to change) in a business process. To me (and my clients) I want sustainability in my business process models. In order to attain that goal I want to base my process models on the most stable elements of a business process that there is. Of the “W5 + How” Zachman perspectives, the 3 most stable (once the reason for the entire process has been established) are:
1. the When (the events that trigger and direct a process),
2. the What (the “things” the process deals with including data) and
3. the How (the actual process steps).
Ould’s ‘units of work’ sure seem like the main business objects (~data entities) the process deals with.
Events are, believe it or not, the most stable of all elements of a BP. An example is “claim arrives for payment”. A much more tangible business strategy can be written mainly using business events - which ones are we to begin/continue/cease responding to in the next n years.
I think what we need to do to maximize the value of modeling to our clients is to:
1. Have 2 views of a BP - separate the logical (much more stable) model from the physical model and map between the 2. Let them vary independently, but always preserve the traceability between the 2.
2. Combine the events/When, things/What and process steps/How together in the same model. I refer the reader to IBM’s LOVEM style diagrams or Eriksson and Penker’s Assembly Line diagrams.
What we need to do as business analysts is to try to tease out the stability that is inherent in a business process and base our models on those elements. Of course those elements will change, but not as much as some of the others. Role should be the last element to consider when designing as stable a process as feasible. In this way we let the process determine the roles needed to execute it. That is the way to optimize a process and make it “world class”. If we don’t do it well, some other country’s BAs will.