APIs form a line in the sand for many an enterprise; formally, a line between service provider and service consumer.
Why? A closer inspection would recognise that by taking on the role of standardised interface, of single-point-of-access, of access control, the API gateway provides a boundary between external consumers and (internal) providers of services. As such, API gateways provide a means of expressing this boundary, in terms of interfaces and policies.
This is how we at SAP separate the service provider (e.g. functions provided by S/4HANA) and the service consumer (e.g. a mobile application or an operator’s screen). A similar approach can be applied between the current, or “to-be” environment and existing, or “as-was” legacy-enterprise domains. Simply – both can view the other as an external consumer of its own services. API requests between these domains can then be routed to the right services whilst also managing data transformation, transport and data-privacy concerns.
What’s neat is that, over time, this ‘mutual-brokering’ function can be used to allow services to move location – migrate – from one domain to the other (e.g. from legacy-enterprise to S/4HANA) without disruption, as the move is captured as a configuration change to the API gateway. This is partly because API gateways recognise the importance of configuration for managing this (something ESBs forgot), but also because API gateways can manage the “impedance mismatch” between these worlds. This last part is important, because if your business is now increasingly running at a real-time speed, such as is provided by HANA, then the rest of your (legacy) infrastructure might not cope so well with being directly connected to that. Policies (like SLAs) help mediate that impedance mismatch.
As part of the broader simplification of the business’ systems, this “new middleware” allows legacy-enterprise systems firstly a means with which to connect with core business processes and a means to have their data included in the end-users views of the business. Secondly, by using an API approach for domain mediation, it’s also simple to move services from these legacy systems provide onto HANA over time in a non-disruptive fashion.