Thursday, December 03, 2009

Use Cases, Explaining Main Success, Alternate and Exception Scenarios

Once you understand the difference between a main success scenario, an alternate scenario and an exception scenario, you may wonder why it took you so long to get there. The reason probably being that the explanation was pretty abstract, talking about scenario's that do or don't have the same goal, post-conditions that add to or are instead of those of the main success scenario, blah, blah, blah...

Having gone this road myself, I started to wonder if there is a simpler way to explains what should be pretty natural for most of us. And as always, finding an example that relates to day-to-day life did the trick for me to explain it to others. The example being the following.

Suppose that have to drive from A to B. Your goal being to be in time for a customer meeting. The post-condition being that you successfully reached your destination in time.

So the main success scenario is that you drive from A to B, without interruptions.

An alternate scenario would be that you have to take a small detour by going through a gas station to get some gas. An extra post-condition this detour might add to the one of the main success scenario, could be that you have to obtain the gas bill, otherwise you employer won't cover your expenses.

An exception scenario might be that your car breaks down, and you will never be in time for the customer meeting. A post-condition of this exception scenario might be that you have to inform you customer that you have to cancel the meeting. This post-condition replaces the post-condition of the main success scenario.

Other exception scenario's might concerning a serious traffic jam, getting busted for speeding, car-jacking, and so on.

Now that was not too difficult, was it?

Sunday, November 29, 2009

Is There Life After Oracle BPM Studio 10g?

Let me begin with the answer, which is: absolutely!

After a Thomas Kurian discussed the positioning of Oracle BPM (fka ALBPM) a year ago (is it that long? Yes it is!), I must admit I was worried about the strength of Oracle BPM being properly appreciated. For quite some time focus seemed to be solely on the Oracle BPA with BPEL (from the SOA Suite) combination only.

But times (and vision?) have changed since then. Recently I was in a conference call in which a preliminary version of BPM 11g was demo-ed. And I was surprised in a positive way. Oracle BPM 11g seems to preserve all the good of 10g, while at the same time it is really integrated with the rest of the product stack.

Some Things That Struck My Eyes

With BPM 11g Oracle managed to continue the ALBPM "experience" of easy process modeling and implementation. In a series of short iterations you transform the BPMN 2.0 process you collaboratively modeled with the business analysts in an executable one, without a paradigm shift like you for example would have when going from BPMN to BPEL. For me this always has been one of the major strong point of BPM. What has been added to this is a so-called zero-code environment of developing screen and including external resources (like services).

Some of the more technical features that I found appealing were:
  • Usage of the common adapter framework, as is already available in the SOA Suite,
  • Support for easy (ADF-Faces) development of rich task forms with AJAX support (without bothersome JSP development),
  • A web-based UI for modeling processes by business analysists,
  • Native integration with Oracle BAM,
  • A composite (SCA) view on business processes, which (among other things) supports native integration with BPEL,
  • Native integration with Oracle Business Rules,
  • Unification of the BPM and BPEL worklist,
  • With all this, an improved support for true Business Process Management.

What About The BPA Suite?

The positioning of BPA has not changed, but became more clear instead. BPA is typically for a more enterprise approach to business analysis, including a top-down approach to business process modeling, including BPMN. When you have a human-centric business process, you can decide to export these to Oracle BPM 11g. Otherwise, BPEL is the obvious choice.

Boy, I can't wait to get my hands dirty with BPM 11g, which hopefully will be somewhere in March 1010!

Friday, November 27, 2009

OUM 5.3 Has Been Released

November 13 there has been an announcement that the Oracle Unified Method version 5.3 has been released. As explained in a previous posting, we do offer OUM to our customers.

What's New?

Although the increase in version number (from 5.2 to 5.3) seems to suggest this to be a minor upgrade, some of us will receive as a major upgrade.

For example, this version includes an initial support for Business Intelligence (BI) and Enterprise Performance Management (EPM) implementation. We also added a view for Software Upgrades, which will help in in quickly determining which tasks to consider for an upgrade of Oracle software products, including middleware, database, enterprise application products and Business Intelligence solutions.

Regarding the other, existing views, a lot of improvements have been applied. Especially Envision (the focus area of OUM covering enterprise / business level aspects) has been upgraded, and is rapidly reaching a "mature" state. Two of the topics that I would like to point out are IT Governance and IT Portfolio Planning, mainly because I have been personally involved in that (sorry, too hard to resist)!


