...

• Improve time-to-value of product delivery teams.
• Minimize the resources required for enhancement and maintenance of the edX platform.

Metrics 

Rationale

In order to validate the impact of architecture initiatives, measure and observe trends in time and resources required to deliver products and features.

...

Education (Diagrams, Docs, Courses, etc.)

Rationale

Increase general understanding of the edX platform architecture and best practices across all parts of engineering (internal and external) in order to

• reduce time to onboard (internal and external) developers.
• reduce time in reviewing internal PRs, contractor PRs, and OSPRs.
• reduce unexpected surprises that could have been alleviated if a system was better understood.

Todo

1. OEPs and/or edX Courses (also see Architecture Decisions for eventual OEPs)
2. Design docs and diagrams (see Architecture Onboarding and Open edX Architecture Design Documents) 
3. Consolidate documentation for better discoverability 

...

System Architecture

Rationale

"If you can’t build a well-structured monolith, what makes you think microservices is the answer?"  (Simon Brown's keynote)

Regardless of how many integration and extension points are poked into the edX platform, the large monolith will remain sluggish and there will still be many reasons to update it as long as core functionality remains hidden within it.  Alternatively, edX as a business will simply implement cursory features around the platform without really digging into or innovating in its core features - with the mindset of wanting to deliver value (not core value) quickly.

Furthermore, while future development happens outside of the monolith, unless the future architecture is strategically designed the development team may continue to create tightly-coupled interfaces but now across process boundaries.  So, a strategic consideration of industry-tested best practices with microservices is fully warranted, followed by education and enforcement in future development.

Todo

1. DDD
   1. DONE. Domain-driven design (DDD) book club.
   2. Follow DDD
      1. Domain Vision Statement
      2. Bounded Contexts
      3. Ubiquitous Language
   3. Evangelize Domain-driven microservices, path to the Reactive Manifesto
   4. Katas of modern architectural design patterns → leading to a strategy.
   5. Determine what Architectural Linters can be put into place
2. Taming the Monolith
   1. Time-boxed effort on high-level clean up of the platform as started with edx-platform Code Structure: Hackathon XIV and later documented in edx-platform Repository Overview.

...

There is a proliferation of feature toggles in the edX platform.  There may even be a steeper increase over the last 2 years due to more frequent releases and encouragement of shorter-duration git branches.  However, there are drastic long-term maintainence issues of the platform if these toggles are not properly maintained/removed/etc.

Todo

1. DONE. Document best practices in Feature Toggles OEP.
2. Implement #9, #11, and #12 of the framework requirements.
3. Runway for testing toggles in unit tests, end-to-end tests, etc. as suggested by the OEP.
4. Evangelize and establish sustainable process of toggle creation, maintainance, and cleanup (as described in the OEP).

...

1. Discovery
   1. Assess self-reported pains documented in Architecture Challenges.
   2. Hold live meetings to understand challenges involved: roundtable discussions, feature retros, value stream mapping exercises, 1:1 with team leads, etc.
2. Known pain-points
   1. FED development
   2. Monolith updates (may be addressed by IntegrationandExtensionPoints(APIs,Plugins,Hooks,Events,etc. from  and SystemArchitecture from above)
   3. Coupled services (may be addressed by SystemArchitecture from above)
   4. Data migration (can't evolve schema of large tables)