Following a theoretical Part 1, I was glad to talk about more practical API-related things and ways they can be designed.
While preparing for the webinar, I expanded my knowledge of the FastAPI Python framework to design mocks. Some of them were not only displaying docs in Swagger UI but also worked kind of. My overall purpose was not only to talk about APIs from the Business Analysis perspective but to show them.
Following a theoretical Part 1 of the "Requirements & API" webinar, the second part will come on November 9 at 18:00 (GMT+2). Here is a LinkedIn event with a Zoom link.
We will dive into API design-first, OpenAPI specification, and related tooling. Also, we will review a few practical cases and API patterns.
See you there!
As I mentioned, the entire webinar is based mainly on my API Design series, which I have worked on throughout this year.
I will publish the recording as soon as it is available.
Stay tuned!
On October 26, 2023, I hosted a webinar for Business Analysts about API and the requirements specifics about that (announcement).
I was very excited about that opportunity. Even that part was based on my previous materials published here in my blog, and from the offline API workshop, I spent a lot of time polishing and re-structuring the content to fit a remote audience with different backgrounds.
I am proud to announce that I am hosting a two-part "Requirements & API" webinar for the IIBA Belarus Chapter.
Part 1 will happen on October 26 at 18:00 (GMT+2) - a LinkedIn event link. The second part will come two weeks later.
That is an online version of the workshop I made in Warsaw this February. There was great interest in the event. However, many folks could not travel to Warsaw for this specific event. So, there was an idea to transition it to online.
Along with my blog, I have several sources where I publish my materials. Recently, I started posting a new "Replacing Legacy" series of articles. That idea initially derived from my BArsawa (a.k.a Business Analysts Community in Warsaw) speech. In its turn, it derived from my lecture about Legacy monolith decomposition I made in 2019 (I will share a link later).
Last year I wrote a short essay summarizing my first 365 days as a Product Manager. One more year has passed, and it is time to share more insights or learned lessons.
Important notice: It is only about my experience, so some things may not apply to what other PMs are experiencing. Product Management is a vast discipline with different responsibilities across different companies and industries.
In early 2021, at the climax of the Covid-19 outbreak, locked up in the apartment with my wife and 6-month-old kid, I decided to have my blog. I will not dive into the reasoning there. I decided that sharing my thoughts on the media platform I own was a good idea.
My initial requirements were:
A static site generator, GitHub pages, and a custom domain name cover those points. Having a static site generator benefits in supporting the Markdown syntax, which I am using to write my notes. Plus, it is an additional technical challenge to configure and support that all by myself.
So my first choice was pretty obvious...
There are some changes in the content allocation across my Blog and other social media platforms. That will impact what and where you will see.
I learned what backward compatibility means regarding software engineering when I started working on microservices. When you are responsible for services widely used by other teams inside and partners outside, you most likely become paranoid about maintaining backward compatibility of your API as much as possible. Especially when it is a highly volatile environment with rapidly growing functionality and direction changes on the fly.
At some point, I invented the term "backward awkwardability" - an awkward feeling while telling consumers that there are breaking changes in a new release, so they have to migrate. If your team does it frequently, they will say something like, "C'mon guys, you introduced breaking changes just a few iterations before! What's going on?"
Let's talk about backward compatibility and how to deal with the breaking changes in terms of API.
Previously we discussed the notion of requirements for APIs. Now let's talk specifically about their quality attributes. Or how we can refer to them: non-functional requirements.
When we use the term "non-functional requirements," we imply that there should be "functional requirements" as well. What is a functional requirement for an API endpoint? Return a response based on the provided input data. It sounds oversimplified, but this is how it is.
In detaching API from the functionality, meaning we have a variety of APIs for different consumers, I like an association with a "door." Despite any context, the primary function of a door is to change its state from closed to open and vice versa. The door can be built from different materials, and it can be opened by various means. The opened door can lead to different locations. But its primary function remains the same. We are not considering it as a weapon, even if you hit someone by a door (accidentally, I believe).
However, the quality of that door matters, and the same we apply to API. There are dozens of non-functional characteristics, so we only look at major ones.