API CatalogAPI ManagementAPI Product LifecycleAPI Product ManagementAPI Product RuntimeAPI Product StrategyAPI ProductsBiModal: Aligning Mode 1 + Agile RolesDevOpsEnterprise Application Integrationignite

API Lifecycle: Run Stage (Part 4 of 4)

Hello again, and welcome to the final post in our series on the ignite API Product Management Lifecycle, starring our very unique ignite platform. If you’re visiting for the first time at the Run stage, we encourage you to check out the other lifecycle stages to understand the events typically leading up to Run — but hey, we’re made for an Agile workspace, so feel free to jump in wherever you see fit.

Plan — Ideate, Plan Product, or See Progress

Design — Create New or Extend an Existing API

Build — Generate Artifacts

Run — Management and Execution

ignite Runtime

The way we see it, runtime has two parts: 1. Management and 2. Execution. There’s no particular order here, although they do flow nicely from one area to the next and back into the other stages.

While it’s hard to find the perfect tool that comes with all of the features you need, we find that a combination of open source components checks all of the boxes for a more robust option than any existing API runtime management in place, so we’ve integrated these options into our platform for all the functionality you could ever want, and then some.

ignite Runtime Combines the Best of Open Source, Extends Design Maturity, & Protects Against Vendor Lock-In

1. Management

As soon as you hit deploy, whether to runtime or testing environment, your API is in the Run phase. Are you prepared for what comes next? Did you make us proud and put the crux of your efforts into design-time governance, so there were hardly any “tweaks” for your developers to work out?

And once you deployed your APIs, what then?

API Product Management questions to ask:

  • What is the success criteria of the API Product?
  • Who owns the APIs?
  • How are you going to keep that success criteria aligned to the business model?
  • What is the incremental ROI on this API Product?
  • Who is consuming your API Product? Are they the intended customers?
  • Who manages your third-party APIs? (To avoid surprise bills, this is highly encouraged.)
  • How will this API Product be discovered internally?
  • How long between updates, and how will you keep track of them?
  • What parts of the API need to be scaled?
  • When will you know which products to scale out, and which to retire? (You can’t measure an API on its calls alone, you know.)

For some, the roadmap gets… foggy here. 

stephen king's movie the mist
Fantastic movie, btw.

Design Upstream for the Smoothest API Runtime

If you’ve captured all of the right data fields upstream, your API metadata is thorough and comprehensive. There’s no break between the design (Swagger/OpenAPI) and all of its info.

You’re including the NFRs, SLAs, and context mappings to the associated domains within that metadata, so at any point in the API lifecycle, every role has access to the most up-to-date business decisions, and use cases behind every implementation.

No more emails, spreadsheets, or version control bottlenecks.

When these details are kept right within the actual API and mapped to the associated domains, your information is accessible for your teams when they need it. No bottlenecks caused by the loss of the latest version of a spreadsheet from another department, no waiting patiently for that email. No teams recreating an API that already exists, simply because someone wasn’t using the language of the business.

Now you’re managing the digital like physical — or, can we say proper digital yet? — so you have constant access to your APIs’ business success criteria, owners, change management, contracts, policies, etc.

The modern enterprise must be digital, and that means accessible, flexible, well-governed, and — speedy.

API Management

ignite has a unique approach to applying policies as it leverages the code generation features of the Build stage to allow policies to be applied to traditional API management layers, API code, or both.

By allowing policies to be automatically baked into code as well as management layers, much higher quality results are possible.

So whereas policies such as caching, throttling and load balancing make sense to apply only to runtime management, beit your existing or our connection to open source Kong, authorization may be best applied to both the API management layer AND to the API code – providing superior multi-layered security, rather than relying on a single point, which helps to protect against internal threats which can bypass the proxy.

This equally applies to redaction and trimming polices where sensitive information is either always masked or not sent over the internal networks if it will simply be trimmed out by a proxy policy – significantly increasing the level security with no extra work in API design.

Our Professional Services provide a consulting service to ensure that customers take advantage of what ignite offers, and tailor it to use familiar terminology and processes to aid adoption throughout the enterprise.

Runtime Dashboards: Design-Focused Metrics

Every company has its idiosyncracies. Each industry is different (e.g., banking and insurance customers will often request unique view controls per team for security compliance reasons, and healthcare business requirements change drastically across states). Likewise, every business model, its own set of policies, so our runtime dashboards are specially built to each company’s specific needs.

These dashboards are the first point of contact, there to help people see quickly if there’s a problem (or not). They are simplified and displayed in the context of the design, so it’s clear how the design is performing. So your teams can quickly catch underperformance, lagging load times, throttling glitches and bugs far before they show up in stacks of support tickets, and long before they affect sales. A few of ignite's dashboard reporting viewsIn order to measure success and determine future initiatives of your API Products, you need to be able to compare actual performance to the policies you set in the Plan stage around your Service Level Agreements (SLAs) and NonFunctional Requirements (NFRs).

Often, as results come in, updates are required, as business needs must be met. Again, ignite allows these changes to be made upstream, in design. So you’re able to keep track of those business-led changes, when they were made, and why.

You’re able to have version control, change management, and data lineage through baked-in design-time governance that doesn’t slow you down — in fact, it speeds your pace.

2. Execution

