2 Design

Original design

The design of the new project “Endeavour” (unofficial name) closely follows the original one designed previously, discussed last time in the ITC meeting 2014.

The main points that have been kept are:

• Usage of LDAP structure in spite of a single, unified database strategy;

• Having a “backbone” that processes all requests and replies accordingly;

In particular, the single database architecture was discarded to achieve more modularity and let the “backbone” architecture possible.

The original concept of OMS was to first achieve a MVP (minimum viable product, i.e. a first prototype with core functionalities) called OMS-basic. The OMS-basic would be constituted by “OMS-core” and various “OMS-modules”, which would conversate then between each other. Every module does not know of the existence of other modules: it just requests to the core whatever it needs and offers services to the user.

Introduced design elements

Since technology has tremendously changed ever since last design took place (anyway things change every year or 2, now!), a change in architecture design has been made. The main change is the introduction of REST API.

The change is important for several reasons, namely:

• It helps achieving the goal of the “backbone” serving all the requests;

• It gives more motivation for people to join the project, as it is a trend for companies to ask experience in creating APIs, or RESTful applications;

For a better insight on what is REST, read this introduction I wrote, and modify it accordingly if it is unclear.

Likewise, the other change introduced is the usage of Node.js instead of PHP as a language for the project. Again the reason here is:

• Current job market trend;

• More modern than PHP, with the consequence that it is designed with all the features needed in a year > 2010 (e.g. scalability);

EDIT: the language is PHP again, however with the help of the most spread framework "Laravel"

Tools

Other minor, but important, factors to take into account is also the methodology used for the development, and the tools involved for such methodology.

With the advent of git, in first instance, one could use a truly collaborative and easy to learn tool that helps to track changes of a project. Read this introduction about git, and modify it accordingly if it is unclear.

Among the many methodologies, the one that makes the use of git powerful is the Agile methodology - the most important principles that it is good to know are the following, taken from the Agile principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. (!!)

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Consequences

As a result of the first change, one does not need to learn Node.js (javascript) if s/he doesn’t want to. Although it is encouraged to do so --both for maintainability and for improving skills wanted in the job market--, any person can come up with a piece of functionality in any language, as long as it respects the standards of communication between core & modules (i.e. uses REST calls, or in other terms “is RESTful”).

Suggested technologies ranked in terms of “easy to learn”:

1. Node.js (javascript)

2. PHP

3. Python

4. Ruby on Rails

Suggested technologies ranked in terms of “employability”:

1. Node.js (javascript)

2. Python

3. Ruby on Rails

4. PHP

Further design adjustments

Once the first prototypes of the oms-core and a module for membership management have been implemented, one of the participants to the project suggested a shift in architecture. Such changes do not come too late within the project, because as we learn from Agile, if something is needed it will be put into the project no matter what.

The architecture conceived was a monolithic core handling the requests. The change will make the core being a federation of microservices instead (à la Google products: drive, mail, keep, youtube, calendar…). To be more precise: these products are equivalent to the modules; my example refers that the service that stores and provides such information (events for calendar; notes for keep;...) are not in a single core service, but in various micro services that communicate among each other, and communicating externally with the modules --this way, effectively making the “backbone” still logically there, but not composed by a single program.

The advantages brought by this kind of architecture are quite a few, namely:

• If one service goes down (e.g. events) an user can still access other services (e.g. profiles)

• Even more modularity allows people to work truly independently and with absolute no knowledge of the other functionalities, as long as their interfaces (through API) are well-documented

• Changes that a team performs on their functionality cannot affect other code already existing and working