When you are in the API game you hear this phrase a lot, “didn’t we already do that?”. It is a common belief system that because something was already done, that it means it will not work ever again. When you are operate solely in a computational world, you tend to see things as 1s and 0s, and if something was tried and “didn’t work”, there is no resetting of that boolean switch for some reason. We excel at believing things are done, without ever unpacking why something failed, or how the context may have changed.
One of the things I’m going to do over the next couple months is go through the entire SOA toolbox and take accounting of everything we threw away, and evaluate what the possible reasoning were behind it—-good and bad. I strongly believe that many folks who abandoned SOA, willingly or unwillingly, and especially the people who enjoy saying, “didn’t we already do that”, haven never spent time unpacking why we did, why it didn’t work, let alone whether or not it might work today. I think this paradigm reflects one of the fundamental illnesses we encounter in the tech sector-—we have a dysfunctional and distorted relationship with the past (this is by design).
I’ve written about this before, but I’ll say it again. Can you imagine saying, “didn’t we already do that” about other non-technical things. Fashion. Art. Music. Stories. Law. Why do we say it in technology? When it comes to SOA, there are many reasons why it didn’t work overall, and most of the reasons were not technical. So why would we not want to re-evaluate some of the technologies and practices to see if there would be a new opportunity to apply an old pattern or approach? This question isn’t just something I’ve heard a handful of times. There have been literally a hundred plus blog posts on API Evangelist where people have commented this—-especially when it comes to JSON Schema and OpenAPI.
Anyways. I’m going to revisit my SOA history. My therapist said enough time has past and I’ve healed properly, so I can begin digging around in this part of my past. I’m guessing there are a lot of practices, tooling, and patterns we can rethink in a JSON, YAML, containerized, CI/CD, cloudy world. Alongside this work I’m going to be assessing what the preferred open source tool are for the API lifecycle, making sure it represents my vision of a diverse API toolbox, tracking on tooling for JSON Schema, OpenAPI, and AsyncAPI that will help us service the entire API lifecycle for both internal and external API delivery. There is a lot of work that has been done in the past that we should be learning from, and I’m more than happy to dive in, do the research, and shine a light on what we’ve left behind.