Perhaps even more important than having a comprehensive method, is being able to provide training on that, and assist in applying the method. In the last year The Oracle Methods Team therefore has put considerable effort in creating various training modules, from high-level overviews that make you understand what OUM is all about, to more task-oriented modules around requirements gathering or analysis and design.

Customers won't find them in the curriculum of the Oracle University (yet) but don't let this keep from for asking for it, as we can deliver customer training.

See you in class!

Wednesday, September 30, 2009

OBPM Business Exceptions and Heirs

Often the solution of a problem is having an eye for detail, like properly reading an error message most of the times is half the solution. Finding out how to create heirs for the Oracle Business Process Modeling Suite (OBPM) appeared to be yet another thing requiring an eye for detail.

A colleague insisted it worked for him. However, no matter how I tried it simply did not for me. We checked versions numbers, build numbers, both the same. Then another colleague came by the other day, and for him it worked too. Then I started to pay attention to the details and watched how he did it.

What I did was right-click an existing Business Exception -> Create Heir, resulting in an ordinary business object. No matter how hard I kicked it, it refused to becoming throwable. What he did was this:
  • Create a new business exception, but not as an heir.
  • Then in the properties tab set Type Inheritance to "Behavior Inheritance"
  • And set Inherits Behavior to the Business Exception you want to inherit from
As simple as that.

Monday, September 28, 2009

BPM & Use Case, Who's Counting?

(O)BPM and Use Cases

Business process modeling and implementation using the Oracle BPM Suite should be an iterative process. Because of that you try to postpone the need to create (paper) specifications as long as possible. After all, your running BPM prototype is the specification. Otherwise, while you are iterating, the paper specification would need to be changed as well, resulting in a lot of overhead which would not add much value, but cost the more.

However in some situations it me be necessary to create (preferably nearly after-the-fact) specifications, for any combination of the following reasons:
  • Acquire official approval of the detailed requirements
  • Support change control
  • Provide the base for test scenarios.
When your customer is standardized on use cases, that is a reasonable format for those specifications.

A Quiz

Now let's do a quiz and count use cases in a simple BPMN diagram that has been created with OBPM. For those that are not familiar with use case modeling: a use case captures requirements from the perspective of an actor that wants to achieve some goal using the system. So how many use cases do you count in the following business process, when for now you ignore the Receive Order by JMS activity?

The good answer is three. In case you had another answer, read on!

Counting Use Cases

The first use case is Place Order. The (primary) actor is the customer, and the goal is placing an order. The global interactive activity Place Order covers that, and will kick of the process. As a result the first thing that will happen, is that the system automatically notifies the account manager through the automatic Notify Account Manager activity. You may think this is the second use case, but consider this:
  • The notification is triggered by entering the order by the customer
  • The notification will take place immediately after entering the order, right after the user pressed the submit button.
So from the actor's perspective, sending the notification is part of the single-setting and a direct result of the actor's doing. The account manager is a secondary actor in this use case.

Still Not Convinced?

When your thinking was that the notification is part of the second use case, which by the way is Handle Order, consider this. The receiving of the notification by the account manager may have happened much earlier than the actual handling of the order by that account manager. So the notification itself is not an integral part of the single setting in which the account manager handles the order. So, yes receiving the notification is the trigger of the Handle Order use case, but not part of that use case itself (i.e. not the first step of the scenario).

For a similar reason as discussed for the Place Order use case, the (automatic) Create Back-order activity is part of the Handle Order use case. The creation of the back-order actually is handled through an alternate scenario of the Handle Order use case.

The last and final use case is the Ship Order, obviously.

Requirements vs Solutions

Now let's review the Receive Order by JMS activity, and let's assume that this only supports a different channel through which the same customer can place an order. The JMS queue may for example be used to pass in some SMS message. From a requirements perspective you can state that this is part of the Place Order use case. The argument being that using a OPBM screen or sending a text message are just two different solutions to the same actor goal: placing an order. Supporting different channels is "just" a supplemental requirement for the Place Order use case.

Now if you really think about it, you probably will agree with me that when doing a more detailed analysis of the Place Order use case, will reveal several reasons for (in the end) having at least two use cases, one for placing the order through a screen and another one for placing it by SMS. If you are a fancy use case modeler you could even model the Place Order use case as a super-type use case, having to siblings: Place Order through Workspace and Place Order by SMS.

