Syndicated from ebizQ
Michael Cote of Redmonk had a nice piece on over on his People over Process blog. He made a series of great points about the risk of business and IT people not being aligned – risks to the business and to IT. In particular I was struck by this comment:
What happens here is that at the start of an IT project, the business will want one set of requirements, but these evolve over time to match new customer demand. Often, during the project, these changing priorities mismatch with the development IT is doing. By it’s nature, most IT is not flexible enough to adapt to change.
This is, of course, both a critical issue and the primary driver for the adoption of business rules as a development technology. Separating out decision-making from the rest of the system and using business rules technology to ensure that the decisions can be evolved as the business priorities and needs change is a powerful tool for increasing the overall agility of a system and thus the likelihood it will remain in synch with business needs. For many systems it is the decision-making logic that must evolve all the time (not the data model or the UI) and rules can really make a difference.
Adopting rules technology can make sure that there are fewer degrees of separation between business and IT people and help IT embrace change. While adopting business rules has implications for business and IT people and while it is just as common to get resistance from business people as it is from IT people, I think it is time for developers to send a message to the application developer in the mirror because I think application developers need to take the lead towards application development 2.0.
Comments on this entry are closed.
I agree that business rules can bring business and IT together. I think business rules being declarative and more human readable facilitates quicker reviews, lesser learning curve, and most importantly agility.