Establish a robust approach to rule placement and ruleset management at the start of the project and document it so that the whole project team can collaborate most effectively and that the application is structured for ongoing and future development.

Understanding your ruleset and management processes

To make it easy for your software to change as it grows, it needs to be organised efficiently. By managing your rulesets by following best practices, you use experience gained over years of development and give yourself the best chance of producing a robust outcome.

Having a defined ruleset structure for your project team ensures that every rule is in the right place to make ongoing development easier, and future specialisation work more efficient and robust.

This is usually a process that is defined by the project’s Lead System Architect (LSA) at the start of the process. The LSA will document and communicate the process with the rest of the technical team.

Configuring your ruleset processes

The following best practices help to ensure your development is robust and future-proof.

1. Define your application structure at the start of the project. Use your understanding of the project to decide how many application layers you are going to use. Decide if you need a Framework layer.
2. Have a dedicated ruleset version for each of your application rulesets for each sprint. Lock rulesets at the end of the sprint so that work done on each sprint is kept isolated and unique.
3. Define a project guideline checklist for system architects to follow so that they know where their rules should be created throughout the project. Make a review of this checklist part of the review process in the definition of done for user story development.
4. Have a separate application (and therefore ruleset) for unit tests. By creating an application that is built on your main application that only holds unit tests, you can be sure that unit tests only get deployed to the environments where you need them. For more information see Managing test cases separately in Deployment Manager.

Outcome

Once you have followed the steps above, you will have an approach that the whole team follows for the duration of the project. By following the best practices, you can be sure that rules are in a logical home and that the application is ready for ongoing development and change.

Frequently asked questions about the build and deployment process and procedures

What types of rule should I put in the Organisation layer?

The organisation layer should contain all rules and features that can be reused in any application at your organisation. For example, any rules that are used to configure single sign on, or that integrate with your core line-of-business applications would go in the Organisation layer.

When should I use a Framework layer?

A Framework is usually a complete application which is designed to be specialised for different regions or divisions within your organisation. It should be possible to run an application based only on the Framework without modification, with only the specialisations in the top-level application. If you are certain that there will never be the need for this kind of specialisation, then you don’t need a framework layer.

How should I decide which ruleset to put a rule into?

When creating a rule of any type, always pause to think about the best layer/ruleset to place that rule into. Place it as low as you can whilst thinking about possible reuse. If it is specific to the region/division/application you are developing, then place it at the top. If it may have relevance elsewhere in the application, then place it as low as you can. The project LSA will have a clear picture of which rule should go where, and he or she will always provide guidance.

Should developers use private checkouts?

A private checkout is useful to allow a developer try something out quickly without having to copy a rule from a locked ruleset into the latest development branch. We don’t recommend using private checkouts for ongoing development though as it is easy to check-in a rule without realising that another developer may have changed it and checked it in whilst you had it privately checked out. This can cause you to check in an old version of the rule without realising.

When should I use branches?

Get into the habit of creating a development branch for each user story or bug that you work on. Even if your project team is small, following a branch-based development process helps keep development isolated and makes it easier to manage multiple concurrent development tasks. Always delete the branch again once the work is finished and accepted by the Product Owner.