How to apply agility to Apification?

Agile methodologies are here to stay. As mentioned in a previous note from Tecnova, the agile concept around software development projects is defined as “a formula for the development of projects that need flexibility, adapting to the needs of the client, and focused on results.”

Although not all companies have adopted these practices, they are gradually being applied to new developments, such as apification, or development of APIs. This does not mean merely applying practices such as Scrum to the development of Web Services, but the creation of frameworks and supporting technologies specially designed for the creation and governance of small and large-scale APIs.

In the past APIs were developed as static elements that were attempted not to change or evolve over time. This has changed as there are more and more API consumers such as IOT devices, mobile devices, and digital end-user service channels. This makes APIs a living entity that grows and evolves constantly.

For the development of APIs, several disciplines are required, which can be addressed with different practices and technologies. These disciplines must be considered within the project and they include design, construction, testing, delivery and monitoring in production, among others.

When an organization reaches a critical mass of APIs, the traditional cascade development model becomes obsolete not only because it does not allow for proper time to market, but because the lifecycle of an API transcends its implementation. An API is monitored, modified, versioned, and published multiple times over its lifetime, ranging from static software parts to ever-evolving pieces of software. This means that traditional lifecycles are not presented as the most suitable or convenient options.

How to apply agile practices for the lifecycle APIs?

At Tecnova we have devised a Scrum-based life model that combines Software development disciplines with Apification disciplines to bring to life an agile model of apification adjusted to the reality of the national industry.

This model can be applied completely or partially according to the maturity level of our customers and their needs in relation to the creation and governance of APIs.

The four main stages of our life cycle are:

  1. 1. Devise: This stage groups the organization’s knowledge leveling activities in relation to what an API is, the requirement discovery activities that APIs and the modeling of service contracts that satisfy those service contracts Requirements.
  2. Design: This stage solves the logical design and documentation needs of APIs, with special emphasis on self-consultation documentation using Developer Portal-like tools.
  3. Create: API creation encapsulates typical software construction activities at a separate stage. This allows coding tasks to be abstracted from the rest of the API lifecycle by allowing full or partial application of the lifecycle. For example, a strategic can incorporate the devise and Design stages while an operational service can consist of Creation and Control. In addition, having development activities contained in one stage, and operating activities at another, facilitates the adoption of DevOps practices.
  4. Control: The creation stage solves the needs of API monitoring, maintenance and deprecation or removal of APIs that are not required. In an environment where significant volumes of APIs exist, controlled removal of unused APIs can result in significant savings in infrastructure resources.

The different phases of API development “create a truly iterative and incremental cycle that allows you to be more efficient especially when deploying important volumes of APIs.” But this is not only the benefit of the API user, but also the developer itself, since the agile API development model can be comprehensively supported by API management tools.

Tecnova has acquired a commitment to combine the best methodological and technological practices to live up to the paradigm shift that the Apification represents and to accompany our customers in its adoption.