Standard limitations

Few months ago, we have an interesting problem: some business units needed to have a Customer relationship management (CRM).

The IT department did some searches to find existing solutions, comparing features, limitations, pricing, integrations, etc.

While, at the same time, other business units suggested the direct integration in our custom tools.

It was a shock for the IT, I remember posting on Slack: "can we agree not to do it?".

The business suggesting it argued that have it integrated in our tools would cost nothing.

Which is an issue as the development and maintenance of a CRM is costly, even for not advanced systems.

CRM, is more complex than keeping a list of names.

It's about building a comprehensive framework for work and thoughts, going into the detail of each action.

Of course, starting with a blank page let a lot of freedom, but it is this freedom which makes the technical debt grow faster in a green field project, rather than in a legacy project.

Needs have been identified, architectural choices have been made, and trade-offs are conscious.

Whenever you pick a standard CRM, or any complex classical system, more important trade-offs and limitations are similar, making easier to navigate between them, and finding workarounds.

While trying to mimic them through custom developments, often result in a leap forward, trying to reimplement standard solutions, hoping we can make different trade-offs, which is often lost hopes, as no one wants to deliberately limit their product.