Publish Your (BPEL) Process

As sometimes silly things can take a disproportional amount of time, I thought I share with you what I found on documenting a BPEL process diagram.

Agile as I am (ahum) I try to prevent putting too much in written documentation as possible. The reason is obvious, in general after the initial publication documentation is hardly ever used again, and its expiry date passed before you know it. Among others, ways to prevent superfluous documentation are an iterative development involving end-users, simple but effective design, coding standards, effective naming strategy, and sufficient inline comments.

I think there will be not many occasions making it worthwhile to publish a BPEL process diagram, as developers rather open it in JDeveloper and other people probably will not understand it anyway. Actually, the only occasion I can think of is when you want to document how to create a BPEL process, like in a how-to, or like in my case, where I want to document how you can get from business processes via use cases to an actual implementation (in some posts to come more about this subject).

Anyway, if you feel the need for whatever reason, this is how you can do it.

Unlike the UML diagrams, for BPEL process diagrams there is not a menu option like Model -> Publish that you can use. In finding out how to do it I first tried the hard way of course, Googled on it and read online documentation to no avail. It was only then that I did the obvious and had a second, better look at the interface and found out a couple of "mystery buttons" at the top of the diagram. Of course, I had seen and actually used two of them before (for validation), but the others? Never gave them a thought.


Obviously there is a print button, but to the right of that sits a camera-shaped icon Create JPEG Image, which (surprise, surprise!) creates a JPEG image! There are a few other buttons
that makes me curious to find out what kind of people actually wants to use them, but also another one that I can picture to be useful, which is the pallet-shaped icon "Diagram Properties".


This pops up a window with various options to "optimize" the diagram (still need to find out what that means, as trying it did everything but that), options for coloring, and so on. An interesting option is the possibility to add annotations that (as the online help states) "provide descriptions in activities in the form of code comments and name and pair value assignments". If you have experience with that, drop me a comment as I sure would like to know.

OUM is OUT!

It's official now, the Oracle Unified Method, or OUM for short, is available outside Oracle! Currently only for Certified Partners, but it is a start.

Now why should you care? Well you might care when you are in an organization that uses (part of) the Oracle product stack and:

• Already uses the Rational Unified Process, but having difficulties with figuring out how to use the Oracle product stack with that, or
  
• Is not yet using any formal method, but clearly recognizes the need for one, or
  
• Has a need for some method that covers more that "just one project" at a time.

As I always explain, OUM is for Oracle what RUP is for IBM / Rational, and more. Next to covering the Unified Process, OUM also addresses issues that are specific for the Oracle tool stack, and goes beyond the Unfied Process by addressing cross-project, enterprise-level issues as well.

Oracle tool stack specific issues are covered in three ways. First there is the concept of supplemental guides. With a supplemental guide extra guidelines are added to the method that cover a specific architecture or product. For example, a supplemental guide can add extra, specific tasks. Currently there is the SOA Supplemental Guide, and work is being done on the Identity Management and a Business Intelligence Supplemental Guides.

Secondly Oracle tool stack specific issues are covered in task guidelines, for example by giving examples of how to execute a task and how the tools fit in there. Also, the task guidelines can provide links to more information, for example online-documentation or white papers (of which a few have been written by me). A bit similar to the so-called tool mentors in RUP.

I hear some of you say, "Duh, you already had something similar with CDM for Designer/Developer, so big surprise (not)!". But then you are not fully appreciating the magnitude of the issue we have with a huge (and still growing) tool stack. It's not just Designer/Developer anymore. And to be honest, because of this magnitude OUM is far from what CDM used to be for Designer/Developer where it comes to offering tool-specific guidance. But we will get there, one day. After all, there is a limited number of IT companies in the world, and although you might think other wise, also a limited budget, so it will stop somewhere eventually.

As I said, OUM also covers enterprise-level issues. For that we have added what we call "Envision". Envision is not an extra phase. It's more like a collection of processes that cover aspects that should be dealt with not only in the context of a project. Instead, they should be handled at an enterprise level.

The process currently covered by Envision are:

• Enterprise Business Analysis
• Adoption and Learning
• Enterprise Architecture
• IT Portfolio Management
• IT Governance

In the future we might also cover Operations and Support, for which we currently refer to ITIL.

As the following figure illustrates, Envision kind of "folds" around projects.


An Envision process has to start somewhere, ideally within the context of a project on its own. However, in practice it is more likely that the process will be initiated within the context of the first project delivering artifacts that at some point in time are recognized as needing to be at the enterprise-level. For example, during some project a technical architecture might be created that turns out to become the start of a reference architecture for following projects.

Finally, Envision also provides the glue between processes or methods that already exists within the enterprise and a project. I hope this glue is strong enough to let this message sticks with you.