Соревнуюсь c DeepSeek в подготовке слайдов с рассказами об ИТ-архитектуре. Лет 15 назад, я предложил вот такую шутливую картинку, чтоб проще было разобраться в архитектурных ролях.
а сегодня попросил нарисовать нечто подобное дипсика (источник не указывал). Вот что получилось: Читать далее Какие бывают архитекторы
Вот что мне насочинял DeepSeek. Вроде получилось неплохо
Вот таблица, которая наглядно сравнивает Architecture Vision и High Level Design (HLD):
| Критерий | Architecture Vision | High Level Design (HLD) |
|---|---|---|
| Цель документа | Описание «зачем» и «куда». Стратегический документ, объясняющий цели и преимущества. | Описание «как». Технический документ, показывающий, как система будет работать. |
| Уровень детализации | Высокоуровневое описание целей, преимуществ и общего направления. | Более детальное описание компонентов системы и их взаимодействия. |
| Аудитория | Руководство, заинтересованные стороны (Stakeholders), бизнес-пользователи. | Технические специалисты, разработчики, архитекторы. |
| Содержание | — Цели и задачи. — Текущее состояние (Baseline). — Целевое состояние (Target Architecture). — Преимущества и выгоды. — Ключевые заинтересованные стороны. — Риски и ограничения. |
— Основные компоненты системы. — Взаимодействие между компонентами. — Технологии и инструменты. — Высокоуровневые потоки данных. |
| Когда используется | На начальном этапе проекта, чтобы получить одобрение от руководства и заинтересованных сторон. | После утверждения Architecture Vision, чтобы начать техническую реализацию. |
| Пример | «Цель — автоматизировать процессы. Преимущество — сокращение времени обработки заказов на 50%.» | «Веб-интерфейс будет отправлять данные в базу данных через REST API.» |
| Аналогия | Общее описание путешествия: «Мы поедем в Париж, чтобы увидеть Эйфелеву башню.» | Детали маршрута: «Мы поедем на поезде из Москвы в Париж, остановимся в гостинице рядом с Эйфелевой башней.» |
Оба документа важны, но они служат разным целям и используются на разных этапах проекта.
В предновогоднем тексте я заметил, что современный учебный курс по архитектуре решений не может обойтись без хорошего примера. И даже предложил в качестве такого примера известную архитектурную кату Отряд сисопов (Sysop Squad). Но не удосужился перечислить обязательные или крайне желательные характеристики такого примера. Сегодня я постараюсь исправить этот пробел и сформулировать список таких характеристик. Возможно, он будет полезен не только мне и будущему новому курсу, но и пригодится кому-нибудь при подборе задач для собеседования архитектора решений или как набор критериев при подборе других архитектурных кат именно для тренировки навыков Solution Architecture. Итак, приступим Читать далее Архитектура решений. Сложные компромиссы
Накануне, в ходе стрима о Solution Architecture, я отвечал на вопрос: насколько востребованным для архитектора решений является описание потоков данных в DWH. Должен ли он этим заниматься и есть смысл вкладываться в это направление. (Запись всего стрима здесь: https://youtube.com/live/_GKNhoPmZYI ) Я воспользовался картинкой из книжки Alan McSweeney Introduction to Solution Architecture в которой довольно много чего написано про данные в архитектуре решений и задачи, связанные с интеграцией данных.
Картинка выше (надеюсь, цитируя её, я не нарушаю авторских прав) иллюстрирует тот очевидный факт, что дизайн любого решение включает в себя ландшафт данных. Такой ландшафт описывает как данные создаются, собираются, передаются, обрабатываются, хранятся, используются и, в конечном счете, уничтожаются. Причем, в каждом конкретном решении могут быть задействованы существующие приложения или же потребоваться разработка новых средств работы с данными. А еще сами данные могут быть довольно разными по своей природе: документы и контент, следы операций в виде событий, основные и справочные данные.
Чуть ниже автор сетует, что возможно его способ представления выглядит несколько запутанным и слегка неуклюжим, но в оправдание замечает, что в реальных проектах приходится сталкиваться с не менее сложными проблемы в части извлечения и обработки данных.
Все это именно так и, конечно, если вам интересно, то конечно обратитесь к соответствующей главе в первоисточнике. Но уже отвечая на вопрос я вспомнил, что в самом начале года Alan McSweeney опубликовал большой набор слайдов Data Architecture For Solutions Я обещал поделиться ссылкой на него, что сейчас и делаю
Увлекательного изучения!
Продолжение ответов на вопросы с предновогоднего вебинара
По интернетам несколько месяцев бродит в оригинале и переводах статья Ernesto Garbarino Has UML Died Without Anyone Noticing? Слушатели предстоящего вебинара Грамматика системных моделей попросили меня поделиться собственным мнением о том, что же произошло с UML. Я решил разобрать статью целиком и сделаю это по переводу UML умер, а никто и не заметил?
Я часто рассказываю о том, что наибольшую ценность архитектор ИТ-решений приносит не ответом на вопрос как? реализовать ту или иную задачу, а отвечая на вопрос что? делать в первую очередь, что во вторую, а что пока не делать вовсе. Но в этом блоге так и нет внятной записи, рассказывающей о воронке инициатив, её этапах, правилах отсева идей и действиях, которые архитектор, аналитик и другие заинтересованные лица должны осуществить.
Сейчас в образовании популярна новая тема: обучение через большие идеи или дидактика «больших идей». Не знаю, как скоро этот подход проникнет в среднее образование, но для своих курсов по ИТ-архитектуре я нашел его, как говорится методом проб и ошибок. Ну, например, архитектуру ИТ-решений (solution architecture) и микросервисы можно изучать отдельно. Хотя изучать просто ИТ-архитектуру немного скучно. А изучать микросервисную архитектуру, особенно после большого и долгого хайпа, довольно сложно. Все, вроде бы, и так всё уже об этом знают. Ну, может быть, в общих чертах и недостаточно глубоко. Хотя буквально в каждой группе, первая же из девяти характеристик микросервисной архитектуры по Льюису-Фаулеру оказывает сюрпризом хотя бы для одного из слушателей. А вот изучать и то и другое одновременно полезно и с точки зрения поддержания интереса, и для приобретения конкретных компетентностей. Читать далее Коротко об обучении ИТ-архитекторов
Следующая большая вещь (next big thing) в ИТ-архитектуре, безусловно, заключается во встраивании создания и тестирования архитектурных артефактов (описаний, моделей и пр.) в CI/CD pipeline. Идея эта не особо оригинальная. В интернет можно найти множество материалов с заголовком непрерывная архитектура (Continuous Architecture) или Architecture as a Code но в большинстве из них речь идет о чем-то другом (см., например: https://pgppgp.wordpress.com/). Пожалуй, только у Саймона Брауна звучит эта тема (см. Software architecture as code ), но в большей степени фоном для C4model. Одним словом, архитекторы по-прежнему полагают, что кто-то будет будем им рисовать и обновлять архитектурные описания повинуясь зову сердца и чувству долга. Читать далее Архитектура как код
Матрица Захмана, пожалуй, является наиболее ранним и наиболее показательным примером того, когда большая и сложная картинка скрывает суть вещей, которые она, по идее, должна пояснять. Помню своё первое знакомство с этим творением человеческой мысли. Если что-то и привлекает внимание при беглом взгляде на эту картинку, то это карта США в третьем верхнем квадрате, которая в более поздних версиях уступит вое место карте мира. Оторвав взгляд от тридцати разноцветных картинок, кое-где повторяющихся, можно заставить себя прочитать название столбцов и строк, приведенные, по традиции, очень мелким шрифтом. Если названия столбцов, содержащие слова «что», «где», «когда», еще пробуждают какие-то ассоциации, то названия строк: контекстуальный, концептуальный, логический, физический и уж совсем непонятно какой ассоциируются, разве что, с некоторыми уровнями абстракции. Думаю, на этом большинство зрителей этой картинки решают, что всё понятно и какого-либо более глубоко разбирательства просто не предпринимают. Но сегодня я хочу немного злоупотребить вашим вниманием и поговорить о матрице Захмана чуть подробнее.
Читать далее Объясняем матрицу Захмана