Functionally clustering the application

Functional clustering or autonomy is dividing single monolithic application into multiple independent units, each specific to a functional area. This gives following business benefits:

Reduced time to market achieved as a result of:

  • Less dependencies between the team
  • Less effort for regression testing
  • Less effort for performance testing
  • Less effort for staging deployments

Reduced operational costs achieved as a result of:

  • Effective usage of environments
  • Potential reduction in number of environments

It is particularly complex to achieve this with OOTB products which most of the enterprises uses like IBM WCS, Hybris, Oracle ATG and the likes, but there are always ways around those application.

One of the biggest risks with providing the clustering is that each product team will ask for a separate cluster. This is very risky and can cause negative impact on maintainability and operational costs.

The following questions need to be answered before arriving and creating a new cluster:

  • Is a functionality being introduced functionally independent (and in turn technically independent), reasonably sized and complex enough to warrant a new cluster?. The parameters outlined below could be used to determine the complexity
    • Number of use cases and their flows
    • Number of unique business interfaces required for the cluster
    • Number of unique pages in the wire frames
    • New functionality not dependent on more than 3 clusters
  • Is the frequency of business changes high and independent and can cause disruption/regression in other services bundled? Parameters include
    • Frequency of change requests
    • Size of the change requests
  • Is the business priority of this functionality sufficiently high (e.g. needs to be available to end users even though other clusters are under outage)?
    • Page hits for the functionality
    • Revenue loss in case of outage
  • Is the technical complexity/resource usage of this functionality high?
    • Number of unique third party interactions
    • JVM permanent generation requirements
    • Heap occupied by the objects related to the cluster (including versions)
    • CPU utilisation due to the functionalities in the cluster

Overall recommendation is to always break the single monolithic application into individual units to achieve agility as that will help in scalingĀ engineering for digital

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s