Business rules are the driving force behind every enterprise application, from the smallest (such as a Windows application to calculate bus-based shipping costs) to the biggest (such as an application that processes driver’s license renewals). Yet so much attention is directed toward how we build software rather than why we build software.
Take design patterns for example. Design patterns are very useful tools for building applications because they draw upon what’s already been done, so you don’t repeat the work of thousands of other developers. Not everyone is a fan of design patterns, so there’s a ton of discussion about their merits and pitfalls all over blogs, discussion forums, and programmer Q&A sites. The thing is, design patterns don’t make your software finished. They don’t drive the business side of software development; that is, a design pattern is not going to make your calculations for you. But nobody is talking about this. Nobody is talking about a design pattern for managing business rules.
It seems like developers and software architects are happy to just assume that the business rules are going to be taken care of in the process of building the software. We like to think about using ORM for the data layer and MVC for the flow control and SharePoint for the document lifecycle. In a lot of cases the business rules are a foregone conclusion; I know that if I’m going to develop an application that calculates bus shipping costs, I’ll get the formulae for those calculations from somewhere and I can worry about how they work when the UI/database/flow control/etc. are done.
My current customer has their business rules all over the place. They’re in stored procedures. They’re in ASP.NET code-behind files. They’re in ASP.NET pages. The rules aren’t documented anywhere. If I need to figure out how the fiscal year is calculated, I either have to ask the domain expert or dig around in several code files. That’s a relatively simple calculation. For some of the more complex rules, such as determining eligibility for reimbursement, it’s nearly impossible for me to figure them out on my own. The prospect of getting all those rules under control while fixing other bugs and adding new features is daunting to say the least. It will easily take years.
In future application development projects, assuming I get to be in on the design phase, I will ensure that the business rules are captured in a way that is meaningful both to the stakeholders and the developers. Windows Workflow is a great way to do this, for example. There are also enterprise tools from Computer Associates and Rational that will keep track of business rules (or rather, requirements).
Managing your business rules is a fundamental piece of IT governance. It’s a very important IT survival skill.
No Comments » 