Making The Business Of APIs More Modular Before You Do The Tech

I have been immersed in how APIs are being done in the federal government for the last week or so, looking for positive API behavior I can showcase and focus on in my storytelling. I was walking through each step of my API lifecycle, sizing up the federal government for each area I track the private sector on when it comes to APIs. I was taking a look at the areas of microservices, containerization, and serverless. You know the modularization of IT infrastructure in government? I couldn’t find much rubber meeting the road when it comes to microservices or containerization in my research, but I did see hints of modularizing the business aspects of doing APIs in the federal government.

Over at 18F you can find some interesting discussion around micro-procurement, “a procurement model that breaks what would traditionally be a large, monolithic contract into several shorter-term, lower dollar amount contracts.” I feel that breaking down the business of defining, designing, deploying, managing, and even testing your APIs into small projects is an important first step for many companies, organizations, institutions, and agencies. While not all organizations will be the same, many will need to break down the business of procuring API design, deployment, and management services, before they can even getting to work breaking down the technical components of what is needing to be delivered.

I have been working with my partners at Skylight on our approach to breaking down and delivering API projects, discussing the technical, business, and political aspects of doing things in as modular, bite-size chunks as we possibly can. This involves exploring the other side of the micro-procurement coin, with micro-consulting, providing API related services in small, modular projects. I’m exploring the delivery of API training and curriculum, as well as white paper, guide, and other content-centric services using a micro-consulting approach–keeping engagements small, focused, and delivering additional services that support one or many individual API implementations.

Micro procurement and consulting isn’t a fit for every scenario, but I can see it working well when it comes to helping companies, organizations, institutions, and government agencies thinking about how they can break projects down into smaller chunks, which will often involve delivering services across numerous stops along the API life cycle, from design to deprecation. Designing and deploying an API under a micro project approach limits the scope of what I’m able to deliver, easily keeping each API doing one thing, and (hopefully) doing it well. Making it easier for me to deliver microservices, complete with definitions, design guides, container, deployment, management layer, documentation, testing, and other essential elements for delivering APIs.