A number of years ago, I was in charge of designing and implementing a data warehouse. At the same time, the company involved was replacing a number of operating systems with a single new one. Two deadlines had already been missed for go-live on the new system, and a lot of meetings were being held as to why. I happened to end up in one of these, which was about system security. The discussion was about user access to information in the system through the new website portal. The company had several subsidiaries, and at one point I asked the question, “Can an employee work for more than one company subsidiary?”
This innocent question unleashed a major firestorm. As it turned out, the question had never been considered before. And as it turned out, the answer was ‘yes’. Well, the problem was, the system had been designed so that a user had only one level of access. If the user was an administrator, they could look at everything in the system (including all subsidiaries). Unfortunately, what was discovered was that a user could be an administrator in one subsidiary, able to see everything for that company, but a low-level worker in another subsidiary, with very restricted user rights.
The system had no way to deal with this.
The business rule that a user may work for more than one company in the holding corporation, with different user rights in those companies, had not been identified and so the system had not been designed for it.
Ultimately, because of many missed business rules like the one above, the project collapsed in failure.
Now one other factor I want to point out in this is design flexibility. Not understanding business rules properly up-front can be disastrous, but it is guaranteed to be disastrous when coupled with an inflexible system architecture. If thought is put into designing a flexible architecture, it is possible to recover from a misunderstood business rule. Sadly, the same lack of attention to detail and comprehensive thinking that leads to not understanding the business rules also leads to not creating a flexible architecture.
Often hidden behind all of this dysfunction are three controlling factors; scope, time and cost. Overly aggressive companies who want maximum scope for small cost in short time put themselves in a losing situation. Understanding business rules can require large amounts of agonizingly detailed work that doesn’t really seem to add to functionality. The result of too-aggressive scope is often that business rules are only half-understood but system design plunges forward. Similarly, elegant, flexible system design takes deep thought and multiple prototypes where work is thrown away until the right representation of the business rules is met. Tight scope doesn’t allow for this.
The simple fact is, business rules rule, and whatever time must be taken to understand them has to be accepted or the project will fail.
Factors for success:
- Choose reasonable scope, with generous padding for uncertainty and investigation.
- Use personnel resources that are dedicated to ensuring that business rules are understood and that system design is flexible. Give them the room to do this job right.
- Make sure a framework is in place to absolutely verify business rules:
- Create committees of experienced business users with sign-off authority.
- Implement group communication systems where business rules can be posted and viewed by all participants, commented on, and when authorized, referred back to by the community.
- Prototype and test business rules constantly against the system--this must involve business users, not just techies. Don’t wait for the ‘big reveal’ of a system that doesn’t work