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

Decision Management and software development - Agile

user-pic
Vote 0 Votes
Last week I posted Focusing on decisions to improve the software end product and I decided that this week's posts would be a series of follow-ups on how decision management can and should impact software development. Today on how it should impact/be a part of Agile, tomorrow on Model-Drive Engineering and Thursday on DSLs (Domain Specific Languages).

In the article I started to discuss the incongruity of developers claiming to follow the Agile tenets and yet still insisting on writing procedural code that no business user could possibly read. In particular, how can you collaborate with someone who can't read what you are writing and how can you be responsive to change if any change requires a development cycle, even an Agile one?

If, in contrast, you applied decision management in an Agile environment you would see some real differences:
  • Business users, business analysis and programmers could collaborate around the same code (business rules) and everyone could understand what it did.
    Because business rules languages are declarative and verbose, business users and analysts can read and write them. No errors of transmission, no confusion as to what the "code" means.
  • Business users and business analysts could be empowered to make some of their own changes so that the whole system was more responsive to change.
    Business rules management systems provide all sorts of tools for exposing all or some of the rules and all or some of their structure to business users to modify. A BRMS also handles updates of these rules so there is no (or at least much less) need for the whole specify/code/test/deploy cycle.
  • The business logic would not need any documentation even for the business users as they could read the logic as written in the business rules.
  • The business rules would be the specification so that there was only a single source for the logic - the rules themselves.
    And of course a BRMS manages these rules in a repository with versioning, audit trails, impact analysis and more.
  • For many decisions the developers would simply create the shell of the decision and then let the business users and analysts create, modify and evolve the business rules for themselves.
I am sure that developers who claim they are following the Agile tenets while using traditional code mean well, but are they really Agile? Personally I doubt it. Unless the business is part of the project in a meaningful way they cannot be and with most coding languages that's just not possible.

Decision management makes Agile software development truly Agile.

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