We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

James Taylor's Decision Management

James Taylor

Using Decision Management and software development - Model-Driven Engineering

user-pic
Vote 0 Votes

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.

1 Comment

Hi James. 100% agree. The major benefit of agile technologies is to maintain a close connection between the business domain model and the technological solution of the associated business problem. Technologies like business rules which provide greater abstract and declarative "implementations" allow simpler mapping from the conceptual to the the technological.

I highly recommend Eric Evans book "Domain Driven Design" on this topic.

James Taylor blogs about decision-management technologies such as predictive analytics and business rules, discussing how they deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links

Fico

Subscribe

 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Monthly Archives

    Blogs

    ADVERTISEMENT