how to develop highly customizable off-the-shelf software (aleksey stukalov)

By Aleksey Stukalov

How to Develop Highly Customizable Off-the-Shelf

Software

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 ModelProduct 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 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 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 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 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

Product CUBA 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 a @Component• 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 28th October 2015Where: Hilton-Franciscan Room ALab 1: 10:00 am - 12:00 pmLab 2: 12:30 pm - 2:30 pmLab 3: 3:00 pm - 5:00 pm

By Aleksey Stukalov

Thank you!