Skip to main content
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: , , , , , , , , , ,

related posts