Janelle Hill, Gartner Research VP, was quoted by Mike Gammage in The BPMS Finds Its Home
'The right answer in selecting a BPMS is often three BPMSs, based on the particular projects' needs.'
An immediate reaction to this is "what twaddle, doing the same thing 3 ways ..." but this may just be a characteristic of our time.
A need for end to end process definitions was established (and it would be nice for them to be easily transformed into execution). IT solution vendors are just catching up by delivering products or relabelling earlier ideas as BPMS.
Governance practices over introduction of new technology are heavily weighted to buy rather than build, for very good reasons. Unfortunately, the Business Process and its management is only a component of the solution to any practical business problem.
Pure-play BPMS vendors emerged providing an attractive solution to the technical need for a means of execution of business process specifications but a very sketchy idea of how solutions could be delivered. Grafting on Business Rules Engines, rudimentary web user interfaces and database may make the product look attractive to a small development shop but tends not to tick the boxes for a project focussed on getting the business working quickly. A reasonable judgment call would be to accept the need for standard expressions of business process (BPMN, etc) and simply require the bought solutions to be compliant. This may result in multiple products but at least the short-term needs are being met.
If the BPMS bit of the technology portfolio looks to be an area where rationalisation to a single implementation is a priority, we actually need to be able to design to use BPMS as a component of the total solution and not expect the BPMS component or vendor to be the driver for every solution. As Mike Gammage says,
Out in the real world, business processes are only partly automated, and they need to be made visible and managed and improved end-to-end. If BPM is seen as being focused on just one part of the CIO's portfolio of automation capabilities, then we've surely lost the plot.
So in our Enterprise Architecture efforts we need the business to be formalised in Business Rules, Business Process, and Decisions as well as having technology pieces that map to these formal constructs of the Business Operating Model.
2 comments:
Hi David...this is why standards are so important. If we're following what is in BPMN, BPEL4People and other relevant standards, then there's no need for a variety of tools to accomplish the same ultimate goal. Active Endpoints is a serious adherent and promoter of these industry standards with the hope that they ultimately make any BPMS usable irrespective of the solution they want to achieve.
@Pat, I agree wholeheartedly that standards are the way to go and that in an ideal world they will avoid implementing the same functionality in 3 different ways.
My feeling is that we cannot expect business to wait for an EA or CIO to decide on *the one* and is the cost big anyway?
Certainly, if you concentrate on the core BPMS functionality and base it on BPMN 2.0, then a single solution is readily available from Active Endpoints and others. Unfortunately, people are sometimes led to developing the whole application environment from that small acorn and this is where problems will arise.
Post a Comment