By Aleksey Stukalov How to Develop Highly Customizable Off-the-Shelf Software

Off-the-Shelf vs Custom Software Off-the-Shelf G eneric Customization is laborious or impossible Custom 100% designed for the individual customer Difficult to productize for new customers

Ideal Product Implements “good for all” - common business features Also implements “good only for me” - distinctive business features for individual client Customization does not impede regular core product updates

Adjust Model ProductCustomization

Modify Business Logic

Adjust UI

Widely Used Techniques All in One Branching Entity-Attribute-Value Plugins

All in One: Concept Keep single codebase Employ ‘feature toggling’

All in One: Customizability Database Layer Business Logic Layer User Interface Layer

All in One: Ideal Scenario Established, mostly static business area Limited customization requirements Inability to deliver custom development does not impact sales

All in One: What if the assumptions were wrong Customer is unhappy due to lack of desired features OR Codebase turns into the unmanageable garbage can

Branching: Concept Create a new branch for the customer Customize whatever is needed in isolation

Branching: Customizability Database Layer Business Logic Layer User Interface Layer

Branching: Ideal Scenario Master branch is mature and does not require rapid delivery of new features Only a few customer branches required Customer branches do not require frequent synchronization with the core product branch

Branching: What if the assumptions were wrong Constant merging from master to branches and vice versa: Becomes extremely time consuming Leads to unavoidable regression bugs

EAV: Concept Deliver “as is” Employ a mechanism to dynamically add custom fields to entities on-the-fly Mix with other techniques to enable Business Logic customization

EAV: Customizability Database Layer User Interface Layer* * UI can be customized to some extent and naturally limited by the pre-programmed display logic

EAV: Ideal Scenario Flexibility of having additional informative data is required Additional data is not explicitly used in the product business logic

EAV: Limitations Cannot be applied for Business Logic customization May add complications to data utilization and increases the database load

Plugins: Concept Define ‘Points of Customization’ (aka Extension points) Develop functional logic in separate (isolated) artefacts (plugins or scripts) Dynamically execute attached plugins in the pre-defined Customization Points

Plugins: Customizability Database Layer Business Logic Layer User Interface Layer

Plugins: Ideal Scenario Points of Customization are easy to predict User Interface modifications are qu i te trivial Business Logic modifications to be added only in Points of Customization, not in between

Plugins: Limitations Any layer can be customized to some extent, which is naturally limited by ‘Points of Customization’ Architecture becomes more complicated ‘Just in case’ scattering of ‘Customization Points’ leads to poor code readability and hard debug

Ideal Framework Requirements Customization from Model to UI Clear separation between underlying Product and On-Top Customizations Possibility of tight interlacement of Customization and Product functionality Entire product to be opened for customization

CUBA Extensions Implemented in the CUBA platform – a high level framework for enterprise software development Based on the Open Inheritance pattern Main Principles Inherit all the features of an underlying product, using it as a library Contain only distinctive features, without copying untouched product functionality Support hierarchical customization model

Model Customization: Challenge Product implements User entity Customer requires address and department fields to be added Department is required to be a separate entity, linked to a User

Model Customization: Implementation

Model Base entity use should be substituted globally across the product: – Constructors – JPQL queries – Model traversal

Model Customization: How it works Object Factory always returns the deepest child using metadata model All JPQL queries are parsed, analyzed and modified according to the metadata model Model traversal substitution is reached by orm.xml generation, where target-entity attribute refers to the deepest child

ProductCUBA extension UI Customization: How it works

UI Customization: Product Screen

UI Customization: Extension Screen

Spring framework does it – no need to reinvent what already exists! Declare Override in the extension Re-register the new class in the extension The new implementation will be used across the whole product Business Logic Customization

Updating the Underlying Product Version Specify the new version of the underlying product in extension Meet product API changes in the overlapped parts Rebuild the product with the extension

Hierarchical Customization Model

Summary

Based on mainstream technologies Implements: CUBA Extensions Scripting Entity-Attribute-Value CUBA Platform

Our Experience: Thesis Enterprise Content Management system Over 200 implementations 26 custom solutions based on the product Delivery of 26 projects to huge customers would not be possible without deep system customization

Our Experience: Sherlock Taxi Solution Complete Taxi Management Solution 12 implementations 7 custom solutions based the product 2 ongoing customizations Product is constantly being updated for all customers bringing new product features.

Hands-on Labs Try CUBA extensions at our Hands-on Labs, with the help of our CUBA experts, you will develop a fully-functioned business application in just a couple of hours When: Wednesday 28 th October 2015 Where: Hilton-Franciscan Room A Lab 1: 10:00 am - 12:00 pm Lab 2: 12:30 pm - 2:30 pm Lab 3: 3:00 pm - 5:00 pm

By Aleksey Stukalov Thank you!