System Analysis and Design *

It's a strange question to ask in 2026, when agents are at the top of most companies' agendas and calling yourself "AI-native" has become almost mandatory. Against that backdrop, process excellence sounds like a phrase from another era, when any system rollout was preceded by a separate phase: processes were described, aligned on, and prioritized, and only then would anyone decide what to actually automate.

And yet, the closer you look at how companies are currently deploying AI, the more you get the sense that we might be about to rediscover something we quietly skipped.

In the previous article I described my “anime factory” in detail — a pipeline that automatically turns episodes into finished Shorts. But inside that system there is one especially important module that deserves a separate deep dive: a virtual camera for automatic reframing.

In this article, I will break down not just an “auto-crop function,” but a full virtual camera algorithm for vertical video. This is exactly the kind of task that looks simple at first glance: you have a horizontal video, you need to turn it into 9:16, keep a person in frame, and avoid making the result look like a jittery autofocus camera from the early 2010s.

But as soon as you try to build it not for a demo, but for a real pipeline, engineering problems immediately show up:

Hi, Habr!

Over the past few months, I have been building a system that I internally call an “anime factory”: it takes a source episode as input and produces a ready-to-publish YouTube Short with dynamic reframing, subtitles, post-processing, and metadata.

What makes it interesting is not just the fact that editing can be automated, but that a significant part of this work can be decomposed into engineering stages: transcription, audio and scene analysis, strong-moment discovery, “virtual camera” control, and a feedback loop based on performance metrics.

In this article, I will show how this pipeline is structured, why I chose a modular architecture instead of an end-to-end black box, where the system broke, and which decisions eventually made it actually usable.

When the question of describing a system's architecture arises, there are several main solutions for where and how to do it. Among the popular notations for visualizing architecture diagrams, one can choose C4, developed by Simon Brown.

In this article, I want to show an example of applying the C4 notation, which you can use as a guide in your work, as well as tools for creating it. In particular, I highlight Structurizr.

This article is useful for system analysts, architects, developers, project managers, and anyone involved in creating and making decisions about project architecture.

What is a sequence diagram? What does it consist of? Where and how to use it?

Sequence diagrams in simple terms.

And there are also interesting features here that you might not have known about.

Cars are among the most technologically advanced consumer-level devices on the market. They have been shaping lifestyles, laws, supply chains, and many other aspects of human society's evolution.

But today, we’re witnessing a silent revolution – one driven not by hardware, but by software. Modern cars are no longer just machines; they’re dynamic, evolving platforms powered by code. This transformation is reshaping every aspect of the automotive industry, from design and manufacturing to ownership and recycling.

In my latest article, I explore six levels of evolution brought about by software’s growing role in vehicles and related fields:

Capabilities - Over-the-air updates and digital twins unlock new features and extend hardware lifespans.
Design - Digital platforms replace manual processes, enabling faster innovation.
Architecture - Modular systems open doors to new partnerships and revenue streams.
Engineering - Agile, feature-centric paradigms align hardware and software development.
Manufacturing - Factories become dynamic, software-driven ecosystems for flexibility and sustainability.
Lifecycle - Software extends vehicle lifecycles, from supply chains to closed-loop recycling.

This transformation isn’t just about technology – it’s about reimagining the industry itself. Do we need a revolution to achieve a better, more sustainable future, or do we already have the tools to evolve?

The automotive industry is at a crossroads. For engineers, it demands fluency in code. For industries, it requires agility. For the planet, it offers a roadmap to reconcile mobility with sustainability.

The road ahead is coded, but the destination is open-ended – shaped by collaboration, innovation, and the choices we make today.

In recent years, discussions about the environmental impact of information and communication technologies (ICTs) have largely revolved around hardware — data centers, electronic waste, and energy consumption. However, an equally important factor has been overlooked: the software development methodologies themselves.

When I read the UNCTAD “Digital Economy Report 2024”, I was struck by the complete absence of any mention of how programming methodologies impact sustainability. There was no discussion of whether developers use algorithm-centric or code-centric methodologies when creating software, nor how these choices affect the environment.

This realization led me to introduce the concept of Eco-Methodological Sustainability — a new approach that highlights the role of structured software development methodologies in shaping an environmentally sustainable future for the digital economy.

Have you ever struggled to turn business ideas into a product? Or tried to understand the way another team works?

If you have, you know how exhausting it can be. Different ways of thinking –business, analysis, and engineering – don’t always fit together easily.

This article blends a simple story with engineering tools to show how creativity and structure can work together. Using characters like The King, The Troll, and The Prince, it explores how storytelling can help solve tough problems and make complex ideas clearer.

If you’ve ever faced a "troll" at work, this story might help you see things differently – and maybe even make the process a bit more fun.

I always pay attention to assessing the complexity of programming in a particular language. Programming is indeed not an easy task and this is perceived as a fact and usually does not require any confirmation.

But the concept of “complexity” is akin to the term “heap”. For some, five coconuts is not so much, but for someone who ate one and “didn’t want any more,” this means that even one coconut will be too much for him.

