Smart digital content platform

Smart Digital Content Platform

The 4 reasons why the ECM industry must change

Below, I list which situations or common practices in the ECM industry can and should change to enhance our customers' experience.
Las 4 razones por las que la industria ECM debe cambiar / ECM industry
Picture of Veronica Meza

Veronica Meza

18 years ago, our company embarked on its journey in the ECM industry. Personally, I have been in this field for over 13 years now. We have witnessed many things. In this article, I intend to enumerate some of the practices or situations that, from a philosophical and ethical standpoint, can be improved in the ECM software industry (Enterprise Content Management). In some cases, it can even be said that these common practices in our ECM industry are fundamentally incorrect. Although my article focuses on our particular industry, I believe it can easily be extended to the global software industry. So, let’s begin…

The 4 reasons why the ECM industry must change

Industry where technological obsolescence is common

Last November, at an event hosted by a major player in our sector, a user of one of this manufacturer’s products told me:

“Updating XXXX is like giving birth to a whale.”

This user, part of the technical team of one of the most influential Public Administrations in this country, explained how even though 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 platform upgrade. Now they update every 2 years to make it less painful.

It’s not just the case with this platform—or with Public Administration—but a widespread issue in the ECM industry. We know stories of major private companies reaching a crossroads where they have to make decisions because the manufacturer no longer supports that software version. In an enterprise environment where you manage millions of documents, thousands of users, and integration with dozens of applications, you cannot afford to have your information systems’ backbone (read: document management system) unsupported.

Regrettably, we experienced this firsthand, which remains a significant debt to our longstanding clients—some have left, others remain—when our company focused on implementing another well-known open-source ECM platform. Customizations and configurations to meet clients’ use cases often made upgrading impractical. In extreme cases, we’ve seen native incompatibilities between versions as well.

The impact of an outdated platform

Maintaining an outdated platform poses several problems:

  • User needs are not static and are not tied to a specific version of a product. Technologies evolve to meet changing user needs. Users with an outdated, legacy, or obsolete platform often find themselves frustrated as they are blocked from implementing new processes or enjoying new functionalities. It’s not uncommon for a company to have multiple document management systems simply because they couldn’t keep a particular platform updated.
  • Updating should not consume the organization’s technical resources. These resources should be dedicated to serving users, adding value, and helping to build solutions. However, in practice, maintaining a specialized team for a specific platform proves costly for many companies.
  • Not updating exposes the organization’s documents and data to risks: outdated software can lead to security vulnerabilities, typically fixed in newer or current versions.

THIS IS NOT NORMAL, or at least, it shouldn’t be. That’s why, when we made the somewhat risky decision to develop an ECM platform in a sector dominated by major players and stopped implementing third-party platforms, we committed to several design and policy principles:

  • Updates by default should be frequent and automatic: first, to deliver constant value to clients, and second, to minimize the impact between updates.
  • Client configurations, customizations, and parameterizations should coexist with a scenario of frequent updates: our CEO designed a system of modular components that allows the activation/deactivation of much of the client’s custom code. Choosing base technologies (Python vs Java) provided us greater flexibility, ensuring that incompatibilities or errors in client-customized code do not prevent the platform from functioning (as often happens with many Java products).


Keeping the framework updated: the underlying technologies of our software (Python and Django) must remain as current as possible. This requires a significant effort from our team to update code and libraries, but it enables our clients to work in secure environments and access the latest technologies and functionalities available.

An industry where every technological challenge is solved with a new license or a new application

Resources are limited, and this holds true for nearly everything in life. Within organizational contexts, this limitation is even more apparent: there are constrained budgets, deadlines to meet, and teams that must allocate themselves efficiently to maximize productivity. This reality places companies in a challenging position within the ECM industry when new needs arise. For instance, a company may need to automatically generate documents related to product contracts. Business personnel might think, “This should be something the document management system handles,” and they approach their vendor for a solution. The typical response often is, “Yes, don’t worry. You can do that with module XXXX, but you’ll need to acquire licenses for it…” Another scenario could involve data capture: “No, our product doesn’t handle that, but we integrate with XXXXX. Shall I provide you with their contact?”

The impact of using different applications or modules to address a single need

In both scenarios mentioned earlier, business users and IT teams typically face two main challenges:

  • Budgetary constraints: Licenses are expensive, whether for additional modules or, worse yet, if they need to purchase an entirely new product.
  • Technological complexity: Adding new applications or modules increases complexity in the organization’s IT architecture/structure. Different applications operate on different technologies, require ad hoc integrations (or luck with product integrations), necessitate that teams learn and maintain multiple tools, and so on.

