What Can a System Analyst Become?

The hosts open with an anxious question: who is a systems analyst, can a team cope without one, and will the profession exist at all in the future. They introduce their guest as someone who did systems analysis himself only briefly, yet knows architecture, people management and the running of IT. Alexander describes his remit briefly: client interfaces, marketing and engagement, meaning everything through which customers, and even non-customers, interact with the company — online advertising, the mobile app, the web. On top of that comes the architecture function: making architecture and design better across the company. Asked what architecture actually is, he says books on the subject often spend their first fifty pages on the definition alone: a system consists of parts, the parts interact, and changes to them are expensive and poorly reversible. Design, then, is a way of thinking in advance about what is coming and picking the optimal decision.

His own year as an analyst Alexander recalls as a mix of systems and business analysis: he had already been a junior developer, had gone on to a master's in systems analysis and management, and his manager was the operations director. The domain was planning desktop assembly: inside one group of companies the larger firm sold components, the smaller one assembled them into machines for retail chains. A large, branching in-house system supported spare-part sales well, while assembly was bolted on the side: you would agree to ship a hundred and fifty machines, and a neighbour from the larger firm would sell the processors you had promised. It ended with a verdict from the IT side — nicely thought out, but we will not build it: the junior company's turnover was a tenth of the main one's, and the changes would not pay back the engineering team's cost. Hence his decision to own delivery himself. Pavel tells a mirror story: he skipped programming and analysis, landed straight in solution architecture and left because his designs shipped years later or never. The CTO role, Alexander answers, is exactly what joins design to responsibility for delivery, though holding a managerial and a technical focus at once is hard.

The advice to try project management Alexander broadens: working in project mode is useful for an engineering manager and a CTO too. Every tool has limits — people argue about the product approach, Scrum, Kanban, SAFe and LeSS — and a project works well where scope and date are fixed and a team exists. Most of the bank's products were launched that way: the first version as a project, first investments together with a partner, then a broker of their own, and only afterwards did hypotheses appear inside the product and the product approach begin. There are also horizontal projects such as a rebranding or a design change, which somebody still has to drive. An analyst deeply immersed in the domain, with lines to all the stakeholders, can take on project management — there is no rocket science in it, he says — and act as project manager, then as product owner later on; an analyst, he adds, can play almost any role, given the skill.

In a product the responsibility shifts: not a project delivered on time, but the audience, scenarios, economics and development plan. The guest lists approaches from memory — user stories, customer journey maps, jobs to be done — and remarks that IT is cyclical, re-dressing ideas like a shop announcing that pink is now the favourite colour. Other trajectories: an analyst who understands a complex system better than anyone becomes its technical product manager, while one who knows a platform's building blocks becomes a solution architect, the person a business line is brought to with a request, who knows what exists out of the box and what extending a scenario costs. Asked by Esenia about fashion, Alexander answers that there are no ideal solutions, only trade-offs and an understanding of the current limiting factor. His example is the Apple Newton, whose handwriting recognition was built, as he puts it, by people from Russia: the concept was right, but thirty years ago the technology could not carry it. Products, he observes, live differently: some close because they stop being relevant, while others suddenly need three times the features because the former market leader walked away — and needed them yesterday.

Alexander has largely swapped books for white papers: instead of two to four hundred boring, repetitive pages, ten pages you work through with a pencil, tracing the connections, with more insight at the end. A host objects that a white paper has already passed one filter, its author's. In the guest's bag there is a Google study on AI-enhanced API design: one group of engineers was given a process and linters, another only the process, a third neither, and the first produced significantly better specifications with comparable people. In the final part, specifications written by a generative model were rated by about ten experts with some two hundred years of design experience between them: so far the model writes them poorly, but as an assistant it noticeably amplifies the author. Hence the hosts' question: if AI writes specs, what is left for the analyst? Alexander advises not fear but getting used to a human plus a computer doing more; his own worry lies elsewhere — juniors are left without the simple tasks on which seniors grow.

The talk turns to how development is organised: Western big techs are moving towards a model with engineers and managers and nobody else, which means security, data and quality have to be platformised, leaving a team with contracts, integration points, reliability metrics and a basic grasp of threat modelling. The strength of analysts Alexander illustrates with Vanya Puzyrevsky, CTO of Yandex Cloud: there are few analysts there, but they take apart regulated areas and translate bureaucratic language into human language for engineers. The counter-example is his own department: while experiments in web and mobile served several internal customers, analysts covered the requirements, but rolling the A/B platform out company-wide meant assembling the concept from white papers by Google, Microsoft and others, and rebuilding the teams. There is no universal definition of a strong analyst: there is systems thinking, Meadows's primer on it, and the typing of roles Olya Tsyganova began — a technologist up to grade 14, then a choice between systems and business analysis.