Gregor Wolf, Chief Operating Officer at OPTIMAL SYSTEMS, describes how modern IT architectures are gradually outstripping the previous system designs in a guest article for the Project Consult newsletter.

Is the architecture of the major ECM systems nearing its end?

[…] Gartner didn’t make it any easier after it announced the end of ECM and started spreading around the enticing term ‘content services,’ which was left open to much interpretation and co-opting. It could have a positive effect if it were to promote innovation in the stagnant market and initiate dialog on how to design a modern ECM system. But it didn’t really happen. The only thing that happened was the same old systems were suddenly rebranded as content services. […]

If the same manufacturers offering the same old systems suddenly transform into content services leaders, then it’s doubtful whether enough value will be given to modern and useful software.


From content services to actual modern ECM software

Are the terms ‘modern’ and ‘useful’ objective criteria for assessing something? It’s clear that software needs to be useful. This means that it is modern if it better fulfills the interests of today with modern concepts compared to the legacy concepts. Being modern isn’t about being fashionable.

Who will find a modern ECM software system useful?

  • The end user, of course. These people need it for completing their tasks at work. […]
  • It should also be useful for the company, enabling it to do business according to valid rules (laws and compliance). […]
  • And the next group is underestimated, but nevertheless very important: DevOps (IT department, operators, administrators, CIO). They need to ensure that operations run smoothly; otherwise, the previous two criteria I mentioned could never be fulfilled. […]

ESB and SOAP vs. microservices and REST

SOAP (Simple Object Access Protocol) and ESB (Enterprise Service Bus) have proved to be unwieldy, complicated technologies. The initial euphoria for the two technologies gave way to disillusionment when it came to putting theory into practice. Professed SOA services of monolithic application servers were to be integrated in monolithic ESBs with unwieldy SOAP, which many found too much to ask for and it often failed.

In addition, the all-rounder ESB added a ‘big single point of failure.’ If it failed, everything failed. […]

Microservices can be for integration of SOA 2.0. It’s still about service reuse and integration, but now it’s also about distributed applications and decentralization. Microservices mean considerable progress for all end customers in terms of decoupling the services, which can be seen in simple operation, scalability, and system stability for every end customer. […]

A modern microservices architecture makes de facto all services with REST stateless and available to the outside world via http(s). For this reason, the only thing imaginable is that the services of an entire system communicate using REST both externally and internally in a modern microservices architecture. […]

It can provide its entire infrastructure and develop services that are loosely connected in a network, instead of packaging the application in an unwieldy application server. As an obvious consequence, this kind of system is more agile, clearer, easy to scale, and fail-safe.