January 13, 2009
In a blog post about Hardcoding Considered Harmful – or is it? Jeff Palermo said
Oren Eini boldly makes the assertion that a system is simpler to maintain when configuration is hard-coded in one place within the system. Coupled with an automated testing and deployment process, changing configuration can be just as simple and predictable [...]
Read the full article →
January 8, 2009
Dan Rosanova wrote a piece on The SOA Knowledge Gap that made me think (again) about the value of business rules as a way to manage requirements. Dan points out that
“A unique SOA challenge is its need to bring together SMEs from across the enterprise.”
Now this is true but I don’t believe that better management of requirements is the answer. In fact what is needed is a way to turn what the SMEs know into something that can be managed in a repository and used to power systems directly. Working with SMEs to create sets of business rules to represent their know-how not only allows this knowledge to be stored in an executable format – reducing the likelihood of implementation error and speeding deployment and maintenance – it also allows each SME or SME group to manage their own rules. A modern Business Rules Management System (BRMS) will allow different users to have different access to rule sets, allowing each set of rules to be managed by those who know them best or those who “own” them. The BRMS can then be used to package up the relevant rules – typically many sets from many SMEs – into a decision service that can be deployed into a service-oriented architecture.
Because the SME’s can edit the rules directly, business agility is increased because the time from the SME realizing that a change is needed to the time when that change is deployed can be cut dramatically using the rule management features of a typical BRMS.
Dan’s comments about how to gather the know-how from SMEs are all good, but gathering their know how as requirements and not rules is going to limit the good it can do. I have blogged a lot on this topic but check out these two posts on the difference between requirements and Requirements and on how to fit business rules into a software development lifecycle.
Read the full article →
