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.
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
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.