BEL, Meet BPM
- November 17, 2010
- 1 Comments
Sandy Kemsley covered a few sessions at CASCON on her blog, and a few of them caught my attention. In particular her blog of Richard Hull’s Keynote on Business Entities with Lifecycles. Interesting take on present state of BPM:
He stated that today’s approach to BPM environments is fundamentally disjointed: there’s one conceptual model for rules and policies, another for analytics and dashboards, and another core business process model based on activity flows, while the data being manipulated is often not related to the conceptual models but is more of an afterthought in the design.
I don’t have enough data points to dispute his characterization, as I only know about the projects our teams have worked on. But I’ve seen quite a few IT (including BPM) efforts that did the opposite – focused so much on defining data entities that they missed the boat with regard to the real requirements of the business processes. I think the point is, business entities need real thought into their data and lifecycles. Process data, which has a lifespan only of the process, needs a lot less up-front design to get right – and in particular, needs to remain agile as you implement the processes (and uncover the real requirements through iterative feedback).
Maybe I’ve just seen too many leading-edge products and methods, but I don’t find anything here that new. Yes, it’s nice to have more formalized models and methodologies around this, but the idea of linking business object and process models, and auto-generating user interface screens from them, isn’t cutting edge. He positions this as not really competitive to WebSphere (process modeler), but being for cases when BPMN just doesn’t cut it. He described the differentiator as that of disaggregating operations into chunks that are meaningful to the business, then modeling the lifecycle of those chunks relative to a more global information model.
Well said. I think auto-generating screens is about the least-useful innovation for this kind of work. The real progress is just getting people to think through these issues and document them. The end result will be a much more robust set of data objects and processes. Not to mention better organizational knowledge of both.