From January 2025, the European financial sector will have to comply with the Digital Operational Resilience Act (DORA), a regulation aimed at improving the digital operational resilience and cybersecurity of this sector. DORA was born in a context where interconnectedness and dependence on information and communication technologies (ICT) are critical, meaning that a failure or attack can have a profound impact. Its objective is clear: to ensure that organizations have a robust risk management framework to prevent and withstand incidents in an era where threats are constant.
Who will be required to comply with DORA?
This regulation targets key entities in the financial sector, such as banks, insurance, trading platforms, fund managers, security firms and rating agencies. Its main requirements include ICT risk management, incident reporting, resilience assessment and risk management of external providers. From January 2025, any non-compliance may lead to sanctions.
More than compliance, evolution
DORA requires robustness and resilience, but how is this achieved? Building a resilient and secure architecture is not only a regulatory requirement, it should also be an approach that applies naturally to all projects, tools or applications. At Xeridia, aligned with these principles, our solutions are designed to adapt to standards such as DORA without compromising innovation.
Foundations for a resilient architecture: techniques and practices that make software more robust
Modernizing applications
Modernizing doesn’t simply mean upgrading an interface or adding an AI layer; it means building a robust infrastructure that enables continuity, security and, of course, compliance.
An old application is sometimes (more often than we would like to admit) synonymous with fragility, rigidity, opacity and quite difficult to scale. Old code often carries with it a large technical debt and, in many cases, little (or no) documentation to make it easier to evolve. But which technical approach is the most appropriate? It depends. We will choose one or the other strategically according to the impact and needs of the company:
- Retire: applications that are no longer used, no longer valuable or, as is often the case, perform redundant functions.
- Replace: old component(s) or the application itself with other commercial off-the-shelf (COTS), SaaS or open source software options.
- Lift and shift: migrate an application to a more modern infrastructure (cloud) without changing its architecture. But modernization does not stop there, relocating can give greater flexibility, security, but does not solve code-related problems.
- Platform renewal: the code is moved to a new platform with some modifications (changes to the database, middleware, performance optimizations, etc.).
- Refactoring: this involves rewriting the application code, improving the structure but without changing the behaviour (decomposing monoliths, adding native cloud services, etc.).
- Rebuild: modules, capabilities, or components.
- Redesign: redesign and build the entire application from scratch.
Microservices and Kubernetes
Opting for microservices allows greater flexibility and resilience. An application divided into smaller components makes it easy to isolate one component if it fails so that it does not affect the others. Kubernetes, as the orchestrator of these services, distributes loads and ensures the proper functioning of each component.
Distributed Deployments and Resiliency Patterns
Distributing an application or system across multiple servers or geographically dispersed environments (databases, APIs, etc.) improves scalability and fault tolerance.
The Circuit Breaker pattern helps to detect failures by preventing them from cascading. It acts as a circuit breaker to temporarily stop calls to these failed services until they recover. When failures are temporary, the Retry pattern automatically retries the failed operations to give them a chance to recover.
In conjunction with the Retry pattern, exponential backoff strategies can be employed to increase wait times between retries, rather than constantly retrying and avoiding overloads.
Event-Driven Architecture (EDA)
The decoupled system components communicate with each other by publishing and consuming events, which trigger actions. This requires the use of a message or event broker. Event-driven architecture provides scalability, flexibility and increased fault tolerance through event persistence, which ensures that events are not lost and are quickly recovered after a failure.
Looking under the bonnet: observability and testing
Observing makes it possible to react in time. Predictive monitoring or the use of structured logs and distributed traceability helps to identify, track and resolve problems.
Completing this capability is testing. From functional testing to stress, load and integrity testing. Automated testing allows us to simulate the peak loads that applications and infrastructures have to withstand under certain conditions to ensure that everything responds appropriately.
Building resilient platforms is a team effort
By choosing us, our customers find in Xeridia a partner who understands all the needs of the most demanding environments, such as finance. Our approach combines the expertise of teams specialized in DevOps, microservices and other innovative technologies such as GenAI, blockchain or low-code platforms. We work as a team to anticipate challenges and build robust solutions that facilitate the evolution and maintenance of reliable infrastructures.
