The pasta analogy of the evolution of software architecture has been talked about a lot. Today I finally find the time to mention that this analogy also applies to the educational technology architecture.
What is the pasta analogy of the evolution of software architecture? The following infographic says it pretty well.
In software engineering, spaghetti-oriented architecture refers to the lack of structure in the tech framework, which was very common prior to the 2000’s. At that time, if one needed to write a piece of software, they wrote it from head to toe without consistent structures (i.e. procedural code, not object-oriented). Also, if time was an issue, software engineers would copy codes from various existing projects, make modifications to suit the current project, then assemble the codes together. As a result, the source codes were intertwined and entangled (like spaghetti, hence the name) and difficult to understand or debug. Software with such architecture took long development cycles and has little reusability.
The educational technology architecture was also spaghetti-like in the 1990’s and early 2000’s. At that time, various learning media and technologies were isolated by nature but forcefully mingled together to assemble the curriculum. For instance, a multimedia desktop application had all its resources (e.g. videos, practices, tests, etc.) inside the software. The instructor had to declare in the syllabus that, for example, in Week One the students should read Chapter I and II of the paper-based textbook, finish Section 1 of the multimedia application, and complete a number of assignments in paper. Similar to software engineering, educational technology in the spaghetti architecture is also difficult to create, use, or transfer from course to course.
In order to manufacture software more quickly, software engineers used the lasagna-oriented architecture in the 2000’s. The lasagna architecture structures the software with different modules based on functionality, and each module was written with the object-oriented principle. The source codes were much more maintainable and reusable with the lasagna architecture because the modules could be used for different projects with minimal changes.
Educational technology also evolved to a lasagna-like architecture in the later 2000’s and early 2010’s. For instance, Moodle offered customizable modules that allowed the instructor to construct courses with various media types: hypertext, video, audio, etc. Those modules were consistent across courses, and the media assets were reusable. The students could conduct various learning activities in Moodle such as reading course materials (provided that the materials were digital), watching course videos, completing assignments, receiving grades, and so on. This was a major improvement compared to the spaghetti architecture because students did not have to switch back and forth between various learning media.
Supposedly, educational technology with the lasagna architecture should provide improved learning experiences. However, the reality is often found to be the opposite. For example, when I was a student I really hated Moodle. If there was an option to read the course materials outside Moodle - either in Adobe PDF on the computer or in paper - I would definitely avoid Moodle. Also, in the classes that I taught where I put course materials online, I chose Wordpress instead of Moodle despite the latter was labeled learning management system (LMS). The reason was Moodle attempted to cramp everything related to learning inside itself but every single thing was done poorly. Besides, every course looked the same in Moodle with many unnecessary features that made the user interface awkward.
Currently, the recommended software engineering practice is the ravioli-oriented architecture. In this architecture, the technology framework is much more flexible by packing related functionalities in loosely-coupled modules. The difference between a lasagna module versus a ravioli module is the former’s structure is much more rigid and UX is far from satisfactory when several lasagna modules are put together, whereas the latter is optimized for its own functionalities and various ravioli modules can fit together much better like Lego modules so as to optimize the overall efficiency and UX. The ravioli architecture is also known as microservice or service-oriented architecture.
Similarly, in educational technology the current trend is to separate the learning modules previously all cramped in a single technology frame (e.g. Moodle) into various independent apps that can work together well. Each of these apps provides a set of API to allow other apps to utilize its features flexibly and efficiently, so that all these apps can be integrated seamlessly into a single learning suite that adapts to the unique instructional needs.
One good example of the ravioli architecture in educational technology is Google Apps for Education. Google has a suite of apps that can be used for education including Google Docs for collaborative writing, Google Sheets for collaborative data manipulation, Google Drive for file sharing, Google Sites for online survey, Google Slides for presentation, Gmail for asynchronous communication, Google Hangouts for real-time communication, and so on so forth. A course or school may not need all the features provided by the Google Apps suite. But the instructor or administrator can choose what features they need and Google makes sure those apps will work seamlessly together.
Unfortunately, most of the educational software in the market does not work in the ravioli way. And even Goole Apps for Education have large rooms for improvement. For instance, Google Apps do not provide effective ways to scaffold critical reflective learning based on videos. And Google Hangouts does not offer the features such as channels, plugins, mobile optimization, etc. Educational users may want to choose Slack for those features that Hangouts does not provide. But Slack is not compatible with other Google Apps because it is not made by Google.
The ravioli-oriented architecture is the right direction for educational technology design. I am looking forward to seeing more and more apps created with this architecture that will allow teachers and educators design more adaptive and efficient tech-savvy courses for their students.