Browse Prior Art Database

Scalable Customization of a Cloud Application Disclosure Number: IPCOM000244322D
Publication Date: 2015-Dec-02
Document File: 6 page(s) / 59K

Publishing Venue

The Prior Art Database


Customization for enterprise software is difficult and costly for customers, and in a cloud environment this cost can be pushed back to the enterprise software vendor, reducing profits. This article describes a method of letting customers choose their own customization points, which get pushed back to the vendor, making updates safer for both vendors and customers.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 20% of the total text.

Page 01 of 6

Scalable Customization of a Cloud Application

Executive summary

Middleware is often very large and complex. The more customization points, the harder it is to control the future architectural direction of the software. There is a need to reduce the number of customization points to control the future direction, while still allowing flexibility, and the ability to push updates to customers.

Detailed background

Note: In this disclosure our main consideration for middleware is an application which provides many base functions and is complete in itself, but most enterprise customers need to enhance for various reasons. The disclosure is not exclusive to this type of application or situation though.

Middleware is often very large to tries to cover as many cases as possible for a variety of customer scenarios. However, there is no way to anticipate all customer needs, so customization is required. However, the middleware author cannot even anticipate which parts will need to be customized, so it cannot create the proper customization points for all cases. However the vendor must make a "best effort" and try to guess which parts will be customized and design for that. This has two undesirable, but related problems:

Many more customization points are created than are necessary. For example, in Java, if a class is allowed to be replaced by a subclass at runtime, all public and protected methods of that class become customization points.

Every customization point adds design complexity for future changes, since the order and execution of customization points is not

allowed to change. The middleware author is not aware of which customization points are used and which aren't, and so must assume that all customization points are used by at least one customer in order to be safe. This can introduce strong limitations to future changes. For example, if a class is found to have performance problems and needs to be rewritten, this might not be possible if it has several public or protected methods, since the methods must still exist, and must still be called in the same order so that behaviour remain the same. This has the effect of "freezing" parts of the code, and leads to business policies that forbid changes.

While dealing with these issues, middleware authors must keep improving the software to remain competitive, and push these updates out to customers to keep them happy. This is especially true in a cloud environment, where development cycles are measured in days or weeks, rather than quarters or years.

After a middleware upgrade is released, customers with customizations are faced with a dilemma:

1) Patch and spend additional money patching customizations.

2) Don't patch and miss out on new middleware features.


Page 02 of 6

The more extensive the patch, the more expensive it will be to patch customizations - possibly prohibitively expensive. The risk of patching is also higher as more customizations are implemented. The result is that m...