.png)
Backend API Enablement
Backend API enablement, which is the most common and long-standing of the 3 modernization approaches, allows you to connect your “legacy” system of record (SoR) applications (ERP, CRM, core banking, claim management, billing, SCM, etc.) to your modern, digital applications through APIs. In this scenario, your SoRs won’t change, but your digital applications will be able to leverage their data and business logic—a necessary precondition for most digital applications (think about mobile banking or mobile commerce, for example).
Your enterprise automation platform plays a significant role in supporting this architecture. Its API gateway capability publishes, monitors, manages, and secures the APIs that can be consumed by your digital applications. And, on the other end of the architecture, the enterprise automation platform’s data and application integration capabilities connect the composite services that implement the APIs’ functionalities to the various SoRs.
Once you’ve established all of the above, these composite services can respond to the digital applications’ API calls by retrieving the requested SoR data and sending it back to the digital applications that need it.
While this architecture is clearly valuable, popular, and amply proven, it comes with scalability, performance, and availability limitations. For example, if a system of record is temporarily unavailable, certain API calls won’t work. Therefore, the digital applications can’t retrieve the data they need from a given SoR. Moreover, your SoRs likely aren’t designed to support the high workload required by digital applications—as the latter can serve hundreds of thousands, if not millions, of users. In other words, since your SoRs cannot efficiently serve in a low latency fashion with a high number of incoming API calls, your digital applications may not be as responsive as they need to be in order to keep customers happy.
The Digital Integration Hub
The digital integration hub (DIH) architecture works the same as the previous approach—with one big exception. There’s now a data management layer that sits between your SoRs and your APIs, the associated services, and digital applications. This layer essentially stores a consolidated and optimized copy of the SoRs’ data that’s needed to support the APIs. This allows API services to retrieve the data they need by querying the data management layer—as opposed to triggering transactions in the SoRs, as is the case in the classic back-end API enablement scenario.
The data management layer is connected to your SoRs by the enterprise automation platform’s application and data integration tools. And by using event-based technologies, like change data capture and/or event brokers (e.g. Apache Kafka), the new layer and your SoRs’ data can be kept in sync in real-time or near-real time. Therefore, if a certain piece of SoR data is, for example, modified, then the associated data item in the data management layer is also updated as fast as possible.
This approach addresses the previous one’s shortcomings in terms of resiliency, scalability, and performance.
It’s no longer necessary for your SoRs to be available 24/7, as your digital applications can locate the data they need in the data management layer. Furthermore, it’s significantly easier and cheaper to scale your data management layer up or down, thus optimizing your digital applications’ performance over time. For example, it’s much easier to scale a data management layer built on NoSQL or in-memory technologies than it would be with a system like a mainframe core banking application or a classic ERP system.
Once you’ve successfully established a DIH, you can also leverage it to gradually modernize your SoRs.
In fact, the DIH acts as a strong decoupling layer between the digital applications and the SoRs. In principle, they don’t need to know anything about each other as the only thing they have in common is the DIH’s data management layer. As a result, a new digital application has no or minimal impact on the SoRs, and replacing a SoR is transparent to the digital applications as long as the new SoR can provide the same data to the data management layer. Eventually, a DIH allows you to start modernizing your legacy SoRs one-by-one, at a pace that makes sense for your business, and through a variety of approaches. This includes anything from replacing a legacy system with a SaaS application to rebuilding the SoR in a cloud-native way to lifting-and-shifting a still-valuable application to the cloud.
Composable Business Applications
The most advanced approach to modernizing applications involves adopting the composable business strategy.
It requires your legacy SoRs to be replaced with multiple well-defined, packaged application components—often referred to as packaged business capabilities—that can be consumed via the APIs and events they make available. The idea is that applications are “composed” by a joint venture between your IT and business teams. More specifically, they work together in what’s referred to as “fusion teams”, and they use an orchestration, low-code tool to glue these components together in ways that lead to uniquely-valuable solutions for the business.
The top benefit of engaging in this approach comes down to agility: Your fusion teams will be able to build and continuously enhance a high volume of applications quickly and more easily than conventional approaches. And while building composable business applications requires multiple technologies (which make up your “application composition platform”), many would already be part of your enterprise automation platform—making it all the more critical to invest in your enterprise automation platform sooner rather than later. Simply put, today’s investments in enterprise automation technology put you on the launching pad to application composition.
Now it’s your turn: Take a moment to reflect on your current approach to modernizing applications and see what’s needed to move on to the next level. For example, if you’re using the backend API enablement architecture, you can explore the requirements for extending it with a DIH. And if you’ve already adopted a DIH and modernized your SoRs, start to take stock of the technologies you have and those you still need in order to build composable business applications.
Comments