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.
The Insider's Guide to Next-Generation BPM
Subscribe to this blog by RSS
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:
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
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:
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