As a business rule developer, I tend to notice that a good amount of business rules projects tend to be linear across the business. What I mean by "linear", is that I tend to notice projects that share a good amount of similarity between one project and another, all within the same business application. For example, Business_A has 5 separate rules projects, Project1, Project2, etc...

That being said, at what point does reusability, extensibility and consistency play a part in enforcing a robust and fruitful rule application, beyond the scope of the current requirements and utilization? Does it come into play during architecture? Implementation? Or does it fall all the way back in the Iterative cycle to flush out the best place to implement a scalable project?

Let's take a step back and look at each of the phases listed above and see where it should fit in.

Architecture Phase:
The design phase of rule development usually includes a large amount of rule analysis, but rarely includes a deeper scope of all rule projects that will be built and used within the business. Without this deeper understanding of the future implementations is it possible to know how extensible to make each individual rule project? I believe within reason it is, but only by making the project as "generic", as possible without sacrificing core functionality.

Implementation Phase:
Again, as with the Architecture phase, Implementation is usually done on a project to project basis. As work continues on one project, another projects scope may be introduced or need to be modified. As this is usually the case, there is the ability to enhance the previous project(s) with knowledge gained during implementation of the secondary (or other) projects. Opening up the ability to pull in similarities between projects or alternate execution points into the rule project.

Iterative Phase:
In my opinion and experience, this seems to be the most optimal, although sometimes not the most time conscious, location to perform a thorough reusability assessment of all projects. This is most likely being said with the knowledge that everyone knows this to the be the best location and time to perform this. However, it should be strongly noted that it is at times, a very time consuming process to navigate through multiple rules projects simultaneously and put together a strong reusable set(s) of project code and/or implementation, that is effectively reusable between the multiple project while maintaining strong rule code design and business functionality.

Overview:
It should be noted that most of the time, there simply is not the resources nor time available to perform these necessary updates to a project. I have stated the word, necessary, due to the fact that this is, at times, one of the most often overlooked aspect of a rules project. In my opinion reusability and extensibility should be a cornerstone of a single site multiple rule project implementation.

Reusability and Extensibility within rules projects, allow for (among other things):
1. Faster development through code reuse or reference
2. Ease of code interpretation
3. Faster knowledge transfer between new and existing team members
4. Robust reusable implementations
5. Cleaner future code maintenance
6. Easier code and deployment manageability