So when you had "four" or "five" as your answer, depending on your reasoning, you might have been correct as well.

Introducing a Timer

Another interesting aspect to consider is what happens when the Notify Account Manager activity is not done directly after the customer issued the order, but for example by a trigger at 8:00 in the morning. In that case, the notification is no longer part of the single setting Place Order.

Mind that for the reason explained earlier, this still does not mean that the notification becomes part of the Handle Order use case. But who is the primary actor here and who is having the goal? In this case the primary actor is the timer. It depends on how you formulate the goal, but for reasons of simplicity, let's assume that it is the customer having a goal of the account manager handling the order as soon as possible. But granted, it is debatable.


So, in conclusion: unless there is a timer involved, all automatic activities are part of the interactive use case that precedes them, which may be outside the OBPM process (in another system sending the message).

Tuesday, July 21, 2009

Oracle Enterprise Repository Installation Issues

The other day I installed the Oracle Enterprise Repository 10.3 on my laptop. In principle the Oracle Enterprise Repository, or OER for short, is a web application featuring a rich user interface that requires Java Web Start.

Apart from the fact that the order of the steps in the installation guide is not exactly as you want to follow them, the installation on Windows XP is relatively easy. However other than for simple tools like TextPad or Total Commander for some reason in my case installations are not supposed to be bump-free (some higher God is making sure they are not). With the finish line in sight, I already thought this was an exception to that rule.

I started the application and the welcome screen rendered OK, the final thing to do is to click on Edit/Manage Assets, and then ...

Yes, you see that right, the browser equivalent of a blank face. Now what?

As we all know, logging and JavaScript are the perfect couple, so other that checking, double checking / triple checking all the steps made, I had no clue what to do. Except for contacting a colleague who just might have ran into the same issue, and surprise surprise, she had! Clever as she is, she already found out that Java Web Start of Java 1.6 and OER 10.3 are not the best friends.

So like in her case I was able to fix the issue by disabling Java 1.6 in the user Java runtime settings, et viola!

Fortunately for me she has better things to do that blogging about silly installation issues (like taking care of a baby).

Friday, June 19, 2009

OUM & Software

Some time ago I got a question in a comment if the Oracle Unified Method (OUM) is or will contain any software components like we used to have with CDM (like CDM RuleFrame and Headstart).

The answer is no. And the reason is as follows.

CDM was restricted to Oracle Designer/Developer and the usage of the Oracle Database with that. OUM is not based upon any specific tool set, just simply because there are that many that (currently) it simply is impossible to do so. Maybe someday, when we "fused" all our products into one consistent tool stack, who knows ... But I don't see that happing in a future near me.

On the other hand, I hope we will be able to add some technology and even tool specific guidance to OUM for some of the tools we have.

Oracle BPM and Java objects

Why using Java for business objects?

When creating business objects for Oracle BPM (10.1.3), I have a couple of compelling reasons for basing them on a Java class model. The reasons being:
  • Ease of migration
  • Testing
  • Reuse
At the end of the day, Oracle will get rid of the proprietary PBL language and target for Java instead. So building your business objects on top of a Java class model, might be a good strategy to ease migration to any one of the new versions.

Oracle BPM leverages CUnit (and PUnit), both being proprietary testing frameworks. When you base your business objects on Java, this also offers the opportunity to test your objects using the de facto standard unit testing framework JUnit.

BPM business objects can only be used by BPM. A Java class model can be reused almost anywhere, including BPEL, and (obviously) Java applications.

How using Java for Business Objects?

Just follow the instructions for catalogueing components in your catalog. To leverage the extra functionality that BPM business objects offer (including creating object presentations), create a BPM business object for every top-level object type that you need, as an heir of the Java class. Don't do them all, only the ones you need the extra functionality for.

I put the Java objects and BPM objects in the same catalog, and name the BPM objects after the Java classes, post-fixed by "BO", for example CustomerBO for the Customer Java class.

Finally, to ease synchronization between JDeveloper (or your preferred IDE) and Oracle BPM, after first-time catalogueing, generate the jar file with the Java classes directly to the lib folder of your BPM project.

Wednesday, March 18, 2009

Service Oriented Confusion (SOC)

In a previous article I presented a service taxonomy. As I explained over there, deciding upon a proper service taxonomy supports a proper service layering. I should have said this is only one of as set of taxonomies (plural) that you could use, even at the same time.

