Towards a group central API
Possibly is a good idea to ask ourselves why a company like FEXCO, a well known and market consolidated Fintech needs a centralized API. It is not trivial that in the current era of digital transformation, where is obvious that working with software is mandatory no matter what your business or market area is.
That dynamic illustrates a current reality: Regardless of industry your company is now a software company, and pretending that it’s not spells serious peril. With hardware and software growing more capable at exponential rates, data of all sorts are increasingly getting into the hands of ordinary people—competitors, employees and, especially, customers. Extraordinarily sophisticated tools of measurement, analysis and communication allow these empowered hordes to evaluate, process and distribute the data, along with their opinions about it. Ordinary people increasingly have tools that match and in some cases exceed the sophistication of those used inside the companies that serve them.
APIs play a critical role in enabling inter-operability, improving efficiency, reducing costs and communicating with partners and customers independently on what is the focus of the business.
APIs are a commonly chosen option in markets and specifically in Financials, that actually counts on the second bigger presence in the APIs landscape.
The most common business areas for FEXCO (DCC, Bank Transfers, Outsourcing services. Retail FX, Asset Finance, etc.) can take advantage of services provided by a central API: order management, product inventory, e-commerce, internal processes to any kind of devices and communication with partners, for instance. It is under these assumptions when a centralized API meets an outstanding role in order to avoid the costly dispersion of services, lack of performance and an excess of investment and final cost for software services.
That means about our objectives. To turn FEXCO into an API-centric company counting on these main goals:
- Dramatic reduction of costs for software services and ownership of software products.
- Accelerate the creation of software products decreasing the general cost and reducing the Time To Market factor.
- Increase the Return of Investment in Innovation areas (by concentrating the Innovation budgets in the same areas and not dispersing across companies, vendors and external products).
- Increase the Vertical Integration patterns in FEXCO, with a growing level of ownership and expertise in key areas and avoiding externalization.
- Bring FEXCO to the next phase regarding Quality, Speed and cutting the edge technology in order to make possible new products and services.
What is an API-Centric approach?
It is not an easy question. Traditionally the software and technological actors consider as a API a mono-protocol HTTP REST architecture based platform. This traditional kind of API is 100% web oriented and the resultant implementations met the purpose they were designed. Are they useful enough nowadays?
Obviously not anymore. The evolution of software technologies, the IoT principles, the change to Cloud Computing and the dramatic improvement of telecommunications and networks have made possible the construction of multi-protocol APIs. This type of API, more advanced and versatile than simple HTTP-based ones, can support much more types of clients, they can be consumed in a bigger scale and at the same time they offer much more services and technical features. Definitely, Multi-Protocol API is a key concept here.
Besides, as we said above the improvements of communications and the cost for Cloud Computing have changed things. We have faster, cheaper and more capable networks, flexible Cloud IT, etc. but at the same time we need to save resources in Cloud, looking for the shortest way to perform operations. The result is, we need to move computing load to other layers in order to reduce the general level of needed computing and the latency due to data transfer across the network.
So, we have here several protocols to server to different purposes:
- HTTP: Traditional web endpoints using strict REST architecture.
- gRPC: Streaming, keep in sync data structures, provide big files and data as they are being retrieved.
- MQTT: Telemetries from devices and networks.
- AMQP: Support for Enterprise Integration components via asynchronous messaging (queues, topics).
And why multi-protocol API? Because we take advantage of new network architectures. The Internet of Things computing world brought a concept to us again (it is not new!) but renewed and improved. This concept is about Edge and Fog computing. What does it mean? Well, we can assume that if we call Cloud to our central API services and Edge to the computing area at the edge of the network, we can call as Fog to the layer in the middle. According to the architecture, the Fog layer access to the Cloud (the central API) and acts as the endpoint for the Edge layer.
Multiple protocols and computing levels are key factors in modern APIs
The benefits of this architectural approach is obvious: a substantial part of the computing load can be moved out from the Cloud to the Fog and Edge, taking advantage of the computing power of devices in these layers and saving money from Cloud resources. It has been really successful in the IoT systems and it is absolutely applicable to other types of architectures, for instance focused on providing a much better level of service specially to branches, retail business, remote places with not ideal connectivity, banking, etc.
From a practical point of view a bunch of heterogeneous clients consume the API services (Cloud) in a seamless way. Federated services provide full control and visibility of security, access (e.g. Single Sign On), usage and frequency of consumers and resources, control of access rates, etc. A full control of how the API is being consumed. But using several protocols we are not limited to web clients using HTTP. The multi-protocol API allows you to integrate all kind of traffic including ATMs, Automatic Points of Sales, etc. Same for mobile devices that offer a vast field of data to be exploited and used in order to improve marketing campaigns, Know Your Customer services, Anti-Fraud features, and cyber-security levels in general. That’s why the Cloud/Edge/Fog approach is so successful.
From an internal point of view the API is composed mainly by two big blocks. One of them provides the Delivery Model to the software products. That means that it provides as well all the infrastructure the product needs to work in Continuous Delivery/Deployment pipelines. The other one provides what is usually called SDLC (standing for Software Development Life-cycle) but not only. It provides the computing infrastructure, the prototypes to build new components, full scalable distributed data, architectural patterns and integration.
Well, we are proud to introduce to you these two guys:
- Delivery Platform (the Delivery Model is key for the life-cycle of products mainly based on automated testing and processes, assuring the expected levels of Automation, Quality and Agility and provide the IT in automatic processes)
- Computing Platform (software components -the API producer- using parallel computing servers and real-time asynchronous communications, common fully scalable multi-region data and much more)
Delivery and Computing are the pillar platforms on which the API is based
Both are really related each other being needed and complementary parts of the same system.
The API-centric approach speeds up the Automation
Automation is the key for success. It reduces the cost for human resources (QA testing), it provides IT in a flexible way and performs the test (functional and not functional) the product needs in order to guarantee to release versions to Live several times every day.
How does work an API-centric corporation?
It is really straightforward. The API-centric approach consists of a safe, multi-protocol, highly scalable and accessible set of services able to be consumed ing different ways or protocols. This is the producer part. Now, we need consumers: Client components that composes logic consuming the services available in the central API or software in devices at the edge of the network consuming resources published by other software components in the Fog. We can define different types of consumers according to functions, purpose, protocols, etc:
- Web clients. Browser-based clients, web applications for public or private users.
- Desktop applications.
- Mobile applications.
- Devices. ATMs, Automatic point of Sales, etc.
- REST consumers. Other organizations able to connect to the HTTP services in the API.
- Streaming clients. Consumers that need synchronization or Real-Time data.
- Messaging client. Organizational consumers integrated via asynchronous messaging.
- Fog components. Usually called Access Controllers.
So, this is the paradigm: producers and consumers. The API-centric approach enforces the quality, performance, security and SLA levels that the organization need and implement it globally in a seamless way.
A Bigger ROI for Innovation?
Well, this is always a dangerous assertion but honestly, if you get a single point of control, supervision and audit for the target of your Innovation budget you’ll get much better results (ROI) than investing your scarce resources in many small departments, sections and companies with different approaches and understanding about what Innovation actually is.
By centralizing the construction of the systems that compose the API the Return of investment is much bigger than maintaining multiple heterogeneous smaller systems.
With the API-centric approach the investment on Innovation has a direct effect and impact on the quality, coverage of services and performance of the services your provide, always well-controlled and supervised by an homogeneous architectural team. Same patterns, same places, better usage of the money.
- Full Automation (No-Human pattern)
- Documentation & Automation
- Scale smart
- Patterns for Automated Integration of new products
- Federated services (Do-It-Once-Use-Everywhere pattern)
We’ll develop these bullet points in future posts, going further in the analysis of different types of services and expected services to provide via the API-centric approach.