Solution Strategy

It is critical to define the correct solution strategy to support your individual deployment. Generally, the deciding factor is based on how complex the implementation is. If you have a simple implementation, a single solution approach can be adopted for larger more complex implementations, a multi-solution approach is preferred.

There is an assortment of approaches to defining your solution strategy and there is no right or wrong answer. What is crucial is that the needs of the organisation are addressed in a way that works today and provides scalability for future developments.

Single or Multiple Solutions

Single Solution Approach

When you are building a simple implementation, a single solution approach can be beneficial. It allows all the customisation to be contained and managed within one single solution container. This means that all customisations and configurations can be deployed together.

Adopting a single solution approach simplifies the solution layering process making it easier to manage, thus reducing customisation conflicts.

Multi Solution Approach

In more complex implementations is it generally considered good practice to develop using multiple solutions to deliver the overall application. A multi-solution approach gives more flexibility in regards to different development streams and utilising numerous development resources.

In regards to the solution segmentation, this is entirely based upon the requirements of the business. There is no right or wrong answer on how to segment the solutions into logical groupings. It is good practice to decide before development commences what clusters or groupings are to be implemented.

Some logical examples are:

When working with multiple solutions, it is vital to understand the solution layering behaviour as this could affect the intended and expected behaviour when the multiple solutions are deployed into the same instance.

The following example explains solution layering using a single component – the account name. It is worth noting that this layering occurs anytime a component is included in more than 1 solution.

In the example, the base system has the attribute Account Number with a filed length of 20.

1. The first solution (Solution A) is deployed, and the Account Number field length has been extended to 30. This will result in the application allowing 30 characters being entered into the field.
2. A second solution is deployed (Solution B), which extends the length of the account number field to 50 characters. This will result in the application allowing 50 characters being entered into the field.
3. Solution A has been updated to change the field character length to 35 and deployed. This will result in the application allowing 35 characters being entered into the field.

Solution Lifecycle Strategy

As part of your overall solution strategy, you also need to define the lifecycle of any given solution. Establishing a solid lifecycle strategy ensures repeatable and predictable deployment through your environments.

To ensure the deployment approach for production is repeatable and predictable, it is reasonable to take the same deployment approach for environments upstream of production. The earlier within the cycle, the deployment approach can be tested, the more chance there is to resolve problems.

At a high-level, the solution lifecycle is relatively straight forward.

The primary challenge occurs when there is a need to merge configuration changes that have been developed in several different instances. There are several working patterns commonly used during development.

Consider the following patterns in the context of developing a single solution. Multiple instances may be required to support the development of dependent solutions. This pattern can then be replicated should the approach to solution strategy include solutions segmented by business area or by function as an example.

Single Instance Development

All team members configure and customise functionality within the same environment.

A single instance approach is generally adopted for less complicated deployments or where the team is relatively small, a single development instance is the most practical approach. It reduces merge complexity and the effort to automate version control, build and deployment are relatively low.

There are challenges to be mindful of and manage:

• Minimise the overlap of responsibility between team members – avoid multiple team members working on the same attributes or entities.
• When the solution is exported, the components included within the solution will contain all changes made to them at that point, and these may be unfinished.

Multi-Instance Development

All team members work towards composing a single solution for release. They require a degree of isolation from one another to avoid contention and blockages during the development phase.

Typically for more complex deployments, a single development instance does not provide the agility required for an efficient development cycle.

In this solution strategy, a central or master development instance is also required to promote and compose incremental change to the solution from the team members.

• This enables isolation between team members while implementing and debugging custom code that might block other team members’ productivity.
• Incomplete work items may be omitted from promotion at a given time (per development instance).

Using multiple development instances does increase the complexity and requires a greater process responsibility amongst team members.

• It is still essential to reduce the overlap of responsibility between team members – avoid multiple team members working on the same components in different instance to prevent conflicts.
• Merge conflicts should be resolved within the central development instance. This may need to be conducted multiple times (once per development instance promoting change).
• Once changes are pushed to the central development instance, the subordinate instance should be rebuilt with the master solutions.
• Ensure developments are suitably granular and frequently committed to source control and the master environment. This minimises the disparities between sub-ordinate development instances and will help to reduce merge conflicts and collisions.