API-framework
In addition to the All Finance Data Catalog (Introduction All Finance Data Catalog), the All Finance API-framework (AFA) forms the basis for the digital ecosystem (see also Introduction AFS). Within the digital ecosystem, the use of web services plays an essential role, whether it is exchange of data, performing functions or following a workflow within the distribution chain. The characteristic of a web service is that two machines communicate directly with each other (synchronous communication) to perform a service (function). Making one or more web services available to third parties is called an API (Application Programming Interface). For many organizations, APIs are essential for digital business. They provide a means to offer transactions (e.g. rate, offer, contract) and publish content (e.g. object data, weather data).
An API-framework:
- Provides insight into which functions/services are currently pre-defined within the financial services industry.
- Ensures unambiguous processes between parties.
- Ensures good accessibility of online services within the distribution chain.
- Enables co-creation where third parties can develop applications.
The SIVI All Finance API-framework started with the functions included in the ‘AFD webservices’ standard and is now expanded by request of the SIVI AFS users.
Figure 5.1-1 provides an overview of the building blocks of the API-framework within the All Finance Standard. The blue blocks are specific to the financial services industry. The yellow blocks are additional agreements made around the relevant generic standard for use within the domain.
Structure of the API-framework
The structure of the API-framework is basically formed by AFD structures and operations executed on these AFD structures. The API framework is designed to support a number of clusters. The API framework thus supports an important part of the work areas within the financial services industry. The clusters are grouped into operations. These operations are best viewed as application areas, most of which have a specific AFD structure (see also AFD structures). Within these operations over twenty variants are defined. For example for the operation new on cluster contract 9 variants are defined. By using (multiple) variants the resource of an endpoint (an example of the resource of an endpoint is an insurance company) can configure different endpoints and possibly connect them to internal processes.
Generic functional description, technical details based on JSON/REST
The objective for the API-framework is to describe functions as independently from their technical implementation as possible. The functional requirements are usually more constant in time than the requirements around technical implementations. Therefore functions are described using system agnostic (architecture, application and platform neutral) terminology in order to avoid any dependencies on specific technology or architecture. Starting with SIVI AFS the more technical elaborations and examples are based on the general use of REST (web) APIs. Technical specifications are drafted according to the Open API Specification (OAS) 3.0 standard.
In the Overview of the API-framework you can find a list of the clusters, operations and variants included in the SIVI API-framework. A detailed overview is available in the Overview of all functions.
No microservices
The SIVI API framework is designed to facilitate services, not microservices. Microservices are applicable when, for instance, an insurer has separate web services for successively requesting customer data, drafting coverage, and adding objects. Services, on the other hand, facilitate an entire process step, for example the creation of a policy.
The main reason for this choice is that microservices are most effective when developing a specific application. It can be relevant for parties within different processes or at different times to have insight into contracting parties. This is also very interesting if, for example, the goal is to create a detailed integration with the software of a specific supplier. At that moment, the ability to perform detailed operations is convenient and makes the development process agile. However, if a dozen different services are needed to set up a process, this also brings more complexity and costs. It is not likely that every customer or supplier with their own application will set up a detailed connection. SIVI’s agenda is to minimize costs in data exchange within the chain: therefore, the focus of the API framework is now on defining services that encompass an entire operation.
Post your comment on this topic.