In the first post of this series, I started listing a list of best practices that can and should be used when working on a business rules project. This post is about detailing one of these practices further.
Build a prototype
Building a prototype serves multiple goals that will help you with your project.
First it will serve as a real life starting point for your team to get acquainted and more knowledgeable about the processes and technologies involved in the project. Second, it will serve as a test for the architecture that is proposed for the system you are building. Third, it will accomplish something tangible that your team and the rest of your organization can see and touch and really discuss.
I covered this in the previous post on the topic which you can see here, but it is worth mentioning it again. There is a good chance that your team will not have all the knowledge it requires to work on the project at the beginning. This prototype* or pilot* will serve them well as a step to acquiring the knowledge they need for the rest of the project. You will need to take this into account for this phase of your project.
You first need to identify the key people that you want involved in this portion of the project. This prototype or pilot will serve as a learning tool for those people and they will become references to other people in your team later on.
With some outside help, this team will start working on the prototype and learn more about how to use the product, how the product relates to other components of the architecture, what needs to be done, in what order, to what degree of completeness, etc. This knowledge and experience is usually specific to each organization, so they will need to learn how to do things and then prepare checklists and processes that will make all of this work in the organization.
By no means should these processes and checklists, etc. be set in stone, but it is a starting point for future work and will need to be adapted as new situations arise.
Once the prototype is completed, the people involved will become references for others that will be joining or expanding on the project. They might become advocates and evangelists for the project and the technology.
Although the focus has been on getting the team to gain the knowledge, another person that will benefit from this exercise is the project manager. They will get to see what is required to succeed in the full project. The team he is working with will also be able to help the project manager with the planning phase of the project since their estimates and comments will be based on experience, not on guess work.
Validating the architecture
Having a business rules project usually means changes to an existing architecture or a totally new architecture (in the case of a legacy system replacement for example). The prototype will serve as a test for this architecture. The focus should be on the “happy path” making it work is of the upmost importance. Dealing with exceptions and special cases should be delayed as long as possible since it will add little value if the architecture doesn’t work in the first place.
The team that will work on the prototype will have to deal with most of the technical issues to make things work. But once they have worked through this, it should prove that the architecture works and that it is something that can be worked with in the future. Of course, you should expect some adjustments to be required, but it should be considered somewhat of a rubber stamp on the direction that was taken.
During this phase of the project, you should also expect to have to perform some proofs of technologies* or short tests to prove the technical feasibility of one technical option or to help choose between equivalent technical options.
A starting point
Once the prototype is completed and operational, some debriefing of the team needs to take place to learn from the experience, document that knowledge and to prepare for future phases of the project. This is a time for reflection on what worked well during the prototype and what didn’t. Outcomes from this should be lessons learned, preliminary processes for future development and a list of skills and knowledge required to succeed, etc.
The prototype can also be used to communicate to others in the organization. It can be used to excite people about the new architecture, new possibilities and business rules. Other people in the organization will be able to see what “it” looks like, how it works, ask more specific questions, etc.
All in all, the prototype serves as a learning tool, communication tool and architecture validation tool, and all of those are good things.