Mapping Requirements

Take business requirements and identify the suitable Kentico Xperience features and functionalities.

Get familiar with built in functionality

Selecting the right Kentico functionality for any given requirement requires you to be familiar with what Kentico offers. As with anything, you will become more familiar with Kentico functionality and how to use it over time, but where should you start? Thankfully, there are many resources available to you. We recommend starting with the below:

Evaluate built-in functionality

Once you narrow it down to a feature you think is suitable for your purpose, it is a good idea to evaluate it more thoroughly through a proof of concept. Doing a proof of concept validates whether or not all the functional requirements can be achieved.
If you find that the selected feature meets most but not all of your functional requirements, consider whether you can extend the feature to meet all requirements. 

Extend built-in functionality

If you find that you need to extend Kentico to meet some functional requirement, you need to do three things:

  1. Make sure that you've checked the resources mentioned at the beginning of this section for other features that might accomplish what you need to do. This avoids creating a solution to an already solved problem.
  2. Research the available extensibility options of built-in functionality, being conscious of customization best practices in Kentico documentation.
  3. Compare extending Kentico functionality versus building something completely custom. When doing the comparison, consider the viability of one versus the other with regard to the effort (in time and cost), the ease of use from a business or other end user's perspective, and the technical complexity.

Build custom functionality

If you find that there is no suitable Kentico feature that meets your needs, or you determine that extending Kentico is not a viable option, do the following:

  • Architect the solution with low maintenance in mind by using as much built-in functionality as possible.
  • Design the solution to be extensible and scale-able for the future.
  • Investigate how other built-in functionality influences the solution (e.g., content staging, web farm, workflow).

Scenarios

Handling market-based pricing

A client wants to specify different product prices for different markets (e.g., different geographic regions). The partner developing the site knew from their training and the documentation that the built-in shopping cart price calculation process does not natively support this.  Therefore, they knew that they needed to either extend the system or consider another solution.

After doing some research, the partner found in the customizing product prices documentation that they could implement their own product pricing service to change the pricing logic. They even found that the documentation had an example of using an external pricing service which gave them a good starting point.

As the customization is minimal, fulfills our requirements, and is extensible for new markets in the future, this approach was selected over building something completely from scratch. 

Synchronizing product information

A client needs to update the product stock and price information in Kentico from an external system that offers a web service for this data. The partner knew that there is no direct support in Kentico to handle this integration without writing code. The customization option they found most suitable was the scheduled task feature in Kentico.

They built a custom scheduled task that called the external system's web service to get data, and used the Kentico API to update the products in Kentico. By using the Kentico API, they knew that the system would ensure that the built-in features, like staging and web farms, would work properly.

The external system provided a way to request only changes since a certain date and time, so the partner used this to request only products which were modified after the last successful product import. This ensured that the solution was scale-able when the number of products grew.