Development of the system ​

Informal work on the conception of a new system usually starts long before the formal start of the first project in the works on creating and developing the system (the first project life cycle in the full life cycle of the system, if we stick to the old terminology of creating a single system without its development). The idea of the system gradually emerges, and its exact beginning is usually difficult to determine. In fact, the project starts when the visionary and the businessman agree: the visionary believes that the solution proposed by the engineers can be profitably sold, and the businessman believes that it will be beneficial for the company - it meets the strategy, does not divert resources from other activities, does not bring any reputational losses, does not scare off investors, etc. (the visionary looks at the product and the customer base, while the businessman focuses on the company and the investors).

In the latest version of ISO 15288:2015, a new practice "6.4.1. Business or mission analysis process" even appeared. The essence of this practice is to understand what system-of-interest the team is going to make, and to determine if it is worth making at all, if it aligns with the company's strategy, whose team will execute the project. Although ISO 15288 reflects the "waterfall" in terms of stages and the V-diagram in terms of practices, but even a single completion of the life cycle (without system development) has to start somehow! At the project launch, the concept of operations (OpCon or ConOps, concept of operations) is prepared, but to understand whether the system creation is utopian, evaluations and system concepts are conducted (since it's possible to write an excellent concept of operations for a magic carpet, but then discover that there is nothing to build it from, the system is utopian).

On today's date, the end of the system's life cycle is usually not planned, although expectations for the release of the first version of the product can be discussed (usually this is the MVP - minimal viable product, which will then be further developed).

Subsequently, the system may be modernized in a way that nothing of the previous system realization remains. Take a mop, after some time the handle breaks, we change the handle, then we change the rod - is it still the same mop? Yes, it is the same mop-system (the functional object is the same!), only some modules and constructive parts have changed. A mop is defined by its functional description, if you replace the content with specific modules or even change the allocation, nothing terrible will happen to the system - it will continue to exist. The telephone remained a telephone, even though there are no longer wires, receivers, dial buttons, not a single element of the classic telephone that has been around for over a century. But the function of transmitting sound over a distance remained: tele (distant) phone (sound). Although this is no longer the main function, phones stopped ringing and are used as internet access terminals - and calls are massively replaced by chats.

Microsoft announced that Windows 10 would be its last operating system, yet continuously makes changes in it (the release of Windows 11 was widely discussed as having purely marketing value, changing the name did not significantly alter the product itself, moreover, changes in Windows 11 proceed in a similar way as in Windows 10 - programs and functionality slowly change, but the name of the product remains unchanged. Simply, some programs within Windows are gradually replaced by others, this has been happening for many years). The service life of nuclear power plants was initially set at 60 years, but now it is being extended to 80 years with partial upgrades - while some countries want to get rid of nuclear power plants, others want to develop nuclear energy. Tesla came up with software changes for the car, supporting its value through in-service upgrades, Tesla electric cars do not need to be sold in time, they do not become morally obsolete: this is a change in the business model of the automotive industry.

The life cycle of a system turns out to not contain a clearly predefined number of projects before decommissioning/destroying after use, and may not have a specific end date. Therefore, the concept of a "life cycle" ceases to be important. We can talk about the life cycle of a dinosaur organism, but it is more difficult to talk about the "life cycle" of the dinosaur species, which gradually, over ten million years or a little longer, transformed into a bird. This is already the "evolutionary process" (system development, changes in the genome leading to changes in the phenotype), rather than the "life cycle" of creating a single system (the genome is manifested in its phenotype, the phenotype is "pimped" and used - and that's the end of the story).

Even a terminological collision occurred in the nuclear industry: lifecycle management is not referred to as the practices of managing the life cycle from a systemic approach, but as practices of extending the operational life of nuclear power plants^[1]! Fortunately, as knowledge of systems thinking spreads among nuclear industry workers, the meaning of the term changes to the commonly accepted one.

Another variant of presenting the life cycle is associated with this "never-ending/open-ended development" - as timelines in the release of versions of a certain system, a roadmap. This term came from project management^[[In project management, this is a diagram of the main project checkpoints, https://www.productplan.com/roadmap-basics/], but is increasingly used to show approximate release dates of system versions. Here is an example of a life cycle focusing not so much on engineering or management practices, but on entrepreneurial practices - combined with a roadmap (showing three products of different readiness levels).