Skip to main content
Are business rules a bridge or a ferry?

James Governer had a great post today - On Agile, IT-Business Alignment, Martin Fowler and The Yawning Crevasse of Doom talking about a presentation by Martin Fowler and Dan North. There were some wonderful comments in it:

  • The biggest problem we have in software is communications between the business people and the developers.
    Yup. This is one of the things that makes business rules such a powerful technology - it helps close that gap and resolve the different perspectives business and IT have.
  • We dont need to make the decision now. make it when we need to. Its easier.
    In a rules context this means define the template now (the type of rule) but don't put the actual rules in until later. Instead of putting "rules" into code you allow them to be managed as assets.
  • Try to make the language as readable by the business expert as possible.
    Business rules do this anyway but, frankly, business users don't want to maintain rules anymore than they want to maintain code.
  • The best requirements come after the feature is put into production.
    And the best rules too. Letting the business change their rules once they are in production and their impact can be observed is way more effective and really improve the maintenance process too

When I read this article, though, the comment that really sticks with me is the Ferry/Bridge analogy. It seems to me that the need for a bridge is not just when an application is being developed but also when it is being maintained and evolved for the rest of its useful life. Unless the business people whose business it impacts and the technical people who support it can collaborate effectively and constantly, things will not go well. The use of business rules in an application or service can ensure that the bridge gets built and kept in use over time. This is the core value proposition.

, , , , , , ,

related posts