The same goes for the complexity of programs. It seems that the constant increase in the complexity of programs is obvious to everyone and is observed in all areas of application of IT technologies, and programming languages themselves become more and more complex as they develop, but assessing “complexity” using numerical metrics is a problem. obviously a thankless task, but also “You can’t manage what you can’t measure...”

Typically, talk of “complexity” only implies value judgments without any numerical evaluation. And since I am personally interested in the issue of the complexity of programming languages, I decided to calculate the complexity of implementing the gcc compiler on some conditional “parrots”. What if we could see some patterns of difficulty changing over time?

Modern product development demands more and more sophisticated designs. This in turn leads to the increased complexity of both demand and implementation. Business is flooding the architecture and development teams with the new and changed requirements. Development teams are struggling to understand what the business demand is and find the best product increment strategy. One of the widely adopted conversational methods is the Use-Cases. This guide is intended to shed light on the process of the requirements development and maturing.

Introduction to ADRs

ADRs are critical for documenting architectural decisions in software projects. They provide a historical record of decisions, rationales, and impacts, vital for future teams and stakeholders.

Defining ADRs

An ADR is a document capturing key architectural decisions along with their context and consequences. It helps stakeholders understand why certain choices were made during a project, promoting transparency and clarity.

Multidisciplinary project emerges when multiple teams with different expertise areas join to create a product. Despite the fact the product development is not something happining merely my a wish, product leads often perceive it as an easy walk. Usually this easy walk becomes a crash course. Let's uncover what leads to crash and what is necessary to succeed.

Generative AI is creating waves in the way we work, significantly revolutionizing the software development process. AI tools are appearing in various phases of software development, such as design, development, and testing. However, there aren't many tools specifically focused on software business analysis tasks.

But with a little creative thinking, we can put "one-size-fits-all" applications like ChatGPT to good use. It can definitely speed up execution of many typical tasks and free up analysts to focus on the more challenging, strategic aspects of the job.

This article is written in a how-to style. It is based on my personal experience and opinions, so it may omit some steps that are common in BPM practice but that I have not encountered in my work. The topic is broad, and each section deserves a separate article. Therefore, if you are interested in a specific topic, please comment, and I will prepare a more detailed description.

Background

As a product manager with over a decade of experience, I'm always looking for new ways to enhance my skills and help other product managers advance in their careers. One area that many companies focus on during the job interview process is analytical and creative problem-solving. And as product managers, we encounter these types of challenges on a daily basis. It's important to stay sharp and continuously develop our problem-solving abilities. That's why I made it a habit to practice a logic puzzle every day. But I also wondered if there was a common approach to solving these puzzles. That's when I discovered TRIZ – the Theory of Inventive Problem Solving. In this article, I'll provide an overview of what TRIZ is and how it can be applied in product management. Then, I'll apply TRIZ principles to solve a series of logical puzzles, showcasing the power and effectiveness of this methodology. So whether you're an experienced product manager looking to enhance your skills or someone who enjoys a good brain teaser, read on to discover the power of TRIZ!

If you find TRIZ to be a useful tool for problem-solving and innovation, there are many resources available to help you delve deeper into the methodology. The TRIZ Journal, for example, offers enough information on TRIZ, including case studies, articles, and other resources. You can also find books and online courses that provide a more in-depth look at TRIZ and how it can be applied in different industries and contexts. So if you're interested in learning more, there are plenty of opportunities to expand your knowledge and apply TRIZ to your work.

Most of the processes that people use in their work lives can be represented as some object that goes through some flow. Each flow contains many stages, in each one of them the object can be manipulated by certain group of users.

In this article I want to suggest an approaches to effectively handle such flow based systems. 

Conference participation is one of the most important practices for professional development. Hence, Innotech is actively sending out both its speakers and listeners for the biggest events. Senior Analyst Anastasia Kochetova shares her impressions from the Analyst Days/14 conference.

This is a set of chapters for young engineers. We give practical advice and discuss goals, challenges and approaches used in modern software engineering.

Along with classical foundations this article contains original ideas of conceptualizing engineer's work with emphasis on bringing order to the situation and finding an insight. Engineering is approached as work in uncertainty with other people which requires special skills. Non-obvious complications regarding modern production in big companies are discussed.

This article is based on 15 years of experience in engineering and management in high-tech industries.

Microservices Architecture is a well-known pattern for building a complex system that consists of loosely coupled modules. It provides better scalability, and it is easier to develop a system in multiple teams so that they don’t interfere with each other too much. However, it is important to choose the right way of communication between the services. Otherwise, this kind of architecture can do more harm than good.

The step has been made. Not sure where to, but for sure from the point of no return. Keep calm and keep walking. It is about time to look around and understand the smelly and slippery route before you. And what are those noisy creatures swarming around our fishy “innovative” design we called Mandelbrot blueprint? You don't get a buzzing noise like that, just buzzing and buzzing, without its meaning something.