API is not a BUZZ word anymore

Share on email
Share on linkedin
Share on xing
Share on facebook
Share on whatsapp
Share on twitter

API is not a BUZZ word anymore. In the domain of information technology and agile development methodology, application programming interfaces (APIs) are one of the key building blocks supporting interoperability and design modularity. APIs, an architectural technique as old as computer science, can help improve the way systems and solutions exchange information, invoke business logic, and execute transactions. As you can see in below picture Data from simple to complex systems can be extracted and provided to simple to complex systems. APIs are playing a critical role in systems architecture, innovation, modernization, and in the burgeoning API economy.
API graphic

An organization’s assets were measured in various ways and today it is measured with their API’s. Data is the crucial entity and analytics build/derived on top of it defines/drives the business. Sooner or later every organization will realize this. The sooner you get this, the faster you can grow.
What accounts for such growth? Increasingly, APIs are becoming a strategic mandate. Reuse and recycle is the driving factor in any sector today. If every company is a technology company, then the idea that technology assets should be built for reuse seems intuitive. Reuse compounds return on technology investments in ways that couldn’t be imagined and this paves way for new horizons.
Every organization looking to grow requires new capabilities to manage the exchange of what is essentially an encapsulation of intellectual property. These new capabilities also make it possible to support the flow of information and operations across organizational boundaries, and to manage the discovery, usage, and servicing of API assets. Collectively, the strategic intent of APIs and this underlying enabling response represent the API imperative trend.
API management will go through a life cycle, the below-listed order might not be a thumb rule for all, but all these will be discussed while developing an API, these provide context for the overall marketplace:

1. Design

Key principles and points to be considered while designing APIs are:
Make them accessible to different classes of developers, consumers, and partners. Design and develop security policies, usage policies, approval workflows, authenticated subscription model, and selective access to data and services. API Manager solution should facilitate the creation of APIs that expose the functionality of backend systems and services cite the need to serve the different sections of the enterprise.
It needs to address each constituency or user group engaged in building and running an API. These include API Architects / Developers, Security Architects, IT Operations and Business Analysts (API marketers). A platform needs to be extensible. There needs to be a way to build on top of it.
Enterprise API Management must include the entire Enterprise, not just the techies in IT. The solution must focus on both IT novice and the business owner of the API program.
Tech teams must be partnered with business teams who have a vested interest – and will be managing a big part of – the API resources and platform.


2. Document

To make APIs successful and accessible, create thorough documentation with sample input/output and provide the ability to test the APIs on the platform itself. This makes life easy for both the provider and consumer, as everything is documented and made available to everyone.
With every release, documentation must be updated and communicated to all stakeholders, so they know what new features and functionalities are added to the API’s. Keeping them updated and notified increases the use of API’s.
Whenever you are going to develop API’s, have a process for bringing the heavy consumers into the design and development process. It would not require doing everything they request, but make the process inclusive as they are the future consumers. This will also give more clarity and visibility to the consumer.


3. Analytics

Once the API’s are made available to consumers, it is time to think about the collection and processing of all the statistics associated with the use of the API, with an eye toward supporting and encouraging effective usage and educating more teams/departments to start using the API’s instead of developing solutions in silo’s.
As you keep adding more APIs to your repository significant efforts must be made to define and generate data analytics to make this a continuous process.
Analytics should address below groups/categories:

  • API provider
    The provider would like to get real-time insights into how the APIs are being used by various factors like date, location, application, and platform type using dashboards. The provider would like the ability to create and manage custom dashboards and charts that meet their unique needs. With the data collected, users can perform trend analysis to understand usage patterns and preempt issues in the future.
  • API consumer
    The consumers should be provided with a dashboard of their own, this will improve engagement and satisfaction for all API consumers as it provides them visibility into API metrics such as: API performance, usage, and error rates pertaining to the API calls made by the application.
  • Reporting
    End of the day everyone would like to see/generate a report that will give an insight into how things are going. Be it provider or consumer; they would love to see API reports with a single view. Through API reports, providers can identify who is consuming API, and how it is being used.

The analytics module should be designed in a way that it can easily be extended and improved as the usage of the API’s grow.

4. Access
Access to API’s must be controlled and later audited. This can be done as a subscription model or access by invite. In either of the scenarios, the consumer must be authenticated before providing access to the API’s. Certain business rules must be applied around API’s for the consumer; like limiting the number of calls in a set time, setting expiry for the access, access renewal process, enabling 2-factor authentications and many more such rules must be defined.
API’s access should be made seamless and simple, also support for the various architectures used by the enterprise, whether public cloud, private cloud, on-premise, or a hybrid of several of these.

5. Availability
API’s should be developed in a way that will lead them to high uptime, easy scalability, and redundancy that handles traffic spikes works around temporary failures in the enterprise backend and fails gracefully in the event of a backend outage. Having a system that satisfies all these will make the API’s availability a high priority.
Business Benefits
Using an API-led development approach to deliver IT projects where business needs change or grow rapidly, will enable you to not only deliver on time and on budget with your first projects, but you are building reusable assets that will save your company time and money. Build an infrastructure which is designed for change with built-in visibility, compliance, governance and, most importantly meet the needs of the business, which is a long-term necessity.
It enables your team to move fast on your first project, but then actually accelerate further from your second project onwards, having reusable assets and a built-up organizational capability; API-led connectivity liberates resources, allowing you to innovate and to move quickly.
Our customers found that the increase in agility and speed provided by API-led connectivity steered to delivering projects much faster and increased team productivity multifold, compared to legacy or homegrown integration solutions.