"In other words, Frankel is saying that you can use MDA to execute mechanistic business processes"

Certainly! And you can also use .NET. Or Java. Or C++. Or FORTRAN. Or assembly. IT shops have been doing Business Process Automation (BPA) forever - what a BPMS conceptually brings into the fold are execution-platform features oriented toward facilitating Business Process Management by business managers/analysts - process monitoring, process version control, process accounting/auditing, process exception handling, yada yada yada. (How well this conception aligns with what currently passes for BPMS in the commercial marketplace is another topic!)

As far as comparing MDA to BPMS - well, isn't that like comparing C++ to .NET? ... is it realistic to compare a programming language to an execution platform?

And yes - I said "programming language". At the point at which UML became "executable", it became a full-fledged programming language. And BPMN is also a programming language. Either of these are intended to be compiled down into lower-level logic representations. Just because they are higher-level than your typical block-oriented 3GL and the fact that running them through a code generator doesn't (necessarily) result in (virtual) machine code doesn't relieve them from this reality. All we're really doing here is raising the level of abstraction to make it easier for business analysts to understand (and perhaps even author and maintain) programming logic. (And in fact, from where I'm sitting the advent of MDA began with the first 3GL - don't 3GLs allow you to model algorithms in a platform-independent way such that they can be transparently implemented on arbitrary platforms?!)

As for how SOA fits into all this, I am in agreement with IBM - the ecosystem of business services exposed using SOA forms the high-level programming primitives of the business analyst. After all, isn't that the point of SOA? - aligning business with IT?

That said, I am also in complete agreement with your assessment that automated mechanistic processes aren't enough ... heck, managed mechanistic processes aren't going to be enough! ... treating humans as just another cog in the machine isn't going to cut it in the emerging Knowledge Age - IT needs to evolve into a facilitator of creative human participation in the business ... and I think your conception of the HIMS is a huge step in that direction.

Thanks for this comment, Paul. I am trying to say 2 things:

1. That MDA technology is now in practice at least as powerful as a BPMS as a means of generating executable processes from models. This you are implicitly agreeing with, I think.


2. That programming has advanced in recent years, to the point where the ubiquituous use of powerful frameworks in enterprise application development brings all the advantages you quote for execution platforms: process monitoring, process version control, process accounting/auditing, process exception handling, and so on.

My experience, both direct and second-hand, leads me to believe that BPMS tools have not done anything to remove the business/IT divide - and neither should they! The divide is there because most business people do not possess either computational training or the computational mindset - and if they do, they have other things to be getting on with than detailed implementation of executable processes. So why not let the IT people use the tools they are familiar with for process implementation; tools that are mature, actively supported by IBM et al, and (if you wish) entirely free?

--
All the best
Keith

What I've seen both here and in the IBM post is a lot of talk without anything to back it up. As an Enterprise Architect charged with helping my organization do BPM, I can't just look at the paper from IBM or a bunch of unsupported claims from Keith and accept this as gospel. Where are the case studies? What kind of success has been seen by organizations using the MDA methodology?

As for Mr. Frankel's comments, I can't take anything anyone from SAP says seriously these days. In our analysis of SAP's product suites (we are a huge SAP shop) and methodologies, implementing a complex process and achieving the type of agility given by a BPMS type solution will require about 3 times as long as using certain vendor's BPMS solutions. Now, that is not some wild assertion in a blog; this is based on real research done on real business processes using real software. For some background on why solutions take so much longer to build using SAP just take a look at a blog (https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/4703) from one of their experts on how they propose you do workflow (just one element of a BPMS). Seriously, stop and look at it. If you don't come away from reading that blog realizing SAP has no clue about helping the business be more agile then I don't know what to do for you. They propose using 9 different tools (depending on the situation) for doing workflow. Are you kidding me? I fell on the floor laughing when I read that blog. The sad thing is SAP has let this blog sit out there since Oct. 13th. One would think they'd have the sense to have the SAP expert add a follow-on fixing this travesty of an explanation on how to do workflow.

SAP's answer to helping your company be more agile is to use their out of the box business processes. Well, if you do that, and Company B does that, and company C does that, and so on, how the hec are you going to differentiate yourself? You're not. You will just have average business processes and will go the way of any company with average business processes. Hello commoditization. Hello bankruptcy and unemployment. I'm not saying every business process needs to be differentiating, but certainly your core ones do. They are what give you a competitive advantage.

This may be a case of the major vendors not being able to do something as quickly and smoothly as smaller BPMS vendors are doing it so they are trying to pour cold water on it. What I know is SAP and Microsoft CAN'T help us achieve the type of functionality our business users want to today. Call it BPMS or anything else you want, but those two vendors can't do it. I can't speak about IBM and Oracle because we haven't analyzed them.

