This is our Git managed process for centralizing the ideation and creation of consistent content, providing a single reference for concepts across the API lifecycle and operations--feel free to use, fork, and submit any content.

A blueprint is just a concept. It begins with an idea, grows with discussion and research, and then becomes an outline, which can be used as a buffet of concepts to work with when producing blog posts, videos, decks, and other reusable content.

These are blueprints that are specific to Postman, and how we operate different aspects of Open Tech.

These are a handful of high-level introductory blueprints meant for the widest possible audience.

Understanding more about how we got to this point in time, exploring the evolution of whath we now know as APIs.

These are the units of value that define business today and are being defined as APIs, providing the atomic unit of the API economy.

Defining some of the common challenges faced by API producers and consumers when it comes to working with APIs, and pairing as solution.

Articuating what a diverse API toolbox looks like today, going well beyond just what is possible with simple web APIs.

Defining all of the ways in which you can define a contract for an API, providing a machine readable definition of each API.

The view of the lifecycle from the producers perspective, looking at how APIs are brought to life and evolved over time, here is a deck being developed to define this side of the API lifecycle

Acknowledging that there are many ways in which the lifecycle can be entered, depending on the team and the type of API being delivered, here is a blog post that tells the story of this entire area of blueprints.

The view of the lifecycle from consumer perspective, looking at how the APIs are being put to work in a variety of applications, here is a deck to expore this side of the API lifecycle.

Understanding how APis are being used to address legacy infrastructure, helping decompose and deliver as simple APIs.

Looking at the operational side of defining an API platform, understanding the cornerstones of API operations and the lifecycle.

Mapping out the digital enterprise landscape to help "see" the digital resources and capabilities that are in use behind applicatinos and integrations.

Understand what defines and improves the productivity across teams when it comes to the API lifecycle.

Understanding the fundamentals of qualityi across APIs, helping define a baseline when it comes to quality across API operations.

Being able to understand the state of the enterprise sytem, then gain the observabilitiiy and control to steer things in the right direction.

Moving API testing, security, and governance earlier on in the API lifecycle, helping enable to do the right thing as early on as possible.

Breaking down the different layers of API-related regulation emerging around the globe, and how APIs are being used to respond to regulations.

Understanding the business of APIs, and why APIs are increasingly defined as products, and how business stakeholders are getting more involved.

Looking at the knowledge that is needed to help teams be successful when it comes to producing and consuming APIs inside and outside the firewall.

These are blueprints focused on the public facing aspects of our API operations, and what we should be considering as we evolve operations.

These are some of the common answers to enterprise organizations asking where they should start when getting more organized with their API journey.

Knowledge and guidance around the modernization of open data APIs and the establishment of standards and service driven solutions to support scientific research and machine intelligence.

The process we are using to move blueprints forward is an ever evolving one, but to help encourage participation across the team, and even from the community, here are steps we are taking to create new blueprints, and iterate upon existing ones.

• Ideas - Use a miro board to get all the concepts on the table in a visual way.
• Discussion - Use Github issue to discuss each concept as we iterate upon.
• Outline - Use individual markdown files as the source of outline for each version.
• Deck - Create a deck to convey the concept for use in demos and presentations.
• Slide - Create a single slide to convey the concept for use in slide decks.
• Blog - Publish a blog post to support the concept and help tell the sotry.
• Video - Publish a video using Space Camp, Exploratory, or Level Up process.
• PDF - Create a one sheet PDF that can be easily shared with anyone via email or link.

This process will continue to evolve as we move forward with more blueprints. This set of instructions is designed to focus on fleshing out as many blueprints as possible, providing areas and elements for each, but then iterating upon actions and other links, videos, and resources with future versions--we will shift the process as we progress.

I'd like to see more scheduling and distribution as part of this, but just focusing on creating as many blueprints, and supporting blog, vidoes, and other content.