Search
Smart digital content platform

Smart Digital Content Platform

Why does the ECM software industry need to change? – Part 1 Obsolescence

I list below what situations or common practices in the ECM software industry can and should change to improve our customer's experience.
Por qué la industria del software ECM debe cambiar - Parte 1 La obsolescencia / ECM software industry
Picture of Veronica Meza

Veronica Meza

Our company started in the software industry 18 years ago. In my personal case, I have been in this business for more than 13 years now. We have seen many things. In this article, I intend to list some of the practices or situations that, from a philosophical and ethical point of view, can be upgraded in the ECM (Enterprise Content Management) software industry. And, in some cases, it can even be said that these practices in use in our industry are fundamentally wrong. Although in my article we will talk about the particular industry in which we work, I think it is easily extensible to the global software industry. So let’s begin…

An industry in which technological obsolescence is commonplace

Last November, at an event for one of the big fish in our industry, a user of one of this manufacturer’s products said to me:

“Upgrading XXXX is the birth of a whale”

This user -part of the technical team of one of the most important Public Administrations in this country- told me how, although they only used the platform as a repository, each update required a colossal human and technical effort. In this Administration, it took them 4 years to perform the first upgrade of the platform. Now they upgrade every 2 years to make it less painful.

It is not only the case of this platform -or of the Public Administration-, we know stories of important private companies that reach a crossroads where they have to make a decision because the manufacturer no longer offers support for that version of the software. In an Enterprise environment, where you manage millions of documents, thousands of users, connection with dozens of applications, you cannot afford to have the back of your information systems (read document manager) without support.

Much to my regret, I have to say that we had to suffer it first hand and it is one of the great debts we have with old customers -some have left and others are still with us- when in our company we were dedicated to the implementation of another well-known open source ECM platform. The customizations and parameterizations to cover the customers’ use cases, in many cases made the upgrade unfeasible. In more extreme cases, we have also seen native incompatibilities between versions.

The impact of an outdated platform

Having an outdated platform is problematic for many reasons:

  • User needs are not watertight, nor are they associated with X version of a product. Technologies change to respond to changing user needs. Users with an outdated, legacy or obsolete platform must watch in frustration as they are blocked from implementing new processes or enjoying new functionality. It is not uncommon to see a company with several document management systems simply because they were unable to keep a certain platform up to date.
  • Updating cannot consume the organization’s technical resources. These should be at the service of users, to provide them with value and help them build solutions. If such technical resources exist, in practice, it is costly for companies to have a team specialized in X platform.
  • Not updating puts the organization’s documents and data at risk: outdated software can lead to security vulnerabilities, as these are usually fixed in higher or current versions.

THIS IS NOT NORMAL, or at least, it should not be. So when we made the – at least risky – decision to build an ECM platform in an industry full of very big fish, and to stop implementing other third-party platforms, we made several design and policy commitments:

  • Default updates should be very frequent and automatic: first, to deliver constant value to customers, second to reduce the impact between updates.

  • Client configurations, customizations and parameterizations must coexist with a scenario of frequent updates: our CEO designed a system of decoupling parts that allows to activate/deactivate a good part of the client’s custom code. The choice of base technologies (Python vs. Java) gave us greater flexibility, so that incompatibilities or errors in the client’s custom code would not prevent the platform from starting (as happens with many Java products).

  • Keep the framework up to date: the base technologies on which our software operates (Python and Django) must be kept as up to date as possible. Of course, this means a huge effort to update code and libraries for our team, but at the same time, it allows our customers to work in secure environments and have access to the latest technologies and features available.

In the next installment, I’ll tell you more reasons why the ECM industry must change.

Continue reading the rest of the installments at: