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

2. 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

3. 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

4. Adjust Model ProductCustomization

5. Modify Business Logic

6. Adjust UI

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

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

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

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

11. 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

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

13. Branching: Customizability Database Layer Business Logic Layer User Interface Layer

14. 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

15. 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

16. 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

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

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

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

20. 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

21. Plugins: Customizability Database Layer Business Logic Layer User Interface Layer

22. 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

23. 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

24. 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

25. 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

26. 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

27. Model Customization: Implementation

28. Model Customization: @Extends Base entity use should be substituted globally across the product: – Constructors – JPQL queries – Model traversal

29. 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

30. ProductCUBA extension UI Customization: How it works

31. UI Customization: Product Screen

32. UI Customization: Extension Screen

33. 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

34. 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

35. Hierarchical Customization Model

36. Summary

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

38. 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

39. 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.

40. 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

41. By Aleksey Stukalov Thank you!