Isomer: Product-Oriented Software Development
We all know that software is becoming modularized into microservices, but what do we call the teams that are restructuring themselves around these microservices? Jeff Bezos called it a pizza team, but I think I have a better way to define them.
Three years ago, I published a blog on the trends I’ve been noticing in software development. It was picked up by ZDNet. So, I decided to build a framework for these new teams and name it Isomer. I first introduced Isomer in 2017 at GlueCon in Denver, Colorado.
What is Isomer?
Isomer is how your engineering teams are restructuring themselves around all the microservices you’re building. Melvin Conway stated that software architectures tend to mimic the communication structure of the organizations that built them, but what about the reverse of this observation? That is, software teams are mimicking the structure of their microservices.
“An Isomer team is an independent product team building a software service managed by a strategy owner with clear measurements on performance, dedicated engineering, and release autonomy.”
An Isomer team is an independent product team building a software service managed by a strategy owner with clear measurements on performance, dedicated engineering, and release autonomy. That’s a mouthful, I know.
One way to think of the Isomer team is to imagine the latest trends in the microservice design pattern. As software is becoming more decoupled into individual services mirrored around specific business purposes, so is the organizational structure of product and engineering departments.
You probably heard it referred to as a two pizza team, made famous by Jeff Bezos. I’m probably describing the same thing Bezos did, but I think mine sounds more scientific, hence better. Obviously.
While these names are terms given to the observance of this functional structure, they fail to provide the parameters of best practices to make these teams successful. So, let’s set the parameters around this modern trend and provide a name that encapsulates the criteria for success rather than just feeding everyone pizza.
Isomer groups six core established tenets that define how product engineering teams are enabling themselves for rapid velocity and better collaboration. Also, Isomer is not a replacement for DevOps, so let’s not even begin that debate.
Isomer Explained
Independent
Each Isomer team has a clear and specific business function. You already know this because the service that you own should be reflecting this. These business functions may or may not be consumer-facing, or even have a UI; they could simply be served via an API. Examples of business capabilities could be:
A Mobile application
A Node.js front-end application
Payment processing service
Service
This requirement builds on top of an already existing truth in large scale service-oriented architecture. There is nothing new here. SOA best-practices have built the fundamental foundations for the requirements of an Isomer team, specifically:
Heterogeneous application stacks: it does not matter what language an Isomer team chooses for their stack
Distributed: applications are distributed and isolated
Interface: an API interface exposed for the consumption of data and functionality.
Owner
Assigning a Product Owner and making them accountable for the success of the product forces strategy. Rather than meeting a deadline, you need instead to answer:
Why do you exist?
Why do those items exist on the roadmap?
What formula did you use to reach the priority on the roadmap?
How do you measure the success of your service?
Measured
Peter Drucker said, “you can't manage what you can't measure.” Someone else also said that “anything worth doing is worth measuring.” An uptime guarantee cannot be your only metric for success the same way that “remaining alive” is not your metric for measuring your health.
“An uptime guarantee cannot be your only metric for success the same way that ‘remaining alive’ is not your metric for measuring your own health.“
How do you measure the success of your product? You use solutions, such as:
Don’t forget measuring the product and usage analytics. These products include:
Engineering
An Isomer team has dedicated engineers including developers, QA, release managers, SREs and anyone else responsible for the service. You’re not sharing resources across the org, your team alone is responsible for the full product lifecycle. You might share tools, but not resources. Hopefully.
Release (Autonomy)
Your Isomer team should have it’s own autonomous release cadence and pipeline. This means that you’re not tied down to a more massive release schedule or procedure and bottlenecked by other teams. If your product is ready to deploy, your pipeline is independent and free to do so.
What is the modern standard is for releasing? Do you know what Harness, Google, and Facebook all have in common? They all release multiple times a day.
“Do you know what Harness, Google, and Facebook all have in common? They all release multiple times a day.”
This is where Harness comes in. We’ve helped companies around the world automate their Continuous Delivery process, relieve engineers from having to manage scripts manually, and focus on reaching maximum peak deployment velocity. If you’re not achieving your peak deployment speed, you’re not an Isomer team.
You can have that pizza, though.
Why does any of this matter?
Let’s sum it up in four words:
Autonomy
Strategy
Quality
Velocity
Similar to the natural biological tendency of life itself, the evolutionary process is designed to advance strength and filter weakness. Whether it is to remove bugs, improve performance, or introduce new capabilities, teams push a service further up its evolutionary timeline.
Evolve, my friends.
This article originally appeared on the Harness.io blog. You may read the original article at: https://harness.io/2019/05/isomer-product-oriented-software-development/
