Строительство. Ремонт. Садоводство

Когда инженерные группы выбирают инструменты для управления своими программными системами, особенно для проектирования и визуализации, они часто сталкиваются с проблемой XY.

Проблема XY возникает, когда кто-то пытается решить проблему X, используя решение Y, но сталкивается с трудностями. Вместо того чтобы искать помощи для решения проблемы X, они просят поддержки для решения Y, скрывая первопричину и приводя к недопониманию и неоптимальным решениям.

Вот конкретный пример из XY проблема веб-сайт:

При проектировании архитектуры системы или визуализации ее компонентов они часто задаются вопросом:

• Какой инструмент построения диаграмм следует использовать для отображения архитектуры нашей системы?
• Как мы обмениваемся и храним записи архитектурных решений?
• Где можно просмотреть список всех API в нашей системе?

Эти вопросы, хотя и обоснованы, фокусируются на Y — предлагаемом решении, а не на X — фактических болевых точках, которые команда стремится решить. Чтобы раскрыть первопричину, эти вопросы следует переформулировать следующим образом:

• Нам необходимо поставлять функциональное программное обеспечение по графику, поэтому нам нужен простой способ визуализации и доступа к актуальной информации об архитектуре нашей системы.
• Нам необходимо без труда достичь консенсуса по проектированию системы и иметь единый источник достоверной информации для записей о решениях.
• Нам необходимо понимать поведение системы и выявлять критические изменения до того, как они произойдут.

К сожалению, многие команды не осознают, что они сосредоточены на Y вместо X. Это приводит к тому, что они принимают фрагментарный подход к проектированию системы, реализуя различные решения для отдельных задач. Они могут использовать один инструмент для эскизов, другой для архитектуры системы и третий для диаграмм последовательности. Системные требования и проектные решения разбросаны по Google Docs, Jira, Linear, Slack, электронной почте, Confluence и т. д. API могут быть перечислены в электронных таблицах или специализированных инструментах.

Такой подход приводит к значительным затратам времени и усилий на поддержание этих ресурсов, поиск релевантной информации и ненужное переключение контекста.

Схемы проектирования системы и архитектуры системы

Проектирование системы часто ошибочно приравнивается к простому рисованию диаграмм архитектуры программного обеспечения. Другое заблуждение — приводить его исключительно в соответствие с BDUF (Big Design Up Front), UML (Unified Modeling Language), определенными архитектурными фреймворками, такими как TOGAF, или различными типами документации, такими как HLD (High-Level Design), SAD (Software Architecture Document), KDD (Key Design Decisions), ARD (Architecture Requirements Document), LLD (Low-Level Design) и ADR (Architecture Decision Record).

Проектирование системы выходит за рамки какого-либо конкретного инструмента или документа; это непрерывный процесс процесс который описывает высокоуровневую концептуальную структуру сложной системы (архитектуру системы) и определяет ее значимые компоненты и взаимодействия. Он охватывает все аспекты системы (т. е. программное обеспечение, оборудование, данные, интерфейсы и взаимодействие с пользователем), чтобы гарантировать, что они работают вместе эффективно и результативно для удовлетворения требований приложения.

Результаты этого процесса может включать:

• Документация по системным требованиям (т. е. подробное описание как функциональных, так и нефункциональных требований).
• Документация по архитектуре системы (т. е. описание целей, ограничений и обоснования выбранной архитектуры).
• Схема архитектуры системы (т. е. предоставление визуального представления компонентов, служб, их взаимодействий и взаимосвязей).

Однако проектирование системы должно быть сосредоточено на предварительных и непрерывных обзорах проектирования системы, которые постоянно фиксируют и пересматривают системные требования, решения, компромиссы и компромиссы. Это важный шаг в разработке программного обеспечения для оценки технической осуществимости, функциональности и производительности системы, а также выявления зависимостей и рисков для принятия обоснованных решений.

Сведение проектирования системы к простому созданию диаграмм или документов Риск упустить из виду важную информацию и способствовать неэффективной практике в инженерных группах. Это в конечном итоге это приводит к накоплению архитектурного технического долга и обременению команд ручными задачами и неэффективными ресурсами.

В наши дни диаграмм недостаточно

Разработчики часто используют диаграммы для решения фундаментальной коммуникационной задачи: четкого и эффективного донесения сложности распределенной программной системы, включая ее компоненты, зависимости и API, до распределенной команды.

Разработка программного обеспечения по своей сути является совместной, требующей общего понимания конструкции системы, ограничений и будущей эволюции. Такое согласование имеет решающее значение для устранения двусмысленности и обеспечения сплоченного прогресса команды.

Визуальные иллюстрации являются мощными инструментами для достижения такого соответствия, поскольку они помогают обойти возможные недоразумения и задержки, присущие письменному и устному общению, гарантируя, что ментальные модели согласованы по всей команде. Однако инструменты для построения диаграмм имеют существенные ограничения. Эффективные диаграммы предназначены для того, чтобы рассказать определенную историю определенной аудитории, предоставляя статический снимок программной системы, которая решает проблемы определенных заинтересованных сторон (например, Backend-команда, Frontend-команда, QA, PM, DevOps, C-suite).

