Continuing this weeks posts on using decision management to improve development, I thought I would post on how decision management should be part of model-driven development (model-driven engineering, a model-driven architecture or whatever).
The recent, and premature, discussion of the death of SOA led Johan den Haan to post SOA is dead; long live Model-Driven SOA in which he said:
That’s why we should talk more about the problem domain. We have to capture today’s business with formal models.
I have posted before about using decision management with MDE and answered some questions from a reader on MDE but I thought his comment was particularly pertinent to the issue of using business rules and decision management in MDE.
The key challenge, as he notes, is the problem domain and capturing today’s business. I would go further and say that we want to make capturing the problem domain as close to the solution domain as we can (so that the business users who understand what they need to do can make their software actually do it) and that we need not only…
Copyright © 2009 James Taylor. Visit the original article at Decision Management and software development II – Model Driven Engineering.
Continuing this weeks posts on using decision management to improve development, I thought I would post on how decision management should be part of model-driven development (model-driven engineering, a model-driven architecture or whatever).
The recent, and premature, discussion of the death of SOA led Johan den Haan to post SOA is dead; long live Model-Driven SOA in which he said:
That’s why we should talk more about the problem domain. We have to capture today’s business with formal models.
I have posted before about using decision management with MDE and answered some questions from a reader on MDE but I thought his comment was particularly pertinent to the issue of using business rules and decision management in MDE.
The key challenge, as he notes, is the problem domain and capturing today’s business. I would go further and say that we want to make capturing the problem domain as close to the solution domain as we can (so that the business users who understand what they need to do can make their software actually do it) and that we need not only to handle today’s business but create an environment in which we can easily capture tomorrow’s also. We must handle change. In an era where most of the cost and time spent on a system will be spent in modifications not initial development, this last is crucial.
Modern systems must act – they must respond to events, keep processes moving to enable straight through processing, support busy people with no spare time and high throughput demands. Any model of such a system should model the decisions within it as first class objects to enable this. Further, these decisions – these decision services – must be easy to change and controlled by those who understand the business. After all any move by a competitor, any new regulation or policy, any new marketing initiative, any new contract will require the decision making in the system to change. If the business users who understand these drivers cannot make the changes for themselves then the result will be delay, confusion, inaccuracy, lost business and fines. Automate these decisions with business rules and all this can be addressed.
So, model-driven is certainly the future but those models should model decisions and do so explicitly and the decisions should be described using business rules so they can be managed and evolved.
