Hi Keith,

Sorry, but I think you are totally off here. I fully believe in MDD, but with your focus on the programming part you just miss the point.

Your conclusion is in fact completely misaligned with what the IBM researchers said... Funny interpretation. They talk about the need for higher level models and the issue of programmed processes - which you seem to promote.

Of course you can continue to program rigid, inflexible applications, but I believe that executable, higher level models are a much better and proven approach. Abstraction will help you to overcome technology shifts. At the same time, programming, in particular modifying generated code, will lock you into technology. this has been proven a number of times now.

Programming will still be needed and used, but not necessarily a one-size-fits-all, and definitely not viable as an enterprise vision.

I am open to further discuss this with you.

Best regards,

Theo.

Hi Theo

My conclusion is exactly the same as that of the IBM research. When I read their white paper, I thought, "At last, someone else is saying this".

Your comment implicitly associates "programmed" with "inflexible". What I am saying, and what the IBM research is saying, is that this is not true - in fact, we are saying that thanks to MDD, a programmed solution to process execution is more flexible than a BPMS, since it is based on business objects.

I have been trying for some time now to explain how an object view of an organization is the only way to ensure true alignment of processes with business goals, and hence true flexibility - i.e., which processes you want, and how they are to be implemented.

You say you "fully believe in MDD". Then surely you will agree that MDD technologies have advanced to the point where model changes can be generated automatically into code changes. In other words, MDD gives you exactly the same advantages that are claimed for a BPMS - minus all the vendor-specific fluff and ill-conceived "standards", and plus not only the ability to leverage 10 years of revolutionary thought in software development but also the chance to implement processes that are based on business reality, rather than on activity sequences.

--
All the best
Keith

Keith/Theo

A very topical debate right now. I'm the Enterprise BPM lead for a large bank, and this is the sort of debate that comes up in the Tech Arch community time and time again.

