From dfc24fbb376dab0458ce2fb9a0bcfd287940ffc8 Mon Sep 17 00:00:00 2001 From: Guilherme Dellagustin Date: Thu, 11 Apr 2024 15:37:34 +0200 Subject: [PATCH 1/3] docs(known-instances): Added SAP to RFC pattern --- .../transparent-cross-team-decision-making-using-rfcs.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md b/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md index f21de9753..3e6671550 100644 --- a/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md +++ b/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md @@ -98,6 +98,7 @@ Also for decision making outside of pure software design decisions, transparent - **Uber** - According to this blog post by Gergely Orosz: [Scaling Engineering Teams via RFCs: Writing Things Down][uber]. - **Google Design Docs** - As described in this blog post by Malte Ubl [Design Docs at Google][google] - **DAZN** (10/2021) - One way that DAZN makes technical decisions is via RFCs. RFCs are used for decisions that apply to engineering-wide processes only! The RFCs live in a GitHub repository, and technical standards are then gradually adopted within their tools and by their engineers. An RFC can be raised by any engineer, and voted on by all engineers. If upvotes exceed downvotes, the RFC is adopted. It’s worth noting, that the RFC voting process hasn’t yet been “stress-tested” by any contentious decisions. - As described in this blog post by Lou Bichard: [Building A DX Team: Lessons Learned][dazn] +- **SAP** - As described in the blog post [Cross-Product Architecture: Embracing Conway's Law for Better Software Architecture][sap-cpa], SAP has a mature tool-assisted process for document review across teams. It is primarily used for the review of Architecture Decision Records (ADR) originating from cross-team work done on the Cross-Product Architecture collaboration model. This means that the review process in not easily available for decisions on small projects. Also, the documents are not by rule related to InnerSource projects. That means it is not a universal solution for engineering decision making in the company and also not a 1:1 fit for this pattern, but close enough to be mentioned as known instance. ## Status @@ -123,3 +124,4 @@ Structured [bbc]: https://www.youtube.com/watch?v=U6zlghE0HcE [google]: https://www.industrialempathy.com/posts/design-docs-at-google/ [dazn]: https://medium.com/dazn-tech/building-a-dx-team-lessons-learned-4a66446088bc +[sap-cpa]: https://community.sap.com/t5/technology-blogs-by-sap/cross-product-architecture-embracing-conway-s-law-for-better-software/ba-p/13648600 \ No newline at end of file From 209dfd6c635a84474c2efdf036122951052d6015 Mon Sep 17 00:00:00 2001 From: Guilherme Dellagustin Date: Thu, 11 Apr 2024 15:40:04 +0200 Subject: [PATCH 2/3] fix(markdown-lint): Fix missing newline at the end of RFC pattern --- .../transparent-cross-team-decision-making-using-rfcs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md b/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md index 3e6671550..170c9aaec 100644 --- a/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md +++ b/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md @@ -124,4 +124,4 @@ Structured [bbc]: https://www.youtube.com/watch?v=U6zlghE0HcE [google]: https://www.industrialempathy.com/posts/design-docs-at-google/ [dazn]: https://medium.com/dazn-tech/building-a-dx-team-lessons-learned-4a66446088bc -[sap-cpa]: https://community.sap.com/t5/technology-blogs-by-sap/cross-product-architecture-embracing-conway-s-law-for-better-software/ba-p/13648600 \ No newline at end of file +[sap-cpa]: https://community.sap.com/t5/technology-blogs-by-sap/cross-product-architecture-embracing-conway-s-law-for-better-software/ba-p/13648600 From 8c84b58445d3456bb849ddfe700bb2982dbfa1e1 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Wed, 11 Dec 2024 19:16:02 +0100 Subject: [PATCH 3/3] Various formatting changes. --- .../transparent-cross-team-decision-making-using-rfcs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md b/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md index 170c9aaec..2250410a2 100644 --- a/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md +++ b/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md @@ -98,7 +98,7 @@ Also for decision making outside of pure software design decisions, transparent - **Uber** - According to this blog post by Gergely Orosz: [Scaling Engineering Teams via RFCs: Writing Things Down][uber]. - **Google Design Docs** - As described in this blog post by Malte Ubl [Design Docs at Google][google] - **DAZN** (10/2021) - One way that DAZN makes technical decisions is via RFCs. RFCs are used for decisions that apply to engineering-wide processes only! The RFCs live in a GitHub repository, and technical standards are then gradually adopted within their tools and by their engineers. An RFC can be raised by any engineer, and voted on by all engineers. If upvotes exceed downvotes, the RFC is adopted. It’s worth noting, that the RFC voting process hasn’t yet been “stress-tested” by any contentious decisions. - As described in this blog post by Lou Bichard: [Building A DX Team: Lessons Learned][dazn] -- **SAP** - As described in the blog post [Cross-Product Architecture: Embracing Conway's Law for Better Software Architecture][sap-cpa], SAP has a mature tool-assisted process for document review across teams. It is primarily used for the review of Architecture Decision Records (ADR) originating from cross-team work done on the Cross-Product Architecture collaboration model. This means that the review process in not easily available for decisions on small projects. Also, the documents are not by rule related to InnerSource projects. That means it is not a universal solution for engineering decision making in the company and also not a 1:1 fit for this pattern, but close enough to be mentioned as known instance. +- **SAP** (03/2024) - SAP has a mature tool-assisted process for document review across teams. It is primarily used for the review of Architecture Decision Records (ADR) originating from cross-team work done on the Cross-Product Architecture collaboration model. Some noteworthy implementation differences from this pattern: The review process is not easily available for decisions on small projects. Also, the documents are not restricted to InnerSource projects only. - As described in the blog post [Cross-Product Architecture: Embracing Conway's Law for Better Software Architecture][sap-cpa]. ## Status