c4-notation VS backstage

Start by formalizing the architecture. You don’t need heavy enterprise methodologies like TOGAF; use formats that fit the team and product. Frameworks like arc42 are suitable for complex systems, while simpler projects may only need C4 diagrams supplemented with a few additional visualizations.

Software Architecture is all about developing systems that scale and are maintainable. Clear visualizations will help teams to communicate the design effectively. The C4 model comes in handy for this task! But what is C4, and why should you care?

https://c4model.com/ is very useful for this. :-)

I've told it before, but when we were doing some clean sheet work a while ago I decided to use the C4 model and drew out the obligatory "Context" diagram with "user" "phone" "laptop" "app" sort of stuff... and then two hours later realized that because we had both an online and a semi-disconnected mobile app that could be offline, certain things -had- to use a queue and expect an arbitrary amount of time for a task to run, and it completely changed how we thought about the core of how we implemented something pretty important.

Sold. :-)

What sort of maps are you wanting to build? https://c4model.com/ seems to be the more popular standard for this style at the moment. https://github.com/plantuml-stdlib/C4-PlantUML makes this somewhat easy to code out. (And I think most cloud providers have addons for it.)

It sounded like it was working up to a C4 pitch but never got there. It bears a look exactly for this post's title.

https://c4model.com

Simon Brown is another person who has done a far better job than me of "democratizing" software architecture for developers. His talks [1] and workshops on architecture are exceptionally effective and his C4 architecture modeling language [2] is getting real traction.

I have youtube videos too [3] but they aren't as effective.

[1] https://www.youtube.com/results?search_query=simon+brown+arc...

[2] https://c4model.com/

[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...

Second this.

Reference for anyone looking I to it: https://c4model.com/

There is also quite a lot of options for helping create these diagrams. I've found https://structurizr.com/ to be the best of what I've tried so far.

What you are describing sounds a lot like C4: https://c4model.com/

Open source: Developer platform Backstage solves so many problems, in such a complete way, that once your teams adopt it, you’ll have a lot of trouble migrating off the platform. The good news is that Backstage is open source, so you won’t find your SaaS bill for the platform mysteriously rising by 20% every quarter until it dwarfs your infrastructure costs. Adopting an open source tool as your developer platform helps ensure that time spent on adoption is a good investment.

apiVersion: scaffolder.backstage.io/v1beta3 # https://backstage.io/docs/features/software-catalog/descriptor-format#kind-template kind: Template metadata: name: sample-btpsubaccount-remote-template title: Remote Template for SAP BTP Subaccount Setup description: A remote template that creates a basic SAP BTP Subaccount setup tags: - sap - btp - basic - javascript spec: owner: user:guest type: service

Backstage is an open-source platform developed by Spotify for managing the entire lifecycle of developer infrastructure, including services, APIs, documentation, and more. Backstage streamlines the development process through its centralized and customizable platform, offering a unified dashboard that consolidates information on projects, services, and infrastructure. Acting as a service catalog enhances transparency by allowing teams to document and discover internal services easily. Backstage's extensible architecture supports a robust plugin ecosystem, enabling teams to tailor the platform to their specific workflows and preferences. The platform promotes collaboration, accelerates onboarding through standardized documentation, and integrates seamlessly with various DevOps tools.

It’s also well understood that having a k8s cluster is not enough to make developers able to host their services - you need a devops team to work with them, using tools like delivery pipelines, Helm, kustomize, infra as code, service mesh, ingress, secrets management, key management - the list goes on! Developer Portals like Backstage, Port and Cortex have started to emerge to help manage some of this complexity.

We use Confluence and markdown files in GitHub. I think we are moving a lot of our docs to Backstage [0] soon.

One process that ends up being really valuable for documentation purposes is our "Architecture Review Documents". This is a standard document that team leads fill out before starting work on a new Saga/Epic/Feature/whatever. It includes the scope and business value of a new feature or large block of work, high level technical architecture of implementation, the impact on existing database schemas and service APIs, etc. This document is presented in a meeting with technical leadership in our organization who deep dive on the topic and explore potential pitfalls in the plan.

The document and recording of that meeting live on forever, and this information is very useful when getting acquainted with a certain part of our product/codebase. You are able to read and hear clearly the intention of a certain service or module, and you can identify several relevant points of contact to ask questions to.

[0] https://backstage.io/

Check the Backstage repo on GitHub

Backstage - An open platform for building developer portals. [Internal Developer Portal]