Overall I would agree that some form of MDD is required that takes us closer to where object orientation wanted us to go - but this is simply a play on systems thinking which has been around for a long time now. The difference with emerging standards that BPM is helping to drive (e.g. OMG's BPMN, XPDL, BEPL etc) is that the discipline is helping to drive closer collaboration between business and tech - and surely this is where the challenges are and have always been.

If anything BPM suites from some of the leading vendor products such as FileNet have addressed real business issues of digitizing paper and orchestating the electrons around to the right people to get the process done for customers - and ultimately getting these types of capabilities delivered is what its all about.

I'm all for tech innovation - but we need to make sure the technologies have the proven maturity and that the business understands how to translate their aspirations and strategies into real executable capability. We can somewhat blame the consultants for pushing concepts down the pipe that are undercooked and not hinged to real world commerce issues that need to be solved (Web 2.0 is another classic case of hype that may or may not translate into bottom line value for business in the long run - but if we could just harness those smart types into fixing real problems with the exisitng technologies, imagine the possibilities)

In summary - I would agree that BPM will fit more into the composite world in the future than stand alone BPMS - that's a no brainer. But if we head back to the days of custom app build via programming then we're all dooomed - it needs to be a new world of process model driven config type stuff that BA's and IT types can collaborate on and get to market quickly.

Rgs
Barry.

Hi Barry

No-one - least of all me - wants to "head back" to anything. What I see is that "custom app build via programming" is a new ball game since the emergence of MDD.

MDD is not "simply a play on systems thinking which has been around for a long time now". If anything, MDD is what what was always promised by BPMS vendors - the ability to define executable models.

My contention in this and other writings is that the sort of models enabled by current mainstream BPMS products are too weak to be truly useful, since they are based on a naive assumption that an organization equates to a set of activity sequences. Such models don't deliver what a business needs in order to be agile.

We need richer executable models if we are ever to generate executable mechanistic processes in an agile way, and the only current technology I see as capable of supplying such models is MDD. A model defined using MDD is no harder for a business person to understand than a model defined in BPMN - most people would find MDD models a lot easier, not only for the relative simplicity of the notation but also for the closer match to a business person's conceptualization of the "things" that they know about and deal with daily.

Such models and the systems they generate will need support for things like "digitizing paper" - but this can easily be provided by frameworks and libraries. What I see is that people have been dazzled by the rich user interface functionality of leading BPMS products, and overlooked their inability to provide the organization with a sustainable operational underpinning.

--
All the best
Keith

Yes BPM is a discipline about people and their activities and tasks (Or should be?). But coding business functionality over and over can't be right. I hear some "BPMS" suppliers have over a 1000 "suites" all presumable hard coded albeit with a degree of configurability and business supposed to pull together - Is this really going to close that gap between business and IT? The supply industry needs to get back to basics to understand how business really works. It is about People undertaking their daily work where individually and collectively in their teams goals are set and measured. Research has established there are less than 15 task types that can deliver on any business requirement. Simple logic suggests this is the start point which recognises human interaction with systems will take the lead and not what has evolved over 30 years where people are subsumed by systems.
Simple business logic (something in short supply from the major vendors) suggests that using “15 task types” will produce a more elegant cost efficient result to take businesses forward using the power of the internet where people interface is dominant. The outcome will be the separation of the business logic from delivery technologies. Producing 1000s of Suites to bolt together to produce exactly what business requires in any part of the business is a vendor driven solution when business is looking to take control of their processes in a dynamic environment. BPMS may be a step in the right direction but cannot be the end game. Whatever emerges some very fundamental requirements should recognise business analysts not coders will build custom solutions and thus cutting out layers of "interpretation”, no coding, no compiling and software agility to change as the business changes. IT should be freed up to do what they do best and where technology challenges lie with the deployment of the applications and management of infrastructure. Yes Keith I agree who needs BPMS but until there is a widely available alternative it is better than where we have been – just!

Hi David

A focus on tasks and their types is really the traditional approach to work management, isn't it - dating back to Adam Smith's division of labour. Via Scientific Management (Taylor) and then Quality Management (Deming), this perspective has really given rise to BPM as we know it.

Interestingly, there is renewed interest in task management in the programming community, with Mik Kersten's Mylar framework in the vanguard. This is a natural continuation of Taylor and Deming, since programming is after all a manufacturing activity.

My view (as readers of this blog will know) is that what works for manufacturing and other "mechanistic" activities does not necessarily work for other business activities. In other words, a task focus may be appropriate for mechanistic work, but the class of business processes that I call "human-driven" - innovative, adaptive, collaborative human work - is not helped but rather hindered by focusing on tasks.

We do not judge books by the number of words they contain, or the average length of each word - and authors do not base their efforts on such criteria. Neither should we try to measure and implement human-driven business processes by focusing on tasks. Rather we should start with goals, look at how these map to business objects, ask who has which responsibilities for these objects, and so on - the core precepts of the GOOD methodology. Then we will start not only to leverage but to properly value and recompense the less tangible efforts that are in fact the key drivers of business success.

This set of ideas, that I call Human Interaction Management flies in the face of a typical BPM focus on tasks, and acceptance of such an approach is the step change one must make if one seeks to optimize human work in the enterprise.

So having said this, how does a task focus relate to the discussion started by this blog article? My assertion above is that you can implement mechanistic business processes using MDA technology rather than a BPMS. And I see no reason why adopting a task focus diminishes the validity of this argument. BPMS tools typically offer a wide range of features - for messaging, reporting, configuration, and so on. However, none of this is directly related to business success - in fact, there is an argument that adoption of multi-functional workplace tools does exactly the opposite, by drowning people in excess information and obscuring their business goals and responsibilities! I will address this in more detail in my next blog posting.

--
All the best
Keith

There are some solutions address in this directions like http://www.bizagi.com/ that build the BPM solution based on the Business Process Definition in a Business Process Modeling tool, the end user define their owns process. Then this process is programing and involve in the Solution.