Akshay Deshpande is the Chief Technology Officer at Quinnox, headquartered in Chicago. This article discusses how Quinnox has leveraged its extensive experience in API development, built tools and accelerators to help deliver your APIs faster, without causing security challenges, and by helping in governance.
5 Key Objectives which drive API development
There are five key objectives for why organizations look for API development.
- Customer experience – Because of the pandemic, there is a big shift towards reaching your customer directly. Customer experience is one of the key things where you want to reach out to your customer, build mobile applications ensure that you have constant engagement. Otherwise, you’re going to be obsolete with someone else trying to really disrupt you.
- Integrations with business partners – If you look at it, traditionally, all the organizations used to rely on b2b transactions. Most of these transactions used asynchronous protocols. These rely on your partner to be onboarded and to adhere to standards. Our experience tells us that any partner onboarding takes a minimum of four to six weeks.
- Data driven business management – Then comes the whole aspect of data driven business management. There’s a lot of available data. You are trying to build your entire business model based upon data and business processes.
- Mergers and acquisitions – You’re looking at organizations trying to pivot towards new business models through acquisitions.
- Business Growth – The last piece is growth, newer products and other perspectives.
Now, why are organizations doing this?
Organizations are looking at increasing your revenue. You are trying to come up with operational efficiencies to impact your bottom line. The biggest thing is the time to market. Traditional development timelines take too long and you are looking at newer digital technologies to be delivered in two- or four-week cycles, which puts a big pressure on organizations for building APIs.
In addition, you are trying to address aspects of compliance, where you’re either sending in the information to some of the regulatory authorities, and you want to make sure that you are providing consistent information to be compliant.
If implemented well, APIs can help you deliver your product faster by at least 40%.
But there are many challenges and pitfalls. The biggest concerns are scalability, and business downtime.
Challenges in API development
Scalability and business downtime
There are many legacy systems in organizations. When you expose these capabilities using APIs, which were never designed for the API transactions, you will start impacting the downtime, and having the right controls is one of the key aspects. Otherwise, you see challenges.
Inconsistent documentation and low developer experience
My experience as a practitioner tells me that most of the time, the documentation is where it started. You develop an API, and the documentation is created, but by the time the API goes live, the documentation becomes obsolete. Governance becomes a big challenge because you now have at least three different types of developers in API. The traditional ones use some middleware platform or ESB to build APIs. The new low-code, no-code guys or the citizen integrators are coming in. Then you are looking at the people who use code or programming languages to build these APIs. It is a big challenge to ensure consistency across these three ways to enforce the governance, and if you have too much governance, you always have ways in which people try to slip out of it, causing challenges.
Agility and adaptability
When information is required, someone builds the connection, and you have information that is plugged up. This gets done in a few days.
But no one is aware of the API. If the API changes or the platform gets updated, the information may not be processed. This results in the failure of the entire engine because the API has changed. You have traditional governance mechanisms that come into play, which cause challenges in the time taken for approval and ensuring that they get deployed.
Security vulnerability and data breaches
From our perspective, security needs to be addressed from the design side. If you do not address security from the design aspects, the security challenges grow exponentially by the time it’s deployed.
Many vulnerabilities get exposed across open-source libraries if you’re using open-source solutions. Many organizations use out-of-the-box policies. They are never tweaked and never adjusted to your organization, which causes challenges, insecurity, and data breaches.
Stretched Development Cycles
Stretched development cycles are a challenge.
API lifecycle in the backdrop of changing ecosystem
The stages in your lifecycle include discovery, design, develop, test, go-live, and support. There are different ways in which APIs are built. The knowledge of existing systems is a key to this. How do you have a mechanism to discover existing components so that they can help deliver these capabilities? Security challenges mean people predominantly use a firewall and IP filtering. Is this sufficient, or does this have to have some knowledge of the API contract to ensure you don’t have a leaky abstraction? The last piece is the growing channels of interaction; it’s no longer SOAP and REST. You are talking about additional ways people are trying to expose APIs, and this puts forth different challenges.
Three pitfalls to avoid and deliver value through APIs
- Lack of proper documentation and governance
- Inadequate testing
- Insufficient monitoring
Digital reference architecture is not a static document. It h
as to be something you engage and leverage in a way that people will keep leveraging. It should not become an artifact that sits in your content management portal. We believe in creating an interactive product decision tree that helps you pick the right product for your solution.
Discover – the ability to investigate what exists at the network layer and hardware layer. Identify legacy components and APIs or services in your ecosystem that will help deliver these capabilities.
Design – We are looking at a scenario where the developer experience is interactive. We build plugins on top of standard API developer portals, where your collaboration is all within the platform. You enforce governance on design patterns. So there is a standard reference kit of design patterns built as part of the platform. When someone tries to create an API request, it will try and identify details and say this is the pattern, giving you a reference implementation. So the only thing you need to do is implement the business logic associated with it.
Develop – We would look at converting and generating a scaffolding for a target platform of your choice. This is a platform-agnostic approach. You can take an existing solution and deploy this on top of any new platform.
One of the common things in any business process implemented in an API is the orchestration of multiple APIs. Error handling is an important aspect. Error handling frameworks help with error handling and also help with inconsistent tracing and monitoring.
Codeless test automation – Most people perform unit, system, integration, and performance testing and then roll out the APIs. Post-rollout, there is no validation.
We test such that a business process is simulated.
Go-live and Support – We provide an outage management tool and a control tower. The control tower provides end-to-end visibility of business transactions, technical errors, anomalies, security, and the ability to address all those things.
Reference Architecture Framework
This is a full-blown living platform with a repository of patterns, decision trees, and jumpstart kits with a reference implementation. It can be deployed on top of any API gateway and can hook up with multiple products.
We are working with one of North America’s biggest rural retailers. It was the start of the pandemic; people could not go to stores, impacting business. At the same time, they were also looking at an acquisition, which involved an additional set of products. Now, the challenge with all of these things was they were trying to create a consistent user experience. This needed consistent APIs to be developed and their legacy systems to be taken care of.
We led this entire digital transformation with a value stream-based approach, and modern application development, leveraging the APIs.
As a result of the discovery, we identified redundancies and eliminated this to come up with a simplified landscape and eliminated some of the legacy applications. An entire stack got eliminated, and as a result of this, there was simplification and a reduction in the subscription cost. We did multiple integrations with the SAS platforms and helped roll out some of the capabilities faster, specifically from a loyalty program and customer outreach perceptive.
An entire API mesh was deployed to address the aspects of scale. This was done such that, as traffic increased, you could address the aspects of increased scale. Mobile applications were coming in. without impacting the aspects of security. There was extensive API development with agile practices being done. We imparted training to the end users, and it also helped address the aspect of velocity.
With the new APIs with the automated testing framework, we were able to get this done in less than 12 weeks. So that’s the aspect of real benefits delivered through the APIs and an extensive set of accelerators to help drive the delivery of digital transformation capabilities.