On the subject of how to manage innovative projects in software, a few weeks ago, I wrote about how it is necessary to adopt an agile approach, and how this would be an advantage for the success of the initiative.

Well, an agile approach is necessary, but not sufficient: an agile management of the project must combine the use of technologies that are based on the same principles, so that these will not only be a tool for the implementation of the product / service but also an enabling factor to support the management of the project.

The database is often a key element in the design of a new system. Up until recently this choice allowed for a few alternatives, more than anything based on the vendor to rely on. For the rest, it was obvious to use a relational database, the so-called RDBMS.

A relational database requires great attention in the design of the data structure and of the relationships between these: it is necessary to have a complete and detailed vision of the project's business objectives in order to be able to design the data structure. An oversight, an error or simply, a slight change in the business needs occurring during the project often results in significant changes, both on the database structure and on the application code already written, with the obvious consequences on the project in terms of time and additional costs.

 All this is not matching well with the use of agile methodologies, for this reason we are witnessing today a real revolution in the sector: after having dominated for several decades, the supremacy of the RDBMS is being challenged by the so-called NoSQL databases, which are established on the market because of their flexibility characteristics without having anything to fear in terms of performance, safety and scalability. There are different types of NoSQL databases, each one designed for a specific need: document, graph, key-value, etc. Among the most common are those of the document type, whose design criteria are radically different from those of relational databases. Some are the following:

• The concept of a record, that is a fixed and predetermined set of fields, is replaced by that of a document: a data structure whose complexity can be defined at will, which is memorized by associating it with a unique key.
• The concept of a table, that is a set of homogeneous records, is replaced by that of collection: a set of documents that are not necessarily homogeneous with each other.
• The concept of relationship, that is a fixed and pre-established link between two tables, is extended by that of sub-document, so that one document can be contained in another in hierarchical mode.

The availability of a technology based on document and collection allows it to design the data scheme in a dynamic way, allowing changes to the data structure during the various phases of the project without it having repercussions on existing data or on the already written code: an advantage significant for the budget of a project.

The concept of document then finds an ideal correspondent in the concept of object that is the basis of object-oriented programming now used in any language: this simplifies the use of OR mapping frameworks to the advantage of simplicity, maintainability and system performance .

These are only some of the peculiar aspects that make the use of a NoSQL database advantageous. There are many others, such as horizontal scalability, that is the ability to distribute the workload between multiple servers in a native way and with a minimum effort in terms of configuration and management (who has at least once in a lifetime had to configure a RDBMS cluster knows how delicate and burdensome this aspect is).

Adopting agile methodologies for software development projects is therefore not only an organizational topic but also a technological one: it is necessary to identify and select suitable technologies, otherwise these will prove to be a formidable obstacle that can seriously undermine the chances of success of the project. In this sense, in addition to the Project Manager, a key figure is that of the Software Architect, which is responsible for the technical choices and, increasingly, must have among his skills the ability to evaluate options not only for the their intrinsic technical value but also for the implications on the other aspects of the project.