Why can’t a document management system or digital content platform cover the entire spectrum of content lifecycle (capture, management, storage, delivery, archiving)? To this question, one might respond, “Because an application that focuses on a specific problem (such as capture or BPM) typically solves it better. If we use document management functionality for XXXX, we’ll fall short.” Here, I encourage exploring your actual needs and questioning if they are truly as “complex or sophisticated” as perceived. In our experience, only in exceptional cases are needs genuinely complex, and even then, it’s often possible to break down the problem and find a more optimal solution that avoids excessive costs from underutilized tools and adds less technological complexity.

By addressing these challenges thoughtfully, companies can streamline their technological solutions, optimize costs, and better align their tools with actual business needs.

Ciclo de vida de la información

THIS IS NOT NORMAL, or at least, it shouldn’t be. That’s why when we made the somewhat risky decision to develop an ECM platform in a sector dominated by major players and stopped implementing third-party platforms, we committed to several design and policy principles:

  • Designing a platform that allows users to meet common and reasonable needs around their documents or digital content, from capture to preservation and archiving.
  • Not creating additional modules, just functionality, that neither ourselves nor our clients need more things to maintain and care for.
  • Not charging for the software, only for usage. You don’t have to pay extra licenses to use another module or application; you pay for the service you consume in some cases, such as OCR or Blockchain.

An industry where you are dependent on the vendor

To be honest, after so many years in the ECM industry, we’ve witnessed ridiculous situations in this regard. For example, we’ve seen quotes of $6,000 USD just to add a field to a form. How difficult can it be to add a field? But of course, the user needing the field cannot do it themselves—they have to commission the vendor, who has the right to set their price, even if it’s frankly abusive.

If you have specific needs—and everyone does because using a document management system as it comes out of the box only gives you about 10% of the power of having this type of software—you have a problem: you depend on a vendor to customize the platform.

Customizing ECM platforms often involves the use of XML files, which are not complex for a technical user but would be a nightmare for a business user.

Other tools in the ECM industry, to solve the customization problem, have had to create separate tools to generate the necessary code for customizing the document management system. The problem with these “customizers”—probably due to the complexity of the systems they customize—is that they are often unintuitive or difficult for business users to understand.

The reality with most well-known ECM software tools is that they were designed by developers to be customized by developers.

The impact of vendor dependence

  • Your company will move at the speed of the vendor, not at the speed of business users. They will dictate the cost and time to resolve your needs.
  • Helplessness: in enterprise environments, ECM platforms often become the backbone of the company’s IT infrastructure. This inevitably requires changes, adjustments, and new functionalities at some point. If you cannot develop these internally, you have no choice but to accept whatever the vendor demands.

Of course, there’s an alternative, which is to build an internal technical team specializing in the platform you use. Issues include:

  • Costs: maintaining a team of dedicated IT professionals for a platform is not cheap.
  • Market situations: for example, over the last five years, we’ve seen a high turnover and shortage of technical profiles in the sector. While this trend seems to be changing now, we’re talking about highly specialized personnel.
  • Learning curve: if you find a specialist in your platform and can hire them, this person won’t need to learn the technology anew. It will be expensive, naturally, but you’ll save on training costs. Otherwise, you’ll pay the price in terms of time, money, or problems associated with training a new team.

THIS SHOULDN’T BE THE CASE. That’s why when we made the somewhat risky decision to develop an ECM platform in a sector dominated by major players and stopped implementing third-party platforms, we committed to several design and policy principles:

  • Creating a low-code product: once end-users understand the platform’s basic concepts, they can quickly configure their business processes.
  • Providing free training: Athento’s clients can access to learn how to configure the platform to meet their needs themselves.
  • Eliminating deployment issues: users can add a field in less than a minute and see it directly in the user interface. If they don’t like it, they can delete it without needing deployments, restarts, or disrupting operations—it’s priceless.
  • Speed: the product is designed so that processes can be configured quickly, in real-time, without restarts. You make changes and immediately see the results. If client IT policies allow, changes can even be made directly in production. Do you have a new process you want to digitize? Create a new team in Athento and configure it yourself right now!

In this context, readers might argue that the customization possibilities are limited. Our company has always worked in enterprise environments, with many applications, where clients often turned to Athento to solve what they couldn’t achieve with other applications (such as core business functions, CRMs, ERPs, etc.). We couldn’t afford to design software that wasn’t extensible and flexible, which would have been easier for us. Therefore, Athento also features a development framework that allows technical users to customize the platform extensively for automations, integrations, frontend, security, and other aspects.

Beyond our clients’ reality, our company’s reality has led us to develop a low-code application. Athento is intentionally a small company BY OUR CHOICE. Between our teams in Spain and Colombia, we have fewer than 30 employees. We cannot—and do not want to—rely on providing professional services. We’ve shed any complex of being small through years of experience and specialization in this sector. In these 18 years, we’ve learned to value our freedom, sustainability, and economic independence. We make decisions that align with our values and our worldview. This wasn’t always the case, and we had to learn from the challenges reality threw our way. In conclusion, the realities of our clients and our company have shaped our product, and one of its defining characteristics is that our clients must be autonomous in customizing the product, both by technical users and, more importantly, by those who understand the business best and can therefore build better solutions to their technological challenges.

