James Taylor's Decision Management« Pareto, Gauss and John Hagel | Main | Blogging InterACT »
May 14, 2007Change Time in Software Development
I saw an interesting piece over on Keith's blog today - Dealing with change during software development - talking about change and how to cope. Keith makes some good points and I just wanted to add my 2 cents. I have blogged about Ch-ch-changing applications before and discussed how teams today should consider systemt to be built to change not built to last. I recommend using business rules as an approach and a technology as it is both a great fit for agile devleopment (see this article on agile and business rules) and a key enabler for agility. I also think it can help business and IT collaborate and become more change tolerant.
Posted by jtaylor in
Business Agility
• Business Rules
• Decision Technologies
|
Digg This|
Add to del.icio.us
Trackback Pings
TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/1866
Hi James
Yes, definitely! When creating a system design, I always take care to document the high-level constraints on the system - i.e., the business rules that apply to its objects and processes.
There are then some interesting choices to make, aren't there, depending on the technologies you intend to employ to construct the system.
For example, I have been writing recently about how it is possible to automate business processes without use of a BPM Suite. This argument can be summarized as BPM Suite = Tactical, Model-Driven Design = Strategic.
So if you decide to take what I would call the Strategic route, and build processes using Model-Driven Design, you have a number of choices regarding business rule implementation. At a minimum, the following options should be evaluated as part of technical planning:
- Employ software design patterns that cleanly separate business logic from other elements of the code;
- Use a lightweight code library such as JBoss Rules;
- Employ a validation framework customized to your technology (e.g., Eclipse EMF Validation);
- Create a business rules layer, either using a rules-specific engine or a more general-purpose engine that incorporates rules support.
Whatever route you choose, the key thing is to make the rules independent of the code, isn't it - the argument you promote, of course, and that I entirely agree with.
--
All the best
Keith
Posted by: Keith Harrison-Broninski ![[TypeKey Profile Page]](http://www.ebizq.net/blogs/decision_management/nav-commenters.gif)
at May 15, 2007 02:51 AM
Hi James
Yes. When creating a system design, I always take care to document the high-level constraints on the system - i.e., the business rules that apply to its objects and processes.
There are then some interesting choices to make, aren't there, depending on the technologies you intend to employ to construct the system.
For example, I have been writing recently about how it is possible to automate business processes without use of a BPM Suite. This argument can be summarized as BPM Suite = Tactical, Model-Driven Design = Strategic.
So if you decide to take what I would call the Strategic route, and build processes using Model-Driven Design, you have a number of choices regarding business rule implementation. At a minimum, the following options should be evaluated as part of technical planning:
- Employ software design patterns that cleanly separate business logic from other elements of the code;
- Use a lightweight code library such as JBoss Rules;
- Employ a validation framework customized to your technology (e.g., Eclipse EMF Validation);
- Create a business rules layer, either using a rules-specific engine or a more general-purpose engine that incorporates rules support.
Whatever route you choose, the key thing is to make the rules independent of the code, isn't it - the argument you promote, of course, and that I entirely agree with.
--
All the best
Keith
Posted by: Keith Harrison-Broninski at May 15, 2007 05:49 AM
