API Product DesignCI/CDDigitized Business FunctionsIntegrations

Is an Abstraction Layer of Digitized Business Functions an Academic Exercise or is it Connected to My IT Landscape?

Digitized Business Functions 101

In past posts we have explored:

But all of this is pointless if you cannot connect this abstraction layer to your IT landscape to harness your existing information for new products. Read on to find out why the abstraction layer of digitized business functions is no longer just an academic exercise…

We are seeing more and more Silicon Valley investors targeting businesses who successfully identify a repetitive behavior and build a relevant API for it. Some of these businesses are subsequently receiving massively hyped valuations in this market.

This is great for a function where a company is happy to have a third party provide information which they have no interest in maintaining e.g. Google Maps. However, it only scrapes the surface of the number of functions an intelligent enterprise needs exposed as APIs or services.

An API is just an interface to a back-end capability. There are many capabilities that large enterprises do not want to outsource, as they have an interest in maintaining the information behind the API.

As an example, let’s take a membership system for a healthcare company. This would be full of commercially sensitive information – not to mention the security and PHI implications – so you would absolutely not want this outsourced. Let’s also imagine that, as some do, this healthcare company has several membership systems due to historic growth by acquisition.

If you then analyzed all the healthcare company’s business functions (the membership system being an individual example), it would quickly become clear that the total number of internal APIs and services needed runs into the hundreds, or even thousands.

Taking a modern blended abstraction layer approach is the best way to tackle this huge requirement of internal APIs and services

The abstraction layer is used to generate working code that can be automatically deployed using modern CI/CD and cloud technologies. This way, it can be both an abstraction layer in the way the business knowledge is abstracted away from any particular technology or coding format, AND in the way that the code generated and deployed can abstract the relevant information and capability offerings from your existing IT landscape.

Building and using your abstraction layer is quick and easy

Let’s continue to use our example of the healthcare company where you want to provide an abstraction layer and use it for generating a membership information API. First, you would want to build out a layer of abstracted service building blocks.

Using a platform like ignite, this would be simple to build. You could either leverage the pre-built content supplied with ignite or use some of its tooling to aid and accelerate the building of this layer from your existing assets, e.g. an existing canonical model for data in motion.

The next step would be to import all your existing services (APIs, Microservices and legacy services). With everything now in one place, you can combine the abstracted service building block with metadata from the imported services to a level ready to generate your API.

The API you want is for getting member information. It will be held in an abstracted design in ignite. You apply an output template to it, which generates the implementation code to be deployed to your Source Code Management (SCM) system and to then be picked up by your CI/CD systems. The same design can also be used to set your proxy settings in sync with the code.

ignite Output Options

This means that the abstracted design, rather than the code itself, becomes the artefact of the greatest value

It can be used time and time again, by applying different output templates, to generate different code for your rapidly changing runtime environments.

Back to our healthcare example; let’s say your get member information API runs off a SOAP service with a WSDL but needs to be migrated to a RESTful API. You can now do this in minutes: instead of rewriting the code manually, you simple apply a different template, (and maybe make some changes to the design) and the new code is pushed into the new runtime.

Not only is this much more rapid and flexible; it also gives you built-in governance. Dynamic governance checklists ensure any concerns are considered as early as possible, preventing them from becoming a bottleneck further down the development pipeline. By using templates, a lot of governance is also already baked-in to the code generated – e.g. your security policy standards will automatically be embedded and adhered to.


Are there examples? Who is using this abstraction layer? Read the final post in this series here.

Andy Medlicott

Andy is a digital expert and Lead Engineer at Waitrose and Partners. He has a passion for harnessing technology and industry trends to ensure excellent engineering practice which in turn delivers consistently high quality solutions.

Related Articles