What word or phrase does every IT Leader hate to hear? What's the coolest thing that's ever been done with our Middleware products? IT Uncensored is a showcase of thought leadership about all aspects of IBM Middleware from your perspective. These experts get real about middleware—and themselves.
The Four Pillars of IBM BPM 7.5 Part 1: Simplicity
Krista Summitt 270003YAW6 email@example.com | | Tags:  business software simplicity process 4pillarsofbpm7.5 bpm ibmbpm bp3 agility
0 Comments | 12,316 Visits
This is the first of a four-part series on the 4 Pillars of IBM BPM 7.5. We are fortunate to have guest post by Scott Francis, co-founder and CTO of of business partner BP3, a process company.
About Scott Francis:
Now that IBM BPM 7.5 has been out in the wild for a few months, the question we're often being asked is: how do we upgrade to 7.5?
IBM has been nice enough to create some great utilities and information resources for upgrading. Many people wondered if IBM would release an upgrade utility to get legacy Lombardi customers up to version 7.2 or 7.5. And since IBM's policy is not to comment on future release functionality, it wasn't possible to get a straight answer on this. But like a nice gift-wrapped present under the tree at Christmas, upgrade utilities and technical documentation resources showed up with the 7.5 release in June. But now that we have this technical firepower - how best to use it? Should we use it?
Before getting into any specific steps on the upgrade path, the first thing to keep in mind is the general principle to follow in upgrading:
KISS: Keep It Simple.... Whenever possible, choose the simpler option for upgrading. It will typically save you implementation dollars as well as improving time to market. It will definitely make it easier to recover from a mistake.
Simplicity underscores the approach for upgrading. Upgrading always sounds complicated because in the general case it is complicated. But for a specific customer with specific processes, upgrading isn't always complicated. Often a few simple assumptions can make the process dramatically simpler and less error-prone.
There are quite a few good resources online, which you can actually find with a good Google search these days, because IBM does a great job of publishing its technical resources via developerWorks and other media. Perhaps the best resource to start from is the help file on "Migrating from earlier products and versions" for IBM BPM 7.5.
The basic outline for upgrading is pretty simple. BP3 recommends starting with these simple steps, before taking a step back to plan your project:
Now that you have a sense of the issues that need to be resolved and the processes that need to be promoted, you can make some decisions, which we'll frame in the form of questions, in order of increasing complexity of upgrade:
Scenario 1. Are your processes short-lived enough that you can turn off the old system without doing an in-flight instance migration?
You have the chance to just make a clean cut-over to a new system. There's really no need to get involved with running the upgrade utility.
Scenario 2. For longer-lived instances, can you let old instances of your processes finish on the old installation, and start new instances on the new version? (This requires maintaining two BPM systems for the time it takes these old instances to finish).
For processes that take as long as a month or two to complete, a side-by-side deployment can let those processes complete, while allowing new process instances to get started on the new version of IBM BPM.
Scenario 3. For longer-lived instances, can you recreate an instance from its data?
If this is the case, then you have less risk around upgrading - any mistakes or errors or compatibility issues can be worked around in the development environment, and then recovered in production from production data. Essentially, the instance data acts as your insurance policy against a software failure or process design failure.
These questions are important because it is easier to do your upgrading and migrating in the development environment with development assets than it is to do in the production run-time environment - because there is no risk to your running in-flight instances. As your process instances grow in length of life-cycle and complexity, your odds of needing to run the in-flight migration utility against your production database grow. The good news is: there is an in-flight migration utility! But that doesn't mean we shouldn't still use our human brains to simplify our inputs and outputs (and therefore, our risks).
For many products, this would be the EOL (end-of-life) of your old process application and process instances. But IBM has endeavored to make even the most complex migrations possible via the in-flight upgrade utilities (and much thanks and credit should go to the original Lombardi team that had started down this path even before the IBM acquisition).
Always make backups before proceeding.
In Scenario 1, you can simply export your processes, and then import them into IBM BPM 7.5. This is probably recommended if you're coming from Teamworks 6.x - and expect to have to do plenty of refactoring of your processes. But from IBM BPM 7.2, the migration is pretty lightweight and you might be better off just running it against your development system.
In Scenario 2, again you can take either approach for upgrading your development environment. However, you'll have to take a few steps to disable starting new processes in your old environment, and you'll likely have to refactor your processes to take advantage of IBM BPM 7.5.
In Scenario 3 and beyond, you're likely going to want to use the upgrade utility. A few notes on that follow...
Taking an upgrade from Teamworks 6 to IBM BPM 7.5 as an example, here's the upgrade instructions for the development environment, and here they are for the runtime environment. There are similar resources for upgrading from Teamworks 7 and WLE 7.2.
The upgrade utility has a simple default behavior, but also provides an instance mapping file capability - which gives the process developer a finer-grained control over how the upgrade works if needed (for example, so that process names can change, and so that you can pick the right process app and snapshot in the target information):
The upgrade utility will also migrate completed instances - even millions of them. When it comes to this sort of activity - again I would urge keeping it simple. Just because IBM has produced a technically interesting way to do the upgrade doesn't mean you have to do it. If you don't need that instance data, don't migrate. If you do need it - it has business value greater than the cost of migration - then migrate it.
What if I'm migrating from WPS?
Well, you're in luck. IBM has not forgotten you. The help files for migrating from WPS are extensive, but start with this simple overview page. Trust me, there is a ton of content behind the links on that page.
Is it Worth it?
I think unquestionably the answer is yes. Migrating to IBM BPM 7.5 keeps you on the path for future software upgrades from IBM. It includes a raft load of BPM-relevant features that were lacking in Teamworks 6 and even in WLE 7.2. This release also is the first step toward unifying WPS and Lombardi product lines- by merging the repositories. The software management features of IBM BPM 7.5 are going to be crucial going forward: simultaneous development with rich versioning of processes. The direction of the last few updates to IBM's BPM offering hints at more improvements to the repository (versioning, governance, merging), and better use of key IBM technologies like ILOG and Websphere Application Server. All of these improvements affect process development - but they also affect your agility with BPM, and how you deploy processes. These are fundamental improvements to the business of building and deploying processes.
Next Post in this Series: Four Pillars of BPM 7.5 Part 2: Governance by Matt Sanchez, IBM Lead Architect