Core vs Enhancement vs Custom vs Integration

This is the essential 4-part nature of how sites are developed and delivered in Affino. As with all projects, these are governed by the laws of the PQT triangle, with Cost and Time being the two most significant variables. I hereby lay down the why’s and wherefore’s of how the different distinctions are applied, and why we work in the way we do.

1: Core

This essentially means Core Control Centre Affino - i.e. functionality is fully baked into the entire system and sits wholly within the standard divisions of the Control Centre - utilising standard Settings Profiles and automatically enabled for CRM, Customer Ladder / Conversion Events and Core Campaign and Message elements etc.

Obviously when developing a fully-fledged solution - say a new component element, this route takes the longest and is the most expensive. The obvious upsides are that it is a standard part of the system, and is fully maintained within the conventional update and upgrade path. It’s also easy to find, deploy, configure and tweak.

So in short, when new functionality is required which does not already exist in Affino, the ideal path is the one of Core Development, although this is both the most expensive and most time-consuming option.

2: Enhancement

This is based on ’Nearest Match’ methodology - i.e. utilising existing component/s which closely match the new requirement/s, but need the addition of certain settings to enhance the functionality of the existing component/s. Often this is the best choice, as it can be implemented quicker and more cost-effectively than an entirely new Core component element.

At times however there may be compromises in this approach, and some of the flexibility of a fully stand-alone solution component may be lost. It is of course down to the negotiation with the Client as to exactly what is required, and the willingness to make concessions in budgetary or timing terms.

The upside is that this is a very cost-efficient and relatively quick approach, which is fully maintained within the standard Affino update / upgrade path.

3: Custom

A fully Custom solution is created usually when there is a limited use-case scenario for the new requirement or acute timing constraints. If only a single Affino site owner will make use of that specific functionality, it’s not worth baking it into the core of the system, to foist onto all and sundry. If only one Client will ever use the functionality, it may overly complicate the interface and settings made available / visible for other parties.

There is a separate slot on the Affino Control Interface - where Custom Components can sit. The methodology here is two-fold, but mostly governed with time and cost again, and it may be implemented to be as close to Core as possible - meaning that it has unified functional ties with other key areas of Affino - we do need to be careful of creating too many additional settings in Affino which will only very rarely be used.

Unlike ’Core’ and ’Enhancement’ which are updated within the natural course of Affino release management, Custom functionality is paid for and maintained by a single Client - so that every time the component needs to be updated, the cost lands on that single Client.

The other downside is that in this scenario, the component does not benefit from the ’Hive Mind’ evolution - where a component used by several different parties is continuously innovated and evolved based on quite diverse deployments.

Upsides for Custom are that you’re getting pretty much exactly what you want at a keen starting price, although ongoing maintenance is higher.

4: Integration

This means using an external / 3rd party component to render certain specific functionality. The use and deployment scenarios for this are various - sometimes built on existing business alliances and partnerships, sometimes built on the premise that said component does not easily coexist within Affino, or there are budgetary or timing constraints which necessitate such an approach.

Many times the same or similar functionality already exists in Affino, but the Client simply requires a slightly different flavour which is more effectively served up by means of an Integration. Sometimes the scale of the new requirement is such, that it is simply not particularly viable on the timing or cost scale - for the immediate requirements.

Every Integration is different, and some connect into Affino functionality at a more concerted level, while most are simply surface components with a fairly basic degree of component integration with Affino. For certain types of functionality, and for a variety of reasons, it may not be suitable to bake something into the core of Affion.

Yet often the workflow of new Affino component delivery starts off as a surface integration, then becomes Custom functionality, and is eventually baked into the Core of Affino as time and budgets allow.

Time is almost always a factor in the use-case for Integration - where you need to get certain functionality up quickly. So the upside is often, but not always, one of speed.

There are various downsides with this approach though, and none more significant than maintenance overheads. Unlike Core, Enhancement and Custom, - Integration is entirely outside the control of Affino, especially when it comes to update and upgrade paths. Meaning you are often forced into expending resources outside your normal cycles, and at some times the functionality can be compromised by an unseasonal and sudden update of the core Integration API from the 3rd party solution side, or some other unexpected change in service, occasionally even termination of the specific service components your were utilising.

The more external and 3rd party integrations you use, the more vulnerabilities you have for overall system stability and security. That said, sometimes Integration is the only viable option on the table.