Products health status quo

Today is very common to hear about ownership and accountability, it seems like during the last years the expectations have changed quite a lot, teams are now expected to “own” much more their products, and be accountable on their stability and availability for the customers.

First of all, I will explain here what I mean by product, to make sure that you are on the same page as me, at least on this post 🙂

I think its a great breakthrough in the industry, it just makes sense, and with all the Agile / DevOps movement, even more, the problem comes when teams don’t know what they own, and I’m not talking about not knowing how those products are used, I’m talking about the technical perspective, for instance:

Let’s imagine you just joined a new company to work as a software engineer, I’m pretty sure the following things would contribute to integrate you much faster into the team.

• Available information so you could perform a production release if you wish.
• Being able to find out the infrastructure information that supports the products you own.
• Being able to find out the available monitoring around those.
• The technology stack, and technology version.
• Who are the SME.
• etc…

I’m sure there are a lot of things you as a newcomer would appreciate having in your first days in a company; but also, this is important information for the people that are currently working on the company and products, many of this information is not available, and does not exist for old products and systems, the known monoliths.

Products Health Status Quo

Let me share with you a simple table that will help you to see and understand the current health of all your products.

• Product Name
  • It seems obvious, but sometimes we use acronyms or we refer to them by different names depending on whom you ask.
• Criticality
  • How Critical is it? How much damage will it cause a downtime?
• Release and Rollback process
  • CI/CD – No actions are needed, everything is triggered by the source control after each commit.
  • Automated – They can be easily triggered from a platform like Jenkins or similar with a minimum of actions required by a user, there is a very low risk of human mistakes
  • Semi-Automated – a set of scripts or jobs need to be triggered by a person in order to perform the release or rollback, mid-level of human mistakes.
  • Manual – Can be performed by manual actions from a person, no scripts at all or very low level of scripts, very high risk of human mistakes.
• Release and Rollback documentation
  • Regardless of how a release it’s done, is there a place to see how to do it?
• Infrastructure
  • Test environment – Is the application running in a test environment? Is the information available?
    Prod environment – Where in a production environment is this product running? am I able to administrate the environment, servers, etc?
• Repositories
  • Add all links to the source version repositories
• Local execution
  • Is there a place to see how to run it on a local machine?
• Out Of Office Support
  • In case of a problem, incident within or outside working hours, is there a place where I can see how I will need to act?
• Monitoring
  • What is the currently available monitoring? and what information is showing?
• Tech Stack
  • What is the current tech stack? what different versions I’m using?
• Teams working on them
  • What are the different teams that will most likely need to perform changes?
• Specialists
  • Who is the person or persons with the most knowledge about it?

I’m sure there are many more, but those things will start showing you the state of health of your products, can help you to start making decisions around those, that at the end can influence a lot the feeling of ownership.