The business model of MySyllabi is to recruit user on to the main site and have their administrators pay for the right administer activity of their faculty. These decision making administrators value control over their user base as well as control and security over the contributions they make. This translates into a needed file per contribution. Much like email, each indexed record must be a tangible file separated from the database of the system. This need stems from legal concerns just in case problems arise over employment or mis-dealings among the teacher, parent, student relationship. In addition, the MySyllabi model works along the back-end infrastructure to provide email functionality in combination with content management functionality so that we are not creating a new budget for these decision making administrators to pull from. Schools already have email systems in place and tech coordinators that run maintenance on these systems. What we are providing schools is a superior product that has substantially more functionality.

Significant data migration must take place when a school or district makes a purchase. This includes resources created, teacher, parent, and student accounts created, messages created, etc.. From the purchase day on, everything affiliated to the school must be hosted on the schools server and administrative rights must be deemed to school officials in order to monitor, edit or delete these data files.

The key here is how these school satellites communicate with the MySyllabi main hub. Index information must be shared from the school to the main hub in order for the masses of the education community to share. Upon receipt of this information from schools, the main hub compiles data and displays relevant links to users across the nation. When these users click on these links they are actually viewing information hosted on the school's/district's server (mirror). However, proper back strategy should be in place on the main hub just in case someone accidentally kicks a wire in the school's server room. The system must be designed so that certain information (parent and student data) is not available to the masses but valuable, collaborative teacher data is freely available to the masses.

Because we are dealing with independent files instead of records in the database, a form a DRM can be imposed on resources created for the system. We can take advantage of parent data to reflect accolades towards original authors. We can also allow a pulling from the tree mentality for teachers users who like a particular resource but want to tweak or customize it just a bit for their parent/student audience. This ”pull from the tree” philosophy centers around a users functionality to relay or borrow great resources they find while browsing throughout the site. When a uses relays a particular resource, a duplicate child copy is made from the original file and content transport takes place from one school server to another or from the main hub to a school server, or from a school server to the main hub, depending on whether the consumer and/or the author has a school who is paying a subscription to MySyllabi. When a user relays a particular profile onto her classroom page, then a new file is created that acts as an agent that simply mirrors the original file in sync. This mirroring agent can also be created when a user relays a resource from an original author who sets privileges to “no-editing”.

The system is very similar to a file-sharing architecture however it complements email transmittal functionality directly. Version tracking is available for each file in order to allow users to edit from existing content.