Skip to content

Welcome to My Blog đź‘‹

  • in API
  • 6 min read

Breaking changes & Backward compatibility

Breaking changes everywhere

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.

  • in API
  • 5 min read

Non-functional Requirements and API

Slides from API Workshop about Non-functional requirements

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.

  • in API
  • 7 min read

Definition of API Requirements

Cover

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.

  • in API
  • 8 min read

API Design Tooling

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.

  • in API
  • 6 min read

API Design-First

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.

  • in Books
  • 5 min read

Thoughts about J. Gharajedaghi’s "System Thinking"

Cover

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.

How I overcame my obsession with performance metrics

Cover

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.

Sidekick product

Cover

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.

Product Manager: Year One

Cover

One year has passed since I was promoted to a Product Manager position: first six months as an Associate (a Junior grade), and then I stepped in as a fully-fledged Product Manager. And that was a drastic shift that made me revisit some aspects of my work and added a new dimension to my view on product development.

In this essay, I want to summarize my experience with the insights I collected throughout the year. Some of them might be obvious to a more experienced audience. But for me, some were revelations, and some were hugely underestimated initially. It is a good exercise to conduct such a personal retrospective, and others can benefit from that as well.

Pre-interview tips for Junior Business Analysts

Cover

Recently I was looking for a Junior Business Analyst to join my team. I considered candidates with little or no experience in IT. And that was an excellent experience for me. For the first time in my career I:

  • wholly owned job requirements for the position
  • made a final decision to hire someone or not
  • was not doing the tech part of an interview
  • interviewed Junior-level specialists.

It is different from interviewing a Middle or Senior BA. You can discuss various topics with more experienced professionals: practical cases, challenges, techniques, recent articles, etc. But that is hardly applicable for the Juniors as they can share only their background and knowledge of theory with the ability to apply that in practice, at the very least.