Wednesday, October 24, 2007

Demystifying Business Process vs Use Case Modeling

The other day I was part of an interesting discussion that started with the statement that there is a problem with OUM (Oracle Unified Method), or to be more precise the Unified Process being use case centric, while these days much development is based on business process modeling. The problem being that because of this people involved with business process modeling might think that OUM does not properly fit their needs.

I often hear people talk about use cases, and too often find out they actually do not know what a use case is. I’m convinced that anyone that does know both business process modeling and use case modeling, would not say such a thing as they would realize that a business process model is just another representation of the same thing.

Let me explain and convince you that OUM supports business process modeling quite well and does so for as long as it is there.

Now, I’m not going to explain what use case modeling all is about, but rather point you to the white paper. I wrote about that subject. However, what I probably do need to explain is that you can have use cases at different levels. My paper is based on OUM and the original work of Alistair Cockburn, who presents the following levels:

Before I continue I need to make the distinction between the conceptual notion "use case", being the interaction of an actor with a system to achieve a specific goal, and a "use case description", being a narrative description of that interaction.

The key point that I’m trying to make here is that a use case should be specified as a scenario. You might realize that at every level you can describe that scenario either by using a use case description, as an activity diagram or both, whatever suits your needs. And you might also be aware that at any level above the user goal use cases, an activity diagram actually is a description of a business process at some level. So there you are ...

What some of you folks that are into the Business Process Modeling Notation (BPMN) might not be aware of, is that UML activity modeling and BPMN just are two different schema techniques for doing the same task, as is clearly explained in a white paper by Stephen A. White. OK, granted, some patterns are more effectively handled by BPMN (like the concept of ad-hoc process to support the Interleaved Parallel Routing pattern), but that concerns minor details only.

So now I proved that a business process model and a use case description can describe the same thing, I hope with that you realize that the only thing you need to do to transform a business process model into a use case description, is by creating a narrative description out of that. But let me bring this academic discussion down to a practical level and discuss how to get from business process models to use cases. Otherwise, why bother, right?

Mind that narrating a business process results in a summary use case description. Many people not being aware that there are different levels of use cases, probably will use the notion "use cases" only to mean the user-goal level use case descriptions, a use-goal use case being defined as a use case for which the primary actor can go away happily after finishing it. If you are not aware of this it is likely you will have a hard time working with use cases. Just to warn you.

When going from business process models to user cases, you will be aiming at a model of user-goal use cases (and a couple of subfunction use cases going with that) as normally that should be the lowest level at which you capture requirements. Before you can do so, you need to make sure that the lowest level business process models contain activities at the level of user-goal use cases only. If that is not the case, fix that first.

Once that has been done you need to take just one more step from there. How you do that is up to you of course, but you could create a use case description for each activity in that diagram that is a candidate for being implemented and start detailing from there. Whenever useful, you can add an UML activity diagram to that. To prevent confusion, you probably better not use BPMN for that.

19 comments:

To business, they could go either way: business process modeling or use case modeling.

But the question is whether the business process modeling is more suitable for Service-Oriented Architecture? On the other hand, use case modeling is good at component-based, model-drvien architecture?

I don't think the determining factor is SOA versus component-based, model-driven architecture. After all, in the latter case you could start with business process modeling. It probably is more a matter of what people are used to.

And in many SOA project there are plenty of user-goal use cases that are better captured using a use case description than a diagram, because diagrams offer little to no means to express other aspects than just only a flow.

Granted, being a schema technique business process modeling seems to make it easier to go from a model to an implementation, like from BPMN to BPEL.

As often, it depends. Use what suits you best. As long as you a aware that both techniques are just different representations of the same, you can easily switch from one technique to the other when appropriate.

When use case modeling was introduced by Ivar Jacobsen, the vast majority were rightfully confused as to how and what a use case actually was.Alister Cockburn work was fundamnetal in adding some level of precision andhis attempt to categorize use case levels was a big step in the right direction.

The name use case refers to the set of all possible use case scenarios for thatgiven use case. Any scenario or instance of that use case can be also called ause case description and depicted in an activity diagram. Hence the confusion,especially if english is not your native tongue.

I agree that "narrating a business process results in a summary use case description." However, another important difference that comes to mind is the fact that while a use casetitle will be used for low level features it will also be used to name a business process.

While a feature does not add business value for the stakeholder a business process is required to do so. From an application development point of view, "SearchTerm" is more than just a feature for any search engine that wishes to compete with other search engines. However,to search for something in most application is just a tiny feature hardly giving any business value in most applications.

A second thing worth mentioning is that use cases are simply listed in a brainstormingattempt to create an overall view of the essential goals. Business processes are typically sequentially placed in relationship to each other. So as you may compare a scenario/use case description (which can be described either with text or with an activity diagram) to a business process, it is in my opinion incorrect to equate a use case to abusiness process. Understanding the difference between a use case, a scenario and use case levelsis the key for not making this mistake.

I like to start modeling the business goals and business use cases (what an external actor could do with the business).

Each business case is described with a business process to accomplish the associated goal.

Some steps int this business process will be invocation of automated services, and others will be human tasks. Then, human tasks become use cases (user goal level).

If using a BPM engine, the user interface (boundary) for each use case will sure be one-to-one (eg. one set of task specific web pages per use case). If not, designers could come up with a user interface composed by the boundary of many use cases.

So, I don't feel I have to choose either business OR use case modeling. Am I missing something here?

I'm curious why you would say: "While a feature does not add business value for the stakeholder". What would otherwise the rationale be of implementing a feature if it does not add business value to the stakeholder? What is your definition of a feature? Some say use cases are features, but I suppose not every feature is a use case. IBM recognizes the requirements pyramid (not sure what the origin is), consisting of needs - features - use cases - scenarios - test cases, making a distinction between features and use cases.

Without elaborating on it, I rather avoid using the word "feature". For the sake of keeping it short, I also avoided mentioning the difference between a /business/ and a /system/ use case.

I must admit that from what I write it may be hard to recognize, but I also did not try to suggest that a use case is equal to a business process.

What I did try saying is that (depending on the scope) they can represent the same thing, meaning that both a business process and the use case scenario (or set of scenarios to be very precise) of a summary use case represent a "business process".

Unfortunately we currently do not make a difference between /business/ processes (that abstract from systems) and /system/ processes (that do take systems into account). In this context a /system/ process would be something that you can implement with a BPM tool like the Oracle BPM Suite.

Otherwise you could say that summary (system) use cases represent the same thing as /system/ processes. What is the same is that the description of the summary use also would show how the lower level use cases are tied together.

But in my opinion this starts to become too academic. Progressive insight tells me that in practice you probably use business processes to tie user-goal use cases together. In this way business processes are the higher-level things "above" the use cases.

About Me

I am an Integration Architect with a primary focus on Business Process Management, Case Management, and Service Oriented Architecture, both in the Cloud as well as on-premise, and with a solid Java background.