The best way for companies to federate API development?

Google Cloud Apigee
1

Hi All,

I guess this is an expansion on the discussion at: https://community.apigee.com/questions/19380/one-api-team-or-many.html

Is there a recommendation or set of principles on the best ways for companies to “federate” API development within an organisation?

Quick definition (as I understand it - happy to be corrected): Federation is the ability of an organisation to allow the information sharing between “semi-autonomous” and “decentralised” teams.

Basically, how do Teams A, B, C and D know what each other are doing so they don’t all build the same thing?

Obviously governance is an essential factor in successful federation for an organisation, apart from the “roles” we have identified for a governance committee (Policeman, Teacher, Referee), we also discuss the establishment of a Centre of Excellence to help organisations federate.

Thinking about an insurance client I am working with and using the example of a “VIN Check” API - (Vehicle Identification Number) - this is a feature which would likely be created by multiple API Development Teams (and consumed by most App Developers).

You might have the VIN Check API in your:

  • Auto Sales Product
  • Auto Rental Product
  • Roadside Assistance Product

“Generic” APIs such as a “VIN Check” need to be identified and defined somehow - meaning if it satisfies certain criteria, it could or should be “generalised” from the API Product and created as it’s own “product” (for want of a better term).

Teams can search their developer portal for APIs which have already been developed and published, but w****hat is the best way for a team to have visibility around which APIs which are being planned or are in development - before they are launched to the developer portal? Is this even possible?

Clients I’m working with have expressed an appetite for a “governance framework” they can adopt and/or best practices around this.

I get each organisation is unique, which makes a “one solution fits all” approach unlikely, and is why I am thinking principles or a generic framework (which can be used as a base) could be a good starting point.

What other tools do we use or can recommend? Again, the developer portal is obviously a great place for teams to start their search for published APIs, and Confluence would also be useful for visibility around what is in the pipeline (given it is up to date and people know how to use it), but I’m looking or something more "structured”.

For organisations who are new to "the API way of thinking” or don’t have a culture of “Confluence power use”, it is like saying “Here are some bricks, build your house”, which is both overwhelming and likely to fail.

Thanks in advance.

1 Like
2

I wanted to add to David’s comments on the “one solution fits all” solution that comes up a lot in design discussions. As David mentions, it is unlikely that a single solution will fit all the various scenarios / use cases / dynamics of different organizations across the company

This topic comes up more than one would think (specifically around API design). While having a general design standard / best practices will be very helpful in terms of the governance model, one message that should be emphasized is that there is no “set of steps” that one could follow and result in a perfectly designed API.

APIs in their nature are dynamic and constantly evolving. Depending on the business, end user, market, back end limitations, etc, the API would be designed differently for each case. As such, one should focus on the general design practices rather than take the approach of this “checklist” mentality. In summary, when it comes to the design of APIs, there is a bit of art involved.

1 Like
3

David @dyonan, I see you are an Apigeek, but I’ll answer this in a manner to the benefit our many partners solving for these problems at our many customers.

This is a pretty complex question, and we see different approaches at different customers, some of which are partially working. We also see lots of traps and problems, and teams shooting themselves and each other in the feet, as they struggle for autonomy, control, speed, and reusability.

Synthesizing the parts of the programs that are working, let me share some ideas that you can consider for the programs you are working on. I shall use language from agile practices; if you are dealing with waterfall methodologies, we should address that in another thread:

How do I reconcile individual projects doing their own thing with the need for a common library of APIs?

Should we centralize or distribute our API team?

How do we distribute our API construction without losing the benefits of an enterprise API platform?

As we distribute API development among the projects, what is the biggest problem we should avoid?

Thanks for the opportunity to comment!

1 Like