agile with a bottleneck on external api development

They might customize an API Product design to capture validated details from future API Development Teams (producers and consumers), such as Summary Info, Classification, Model Objects, Actions, Security, Review (See: 5-step API ).

Why does it matter to you and your organization Well, lets take a look at the Agile Manifesto for software development.

Take a past experience working in an Agile mobile app team, for example: After building a labelling system for wireframes of each mobile screen, at first no one really used the proper labels because working software comprehensive documentation -- which, to be fair, makes sense.

But unfortunately, not using the labels caused a ton of bottlenecks later on, when copy, requirements, design, and implementation didnt match up.

So, whats the real time suck, doing it right in the first place, or not having working software (Shameless ignite solution: labels and requirements are baked into metadata of every design and generated directly into implementation.

For that, IT needs plans, processes, and documentation (Mode 1), AKA those things above on the right.

So it is critical to get your API management strategy down right, because -- beyond being a monetizable end in their own right -- APIs are the means to every endpoint, supporting all other components of your digital business platform.

This includes your customers, devices, backend systems, development ecosystems, and intelligence (see Fig.

A below). Do it right, and your APIs are giving you a view on your entire digital story, end-to-end, for every transaction, action, and ion.

By exposing consumers to business functions, instead of your applications.

So you have well-documented, domain-driven designs -- think of them as capability blueprints -- available to combine and wrap into API Products.

Your well-documented, quick-to-assemble design blueprints and your innovative API Products are building off of each other and ready for internal or external consumption.

The only way to handle this, especially for a large organization managing tons of domains, products, and teams, is an emphasis on product.

Your mode 2 is bringing new opportunities by leveraging pre-packaged business capabilities from your mode 1 design-driven artifacts and documentation.

For more on this, check this fresh-off the press report Create Great API Designs and Documentation With Integration Across the API Life Cycle by Forrester.).

Intelligence -- your single source of truth (the ignite API Product Management Platform), 2.

IT Systems, and 5.

Devices. (See Gartners 5 components of a tech platform graphic).

While an API Product within ignite can certainly go from PlanDesignBuildRun, it is entirely more likely that over the span of its life, an API Product might look more like PlanDesignPlanDesignBuildRunPlanBuildBuild.

The API Product Manager, for instance, might be involved along nearly every stage.

Not sure where your organization is on a scale of digital maturity Check back soon, as thats a topic for a future post.

From that point, any planning role might dive into the API Catalog to search, discover, and innovate.

They can plug and play with existing business capability building blocks to carry out all of the functions of the service; The API Product Manager might suggest a third-party API to extend locally relevant functionality for an API Product existing across global markets.

The Enterprise Architect role will offer valuable guidance during this process to discuss what exists, works well, KPIs, and business needs, prioritizing these missing pieces by collaborating with API Product Managers to determine where to start, who to get involved, etc.

At this point, youre getting into Agile product and team planning.

Here, a Jira (or any task management system) integration can put the pieces into production immediately from ignite -- no more details getting lost in emails.

He or she might work with the API Designer to create new API Product blueprints, or missing Business Capability APIs designed from Domain-Based Information Models the Information Architect has created.

Agile With A Bottleneck On External Api Development