...
In this step, we learned what a tech radar is and how to apply the concept to Open edX. We took an initial stab at what our quadrants and rings might be, and thought about what sort of blips belong on the radar, and what don’t. We also came up with a plan for how we could collaboratively build the radar with the community.
Step 2: Ideation (Workshop Step)
Each participant individually brainstormed blips based on their areas of expertise. The goal was to come up with a corpus of technologies that might become blips.
...
Step 3: Analysis (Workshop Step)
Participants gathered in breakout rooms by expertise area: Architecture, Backend, Frontend, and SRE / DevOps. We also had breakout rooms for Data and “Rebels”, but they were unused during the workshop for lack of participants.
...
Step 4: Retrospective (Workshop Step)
We paused after our analysis to reflect on the process so far. This included feedback on the workshop itself, the emerging shape of our radar, how we should categorize blips, and thoughts on how we should proceed for the next steps.
...
Step 5: Quadrants (Miro Board Step)
In this step we looked at the output of Step 3 (Analysis) and categorized technologies into quadrants using our learnings and predictions from Step 1 (Learning) to guide us. We confirmed - based on the analysis in the workshop - that having quadrants of Techniques and Open edX Technologies made sense for our Tech Radar. The former is also present on Thoughtworks' Radar, and the latter makes sense given the number of Open edX-specific technologies in use in our platform.
We also decided that we had enough technologies in the frontend development ecosystem, and that they were distinct enough from our other technologies, to justify having a Frontend quadrant. Finally, all other technologies effectively went into the Technologies quadrant. The majority are backend oriented, but there are also a number of services and operational/process technologies in this space.
...
Step 6: Consolidation (Miro Board Step)
In this step, we refined what potential blips should be included in the radar. We came up with a set of criteria by which we could combine some blips and remove others, with the goal of having roughly 25-50 blips in each quadrant.
...
We then populated a spreadsheet with all of our blips and set the quadrants appropriately, and the rings to “Hold” pending Step 8. https://docs.google.com/spreadsheets/d/1ntg2fy7EBR0TFGktyORyv3W-K1bOmhr5Z4EU6WzdSWE/edit#gid=0
➡ Step 7: Descriptions (Spreadsheet)
This is our current step. The goal of this process is to generate descriptions for all of the blips on the radar. We believe that we will more accurately categorize blips into rings equipped with descriptions of what each blip is, and what it means - qualitatively - to the Open edX platform. We intend to do this collaboratively in the Tech Radar spreadsheet. Participants can sign up to be an Author or Reviewer of a blip description.
...
Once we’ve published the radar, that’s not the end. As we all know, technology continues to change constantly, and our Tech Radar will be both the vehicle for how we adapt to changes in technology, as well as our outward expression of those decisions.
Workshop Plan
Important! Before the workshop, sign up for a breakout room by adding your name to a column here: Breakout Room Signup Sheet
Board where we’ll be working: https://miro.com/app/board/o9J_lAwGZaM=/
In the Tech Radar workshop, we will individually brainstorm and collaboratively vet technologies (a.k.a., 'blips', see definition below) we believe to belong on the Open edX Tech Radar. The group will use breakout rooms organized by expertise to work with engineers with a similar background to organize and evaluate their ideas. We believe this will result in a higher-quality list, since the group will have a more homogenous well of knowledge to draw on to evaluate technologies. See the Agenda below for the list of breakout rooms.
Note that in this session, we will be focusing on what technologies should be on the radar, not where they belong. It’s okay to defer conversations about exactly where on the radar a given technology belongs.
The output of this session will be a catalog of technologies used in our software, vetted by engineers who are familiar with them. In a later workshop, we can then use this list to orient technologies (blips!) onto our radar by quadrant and level of adoption.
Agenda
...
5 mins review of this document.
...
15 mins quiet time, self-ideation of technologies.
40 mins breakout rooms
...
Breakout rooms:
Frontend, Backend, Data, Arch, SRE/DevOps, Rebels
...
.
...
Blip by blip, pitch and upvote/downvote
...
Definitions
Blips
A blip is a technology or technique that plays a role in software development. Blips are things that are ‘in motion’ - that is we find their position in the Radar is changing - usually indicating that we’re finding increasing confidence in them as they move through the rings.
...
These include libraries and frameworks developed as part of the Open edX Platform, which we will ultimately want to evaluate in terms of adoption.Quadrants Three and Four
Frontend
We have enough technologies in the frontend development ecosystem, and they are. distinct enough from our other technologies, to justify having a frontend quadrant.
Technologies (All other technologies)
The two quadrants above feel well-defined today. These latter two involve slicing up third-party software solutions into two roughly equally sized buckets. We’ve considered two axes on which we could accomplish this:
Application Libraries vs. Tools and Services
Quadrant three would be third-party code that’s part of our applications.
Quadrant four is code that supports it during development and testing, as well as third-party services our code interacts with.
Application Technologies vs. Operations and Management
Quadrant three would be code related to our applications, including development and testing code.
Quadrant four would be services used to operate and manage our applications.
We hope this workshop will shed some light on the right groupings for these quadrants - until then, we can say that quadrants three and four include languages, frameworks, tools, services, and operations technologies.This quadrant includes both backend technologies and services used in the Open edX platform. As an editorial note, it feels a bit like a catch-all given the variety of technologies added to it.
Appendix A: Workshop Plan (2021-06-09)
Important! Before the workshop, sign up for a breakout room by adding your name to a column here: Breakout Room Signup Sheet
Board where we’ll be working: https://miro.com/app/board/o9J_lAwGZaM=/
In the Tech Radar workshop, we will individually brainstorm and collaboratively vet technologies (a.k.a., 'blips', see definition below) we believe to belong on the Open edX Tech Radar. The group will use breakout rooms organized by expertise to work with engineers with a similar background to organize and evaluate their ideas. We believe this will result in a higher-quality list, since the group will have a more homogenous well of knowledge to draw on to evaluate technologies. See the Agenda below for the list of breakout rooms.
Note that in this session, we will be focusing on what technologies should be on the radar, not where they belong. It’s okay to defer conversations about exactly where on the radar a given technology belongs.
The output of this session will be a catalog of technologies used in our software, vetted by engineers who are familiar with them. In a later workshop, we can then use this list to orient technologies (blips!) onto our radar by quadrant and level of adoption.
Agenda
5 mins review of this document.
15 mins quiet time, self-ideation of technologies.
40 mins breakout rooms
Breakout rooms:
Frontend, Backend, Data, Arch, SRE/DevOps, Rebels
Goal is to define what blips, not where they should be added to the radar.
Blip by blip, pitch and upvote/downvote
20 mins for group retro and discussion of our radar and base assumptions