My company has been trying to close the divide between IT and the Business (I disagree with Keith's assertion we shouldn't remove this divide) for years using MDA type approaches and haven't been able to do it. With BPMS (on top of an SOA) we have and have seen significant reductions in cycle times and IT support costs. We've also seen the business take much more control of the responsibility for the successful execution and results of their processes. That is progress to me.

This article looks to me like an attempt to generate traffic rather than put an honest assessment out there. I'm not saying that is what Keith was trying to do here, but it has that look and feel about it. I have a lot of respect for Keith's work on Human Interactions, however I can't agree with the assertions in this post. Show me your supporting documentation and case studies and I might take this post seriously.

Keith:

This may seem peripheral to your point, but it is worthy of note that, according to the Analyst community, about 3/4 of the business process analysis work currently underway (by both in-house and consulting personnel) is being documented in Visio charts. Analysts have also estimated that about 80% of the activity directed to BPM adoption is still at the level of documenting and analyzing business processes--in other words, just the first two or three steps of a 10-step cycle.

If either BPMS's or code-generating alternatives were ideally suited to accelerating the early stages of BPM adoption, doesn't it seem that the process would be zipping right along by now?

Business users need to be better supported in documenting, modeling, and improving their processes. Since they do understand and accept Visio (despite its limitations) it seems that enabling business users to 'use Visio better' for BPA work is a key to accelerating BPM adoption to the point where business users and technologists will communicate better, and BPM implementation--with either MDA technology or a BPMS--will be more productive.

Brian, Mtalaba

Thanks, both, for your comments.

Brian, you clearly have strong feelings about SAP BPM products! On which I have no comment to make. I quote David Frankel of SAP as an MDA expert whose writings on MDA I find useful in practice.

Re MDA, tools for modeling and then generating code from models have advanced enormously in recent years - which is partly why I started writing this series of posts. Perhaps your company started with MDA too early to realize the benefits that it can now provide as more of a mature technology.

Re closing the IT/business divide - don't get me wrong. Yes, IT needs to be more responsive to business needs. But IMO this does not mean that IT functions should be absorbed by business people, which is the tendency promoted by BPMS vendors - and which I have seen too many times lead to disaster, often in subtle forms that take effect after it is too late to do anything to prevent it.

Mtalaba, the analyst reports you quote accord with my own experience.

I would go further, in fact, and say that in many organizations there is active resistance to process automation - because (A) BPMS products are perceived as a poor match to business needs when it comes to what I call "human-driven" processes and/or (B) due to resistance from process professionals who have been burnt in the past by process implementations that failed to deliver the promised ROI. Stand in the hall at a BPM conference and you will hear people telling each other emphatically that BPM is not about technology.

I think this is a shame, since I believe in technology as an enabler of management practice. What I am trying to do in this blog series is show that there is more than one way to skin a cat when it comes to implementing business processes.

--
All the best
Keith

I agree with many of the points in Keith's posting and the subsequent detailed comments; however, at the risk of repeating or perhaps over-simplifying this discussion, I'd like to submit an overarching view. We're all too familiar with the danger in "doing technology for technology's sake". The notion of BPMS is no different. It really is all about the specifics of the environment one is dealing with, both in terms of their IT assets (infrastructure, skill sets, etc.) as well as the way business interacts with IT and uses technology. In some situations introducing a BPMS is an unnecessary layer that clutters the picture in ways that could've been addressed using the existing technologies, e.g. integration stack and programming frameworks. However, there are many other circumstances where a BPMS is a needed abstraction tool that relieves the problems associated with IT (both from an organizational and level of maturity perspective). Also, in many instances the need for flexibility and quick response to business needs are critical for daily operations, which is more suited for a solution driven by business stakeholders (analysis, rules, etc.). The insurance industry is a good example where niche BPMS products are having some success. So, IMHO, as with anything else typically associated with a hype, it really depends on the specific situation. Just like SOA isn't the answer to every architectural problem, BPMS's don't necessarily have a place in all process management and automation domains. But, I wouldn't go as far as dismissing them entirely on the account of alternative approaches (MDA, etc.)

Kooros, this is a very balanced summary of the discussion - it certainly captures what I have been trying to say. Thanks.
--
All the best
Keith

... an interesting synthesis of initiatives: ModelDriven.org ... from an MDA/SOA/BPMS perspective, this kinda makes sense now that the OMG is backing all three ... I wonder where that Semantic Web outlier came from? (my guess is that the OMG is thinking about making a move in on that turf, as well! ;-)