This is part 1 of 4 in our series on the API Lifecycle. To read about the other stages of the developer cycle, visit:
- The Plan Stage with ignite (1 of 4)
- The Design Stage with ignite (2 of 4)
- The Build Stage with ignite (3 of 4)
- The Run Stage with ignite (4 of 4)
A New Spin on the Not-so-old API Lifecycle
There are tons of informative API Lifecycle guides out there, and they’re all a bit different. We believe in a design-first approach, because it allows you to speed through the other phases (like Build and Run) while keeping human error to a minimum. Some would even say that a well-designed service needs no tweaking!
Of course, the API lifecycle is different for everyone, depending on the end goal. It does take time to build out your modular API Catalog, and the need to Build a Thing Now often takes precedence over such governance. But once you get to that goal state… whew. There’s nothing like it. 10x faster time to delivery. APIs built out, end-to-end, in 2 weeks. Developers getting months of their lives back.
When it comes to choosing the right API strategy, it all goes back to business alignment and which route is right for you. For many of the API Management companies our customers deploy to, the lifecycle goes something like this:
Plan > Build > Operate > Maintain
Example 1: Nordic API Lifecycle
- Analysis — determine strategy
- Development — prepare and construct
- Operations — foster user base, fix and refix
- Retirement — major versioning and deprecation
Example 2: 3scale API Lifecycle
So how is the digitalML API lifecycle different?
Many guides found online come from API Management companies, and as an API Product Management platform, ours puts a much greater emphasis on design-first. Why? Because the goal state for our customers is a catalog of APIs that allows them to expose and share their strategic business functions, achieve business-led digital innovation, and reach high-quality modernization with automation and scale — and that takes quick and early alignment between business and IT.
We help with this by inviting business to get involved in the early stages of our self-servicable lifecycle, and by keeping a business glossary and domain-based information model mapped to the very building blocks you’re building with, so that the right data is available and captured along every point of the lifecycle (there are lots of other features, but we’ll address those later).
This series covers an overview of the 4 API lifecycle stages as per customers of our ignite platform. It’s a complex tool with tons of features, but we’ll run through the highlights for now. From this point forward, the post will cover the first stage of the API Product Management lifecycle, Plan.
Planning with ignite
So you want to make an API. We’re going to assume you’ve already gone through our Starter Pack process (covered in last week’s post), and uploaded all of your existing services, data, and mappings into our platform so that you can get the high-level view of what you have and need. You’ve thrown some of your stuff away, and we’ve combed 600 legacy items down to 400 ready-to-go units. It was all good work at one point, but maybe some of it was out of date, or perhaps you have a Short-Cut Steve on your team and several projects were riddled with duplication. Duplicate code leads to duplicate bugs, as they say.
So now you’re looking out across your empire, and you discover a few gaps. Hundreds of Business Capability APIs across a missing domain or two that couldn’t keep up with data governance, API Products that one model Digital Product could pass to other lines, or a handful of business ideas, real money-makers, that never made the production list. Well, those days are over — you have an API catalog now, and a Wishlist to boot, so let’s use ’em.
The 2,000 ft view
Because it’s closer than the 40,000 ft view. Within ignite, you are able to:
- Access Browse, List, Status, Business Capability, Service, & Stakeholder Catalog Views — Your API Catalog view is customizable so that you’re always giving the right information to the party concerned. EAs love the top-down Browse view, whereas business prefers to search by business capability.
- Search, Discover, and Innovate — Where business and IT meet over one innovation lab-esque platform. View all your existing APIs at their respective levels, and recombine them in new and exciting ways.
- Prioritize and Collaborate — Determine the exact amount of time it takes to perform a task. Syncs up perfectly with Jira, Trello, whatever tracking tool you’re on, so that the team knows where to allot their focus at any given time.
- API Product Management — Dashboard view shows you everything that you need to see — all of your microservices in one place keeps you in shape for business-aligned decision making.
- Compare Expected vs. Actual KPIs — Take control of your APIs now that your core functions are digitized and turned into data-in-motion. If something is wrong, fix it before the hurdles ever affect sales.
But let’s dive a little deeper
We just ran through the what, so let’s cover the how. There are 2 ways to enter the Plan stage, really.
- Import Existing Assets into ignite
- Propose a New API Product
The 4 key steps for proposing a new API Product are 1. Service Intake, where you create the solution, 2. Describe the Solution, and which business capability it supports (this keeps you aligned with business goals) 3. Gather Resources, links to references, business glossary terms to include, in keeping with canonical, data governance goals, etc., and 4. Additional Tasks you’d like the service to include. Voila. You’re ready to send it over to design.
But that’s just the typical route — separately, business can ideate from the Browse View. These steps look more like: 1. Search the inventory, 2. Find and combine cool stuff, 3. Add to Wishlist, 4. Prioritize & Ship. Here’s the browse view of the API Catalog:
If you click on an API in any of the above layers, it will open up to show you the contents, like so:
We also have a more detailed process for developers who want to get in beneath the accelerator level.
To read about the other stages of the developer cycle, visit: