Last week I was talking to a former colleague, he is running a SaaS startup now, and our conversation went around SRE, production, and reliability. We talked a lot about architectural attributes that relate or impact the incidents, from detection to recovery, and on to prevention. I thought to put some of my thoughts around architecture into a blog post since that was the core of our conversation. The next post I will cover more details on architecture for fault tolerance.

What I have learned about successful teams is the trust and the belief in the team’s mission. Trust in the mission, baring some issues like ill-fitting team members, etc. is the single most important factor for success of an individual, a team or a team of teams. When the group of individuals that are part of the said team cannot see a mission they trust, going through the famous steps of Forming, Storming, Norming, and Performing will be harder.

When a new hire joins a team dealing with the development or sustaining of a large-scale application there are a few things that they would need to form a basic understanding of the system: Deeper understanding of what the business about Get a view of the system’s architecture for the software system and the deployment view. Get a bird’s eye view of the system’s dependencies. At least the immediate dependencies. History lessons, how the system came to be at the current state.

Introduction During the past 20 years I have seen trends come and go; one of the thing that has stayed around in one or another form is the term architecture and the architect role. Of course, there are plenty of overloads for the term and plenty of architect archetype like domain architect, enterprise architects, IT architect, network architect, software architect and you name it. Wikipedia has a good definition of software architecture that I quote below:

Amount of information about how a new component or software system can solve all the problem in a specific area is sometimes overboard. The hotter the topic or the framework the more information is scattered around the web for it. For example: Have you seen the plenty of use cases that every vendor in every segment of tech stack provide as part of the adoption or success story? How about the tutorial that shows how quickly and easily something as significant as a an observability solution can be set and be up and running?

Intro Building a new development platform, for example a new microservices oriented platform to replace an existing monolith software system, is a massive endeavour. I have been working on a development platform, the whole ecosystem from ways of working to pipeline in the past 3 years and the experience might help others. So I thought to write down some of the observation and experience before they fully turn into intrinsic/implicit knowledge and hard to pen.