2.1 Metaphors of the Ecosystem
This chapter details the research made into metaphors that were used to model the system in abstract. Metaphors employed here are primarily devised so as to imbue a coherent meaning for the whole project. As such, it represents general background knowledge that informed decisions made throughout the project. They formed the grounding for the architecture derived which in turn influenced and justified the design decisions made. Throughout the rest of this thesis, I'll be invoking these metaphors to explain why certain trade-offs were made. Here's how they formed the hierarchy that influenced the decisions made throughout the project:
[Metaphor informs architecture informs design principles inform implementation.]
2.1.1 Metaphors We Live By
A metaphor is typically defined as a literary device used for suggesting resemblance of one thing to another. But George Lakoff and Mark Johnson in their seminal work 'Metaphors We Live By' [MWLB 1980] advance the idea that our metaphors are pervasive not just in language but in our thoughts and actions. They argue:
"Our ordinary conceptual system, in terms of which we both think and act, is fundamentally metaphorical in nature. The concepts that govern our thought are not just matters of the intellect. They also govern our everyday functioning, down to the most mundane details. Our concepts structure what we perceive, how we get around in the world, and how we relate to other people. Our conceptual system thus plays a central role in defining our everyday realities. If we are right in suggesting that our conceptual system is largely metaphorical, then the way we think, what we experience, and what we do every day is very much a matter of metaphor."
Thus a metaphor has the power to drive the conceptual understanding of a user. Computers and the processes inside them have been compared to a lot of metaphors in the past, one that I think that gets closest to the real nature of the device is one by Alan Kay [CS 1984]. He compares it to the ultimate protean system, one that can take any shape or form. He writes:
"The protean nature of the computer is such that it can act like a machine or like a language to be shaped and exploited. It is a medium that can dynamically simulate the details of any other medium, including media that cannot exist physically. [sic] It is the first meta-medium, and as such it has degrees of freedom for representation and expression never before encountered and as yet barely investigated. "
This remains true even today since the fuller capabilities of the computer hasn't been fully understood or explored yet. It follows that a computer can be programmed to fit virtually any context or use case. The one that I think most befitted this dissertation is to visualise the world as two. I view user facing end of the software which includes the user interface, information architecture and everything that the user interacts with as a universe. This is where the name NCLVerse is derived from. The other world which realizes this universe is that of computations. This is modelled using a centralized client server architecture. These metaphors were responsible for informing the why behind certain decisions.
2.1.2 Building an experiential gestalt
Lakoff and Johnson also introduces an idea known as experiential gestalt in their book. They contend "that a cluster of components are experienced as a whole by human beings which they find more basic than the parts."[Lakoff Johnson 1980] This directly references the work of a prototype done by Rosch [Rosch 1978] in her work on categorizations done by humans. A recurrent complex of properties, our concept of causation is at once holistic, analysable into those properties and capable of a wide range of variation. My aim in structuring this system has to enable a coherent whole whose sum is different when put together than the individual parts. This has been realized with the help of recurrent patterns carefully positioned throughout the ecosystem.
Though it might look like these models were figured out foremost and the truth is quite the contrary. The apps were retrofitted in the end when the final architectural fit was realized. The architecture had to be grown along with the work and it was only with frequent stepping back and revaluation that I was able to figure it out as it stands now. This emerged only after a lot of experimentation and constantly evolving the architecture over time to accommodate the discrepancies. Even then the architecture as it currently stands is not to be held as absolute and constant pruning and controlled evolution is required to adapt it to newer apps and accommodate evolving user needs. This means that the design guidelines and models outlined for software development in the next sections are to be evolved along as new apps are designed and never take them to be steadfast rules.
2.1.3 The Two worlds
The products delivered for this project encompass two different worlds: The user facing interface of the system and the underlying world of computations that enabled this. The nature of these two systems, I have come to realize over the course of the dissertation are very different.
[Insert picture here]
This is a visualisation of how I model the two systems: The upper layer being the front end user facing side of the underlying structures. The dissertation will talk about how the ideas and concepts of the first world are more cogent than the logic layer that lays hidden beneath. It can also be reflective of where my strengths and weaknesses lay.
The Visual World
The first world is that of the user facing end of software. This comprises of everything visual as well as the not so visual (UX) part of the system. While visual side of software allows for infinite imagination it is constrained by the underlying world of processes constraints it because of the limits of the computation.
- Orbits as Courses
- Modules as planets
- Solar system as stages
- Departments as galaxies
- Galaxies form Universe
The view adopted here is that of a universe and the student an astronaut. I visualise each orbit as a stage of a course that student progresses through. A set of these courses can be taken as a solar system and a composition of these solar systems form a galaxy which has been mapped on to a department. All the academic faculty of the university can thus be thought of as a composition of a large number of galaxies. Inorder to make this concrete, Computer Science can be thought of as the galaxy in which G400 is a solar system in which modules are planetary objects that rotate in their course. This is where the name of the project is derived from.
The Computation World
While the user interface of the systems takes the shape of a universe, these are built on a substrate of complex underlying systems where things are very fragile if care is not supplied. This is because of the nature of software development which is ever changing and could potentially lead to breakdown of whole software ecosystem if they are ever allowed to unmonitored changes. Though the software development methodologies presents many ways to organize this complexity, the basic nature of software breaking on interaction with it is still incumbent. This is partly because Computer Science is an emergent field which is still not fully understood by humans, while various methodologies have been proposed to solve the software crisis (Refer Out of Tarpit and Formal Verification Here) no single solution has been proved to be superior.
Given the case it was of much importance to hedge against the brittle nature of software and the environment of constant flux software work against. After evaluating these criteria the model that seemed most fit was to use the model of a centralized client server model.
Rosen and Shklar in their book Web Applications Architecture [Shklar Rosen 2009] describes the server model as:
[In a client-server model], servers … execute by waiting for requests from client programs to arrive and processing those requests. Client programs can be applications used by human beings, or they could be servers that need to make their own requests that can only be fulfilled by other servers. More often than not, the client and the server run on separate machines, and communicate via a connection across a network.
This model albeit in a centralized fashion with a single server at the heart of the services that acts as a data store with all the other applications acting as clients to this service is the model this thesis propose.
The central data store for communication is named Ivory Tower (another name for Tower of Babel from the Bible). This abstraction is the core data store from which the programs acquire their data over wire and execute respective computations. It is to be noted that even though all the current applications in this ecosystem are written in a single language, this architecture affords polyglot development and diverse styles of programming. This was one of the primary decision drivers behind building the central abstraction known as the Ivory Tower which can be enabled to transfer data in any message exchange format.
Thus these two worlds, universe on the user facing side and a centralized server and clients model in the developer facing end of this ecosystem are the two metaphorical lenses through which the design decisions framework adopted for this thesis make sense.
2.1.4 On the dangers of metaphors
Like any metaphor, the ones adopted here conceal some facets of the idea while revealing others. Leslie Lamport has an incisive essay on why the metaphor of biology is limiting in the sense that it gives an amorphous definition to programs that is inherently complex and not understandable, in this sense, metaphors we use to understand the systems can be insidious. As mentioned in the essay, the metaphors we adopt to describe the systems might take us to a cul-de-sac.
Full evaluation of the drawbacks of these metaphors are has not been fully determined due to the limited time scope of the dissertation. Healthy skepticism is to be maintained whenever an idea or a new concept is introduced into the system. As mentioned earlier the models are not to be held absolute and the need for excessively shoehorning a new application into the system is quite possibly revelatory of the inadequacy of the model adopted, a better approach would be to evolve the current conceptual model so that it can accommodate them. This is described in the next section which details about the architecture.