В прошлом, когда программные системы были меньше и проще, одна диаграмма могла (потенциально) охватить всю необходимую информацию. Сегодня, с распространением SaaS, API, компонуемых платформ и устаревших систем, сложность программных систем возросла экспоненциально.

«Сегодняшние программные технологии больше похожи на тропический лес, где животные и растения сосуществуют, конкурируют, живут, умирают, растут и взаимодействуют незапланированным образом, чем на спланированный сад.”

— Джин Янг.

Мы все видели диаграммы, которые пытаются втиснуть всю архитектуру этих современных программных систем в одну картину. По иронии судьбы, эти системы выиграли бы больше всего от эффективного сообщения о своей сложности.

По мере развития масштабов систем и требований к команде ограничения традиционных инструментов построения диаграмм становятся все более очевидными:

• Отсутствие обновлений в реальном времени: Диаграммы обеспечивают статическое представление и не могут автоматически отражать динамическую природу современных систем.
• Неуклюжий пользовательский интерфейс: Обновление диаграмм может быть обременительным, поскольку на форматирование и упорядочивание компонентов уходит много времени.
• Проблемы с контролем версий: Поддержание обновленных версий во всех командах — сложная задача.
• Ограниченные возможности совместной работы: Сотрудничество и обратная связь в режиме реального времени часто нуждаются в лучшей поддержке.
• Не существует единого источника Истины.. Диаграммы редко включают информацию о требованиях, компромиссах, проектных решениях и т. д. Часто используется проектная документация.
• Невозможность управления облачными ресурсами: Диаграммы не контролируют и не генерируют код инфраструктуры (например, CloudFormation, Terraform).

Эти ограничения подчеркивают, что инструменты построения диаграмм не были предназначены для обработки сложностей современных программных систем и эволюции их архитектуры.

Инженерным группам сегодня нужны инструменты, которые охватывают сложность и поддерживают динамическое проектирование систем, превосходя возможности традиционных инструментов построения диаграмм. Хотя разработчики могут создавать более крупные системы благодаря всем новым доступным технологиям, теперь они сталкиваются с проблемой управления и координации этих быстро движущихся, постоянно развивающихся, собранных воедино систем. В большинстве этих реальных, беспорядочных технологических стеков разработчики должны интегрировать новый код с устаревшим кодом, постоянно оценивая, когда и как модернизировать существующие компоненты.

Отсутствие видимости и понимания их программных систем создает узкие места в команде, замедляет разработку и приводит к хрупким, негибким системам. Типичный ответ на управление этой сложностью — поиск более высоких уровней абстракции. Однако упрощение вещей — лишь иногда лучшее решение.

Некоторые проблемы не могут быть автоматизированы, и разработчики должны собирать соответствующую информацию, чтобы предоставить индивидуальные данные о том, как их решить. Например, рассмотрим отладку: высокоуровневая статическая абстракция программной системы не дает инженеру детального понимания, необходимого для эффективного устранения неполадок. Более того, проблемы могут требовать разных абстракций, то есть ни одна отдельная абстракция не может удовлетворить все потребности.

Это похоже на понимание того, как работает ваш автомобиль: вам не нужно знать каждую деталь, но вы должны иметь возможность проверить, что находится под капотом, чтобы диагностировать проблемы, особенно без необходимости каждый раз возвращать автомобиль дилеру. Поэтому нам нужны инструменты, охватывающие сложность, которые сочетают абстракцию с возможностью углубляться в технический стек. Эти инструменты должны предоставлять актуальную информацию о любом компоненте, структуре или взаимосвязи и способствовать совместному решению проблем.

В отличие от инструментов для создания диаграмм и досок общего назначения, нам нужны инструменты, которые различают отношения элементов в организационной схеме и в архитектуре платформы. Расширенные инструменты наблюдения и понимания системы имеют важное значение, позволяя разработчикам эффективно исследовать, раскрывать и управлять сложностью.

Последние мысли

Многие инженерные группы продолжают использовать инструменты для построения диаграмм из-за ошибки невозвратных затрат («Мы уже потратили 30 часов на создание и обновление этой диаграммы, так что давайте продолжим и не будем тратить время впустую»), устойчивость к изменению («Переключение инструментов требует времени и обучения, сейчас у нас другие приоритеты»), и нечеткое определение проблемы («нам нужна обновленная диаграмма» против. «нам необходимо понимание нашей системы в режиме реального времени»).

По мере роста сложности современных программных систем все больше команд будут сталкиваться с ограничениями традиционных инструментов для построения диаграмм. Эти инструменты, которые когда-то были необходимы для иллюстрации идей и проектов, все еще нуждаются в совершенствовании, чтобы охватить всю сложность систем, что мешает разработчикам полностью понимать, проектировать, разрабатывать и управлять ими.

Инструменты построения диаграмм должны развиваться, чтобы поддерживать комплексные действия, необходимые в процессе проектирования системы, и давать возможность группам легко отвечать на более глубокие вопросы об архитектуре своего программного обеспечения.

Сегодня у нас есть технологии и знания для создания инструментов, которые не позволяют разработчикам тратить драгоценное время разработки на расшифровку статических, устаревших диаграмм, ручное обновление документов или сбор информации из разрозненных источников. Вместо этого мы можем позволить командам сосредоточиться на содержательных обсуждениях, продвигаясь к решению сложных проблем и принимая обоснованные решения по проектированию для развития системы.