Friday, March 21, 2008

About Business Processes, Use Cases & SOA (1)

It is my observation that since the introduction of SOA (Service Oriented Architecture) many developers are kind of lost when it comes to capturing requirements and doing design. Quite a few people already got lost during the "giant leap" from relational to object-oriented analysis and design, and (around the same time) had to jump from waterfall to iterative, and more recently from plan-based to agile project approaches. But since SOA too many people have no clue whatsoever how to properly write down customer requirements instead of producing designs of some services (if they even understand the difference).

Apparently some of us are convinced that "legacy" methods like the Unified Process do not properly address the issue of services. What I sometimes hear (and I don't exaggerate) is that a service delivers some reusable piece of functionality that cannot be pinpointed to a specific use case, so use case are useless. The best they can deliver is some flow diagram representing an orchestration of some services and call that a "business process".

Even when I was still clueless about SOA, I already found that hard to believe. What has become so different about user requirements since there is SOA that we cannot capture them as we used to? Has SOA really changed the way we think about requirements similar to how the Star Trek transporter will redefine the concept of transportation in a future near us? Does this question sounds rhetorical to you?

With this article and a couple yet to come, I hope to shed some light on this matter and help you to become aware that the world still turns and it is not you who is spinning around. As an example of this I will try to explain a way (not the but a way) of how you can capture requirements in a business process, and from there go to use case descriptions and finally implement services based on that.

As you might expect from me I will present this in the context of Oracle Unified Method (OUM), but don't let that scare you off. The targeted development environment will be BPEL.

The Case

The case I will use is of moderate complexity. The following activity diagram documents a business process concerning the application of a parking permit by a resident of some municipality.

At this point it is important to point out that this is a true "business process", as it only concerns business level actors like people, or organization units, and totally abstracts from any system supporting it. At this point the whole process could be manual, for all you know.

I find that important to point out as too often I have seen the situation in which the "analysis" is limited to a description of how some system is going to be implemented rather than on capturing requirements. You should only skip that latter step when you do it consciously and the risk of missing something that proves to be important later on is relatively small.

What might surprise you, is that the same business flow can be documented as a use case description, typically of the scope "enterprise" (that is cross organization-unit). In this case it also concerns a business use case, as it describes how the resident communicates with Parking Services, which in this context is an organization, rather than how this resident communicates with some system.

The Use Case

Presented as a use case the same business process could look as follows:

Normally a use case will not be created in one blow at this level of detail. It is more likely to be created in a few iterations of which the first one might suffice to document only the stakeholders, goal and main success scenario together with some business rules. In OUM this is what the Business Requirements process is supposed to be limited to. The example use case has been worked out to a greater level of detail, which would typically be done in the Requirements Analysis process.

How Use Cases Add Value

Compared for example with the situation where only a business process diagram is available, adding use cases adds value in that a (detailed) use case description provides the opportunity to specify aspects of the business process that goes beyond that of what you can express with only a diagram.

One of those aspects is stakeholders that are not directly involved in the process. In some cases identifying such stakeholders might give reason to extend the scope of the use case, like identifying the stakeholder Neighbor might have lead to considering to include in the business process a step that notifies them as well.

Other aspects that the diagram does not cover are the goals, the triggers, preconditions, and postconditions of the use case. All of them helping to validate the use case and some of them providing useful input for the next step in which the use case is going to be analyzed.

An advantage of putting it down in writing that may not be so clear at first sight is that by forcing yourself to express the business process in words might help you to discover flaws and omissions in the original process.

The value of putting effort in converting a business process into a use case description is not always easy to determine. It depends on many factors like the ability of people reviewing the business process to identify flaws in it, or how easy it is to correct errors later in the process. Probably the best advice would be: when in doubt, don’t hesitate and just do it. In case of the example the business process has been converted into a use case description in less than half an hour. The total process took much more time, but that was because the business process model needed to be corrected, because of errors found while describing the use case.

To be continued ...


Richard Veryard said...

I do agree that use cases can be useful - but my own view is that they are mainly useful for describing a solution (however abstract) rather than a pure requirement. I have explained this view on my SOA blog. What do you think? I look forward to your next post on the subject.

Anonymous said...

Thank you very much for the post. I agree that writing out the business process in the form of use case description can only help the process. If nothing else it will provide yet another review iteration.

My approach re: use case models and bpmn is that i first create a business use case model that defines the "scenarios" that would be detailed in the form of bpmn diagrams as well as the actors that would be involved in the process. i use these use case models to communicate scope with the business and order of delivery.

What do you think?

Thank you again for taking the time to detail your experience.

Jan Kettenis said...

That definitely makes sense to me and has proven to be practical approach for quite a while already.

It very much depends on where you come from. For example, application implementation people are use to business process models (Value Added Chain Diagrams and so on), and hardly use use cases. Custom development people often have less exposure to that and might find your approach more appealing.

In the end it does not really matter as long as you achieve your goal and when your models support maintenance as well.

الفيسبوك said...

the "scenarios" that would be detailed in the form of bpmn diagrams as well as the actors that would be involved in the process. i use these use case models to communicate scope with the business and order of delivery.

Your Escort Agency said...

Your Escort Agency offers exclusive and most beautiful London escort girls of various nationalities.

London escorts said...

Bestescort4U more then ten years providing best London escorts companionship in the UK.

London escorts said...

Bestescort4U more then ten years providing best London escorts companionship in the UK.

Escorts London said...

Hot - Collection is a honest and confidential London escort agency which provides genuine London escorts girls for gentlemen of taste.

olsonsfoodemporium said...

This cannot succeed in reality, that is exactly what I suppose.

Anonymous said...

Obat Kanker Payudara Paling Manjur
Obat Kanker Payudara Manjur
Obat Kanker Payudara yang Paling Manjur
pengobatan Kanker Payudara Paling Manjur
Obat Kanker Payudara
artikel obat kanker payudara manjur
artikel obat kanker payudara
artikel obat kanker payudara alami
artikel obat kanker payudara ampuh
artikel obat kanker payudara herbal

Anonymous said...

thank you
vintage study desk
wooden desk
wooden office desk
natural desk
desk for boys
home design
children computer
love study room
inspiring desk
cute room
teenage girl room
computer desk
unique office space
teenage room
study desk

ramuan ajaib said...

Kumpulan Obat Ambeien Sudah Parah
Kumpulan Obat Herbal Ambeien Sudah Parah
Kumpulan Obat Sembuhkan Ambeien Sudah Parah
Kumpulan Obat Ambeien Sudah Sangat Parah
Kumpulan Merk Obat Ambeien Yang Sudah Parah