MDA and Business Rules

I was writing a book review on "Real-Life MDA" and I realized that many of my comments about the book were really about MDA or Model Driven Architecture in general. With this in mind I thought I would dump a few comments about MDA into their own post:

• "some people still believe that MDA is just another technical approach for generating code - a new form of CASE based on UML"
  And I have to say I am one of them
• Is MDA a paradigm shift?
  Perhaps, if/when it ever works and if/when business rules and analytics are properly integrated with it
• MDA lets developers concentrate on the 15%-40% of project code that implements interesting things such as business logic and algorithms
  I don't want to write code to implement business logic - it's a really bad idea. This is what business rules are for!
• Does MDA enable agile development by eliminating the need to write lots of mechanical code?
  Well perhaps. Using agile techniques with business rules to deliver business logic makes sense, but it's not clear this requires MDA
• Projects using MDA have shown a clear reduction in time from problem identification to working code
  But it is still code and IT is still making the change rather than the business
• Some of the benefits stated for MDA seem simple to someone used to a Business Rules Management System (BRMS) or even of a Business Process Management Suite (BPMS)
  For example, if MDA let's you make simple changes to "rules" quickly then that does not seem like much of a benefit given that rules engines let you do that without the step of generating code.
• If the services built with MDA embody business rules then the models that generate them must also
  If it is a bad idea to embed rules in applications (and it is) then why would I want to embed them, or decisions based on them, in a model of an application? I want to manage them as a real asset, not embed them
• MDA is said to support the separation of concerns
  But true separation of concerns should mean that busines logic is managed by business users and MDA won't do that because UML won't do that.

Or am I being too cynical? What do you think?

Perhaps I should just regard business rules as part of a Model-Driven Architecture as they allow you to specify business logic without the nitty-gritty of code? UML does not manage business rules well today. Ongoing standards work is helping but there is still little or no appetite to fix UML to really integrate rules (rather than treat them as an add-on). As long as designers and developers are embedding business rules in use cases (despite advice to the contrary), statecharts, class models et al this will not work. RUP and agile have been adapted to include rules but neither does so by default.

Rules in MDA now!

Technorati Tags: BRMS, business agility, business rules, decision management, decision service, OMG, Rational Unified Process, RUP, agile, UML, use case

Comments

[Alexander Ryan]

This is an interesting post. Personally, I have nevery really understood the business rules movement. Rules based languages and rules engines have been around for decades but they have never really taken off except for in small niche segments. I have never seen a convincing argument for why developers should stop coding business logic into applications in favour of using a business rules engine as general way of developing applications. My experience with rules engines is that they are much more difficult to work with than procedural or object oriented languages are are almost impossible to debug. I am willing to be convinced otherwise though. Has anyone written a convincing paper on this subject?

[Larry Stevens]

UML's list of submodels has many omissions, even 15+ years along. Rules and user interface are two important such domains, but there are many others. It's not a flaw in MDA per se, for which UML is only a vehicle.

My view is that for MDA to "rule", UML's scope and depth both must violently expand.

[Alex Campbell]

I think there's a big issue often overlooked with this "SOA-everywhere" craze and by extension, a substantial risk involved with all SOA-dependent approaches like BPMS and BRM. Namely:
- There's a huge overhead from the intrinsically wordy character of XML, compared to highly-optimized point-to-point protocols.
- XML transformation is very resource-intensive and usually shows bad performance with current parsers (e.g. Oracle).
- Intrinsically unreliable character of web-services (e.g. restoring from bad Internet connectivity or unreliable/hacker-prone services).

My point is, as anything in life, going to the extremes with "agility" is unwise, as extremes always shall come with a price; SOA looks to me more like a one-fits-all architectural approach that's still slower and lot less reliable than the traditional ones based on OOD and 3-tier, and this could become a critical issue when the system becomes really distributed, complex, but poorly managed. I feel SOA/BPM/BRM vendors need to bold their offer with enforced built-in mechanisms to manage unreliable providers (e.g. query caching, load-balancing, exception-handling, XML-to-binary, Kerberos, etc.).

MDA on the other side, is still a developer-centric approach indeed compared to the more business-centric of B[P/R]MS. But think we need to understand that the agility of MDA is displaced at the architectural side; you could change architectural patterns and even platforms without touching models, and that's good for the evolution and maintenance of any IT infrastructure, independently if the suits can use it better or not.

BP/BR/SOA seems king to glue the overbloated enterprise software of today. As a general methodology for designing software applications however, I still think that the SOA concept has a long way to go to prove is a viable substitute of the more traditional OOD.