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 analyst…
Copyright © 2009 James Taylor. Visit the original article at Decision Management and software development I – Agile.
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.
