Why
A technology radar serves as a reference and an onboarding tool for the technologies used in the Open edX Platform, giving us all deeper insight into the composition and history of the software which we collectively steward. It’s a living document that records our technology decisions as they change over time, evaluating their level of adoption and suitability to the platform’s needs.
Today we don’t have a “one-stop shop” for this sort of information, and often teams and individuals are left to reinvent the wheel when making technology choices. We hope that creating a comprehensive Technology Radar for Open edX will save engineers time and make our code more approachable to each other through consistency of approach and implementation.
Creating a technology radar involves gathering information from all corners of the engineering organization, so it only makes sense to do this in a collaborative way.
See Thoughtworks Tech Radar FAQ for more information.
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
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
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.
Our definition of what constitutes a blip may be slightly different in spirit than Thoughtworks' definition. We want our radar to represent a historical record of technologies used as part of Open edX. Since engineers may find references to technologies in our codebase years later, it makes some sense that our blips may be more long-lived than Thoughtworks'.
Rings
Our rings are intended to correspond to OEP states. The “Adopted” state is a new addition identifying those technologies that are not only Accepted - a comparatively low bar for an OEP - but thriving and recommended. The intention is to update OEP-1: OEP Purpose and Guidelines to adjust the states to map onto the rings in our radar.
Adopted | Technologies we have high confidence in to serve our purpose, also at large scale. Technologies with a usage culture and established best practices in our production environment, low risk, and which are recommended for widespread use. |
Accepted | Technologies that we have seen work with success in projects and solve real problems; we have serious usage experience with them that confirmed their benefits and uncovered limitations. New projects may want to seriously evaluate using these technologies when considering options. These technologies are slightly more risky; some engineers in our organization walked this path and will share knowledge and experiences. |
Provisional | Technologies that are promising and have clear potential value-add for us; technologies worth an initial investment of research and prototyping efforts to see if it has impact. These technologies have higher risks; they are often brand new and/or highly unproven in our organization. You will find some engineers that have knowledge in the technology and promote it, you may even find teams that have started a prototyping effort. |
DEPR / Hold | Technologies not recommended to be used for new projects, but may already exist in the code base. Technologies that we think are either not (yet) worth (further) investment, or have been proven to be inadequate or directionally inappropriate for the platform. These technologies should not be used for new projects, but usually can be continued for existing projects. Many will have corresponding DEPR tickets in Jira describing their sunset timeline. |
Quadrants (To be Finalized)
Techniques
These include elements of the software design process, architectural principles, as well as ways of structuring software. In general, these are more abstract and less about particular code artifacts, which are covered by the other quadrants.
Open edX Platform frameworks
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 (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.