Have you ever though about the nature of BPM projects from a software development point of view? Honestly I haven't. But Gartner people seem to have asked themselves questions about this. At least, they can put a name on it. Sandy kemsley affirms that most deleopment lifecycles used to design Business processes rely on the simple waterfall model.
The Gartner BPM Talk she reports about distinguishes between several development lifecycles, while putting focus on the "architected model-driven" one. This one caught my eye, since I also view BPM modelling as being adapted to model-driven approaches, especially since Process model transformations to BPEL (from EPCs or BPMN diagrams) have become a reality. Recent holistic approaches to BPM which consider the high-level strategic views and the low level workflow implementation layers as parts of a common biotope for BPM: of which I think that it makes sense and with which I agree, precisely because of the executable processes. Also, the "architected" in "architected model-driven", as far as I have understood it is also a necessity and a fact: as business processes span multiple vertical silos in the enterprise, they also rely on architectural, organizational and strategic resources for them to carry their added value. This is very easy to see in teh case of frameworks such as ARIS which is an enterprise modeling Framework and also contains views and models to represent the architectures involved in defining processes. Since the enterprise is architected, business processes which run through the enterprise should be architected accordingly, defining interfaces when necessary and splitting processes into layers and blocks.
But the thing about this talk, about which I read on Sandy Kemsley's Colmn2, is the question: what about using Agile development methods for BPM projects. The best point of the talk was the fact that due to the BPM lifecycle having iterations from the strategy phase to the controlling phase (I am referring here specifically to the ARIS Lifecycle, by IDS Scheer), but also including shorter iterations for aspects such as configuration, policies and rules modeling (which is always a keyword for me), agile methods would work much better than classical waterfall methodologies, which are used for most BPM projects. I am no expert in Agile development or RAD (rapid Application Development) though, but it still makes sense to me. I will keep an eye on any works, software or publications on that.
Marwane El Kharbili.
2 comments:
Marwane,
We (ILOG) have recently contributed a plug-in to OpenUP called Agile Business Rule Development.
Check it out, and let us know what you think!
It's a paradigm shift to move to the agile approach, but worth it to get IT to address today's business agility needs. It requires strong project management capability and the understanding of all the parties involved. The last point being an issue in contexts driven by strict contracts such as fixed-price.
Jean Pommier
VP Methodology, ILOG
Hi jean,
Yes, I know of iLOG's involvement in Eclipse Plug-ins. But I didn't know of an existing contribution to agile business rules engineering. Agile development has proven its relevance in the industry. And I think that concepts or methods which have proven their effectiveness by being deployed in the industry, should also be applied to business rules management. It is true that the implementation business process and business rules management shouldn't be considered as classical software development. Both these have specifics that make their implementation different from normal software. But for both, the lack of research on adapted methodologies is clear. This is true at all levels of software development, including project management of development projects involving business rule management solutions. I will have a look at iLOG ABRD, OpenUP plug-in too and write about my learning on thiy blog.
Post a Comment