How to Develop

Highly Customizable
Off-the-Shelf
Software

By Aleksey
Stukalov

Off-the-Shelf vs Custom
Software
Off-the-Shelf
Generic

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
Product

Customization

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 predefined 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 quite 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 OnTop 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 Customization:
@Extends
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

UI Customization: How it
Product
CUBA extension
works

UI Customization: Product
Screen

UI Customization: Extension
Screen

Business Logic
Customization
Spring framework does it
no need to reinvent what
already exists!

Declare a @Component
Override in the
extension
Re-register the new
class in the extension
The new
implementation will be
used across the whole
product

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

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

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 fullyfunctioned business application in just a couple of hours
When: Wednesday 28th 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

Thank you!

By Aleksey
Stukalov