Definitions

• Partner: 
  • An entity representing the common concept of an edX business partner across multiple Open edX sites/services and back-office systems.  The "partner" entity was originally introduced by Otto via the django-oscar project from which it extends.  Partners have "short codes" which are used to link transaction data between Otto and edX's financial systems and data warehouse. 
  • Examples of partners include:
    • edX [short code: edx]
    • MIT Professional Education [short code: mitpe]
    • HarvardX Plus [short code: hxplus]
• Site: 
  • A Django application framework construct used in Open edX to differentiate/partition a subset of the user experience and/or data based on domain/host name.  A site is hosted by an Open edX service (such as LMS) and likely interoperates with other sites hosted by other Open edX services.
  • Examples of sites include:
    • LMS: https://courses.edx.org
    • LMS: https://mitprofessionalx.mit.edu
    • LMS: https://harvardxplus.harvard.edu
    • Otto: https://ecommerce.edx.org
    • Otto: https://payments.mitprofessionalx.mit.edu
    • Otto: https://payments.harvardxplus.harvard.edu
• Organization: 
  • An entity representing an institution, corporation, foundation, group, etc. with ownership of one or more courses.  
  • Examples of organizations include:
    • DartmouthX, MITx, HarvardX - edX Consortium members  (referred to by edX internal groups as "partners")
    • VJx - a "virtual organization" created to deliver courses produced as a joint venture by MITx and HarvardX together
    • MITProfessionalX, HarvardXPlus - "White Label" organizations whose courses are presented via dedicated sites and not via courses.edx.org

Some context

There has been some confusion regarding the concepts of Partners, Sites, and Organizations and how they work together in Open edX to yield a crude form of multi-tenant capability.  Several issues help to contribute to this confusion:

• Only a subset of services utilize the Django Sites framework
• Only a subset of services utilize the Partner entity concept
• Only a subset of services utilize the Organization entity concept
• The Otto (ecommerce) service does not currently feature an Organization model
• The LMS service does not currently feature a Partner model
• The Catalog service does not currently feature a Site model
• At present, only one Site combines and presents Courses from multiple Organizations to learners (LMS: courses.edx.org)
• There is no formal mapping between Site and Organization in any service
• There is no formal mapping between Partner and Organization in any service
• Several other similar-sounding concepts/entities exist throughout the Open edX system, including Group, Client, BusinessClient, and yes, Organization (Solutions/McKA repository)

Notwithstanding these issues, we are continuing to push forward with development of the system's multi-tenancy framework on an ad-hoc, as-needed basis, filling in the gaps on a use-case by use-case basis.  

As of this writing, the most recent development on the multi-tenancy front was the introduction of multi-Partner support in the Catalog service.  This new feature enables Catalog service indexing of data from multiple service endpoints (Sites) tagging each record collected as pertaining to a particular partner.  Clients are subsequently able to filter query results by partner short code.  Discussion was had around the proper concept to utilize in order to achieve the necessary type of data partitioning required for the use case.  Django Sites were considered (with addition of a new SiteConfiguration model), but decided against because the Catalog service is considered a "backend" data service.  We attempted to map the Organization concept to this partitioning, but the multi-organization scenario presented by courses.edx.org meant we could not easily use Organization in that context.  After reviewing our other services, we noted the concept of Partner was already present in Otto and seeing that it supported the multi-Organization case and did not require Django Sites to be implemented, decided it was the right entity to use for the Catalog service as well.

With the expansion of the Partner entity, we now have a concept available which could provide a common thread for workflows spanning across multiple services.  A Partner maps to our backend financial systems, and could function as a collection of one or more Sites, as well as a collection of one or more Organizations, which solves many of the above-noted issues.  We currently have an open question regarding the Source of Truth for Partners, and this is something we should answer before getting too much further along with the use of this entity as the meta-concept for our multi-tenant initiatives.