APIs are not rocket science – but they will be if you don’t take the right steps

From a computer science perspective, application programming interfaces (APIs) are a quite old and basic concept that should not be considered as a disruptive IT change, but still is being promoted as such. You should identify the right steps in the context of your organization vision, define a suitable architecture, select the right technologies, and in the end, you will say “APIs are not rocket science.”

Step by step

1. Business vision

Review your business vision and identify what is the aim for creating/refactoring APIs in your organization. Some examples could be that you are moving towards a digital transformation, implementing/refactoring digital channels for internal/external customers for which it’s required to integrate your client applications (web portals, mobile APPs), enabling integration with third-party companies, exposing APIs to public consumers, etc.

2. Architectural vison

Based on your business vision and non-functional requirements, you should create your intermediate and target architecture. Typically, digital transformation programs include migration to cloud, which should be aligned with your API program roadmap. Also, it will be an opportunity to break the legacy and monolith systems into a modern microservice architecture, in which the loosely coupled APIs are linked with business functionality that can be build and deployed independently, using open standard interfaces.

Separation of concerns applies for your API resources and for the different API layers (e.g., backend-for-front APIs, process APIs, system/domain APIs). Generic and reusable APIs can be created, and at the same time specific flavors can be exposed according to the channel user experience needs. Domain-driven design on the lower API layers is advisable, according to your business entities and products, even so that can be transparent to a specific channel. Adapt the architecture according to your functional and non-functional requirements, don’t create additional layers if they are not required!

3. Migration strategy

Business and IT strategy can conflict, budget and ROI can limit your ambitions, time to market and long-term vision will define the pace of your roadmap implementation.

Your roadmap should consider a long-term vision, but start with PoCs and MVPs to be sure that you are moving in the right direction. Create your migration strategy, assuring business continuity and give space for innovation, and the different speed between your DevOps teams. In most cases, frontend development will go faster than backend, where new APIs are being created or rebuilt. Reduce dependencies between teams and the impact on the API consumers from the ongoing API contract changes.

4. Technology evaluation

Beside your functional requirements don’t forget your non-functionals, the most relevant of which are security, reliability, scalability, monitoring, performance, maintainability. Other aspects,  such as how to expose internal and public API contract documentation and monetization, are also important.

For the implementation of each API component, evaluate the best technologies and frameworks according to your requirements, industry trends, best practices, and skills available in your organization. Good developers are scattered resources in the market, so low-code platforms can be a suitable option in some cases.

5. API design-first approach

Follow a design-first approach that should be based on your business entities, and consequently on your resource models. Even if your starting point is a legacy and complex resource model in your backend applications, it should be abstracted and simplified to your consumers. Quite often, the API consumer’s view is ignored during this design process, which will result in more rebuild efforts later.

6. Development and retrospective

Time to implement and bring APIs to production that give real business value.

Are we done? Not yet.

Go to step one again, revisit your decisions according to your lessons learned. These steps can take an eternity, so avoid becoming blocked with never-ending brainstorms. Instead, fail fast and improve in each interaction.

How can we help you?

We can make these steps together.

Capgemini is present around the globe, with clients across different business domains (i.e financial services, retail, manufacturing, telecommunications, public sector, etc.). Capgemini is technology and cloud agnostic and helps you to choose right solution according to your strategy, vision, and digital transformation plans.

Capgemini created a systematic approach to help you assess the current state of your API program, taking into consideration different perspectives. It’s a tool to for performing periodic health checks on API programs, tracking their progress, refining the roadmap and execution plans. As a communication tool, it will convey the big picture to a different stakeholder, and leverage API program roadmaps, execution plans and budget planning.

We have proven experience in building API programs, from business conceptual analysis to architectural and technology advise aligned with your business/IT context and vision.

Key takeaways

Create your business/IT vision roadmap, interactively and learn with your findings. Avoid the big-bang approach, go step by step, moving towards your target architecture and adjust it according to your effective business results.

We advise enterprises to adopt proper strategy in choosing the right architecture, technologies, and continuous development and continuous delivery procedures. Being vendor agnostic, but at same time with support of our partners, we can help find and implement the best solutions within your business/IT context and vision.

Authors