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:

• free hosting
• own domain
• control over the content and publishing capabilities

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.

Requirements definition for APIs is not a standard part of the Business Analysis activities in software development. Usually, API design was a single responsibility of a system architect or a developer, considering implementation subject matter experts.

During my BA career, I had to deal with API-specific requirements. I realized that the API layer has stakeholders (aka consumers) who have their needs related to APIs provided by a system-of-interest. And those needs should be analyzed and translated into requirements.

The goal of this essay is to give an introduction to the definition of API requirements for my fellow Business Analysts, Product Owner, and Product Managers. I will not discuss technical details and cover API types (REST, RPC, GraphQL, etc.). There are a lot of experts who have done that and did a great job.

I will focus on general things, looking at API from the requirements perspective in general. Also, I have mostly worked with RESTful API, which impacts my view on some things.

This article is a part of the API Design series, where I will review several API design tools and summarize my experiences. There are the following criteria I use in selecting and evaluating the tools:

• it is free: either open source or a free plan of a paid product
• out-of-the-box functionality is considered only: no plugins
• both web and desktop products are considered
• it allows designing REST API definition in OpenAPI 3.x with JSON/YAML (low-code), UI means (no-code), or a combination of both
• code generation functionality is not required as there are several 3rd party libraries to do that

I am not promoting, just expressing my honest opinion. But I might have my favorites. Also, I will describe these tools at the moment of December 2022.

This article is a part of the API Design series, where I will uncover API design concepts for my non-technical peers. You don't need to be a developer or an architect to participate to design or even build an API, but there is something you should learn to succeed.

So we start with API design-first, which takes the opportunity to democratize the API development process.

This is a new rubric in my blog as I tried to avoid any posts about specific books before. I am taking some notes about the best books I have read. But those are not for the public eye. So this piece was not originally planned to be published. I just feel a need to share something with the world after I read a book in the title. Because that was a wonderful but pretty tough experience.

Before we begin, let’s make clear that:

• It is not a review. I will not write about bad books in my blog. By default, any book which has a separate essay is worth reading. Period.
• That will be in the form of an internal dialog.

I fell into a common trap of every manager: obsession with performance metrics. Since I have been promoted to the PO role my responsibilities include tracking stats related to the backlog and team performance. That includes the team’s capacity, estimates, velocity, and other specific metrics. In an ideal world, the estimation of planned features matches capacity, the team performs a predicted velocity and (more importantly) delivers features in time. But we all know that doesn’t work this way.

This is the story of how I became obsessed with numbers instead of being obsessed with a product. And how I overcame that and shifted my focus to real value.

Throughout my career, I participated in the development of a few supplements for so-called “parent” products. They were standalone services with their own, not big, but still considerable business value. Recently I realized that even though those supplement products were developed in different organizations and in different business areas they did have common traits. Moreover, they shared the same problems.

It was something laying on the surface. Sometimes you shoot yourself in the foot twice before starting to see obvious things. What is the nature of those Sidekick products and do they inherit the problems of “bigger brothers”? Let us sort it out in this essay.