ignite offers a different approach than other vendors, as it goes beyond simply providing a microgateway, offering instead a number of options for implementing and running APIs that ensure customers are innovating and using best-of-breed technology in a rapidly evolving marketplace.

For example, Kong is used for traffic management, front-end security and URL mapping to microservice instances. Microservices can be deployed either using lightweight frameworks wrapped in Docker images or using serverless APIs (either from AWS and Bluemix, or using offerings such as OpenWhisk, Fission or IronFunctions).

OpenSource microgateways, such as IBM’s API microgateway, can be used (either/instead of/or in partnership with Kong) for validation of messages, payload enrichment and microservice code execution. Kubernetes and Docker is used to provide a highly available, reliable, and scalable environment.

ignite protects API providers from the details of the infrastructure used, allowing them to concentrate on API design and Digital Products.

DevOps Dashboards: Logging and Monitoring

Our implementation-agnostic approach allows the ignite DevOps dashboard to provide a consistent 360-degree view across all zones, showing clearly what state API designs are in, where they’re deployed and how they’re performing, all in real-time. A lot of our customers want to take that logging and monitoring and pump it alongside the design-time info so that the expected Key Performance Indicators are right next to the actual performing stats.

In this way, our runtime has a unique connection to design so that if anything seems off — say a service is maxed out on calls and needs a throttling adjustment — it is easily possible to make changes upstream with proper change management and logging. Those changes can be pushed directly out into whichever runtime execution and management you’d like to integrate with, whether it be our open source components or your existing, without the worry of breaking anything in production.

 

Sandbox Testing

For most companies, with most API Management solutions, there’s a great deal of money lost in the testing stage. There are usually three culprits here.

1. Too Much “Tweaking”

Time and money is wasted when developers have to “tweak” the solution when, in theory if it’s well-designed it shouldn’t need much tweaking. This is why we put so much emphasis on design-first, and why our platform self-serviceable, so that when changes do need to be made, you don’t have to be in IT to understand how to make them.

2. Cost

Many testing sites charge per call, which can cost tens of thousands of dollars. With a heavy production schedule, more experiences to build out, and several iterations to test for each one, this can get out of hand quickly.

Even if production costs are considered good value because each API call is generating revenue (though it’s unlikely to be quite that clear-cut) any business wants to keep operating costs as low as possible without sacrificing quality… testing costs fall into the came category of wanting to have quality with as little cost as possible.

So using open-source testing tools, combining with open-source execution environments (such as the ignite Runtime with Kubernetes) gives a fixed low cost — avoiding extra licence fees for testing and just paying for any extra execution capacity.

3. Dealing with Bad Data

And three, bad statistics keep poorly performing products running longer. When you can read the data in real-time, you can see what is working, what isn’t, pull the plug on the duds, and scale out your successful products.

But to get good data, you must have good management. It all starts by treating your digital products like physical. Now, where have we heard that before?

Vendor-Agnostic & Future-Proof

The market’s changing fast. There used to be a new “best model” every year; now experts are rewriting the model every month. This is why we chose to offer an affordable testing solution that also builds towards your long-term strategy, so you can quickly determine which API Products are worth scaling and which to retire, or adapt — after all, we provide that design-time flexibility.

Our platform works with the technologies of the future, meaning no matter the vendor, you’re ready to plug in and go — so when stakeholders are beating at your door demanding you launch a new API Product that lets customers shop an EU market from LA through VR goggles, you can say “OK. …how’s next week?”

Integration. So much integration.

Our Run phase’s module increases the breadth of the connection from ignite into build-time and runtime elements of the service lifecycle. This includes the ability to extend impact analysis into the runtime, so release managers can better manage rolling out new API and service releases.

  • Work Management. Task Management Integration — ignite connects ignite to JIRA and multiple runtime environments, API Management, ESB, Microservice containers and more for 360 degree governance.
  • Runtime Managers. We integrate with all of the leading runtime managers and gateways you use (or use our own) to send reporting straight back to your team. Closed-loop service governance.
  • Configuration Management. Integrates with configuration management, application lifecycle management, and build automation tools to support DevOps capabilities for continuous integration and deployment.

The days of data-at-rest may be gone, but their remnants continue to prove useful — we see some of the most intelligent and comprehensive business glossaries from clients who came from SOA and MDM initiatives.

For many of our customers, our platform provides a chance to make something of the great effort and cost put into yesterday’s services (SOA), by allowing them to import legacy assets and transform them into simpler services (RESTful) that work seamlessly with today’s middleware models.

These big-brain efforts, like defining resources and adopting enterprise-wide naming conventions in the language of the business, are the tactics that can save your company unbound time, money, and energy when you get to runtime and beyond.

 

The Most Comprehensive API Lifecycle

And that, my friends, sums up the final stage of the most comprehensive lifecycle on the market. We hope you’ve enjoyed the API Product Management journey as much as we have. With our latest release, ignite now provides the most comprehensive API management lifecycle on the market. 

Including a robust offering along every stage, from the import of legacy, ideation, planning of the definition, designing the specification, PI planning and implementation, to testing, deploying, updates, and dashboard reporting, right back to plan.

 

For more on ignite Agile development and runtime, visit our Developer Teams or DevOps pages.

Tags

Related Articles

Check Also

Close
Close