API economy at present revolves around API hosting and management. The pre-requisite for API management, obviously, is to have APIs (Application Programming Interface) on the existing/new systems within the businesses. It is imperative to arrive at a methodology for designing, developing or extracting; and exposing such APIs around existing legacy systems. Extraction of APIs (API-fication) can be direct: a completely new application or platform leverages the legacy application for supplying to the APIs; and indirect: the legacy application hosts the API within itself.
How to qualify legacy activities
A legacy application is functionality-oriented, it does not necessarily have an API system around it. The most challenging activity to get APIs out of it is qualification of the functions, starting with categorization of activities:
- Routing: The logic that routes messages from one subsystem to another based on rules (e.g.: workflows)
- Decorative: Attach additional metadata and data elements to the primary message (e.g.: authentication tokens)
- Consumables: Marshalling data elements in their entirety (e.g.: product catalog)
- Helpers: Protocol translations, format conversions, data migrations, context attachment services and token systems
- Projectors: Amplifying and delegating activities such as message multiplications and routing to different orchestrated receivers, hub and spoke activities
- Validations: Message validations, business validations against a database, etc
- Interim IO: CRUD (create, read, update, delete) operations on datastore
The categorization needs definitions of complexity levels that are useful in downstream activities of estimations, scheduling and implementation of APIs.
How to rank legacy activities
Upon identification of the functions (activities), the next logical step is to rank them using specific parameters. Since the API ecosystem is pivotal for developers, these rankings orient towards developer benefits:
- Financial impact of the underlying activity for developers
- Financial impact of the underlying activity for the business that hosts the APIs
- Impact by creating direct or indirect APIs
- Helper impact
- Performance and scaling impact
- Maintenance impact
- Living but near-death status of the activity for developers to consider for future upgrade
- Technology reusability impact of the implementation of activity
By design, this ranking mechanism has ‘financial viability’ as the key consideration, to address ‘alternate revenue streams’. The manifestation of financial viability are API-fication scoring models (See figure 1, 2 & 3). The modeller is customizable.