Соревнуюсь 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. Итак, приступим Читать далее Архитектура решений. Сложные компромиссы
В ходе предновогоднего стрима я уже отметил, что времена само-сбывающихся пророчеств в ИТ, похоже, прошли. В нулевые достаточно было консультантам объявить приход сервис-ориентированной архитектуры и вот уже все о ней только и говорят. Похожая ситуация складывалась и в десятые годы, только в роли провидцев теперь уже выступали интернет-гиганты. Они рассказывали про свой опыт построения высоконагруженных приложений или же просто публиковали как open source то или иное свое решение. Потом это тоже закончилось, а жанр рождественских гаданий превратился в отчеты о сделанном в году уходящем и изложение планов на год наступающий. Подчинюсь и я этому жанру. Читать далее Навстречу 2025-му. Свершения и прогнозы
Иногда я буду делать небольшие критические обзоры текстов разных авторов. Сегодня мне попалась заметка David R Oliver C4+1 — The Services Layer. В статье много есть к чему придраться, но я постараюсь только по существу. Читать далее За что не любят архитекторов предприятия
Многотомник текущей (десятой) версии фреймворка корпоративной архитектуры TOGAF содержит много советов по работе c заинтересованными лицами (stakeholders). А нотация описания архитектуры предприятия Archimate включает в себя довольно развесистый набор концепции для описания целей, оценок, движущих сил, ограничений и требований этих самых стейкхолдеров. Но все же, я думаю, что ряд довольно важных вещей, касающихся восприятия и взаимодействия с заинтересованными лицами, остался невысказанными. Они либо вообще не добрались до текста стандарта, либо запутались где-то между строк. Давайте о них сегодня поговорим Читать далее Слоёный пирог стейкхолдеров
Накануне, в ходе стрима о Solution Architecture, я отвечал на вопрос: насколько востребованным для архитектора решений является описание потоков данных в DWH. Должен ли он этим заниматься и есть смысл вкладываться в это направление. (Запись всего стрима здесь: https://youtube.com/live/_GKNhoPmZYI ) Я воспользовался картинкой из книжки Alan McSweeney Introduction to Solution Architecture в которой довольно много чего написано про данные в архитектуре решений и задачи, связанные с интеграцией данных.
Картинка выше (надеюсь, цитируя её, я не нарушаю авторских прав) иллюстрирует тот очевидный факт, что дизайн любого решение включает в себя ландшафт данных. Такой ландшафт описывает как данные создаются, собираются, передаются, обрабатываются, хранятся, используются и, в конечном счете, уничтожаются. Причем, в каждом конкретном решении могут быть задействованы существующие приложения или же потребоваться разработка новых средств работы с данными. А еще сами данные могут быть довольно разными по своей природе: документы и контент, следы операций в виде событий, основные и справочные данные.
Чуть ниже автор сетует, что возможно его способ представления выглядит несколько запутанным и слегка неуклюжим, но в оправдание замечает, что в реальных проектах приходится сталкиваться с не менее сложными проблемы в части извлечения и обработки данных.
Все это именно так и, конечно, если вам интересно, то конечно обратитесь к соответствующей главе в первоисточнике. Но уже отвечая на вопрос я вспомнил, что в самом начале года Alan McSweeney опубликовал большой набор слайдов Data Architecture For Solutions Я обещал поделиться ссылкой на него, что сейчас и делаю
Увлекательного изучения!
Я выдумал этот простенький пример, чтоб лучше проиллюстрировать заметку Развилки архитектурных решений . Набросал текст и сохранил его в комментариях к исходному сообщению. Сейчас решил поднять его из комментов в отдельную запись.
Solution architect Семён получил новую задачку: расширить функционал простенького сервиса обработки заявок. Ничем не примечательный сервис предоставляет HTTP API, с коллекцией request, в которую можно опубликовать заявку. Проведя пару проверок и обогатив заявку данными из внешних систем, сервис отправляет заявку в очередь сообщений. Семён недавно работает в компании и хотя, по его мнению, задачка довольно простая, решает посоветоваться с Enterprise architect-ом Евгением. Тем более, что на днях Евгений собрал всех solution-ов и рассказал им о записях архитектурных решений (architecture decision record). Теперь каждый архитектор должен не только набросать небольшой эскиз, но и выложить набор решений в виде adr-файлов в версионное хранилище. Читать далее Развилки архитектурных решений (пример)
Теория когнитивной нагрузки (Cognitive load theory) Джона Свеллера, популяризированная в мире ИТ книжкой про командные топологии, не только и не столько о том, как правильно выстроить обучение и не перегрузить людей избыточной информацией. Рассуждения о том, что способствует обучению, а что мешает, безусловно, важны, но начинается теория когнитивной нагрузки с описания некоторой (путь и крайне простой) модели организации памяти. В ней память человека делится на рабочую, используемую в данный конкретный момент и отвечающую за обработку информации для текущего действия, и долгосрочную, которая хранит уже имеющуюся информацию и обогащает ей новыми знаниями. Читать далее Теория когнитивной нагрузки и архитектура предприятия