An industry where the manufacturer is far removed from the users

The ECM industry undoubtedly exhibits oligopoly characteristics: a handful of companies dominate the majority of the market. Recent movements in the sector reflect an industry where a $77 billion pie is divided among a few players. Since 2020, we’ve seen Hyland acquire the two most prominent Open Source ECM platforms. With Onbase, Alfresco, and Nuxeo in its portfolio, this giant now holds three of the most widely used ECM solutions.

Having a few significant players in the market naturally results in these companies becoming massive multinational entities. In 2023, OpenText reported revenues of nearly $6 billion and employs over 14,000 people worldwide. Hyland generates nearly $500 million in annual revenue and has over 3,500 employees globally.

When companies reach such scale, they typically organize into hierarchical layers. Moreover, in the ECM industry, it’s common for direct customer interaction not to be handled by the manufacturer themselves, but by integrators.

In my opinion, these natural consequences of having a market controlled by a few major players have a less obvious yet critically significant impact on end-users in product design: the decision-makers in product design are often very distant from the actual users.

¿Por qué la industria del software ECM debe cambiar? - Análisis industria ECM

I would like to quote one of the eminent figures in product design, Don Norman:

“When you design, you have to understand the capabilities of the people for whom you are designing.”

— Don Norman

When you develop a product, you must ensure that the people who have the problems you intend to solve are involved in the design, testing, and iterative improvement. It’s challenging to maintain this closeness when you have 14K employees and thousands of companies implementing and customizing the product for you.

The vision and vocation behind companies

Of all the points I have discussed in this series of entries, this is perhaps the one where it is difficult to establish negligence or bad faith in ECM industry practices. I believe it is simply a cause-effect situation.

I also think that many of these companies truly strive to innovate, conduct research—often through acquiring other companies—and spend money on market research, consultants, and analysts. However, the circumstances of their structure and business network make it challenging to offer this closeness to the end-user of their products.

But it also has much to do with the vision and vocation of the company. At Athento, the focus is always on maintaining an agile and as horizontal as possible structure so that our team has direct contact with clients and end-users. Naturally, there are always team members who have more interaction with users, but in our company structure, the mobility of individuals and cooperation between teams allows this information to flow more dynamically. You can take me as an example; you will see me in projects, giving demos, designing functionality, meeting with clients to hear their feedback, or making technical and/or economic proposals. Our CEO actively participates in designing customizations and client projects, organizing systems, supporting customers, attending business meetings, and frequently programming functionality himself. He is always available to meet with users, something he truly enjoys.

Additionally, another key point in the development of Athento—the intelligent digital content platformhas been that we have been incorporating functionality resulting from the needs of projects that our Delivery team has to implement. Our CEO’s direction has always been: first, we offer this parameterization solution to the user, gather feedback, and if the feedback is positive, we integrate the functionality into the out-of-the-box product.

The improvements included in our software over the last 5-7 years have their origin in the platform users who have been involved in the design and have often been beta testers of new features. For them, we express our recognition and gratitude because we know that Agility and Continuous Delivery are difficult to assimilate at times and have required patience and understanding from our users.

At the project level, we also have a fundamental rule:

“End-users must be involved in the project from Day 0.”

If this does not happen, we raise the risk from project management. You can see more details about our Project Management Methodology here.

The support team is another important point of contact so that the Product team has crucial information on how end-users are using our product. Our CEO is involved in support work on a daily basis. They meet with users and provide evidence and information about the difficulties or challenges they experience. Not everything reaches the Product team, of course, but everything that the Support team suspects could be a product issue is reported and reviewed every morning without fail by a rotating member of the Product team, our CTO – Víctor Sánchez – and myself personally.

In addition to direct team conversations and interactions with users, we have had to establish more formal communication channels to channel all end-user feedback: Portal for requesting features, Athento Community, Exclusive demos for clients, etc.

But of course, in addition to explicit feedback, we must analyze how the product is used, using tools like Hotjar, or investigate through surveys where users and customers want the product to evolve. (In this article, we explain how we have applied the KANO methodology).

In projects with partners, we try as much as possible to have contact with the end-user so that we can listen to and collect opinions from the source. But the partner is also a partner in product development, conveying the needs of their users and sometimes contributing to the development of the platform itself.

Being close to the user is not easy. Those of us who make software get attached, fall in love with our products, have biases, etc. The user is the one who gives us the reality check that is not always easy to hear. But there is no other way. Being close to the user is the only way. We can say with confidence and tranquility today that our clients and users actively contribute to the development of our product and that although we may not always like what they tell us, interacting with users remains one of the most beautiful and rewarding parts of our work. Users never let us get bored 🙂.

If you are looking for a document management solution and want to talk to our team, we are just a click away, contact us.