Moreover, I could also have explained how different service taxonomies can help the process of service discovery. For example, a taxonomy along business domains (like Customer Relationship Management) can help to get an overview of all services provided by a specific business domain.

But I would also like to state a word of caution here. I have seen organizations using an IT related taxonomy including classes like data services and application or utility services in the communication with business analysts. The problem is, that to a business analysts such a taxonomy is difficult to understand, and may look pretty arbitrary. Where does a data service differ from a business service? Do they not both deal with "data"? Yeah, but eh ...

Apart from that, what value does it add to them? Why should they care? I can't tell you that to be honest. What I can tell you is that I've seen situations where business analysts only thought they understood and started to do analysis. The damage done ...

It is my experience that the only two classes of the taxonomy that I presented in my previous article, and that make sense to the average business analyst, are process service (a service implementation of a business process) and business service. From an IT point of view, a business service may translate into one data service, utility service, or some composite service that orchestrates two or more data/utility services, etc.

I've been with an organization that does not strive for business services to be reusable, because in their definition, a business service is a service that supports a specific business purpose, that may be unique across the organization (as shown in the picture above). However, from an IT point of view the services used to construct the business service definitely should be reusable.

Now this may or may not work for you, so you may want to use a different taxonomy for layering. As long as you make sure that it clear what kind of taxonomy is used for what kind of stakeholder, and you only use a taxonomy that makes sense in the universe of interest of the stakeholder.

Friday, February 06, 2009

If It Ain't Broken, Fix It!

For already more than three years I'm the Java developer of some Oracle-internal sales application. Up to that point the application had been maintained by several people who obviously had different development styles.

I'm more a kind of guy that practices principles like coding by intention, responsibility driven design, and refactoring with the main goal to achieve a simple design that is easy to understand and therefore better to maintain. Those principles had not been on the top list of my predecessors. The result being that, to implement a change request or bug fix, you almost always had to debug the code and do extensive code reviews before you even knew where to start. I'm not joking when I say that the same kind of functionality was never implemented twice the same way. There was hardly any pattern to discover, except anti-patterns and a lot of bad practices:
  • lengthly methods, often of 100+ lines
  • names for classes, attributes and methods that do not resemble what it does
  • classes and methods having too many responsibilities
  • no proper layering and separation of concerns
  • and so on, and so forth
At a specific point in time I had (and took) the opportunity to start refactoring key parts of the application, and never stopped since. I did refactor for the sake of refactoring, but restricted myself to the code that I needed to touch anyway. While doing so I tried to apply best practices and extrapolated these to other parts of the application to keep the solution consistent.

The result being that after less than half a year, newcomers needed only half the time to understand the application good enough to do their job. And those parts that had been refactored properly, required only half the time to change. Cross my heart: I dare to state that any investment in this making the application code base simpler, has paid back itself several times already!

Many developers will recognize this situation, and may want to do something about it, but run against a brick wall called "project manager", who is just a plain idiot, not understanding the value of good coding practices, but only focusing on getting the job done in as less time as possible, right? Wrong! The key responsibility stake of the project manager is exactly that: delivering on time and within budget, and most of them are doing that job pretty well.

Unlike what you may think the project manager is not the key stakeholder, but the customer is. So rather than trying to convince the project manager, you must make the customer aware of how a simple design:
  • will reduce their maintenance costs (which still is about 80% of the original development time) and perhaps even more important,
  • will make their IT better aligned with the business, because it will be quicker to change a well designed system than spaghetti.
Try to convince the customer that to achieve this, a simple design is an absolute must, and therefore from time to time you need to clean the kitchen because otherwise at some point the kitchen will get so dirty that almost any meal you make in there, will be a serious health hazard. That cleaning the kitchen is what refactoring is all about.

Even when the project plan is already finished and the budget already fixed, it is likely that there still are plenty of opportunities to help the project manager with reducing the remaining development time, if only you take the time to find them. The biggest problem for applying best development practices is probably you not spotting these opportunities or not being able to communicate them well.

Monday, February 02, 2009

OUM Available for Customers

Finally, the Oracle Unified Method (OUM) is available for all our customers! Until now it was only available for Oracle Certified and Oracle Certified Advantage Partners, but that has changed now.

Customers that contract Oracle Consulting for an engagement of two weeks or longer can download OUM if they meet some additional criteria. Contact your Oracle Consultancy sales representative about the details.

Be aware that soon we can also deliver training on OUM (we already do so internally), so don't forget to ask for that too!