Composable Definition and MACH​

Composability, also known as Composable solutions or Composable commerce, is a design principle in which individual components or services are modular, independent, and interoperable. It allows them to be easily combined, reused, or replaced to build complex systems.

We have a custom-built core product for software businesses, whether a monolith or a set of microservices. In addition, you (when I mention you, I mean a product, area, or organization) have several external integrations with different levels of complexity.

For non-software businesses, several vendors of different scales have some in-house solutions. Those businesses are the primary beneficiaries, as Composable is a way to eliminate vendor lock-in and gain more control while also being flexible enough to adapt to market changes.

Composable addresses the latter case by using "best-of-breed" components available, whether market or house-built and adapting them according to business requirements.

To build such a miraculous system, you need middleware that connects several headless subsystems via API and provides governance and data consistency.

There is much buzz about whether AI could replace human product managers. I am not very concerned. Much of my work involves dealing with stakeholders at different levels and pursuing various objectives. AI will find it challenging to substitute that side of people interaction. I mean politics in a sense of power dynamics among multiple groups of stakeholders.

We don't like politics in the workplace, but it is inevitable when there are more than a dozen people.

Dealing with internal or external stakeholders always involves politics and personal-professional relationships. The larger the organization, the more complex the political landscape and the bigger the stakes.

The power dynamics impact everyone in the organization, including individual contributors. When an individual contributor (IC) transitions to a manager role, they become a part of the game without any choice.

Another year is almost over, so it is time to summarize all that happened and discuss what is coming. First, let me wish you a Merry Christmas and Happy New Year before I dive into self-reflections relevant only to a few readers.

Achievements​

In 2024, I published 24 articles, including 7 editions of the BArszawa blog, where I acted as a writer and an editor. That's two times more than in 2023.

Here is the next blog edition of our Business Analysis Community in Warsaw: BArszawa Blog #7 (December'24)

What is inside:

A new chapter in the Requirements & API series continues uncovering API design specifics. This time, we look closer into IDLs (Interface Definition Languages).

I examine OpenAPI as an industry standard, Microsoft-powered rival TypeSpec, and an underdog JSight. They have a similar purpose but achieve that in very different ways.

For future plans, please don't create one-liner tickets in your backlog.

The only excuse is when you must "proof" some future work. I knew a project manager in an outsourcing project who told business analysts to create 500 Jira issues to showcase to a customer the scope of work for continuing a development team's assignment.

In recent years, I have been dealing with massive backlogs of outdated items written by people no longer around. That has resulted in painful and time-consuming reviews and (re)-negotiations with stakeholders.

If you have such experience at least once, you are likely a fan of focused and precise backlogs like myself.

A new chapter in the Requirements & API series focuses on structuring each layer to design an API. This time, it is more practice-oriented, with examples of an HTTP API call and its OpenAPI definition.

I am in the hallway through that series. Almost a year ago, I did two webinars on the topic. Those articles help look deeper into the topic, which is better done in writing.

Here is the next blog edition of our Business Analysis Community in Warsaw: BArszawa Blog #6 (September'24)

What is inside:

Onboarding is a crucial process of incorporating a new person into a team, product, or domain (for simplicity, let's generalize all that as "area"). The purpose is to align or increase performance as soon as possible after the unavoidable drop due to a structure change. If approached wrongly, it may cause substantial trouble, especially when you dive into a new area as a product manager (PM).

Whether it is a new or same organization, new role, or new area - the approach to onboarding will vary. Here, we talk about horizontal growth within an organization, keeping your role but acquiring a new "area" (for simplicity, let's use this term to generalize one or several products, teams, lines of business, etc). That is the situation I am currently in, so I have something to reflect on. Also, most onboarding guides focus on vertical growth with a new role in another business. So, it is a good topic to uncover.

I follow the patterns of 3 key knowledge types in product management suggested in the "Building Products for Enterprise" book (I wrote about it here): organizational, product, and market knowledge. So, let's construct the onboarding strategy for each.

I finished reading "TRANSFORMED: Moving to the Product Operating Model" by Marty Cagan. This is not my usual a few thousand-word review—rather, it is a few aftermath thoughts.