Doerrfeld Bill - The API Lifecycle An Agile Process for Managing the Life of an API

From conception to deprecation, a Software-as-a-service (SaaS) is prone to constant evolution. Check the changelog for a high-volume platform like Dropbox for proof. In such logs, youll find bug fixes and updates, with the latest likely made within the past couple weeks.

The APIs that open these SaaS platforms are changing just as rapidly. So much so that API Changelog was created to notify users of API documentation changes (22 updates in the last 30 days in the case of the Dropbox API at the time of this writing). This ongoing iterative process is not only agile - its evolution is in symbiosis with many business factors that make up the organism that is the entire API lifecycle.

As the main function of web APIs are to be consumed by third party products, the API is a unique type of business offering. Its peculiar condition as both a software and internal asset makes its lifecycle special highly fueled by ongoing feedback and market validation. Compared with standard SaaS products that may have the power to change their UI or underlying construct, an APIs granular state can make it even more elusive.

AgileScrumcontemporary software development pushes toward quick releases and fluid responses. Response to change needs to be rapidly executed, leveraging user feedback, data, and statistics. These traits are becoming standard practice throughout the software realm. But is producing and maintaining an API the same or is it a different animal entirely?

Exactly how an API lifecycle looks depends on how the API functions as well as the business strategy at its core. We at Nordic APIs have boiled down the common API lifecycle to four main phases: Analysis, Development, Operations, and Retirement. As seen mapped out above, these elements work together and influence each-other. Once the cycle begins, open and simultaneous exchange between each phase will help a practitioner stabilize the API against internal and external factors. New information that arises within each stage may beckon a team to move forward or backward in the lifecycle, encouraging small revisions or large pivoting to reach end project goals. In this introductory chapter we will introduce the main phases of the cycle, each to be covered in depth in the following chapters to come.

This stage involves defining overall API business objectives. Firms should critically ask themselves whether or not an API is right for their particular situation. Some industries, such as social networks, thrive off APIs as a natural extension of their digital ecosystem. On the other hand, traditionally non-digital companies must be creative in handling how APIs extend their business model.

An API should either boost pre-existing operations or work toward overall company goals in some way. In our e-book Developing the API Mindset we defined 3 types of APIs:

• Private APIs streamline internal operations to decrease expenses.
• Partner APIs work specifically with partner organizations to expand a services reach to existing markets to generate revenue.
• Public APIs form new ecosystems by opening up a service to public access. If you intend to have a public release, obtain feedback while you perform analysis to gauge interest and determine access control.

Whatever the chosen API strategy is, its mission statement, usage projections, model for growth, marketing strategy, and estimated financial return should be clearly laid out before production begins. If youve done the necessary preparation, its time to move to the Development Stage.

With business proof and goals laid out, the next step is defining technical requirements and opportunities that are in cooperation with the API strategy. Development plans need to consider the following:

• what operations the API will execute
• management and hosting
• the methods and protocols used
• size and scalability
• access and security control
• usability and experience
• the development team among other factors

An intimate understanding of API processes will help form technical requirements. For example, knowing whether your API will open your firms data, or act as a content distribution channel can impact overall design.

In general, the API development stage should mimic the business objectives set forth within the Analysis phase. A methodical development phase considers design, construction and testing of API processes as well as security. Design your API with both human usability and machine standards in mind. It is a good idea at this point to also implement and evaluate API versioning strategies that will set the API in a good position for future updates.