Another IBM Agility seminar at the Shangri-La Hotel, and some BPM announcements. And in contrast with the sunny spring skies warming Sydney’s harbour (for those of you in the northern hemisphere ) the best bit in here was the cloud.
But first …. Websphere Lombardi Edition is to have drag and drop integration with both FileNet P8 Content Server and Content Manager 8. The extent of the functionality involved wasn’t clear to me – presumably IBM will start with search/retrieval and later move on to others like metadata update and new document insertion? Anyway, further integration will be with Websphere Service Registry and Repository – useful for orchestration purposes – and with iLog, where it will be possible to browse and select an existing Ruleset on a predefined iLog JRules Execution Server.
In the meantime Websphere iLog itself is to be coupled with Websphere Business Events to become Webspher Decision Server, extending IBM’s business events capability, whilst the iLog BRMS SupportPac is to provide Websphere Business Monitoring and predictive analytics integration
All very worthy, but much less interesting than the next piece of news, which was the launch of Blueworks Live. This combines three elements – the Blueworks BPM collaboration community (blogs, wikis); the highly successful (Lombardi) Blueprint process discovery and definition environment; and a new workflow execution engine. All running in the Cloud and, apparently, available through your browser for a test drive from November 20th. (Yes, that’s this Saturday – perhaps one of the software world’s most specific launch dates ever…!).
Now, Cloud-based BPM is hardly new. Cordys was one of the first to offer it globally, and there are niche players too, such as Australian company OpenSoft, which uses open source products to provide integrated Cloud-based BPM to the burgeoning Australian energy and resources sectors. However, Cloud-based BPM from IBM is something else entirely. IBM’s existing mindshare in the global BPM market and its credibility as a corporate Cloud (and FM) provider mean that the interest in this product will be enormous, and as a result it could well be a game-changer for all BPM stakeholders.
The PowerPoint-based demo that followed included a marketing manager setting up a new process for her latest marketing initiative. Yes, that’s one process for one case/process instance. And if the Powerpoint is to be believed, it only took her a few minutes.
How can this fail? The CIO’s happy because it’s SaaS; the Board because it’s IBM; the Ops Manager is comfortable because its running in an IBM Datacentre; the process improvement people have Blueprint to play with; the IT teams can focus on integrated, production BPM system work; and best of all the Business can replace its endless email trails with easy to access, auditable business processes.
So what next? Well, here’s a prediction – Blueworks Live will do for business processes what Microsoft Sharepoint did for enterprise content – it will get everywhere. That means a step change in awareness regarding BPM (how many business – or even IT – people knew of ECM before Sharepoint?) and huge opportunities for BPM professionals to sort out all of those ‘home grown’ processes. Bring it on!
Conversations that include the words ‘Pegasystems’ and ‘buy’ in the same sentence tend to cast Pega as the vendor, so this move has the immediate benefit of surprise.
I’m not going to attempt too much learned reflection on the purchase, since I know very little about Chordiant. However, I do know that CRM / BPM mergers aren’t always easy – Staffware bought a small US CRM vendor in the late 90s (whose original name escapes me now) and my own sense was that in the end this was more distraction than synergy. It’s hard to make a world-beating BPM system and, no doubt, the same goes for CRM. Trying to maintain both of those market positions whilst simultaneously promoting an entirely new ‘CRM+BPM’ market position as well requires a near-superhuman organisation of the engineering teams, not to mention sales & marketing.
What leaves me with some interest and excitement with Pega is that their vision has for some years been focussed on all-round excellence in BPM with an emphasis on BPM’s original mission – providing systems that render the exceedingly complex (UI +process+rules+integration+data) sufficiently easy for business process deployment to be affordable and – crucially – for subsequent process change (=agility) to be realistic.
Given this track record, it could just be that Pega will use Chordiant’s technology to push ‘Build for Change’ in quite new and original directions. BPM needs a lift at the moment – perhaps from a ‘should buy’ to a ‘must buy’ – and the vendor that delivers this transition will be richly rewarded. My money to date has been on the big players – IBM, Oracle, SAP – simply because of the size of the challenge in terms of both re-engineering and re-launching into the market. However, perhaps Pegasystems will leverage its intense focus to take the lead, showing the rest of the market the way.
Let’s hope that the fact of the purchase is the least of the surprises Pegasystems has in store.
For more facts and figures, check out this article. Good stuff.
So what are the really major product enhancements that would drive BPM into Agile territory? What new functionality would allow businesses to see change routinely happening within 24 hrs of the business request, and the disappearance of the dreaded ‘change backlog’?
The single biggest obstacle to Agility is the need to bring down the system whilst making changes, leaving the business at a halt. With business operations under seemingly relentless pressure to extend their operating hours, the windows available for system change are getting ever smaller. At the same time, the number and complexity of systems used to support business is growing, so the competition to use the available windows is intense. This in itself can drive system change back to weekends in a cycle that quickly produces a 2-4 weekly change cycle for any given system (such as BPM).
So one important way forward is to find ways to reduce deployment times (downtime) and keep risk associated with change to an absolute minimum. The latter is important since risk drives contingency planning, such as allowing for a multi-hour system restore period in the change plan – something that can be a big factor in pushing change back to the weekend.
Extreme Programming (XP) sets the pace in at least one aspect of this, by demanding that no development be carried out that cannot be tested, built and deployed in 10 minutes or less. Yes, you read that right – 10 minutes. If we take that as our goal, it has one obvious corollary – the entire process must be automated. That means a scripted build, scripted deployment and – the tough one – scripted testing. XP addresses this head-on by requiring that code is only developed after an automated test harness has been built. For the record, this is intended to drive more rigorous business requirement analysis before coding, as well as facilitating change after coding.
So what can BPMers learn from this? Well, an easy point is that requirements for BPM product selection criteria should include the ability to script build and deployment tasks. Not a very big ask, and one that simply brings BPM products into line with custom code, this isn’t a requirement that will trouble serious BPM vendors. Just remember when evaluating the responses though – it only takes one exception to prevent a fully automated build/deploy cycle.
The big and hairy beast in this discussion is automated testing. This has enormous benefits in terms of minimising the deployment risks I mentioned above, as well as saving time on the critical path of implementing change. As a result it is favoured by software ‘factories’, such as product vendors themselves (for their internal testing) and others where repeatability is attainable. The challenge for BPM solutions is that business processes are often unique to one business unit, which has to bear the entire overhead of creating and maintaining the tests and test harnesses as part of the cost of change. This is made worse by typical IT roles, where responsibility for test scripting (in both the sense of business logic, and automation) is more often than not given to the Test Manager, who quickly concludes that only the Developers have the knowledge and skills to support what is required. And – guess what – the Developers are too busy ‘developing’.
Happily we have – even outside of the world of XP – a shining example of how this can tackled in a way that works. Business Rule Engines are increasingly challenging BPM products as the ‘must have’ technology for BPM solutions. One of the reasons for this is that testing is typically built into development. That is, the same toolset that is presented to the Developer to define the rules compels – or at least encourages – the developer to create a test harness whereby the rule set and any changes to it can be tested in seconds. There are perhaps two reasons for this – firstly that rules are the hardest aspect of IT development to test intuitively and the easiest for people to test incompletely or erroneously, and secondly that automating rules testing is relatively easy. Most rule sets have limited inputs and outputs, with the complexity lying (inside the rule set) in the relationships between the inputs. So BRE product vendors have been able to include a user interface that captures test data and expected results alongside rules, and an automated test execution mechanism that is so easy to use that Developers are happy to use it for unit testing (traditionally part of their job), and see it as beneficial to their world, rather than as an overhead.
The prize here for BPM vendors is significant – the chance to demonstrate real Agility in comparison to their peers. And whilst the problem will not be an easy one to solve, it isn’t impossible (not least because those BPM product developers are clever people!). I expect the better solutions will draw clear boundaries around the product and/or aspects of it in such a way that change can be fully encapsulated, and then render activities at these boundaries clearly visible in the Developers UI. This will favour a native solution – the purchase by a BPM vendor of a third party testing product would at best only help a little, in practice it would likely just eat funds better spent on native development.
And what can those responsible for BPM solutions do to aid Agility, whilst waiting for their BPM product to include native test automation? Well quite a lot, as it happens. Mostly these have to do with solution design – I bet you didn’t read this far without wondering where a BRE could usefully fit into your BPM solution, for example – and the recognition that Agility requires focus. It is unlikely to happen by itself.
And if you are absolutely unable to reconsider your BPM solution design, then putting some investment dollars into a faster backup/restore solution might give a better RoI, in terms of positive impact on speed of change, than most.
Finally, the more I consider Agile BPM – in the sense of BPM that is easy to change – the more facets to it appear. As a result I’m starting a small and very reasonably priced consulting offering around it. So if this is a subject that keeps you awake at night, you might like to read more on www.bpmfutures.com.au/SpringOffer.html and get in touch.