The answer is simple - automation is essentially a code, we use the Infrastructure as Code approach. More precisely, we have Infrastructure as Code as a development process, and this is not the same as Infrastructure as Scripts, as is very often the case. Accordingly, to simplify planning and work, we are starting to apply classical development practices: we are working on a component model of the code that describes our infrastructure, we are working on the formats and sequences of messaging in our infrastructure (for example, which script pulls which hooks and what transmits), we are building a release process for the infrastructure code, we are working on the feature backlog - in a word, we work with the infrastructure as if it were another component of the application.

For complex installations, of course, there may be more components. For example, from the "Application Configuration" one can often distinguish "Secrets", "Endpoints" and "Functional Configuration" (related to the application logic). Or a "Runtime" could consist of both "Virtual Servers" and "Orchestrator".

For each of these components, you also need to work out the corresponding change process. As we said above, depending on which way we chose to go, it can be either spreading instructions or automation scripts. Or in general, we will have separate services - they will manage these components and take on all the complexity. For example, if you keep secrets in Vault, the whole process of making changes to secrets will consist of at least two steps:

After the developed system is recognized as being in demand, the contractor must conduct an analysis of the feasibility of the project. But for this, it is necessary to supplement the concept of the project with a risk assessment, a technical solution, choose a development methodology, develop a preliminary work plan and estimate costs. Only after that it will be possible to understand whether we can implement the project, or whether compromises with the customer will be necessary.

Risk assessment is important because at the initial stage, many questions related to the system do not yet have clear answers. Having compiled a list of the most important risks and outstanding issues, the contractor can try to reduce the uncertainty, for example, by offering the contractor several different technical solutions. Thus, it will be possible to reduce uncertainty, reduce estimates of the required budget and deadlines, and, accordingly, increase the chance of winning the competition.

Particular attention should be paid to the requirements of system flexibility. Execution of dynamically generated code, dynamic scaling of the system, duplication of some components in order to ensure the reliability of the system - these and other similar issues have a very high cost. In my work I encounter them in every project. But you can almost always find an acceptable compromise.

When developing investment software or software that provides the vital needs of your own business, demand analysis takes on special weight. I remember that back in 2008, I negotiated with the head of the security service of AFK Sistema, who tried to force us to add special functionality to our “boxed” product. He was very surprised when he met my firm refusal. But I had my reasons: we had thousands of customers, and changes in our software affected their interests. By introducing specific features into our system, we would gain one new customer but lose hundreds. I explained our position to my interlocutor. In the end, we delivered our security system to AFK almost in its original form, adding only a small plug-in. And for their work, the team received a letter of thanks from the leadership of this well-known organization.

If you see that the implementation of the project violates the interests of your business, abandon it. For you, as a contractor, each project should be either a stepping stone in business development, or a reliable safety support for a rainy day. If the project does not become one or the other, it is not worth wasting your attention on it.

I hope it is clear that before the creation of the concept, it is impossible to analyze the demand. You must imagine what the system being developed will be in order to understand what level it can bring your business to.