3 posts tagged with "Experience Architecture"

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.

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.

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.