Introducing the project

Now is the time to introduce the project we will be developing as we work through this book. The project brief is to develop a learning platform to promote research into societal and economic resilience. The Moodle instance we will be working on forms part of a much larger product landscape; so, it is vital that the Moodle we will be helping to develop integrates seamlessly into this landscape. Not only that, but there are features required of the e-learning platform itself that a vanilla Moodle doesn't support. For that, we will need to develop features to support learner management (one requirement is that authentication is via WordPress), course management (for example, access to materials based on your location), and novel teaching interactions (specifically, a three-dimensional model viewer). However, rather than presenting the details of the entire project at this early stage, we will be introducing features as they are required.

As a developer, don't be concerned purely with creating code. All the world's best designers, architects, builders, and planners have an appreciation and understanding of where they are coming from and where they are going; the art is knowing where to start and the science is in the planning and execution. In the rest of this section, we discuss the importance of planning.

Planning is everything

Creating a new Moodle installation doesn't just involve configuring servers and installing software. That's just a very small part of the process. The most important part of the process is planning. Before you can plan, you have to understand the environment (that is, the people and the organization) that you are planning for. It is best to design your new server architecture in baby steps:

1. Audit the current environment, that is, your whole organization: How is your network configured? How will the new Moodle be accessed? How will the new Moodle interface with legacy systems? Will Moodle work at all?
2. Produce an options analysis: Designing a new architecture is a problem, not a puzzle (puzzles only have certain solutions whereas problems can have many solutions, some more effective than others). Each potential solution will have benefits and risks; these need to be understood.
3. Recommend a solution: The preceding two steps will make it clear why you have reached your particular recommendation.

Only when you reach an informed decision on which architecture you will implement, should you go ahead and implement it.

Obviously, how rigorous you need to be during the planning stage will depend on the organization you are planning for, still preparation is everything.