I often come across the following situation: a new project is developed from scratch, the functionality to be implemented is more or less clear, it is built, delivered, and… problems begin because there is a large number of non-functional requirements that have not been taken into account (and which the client has not specified, of course).
I am not only talking about scalability, performance, maintainability, and all that is called the architectural drivers of any moderately complex software product. Developing a new project also means implementing all the features needed to keep it running in production, with specific functionality to check that everything is working correctly and with the traceability necessary to detect where and how problems arise.
All of the above is necessary but not sufficient.
What about all that functionality beyond what the end user sees and uses? I am referring to everything related to system operation, something of even greater relevance when the project is genuinely complex or has a large number of features.
Imagine a web platform such as Hub de Libros (the project in which I have worked most over the last year): users register, authors do too, reviews and ratings can be added, authors can indicate their works, create their own author website, users can select their preferred genres, write articles, hire services and pay for them, create bookshelves with collections of books, and a very long etcetera.
All that functionality, which is what a user perceives when using the platform, requires much more functionality that the user does not see in order to operate the system. In other words, a second completely independent application is needed to perform activities such as blocking a user, restoring a password, approving reviews, checking log records, managing all the internal details of the platform (task management, database performance, etc.), collecting metrics, managing features such as “author of the day,” obtaining all user emails to create a mailing campaign, sending a message to a specific group of users, deleting a book that an author published by mistake, and many other things of the same kind.
When a new project is published and many of these operational activities have to be carried out by touching database records, it means the necessary operation tool has not been planned.
To put it simply: complex project = functional requirements + maintenance and operation tools.
The system grows in users, traffic, and, fortunately, everything is going well and monetization begins: the end client (the owner of the project) then requires certain types of reports (how many users are there? how many accesses per day? etc.), especially if the project has been conceived from a lean perspective and many metrics are needed to decide what direction to take over time according to the results obtained.
More and more functionality… operational, of course.
Without going further, in Hub de Libros one can hire gigs for the execution of publishing services (editing, layout, creation of PDF/EPUB files for a new book, among others). Logically, gigs must be managed correctly so they are completed properly and the user ultimately receives what they contracted. By using Stripe for payments, it is also necessary to check economic aspects such as whether the payouts from this gateway are correct, among other features related only to service contracting.
For this, the operations system must implement all that functionality for its management: managing the notification of a new contracted gig, checking its payment, sending messages associated with the gig so the user reads them, and many other issues that no visitor to the website sees, but which are behind the operation of the platform and are essential.
I once read a comment (in my opinion rather candid and naive) from someone who wondered how Netflix could have hundreds of developers on staff since the “website” or application did not seem too complex. In any case, I bet much of that team is dedicated to implementing everything needed to operate the system and support the rest of the business, something far beyond what the end user sees when they subscribe to the platform and use it.
In a more or less complex system, it is difficult to communicate all this functionality to the client without them realizing it beforehand, especially when the features and needs related to operation are often greater than those offered to end users.
Implementing an operations application is necessary and vital for the success of a project, and it is not always thought about.
In particular, in Hub de Libros there is a second operations portal completely independent and decoupled from the user portal (admin.hubdelibros.com) that allows all of this type of operation to be carried out, and its development effort, I can assure you, has been greater than the portal seen by visitors when they access the website.
Implementing all this operational functionality in secondary applications means taking into account many security aspects at the same time, while that other system (or set of applications) must have access to the same repositories as the final system and, probably, to part of the functionality of the components that make it up. And this is not trivial, especially if you want a coherent system without causing that dispersion of independently implemented applications, something more expensive to maintain in the medium term.
This is one of the reasons why I implemented the Mantra framework (which I am currently documenting to release on GitHub): a framework that takes into account, from its base, among many other features, that the same component can implement both final functionality and operational functionality without breaking system consistency and facilitating maintenance.
Remember: the operational functionality of a system is as important as the functional requirements the client demands.