Skip to main content

Breaking down the CRM monolith

In my previous posts, I have shared some theory regarding microservices. But it's time to start some implementation. I love to write code and see and feel things working. So I will start a series to refactor a monolithic CRM system and transform it into microservices based flexible software.

Big ball of mud.

Customer Relationship Management(CRM) is that giant software which existed since time immemorial and is used by all companies in some form or shape. Big enterprises will buy CRM software (also known as packages) from top CRM vendors like Oracle, SAP, Salesforce etc and then employ an army of consultants to try and implement it. Most of the classic CRM systems in the market today, even if deployed on the cloud are the big monolithic ball of mud. They are the gigantic piece of software with the huge feature set. Most often those requirements are surplus to the requirement or they will not fit into the processes of the company. So the company has to hire these certified consultants or "specialists" to either tailor the product or tailor your process to the product. This takes the involvement of a lot of people from business, consultants, developers, architects, and managers over a long period of time. Since so many parties are involved and too many ideas and thoughts, these programs often end in disaster (if not managed properly) after wasting months and even years not to mention the millions of dollars that go down the drain. I have had a couple of such unlucky experience to be part of failures. 

Outdated technology stack

CRM softwares are monoliths that have evolved over a long period of time. They most use outdated or proprietary technologies and are often closed source for competitive reasons. Even if you get some modern open source CRMs, they are also monoliths and often suffers from the same challenges as the commercial ones. They are also not based on open standards or technologies that leverage modern hardware. Most of the open source CRMs, for example, are written in PHP which is not always best suited to leverage, for example, the power of multi-core CPUs. Hence it can be challenging in terms of performance and scaling.

Vendor lock-in

CRM or such packaged softwares mean long term commitment to a vendor. Even if you run the newer version of these tools, you still are completely locked into the mercy of this vendor and its cloud offerings. You still haplessly pay software and cloud hardware cost. This bill can be a significant dent to the overall IT budget and thus limit spends in R&D. This also makes integration with other custom or COTs product extremely challenging.

Also, you have to train and work in the proprietary technologies used by the CRM vendors. Competent resources on such technologies are hard to find and even if you find someone it's going to be very expensive.

Lack of flexibility

Often the commercial or the open source CRM products lack flexibility. You cannot pick and choose the modules you need. Neither you can run on your favorite cloud. 

Key components of CRM

Now that we know some of the key challenges of CRM softwares let us first understand the key modules that make up a CRM software. I will try to keep this as simple as possible for easy of explanation and understanding. The goal is not to overwhelm you with business or domain knowledge but to see how to break down CRM monoliths and see if it can leverage the flexibility of microservices.

The key components of a CRM software are typically

  1. Lead
  2. Opportunity
  3. Contact
  4. Account
  5. Campaign
  6. Product 
  7. Quote
  8. Invoice
  9. Contract
  10. Project

The number of modules can vary and some CRMs have additional modules but in general, the ones listed above are the most common set of modules. For the sake of simplicity, we will consider the first 2 modules in our example tiny CRM and build the monolith version in the next post. 

Before I end, I want to take the liberty to post a similar problem from the book - Building Microservices by Sam Newman. Sam writes

The CRM—or Customer Relationship Management—tool is an often-encountered beast that can instill fear in the heart of even the hardiest architect. This sector, as typified by vendors like Salesforce or SAP, is rife with examples of tools that try to do everything for you. This can lead to the tool itself becoming a single point of failure, and a tangled knot of dependencies. Many implementations of CRM tools I have seen are among the best examples of adhesive (as opposed to cohesive) services.
The scope of such a tool typically starts small, but over time it becomes an increasingly important part of how your organization works. The problem is that the direction and choices made around this now-vital system are often made by the tool vendor itself, not by you.
I was involved recently in an exercise to try to wrest some control back. The organization I was working with realized that although it was using the CRM tool for a lot of things, it wasn’t getting the value of the increasing costs associated with the platform. At the same time, multiple internal systems were using the less-than-ideal CRM APIs for integration. We wanted to move the system architecture toward a place where we had services that modeled our businesses domain, and also lay the groundwork for a potential migration 

In next few posts, I will try to build a modern CRM based on microservices architecture. 


Popular posts from this blog

Why do you need Spring Cloud Config server?

Last month I wrote a primer on concepts around 12 factor app. Before getting into the details of the Spring Cloud Config Server, I must refresh on the principle #3 from the list presented in that post.

3 – ConfigurationStore config in the environments
Configuration information must be separate from the source code. This may seem so obvious, but often we are guilty of leaving critical configuration parameters in the scattered in the code. Instead, applications should have environment specific configuration files. The sensitive information like database password or API key should be stored in these environment configuration files in encrypted format.
 The key takeaways from this postulate for a cloud-native microservices application are:
Do not store configuration as part of the deployable unit (in the case of lead microservice - inside the jar or war if you are still deploying war like the good old days). Instead, store it in an external location and make it easily accessible during run-…

Upgrading Lead Microservice - Use MariaDB and Flyway with Spring Boot

So far I have been using an in-memory H2 database or Mockito for testing the lead microservice. To make the transition towards using the Spring Cloud Config server, I need to upgrade the micro-application to use MariaDB. I will be adding the configuration in the application.yml  the file which in the subsequent post will move over to the config server store. I will also be using Flyway to make it easy to maintain the database schema changes in future. I will use this post to introduce Flyway in the mix. Spring Boot also provides first class integration with Flyway. I am using Flyway as its really quick and easy to get started, minimal learning curve (no DSL) and I am comfortable with it having used it in the past.


MariaDB 10 is installedBasic familiarity with FlywayHeidi SQL client is installed.
Step 1 - Update build.gradle to include the MariaDB JDBC and Flyway dependencies.
Do not forget to do a Gradle refresh on your IDE (I am using STS 3.8.4 on Java 8)

Step 2 - Rename the…

How to implement Cache Aside Pattern with Spring?

ProblemYou want to boost application performance by loading data from a cache and prevent the network trip to the persistent store (and also the query execution). This can be achieved by loading data from a cache. However, you want to load data on demand or lazily. Also, you want the application to control the cache data management – loading, eviction, and retrieval. Forces Improve performance by loading data from cache lazily.Application code controls cache data management.The underlying caching system does not provide read-through, write-through/write-behind strategies (strange really ??).
Solution Use cache aside design pattern to solve the problems outlined above. This is also one of many caching patterns/strategies. I believe it is named in this because aside from managing the data store, application code is responsible for managing the cache also.
Let's now try to understand how this caching technique works and then explore how it solves the problems.
ReadCache MissThe applic…