Why is IT not creating API’s, they shout out. My head was spinning around and deep in my mind I found Application Programming Interface. Like a file, message queue, swift or a service, is that what they want?
No, they want an implementation of a restful microservice, deployed as an Open API interface on an API Gateway. But how did we end up here?
Architecture follows the change of the world. Most companies want to earn more money, be more effective, stay ahead of the future. Like the small dinosaurs. The small dinosaurs were eaten up by the big dinosaurs. The small ones started to climb, up in the trees. The big ones couldn’t reach them up there but it was freezing, they were cold. Feathers started to grow out of their skin and they stayed warm and cozy but some of them fell down. The big dinosaurs ate them up and the small ones still had problems of survival. Until the day they stretched their arms out and flew. The question is, when did we in the evolution of IT architecture start to fly? Are we still sitting up in the trees looking down?
Walking from terminal application, web-based application and fat clients to mobile apps, causes us to create smaller services to microservices. But forget about micro. I will try to explain.The next picture describes the Service Oriented Architecture (SOA). The SOA service has all logic on how to create a fund account connected to a cash account and a depot. The service is calling other SOA services in a different system.
What happens if the call to the Fund mgmt. system takes a long time to respond? The original call will timeout. The problem now is that the SOA service cannot rollback the calls to the Account mgmt. system and Depot mgmt. system. We now have a depot and a cash account created, but no fund account. The user of the web application did not get any fund accounts and as a result – unable to trade in funds.
SOA Service is often deployed on an Enterprise Service Bus. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. But some developers feel it is complicated to deploy to a service bus. In the ESB, all the functions included in the service is available. Since the SOA service is dependent of other services, it needs to be tested with all of them and they also need to be deployed.
The more changes that are made to an SOA service, the more complex it becomes. It needs to handle more failure scenarios the more systems it is integrated with. Since the delivery cycles of changes and extensions are longer, the maintenance cost of the system becomes very high.
All these problems lead to a more fragile system that cannot adapt to unpredictable changes. This leads to a volatile system, leading to either total system failure or a costly replacement with a brand new enterprise system built from scratch as a result.
Next picture describes a microservice oriented design. In this case it’s the Mobile App that handle the logic and the control of the process. Here you can deploy your service or API on an API Gateway. The difference from an ESB is that you deploy an Open API contract. It means that the consumer of the Open API only can use methods that is written in the Open API contract. The microservice can have for example four methods:
- GET /Accounts (show a list of accounts)
- POST /Accounts (create accounts)
- PUT /Accounts/{id} (update a specific account)
- DELETE /Accounts/{id} (delete a specific account)
If, for instance, an external consumer is allowed to only use GET/Accounts as method, then that is the only method that is described and deployed on the API Gateway in the Open API contract. You can still publish all the methods of the Open API contract for internal or other designated consumers. Open API Specification is formerly known as Swagger and it serves the purpose of defining and describing REST APIs. One benefit of microservices is that it allows you to develop, change, test and deploy services independently of other microservices.
One of the most challenging aspects of meeting the requirements for scalability and fault tolerance is data management:
- No microservice is allowed to directly access or manipulate data owned by another microservice
- Microservices are inevitably going to be dependent on data that is owned by another microservice, and have the need to manipulate data owned by other microservices
- Data replication and event based messaging are popular solutions to these problems but introduce a new set of challenges
If you use Design first instead of Code first, you can create an Open API contract before developing the microservice. That is nice, because the external developer that wants to consume the Open API can start, even if the microservice isn’t implemented. Next picture illustrates exactly that. The Open API contract will then be the API requirement that the consumer of the Open API needs.
The consumer of the Open API and the developer of the Open API can work in parallel. The Open API contract is deployed in the Sandbox. But banks test data for the external consumer is a problem. They are not used to or not allowed to expose test data in the production environment. The production environment is the only environment that can be reached by external consumers. There are some holes, that we don’t talk about, of course. Nowadays every bank has an external developer portal where they show all API’s that a developer can consume.
Open Banking
So what is Open Banking? The financial authority said to the bank, you need to share your costumer data. Any company, that are certified by the financial authority, will be allowed to consume the information about all customer accounts and payments stored in your bank. With the consent of the customer, of course.
What the Open Banking era needs is mocked data in the cloud. Faked customers, accounts and payments. Every Bank is struggling today to create this mocked data somewhere safe in the production environment. Since they follow the psd2 regulation. They also need to create dynamic test data.
Antifragile Architecture and complex responsive process
Antifragile means the ability to increase the capability of the system so that it becomes stronger or more robust when subjected to volatility, shocks, stressors and errors either from your system or other systems. In other words, what does not kill you makes you stronger or antifragile.
“Complex responsive processes is one of several views of how complex organization becomes what it becomes”.
The dominant alternative view is the systemic process view, see Complex responsive processes.
All architecture follows the knowledge and the organization setup of the people in it. The SOA reflects the hierarchy of the organization.
If we would reflect the organization as a microservice design pattern, with independent information flow, it would reflect a flat organization. Antifragile microservices is a natural design approach for creating antifragile systems that assumes all parts of a system will fail.
The system needs to handle different types of failures and assume that all parts will fail. Therefore, each service can be temporarily unavailable to consumers and system architecture needs to minimize the impact of partial outages of any service system.
If every Open Bank would have these APIs, developers could create apps that would fetch data from all open banks that the customer is involved with. The customer would then be able to play around with their own bank data. Remember Open Banking is for the customer.
- Investment Portfolio app
- Performance Attribution app
- Fund Performance diagram app
- Financial Order analytics app (telling what trade you should place)
- Risk analysis app
- CRM app
- Etc
What can we say about the future?
