Архитектура решений. Сложные компромиссы

В предновогоднем тексте я заметил, что современный учебный курс по архитектуре решений не может обойтись без хорошего примера. И даже предложил в качестве такого примера известную архитектурную кату Отряд сисопов (Sysop Squad). Но не удосужился перечислить обязательные или крайне желательные характеристики такого примера. Сегодня я постараюсь исправить этот пробел и сформулировать список таких характеристик. Возможно, он будет полезен не только мне и будущему новому курсу, но и пригодится кому-нибудь при подборе задач для собеседования архитектора решений или как набор критериев при подборе других архитектурных кат именно для тренировки навыков Solution Architecture. Итак, приступим Читать далее Архитектура решений. Сложные компромиссы

Навстречу 2025-му. Свершения и прогнозы

В ходе предновогоднего стрима я уже отметил, что времена само-сбывающихся пророчеств в ИТ, похоже, прошли. В нулевые достаточно было консультантам объявить приход сервис-ориентированной архитектуры и вот уже все о ней только и говорят. Похожая ситуация складывалась и в десятые годы, только в роли провидцев теперь уже выступали интернет-гиганты. Они рассказывали про свой опыт построения высоконагруженных приложений или же просто публиковали как 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 Я обещал поделиться ссылкой на него, что сейчас и делаю

Увлекательного изучения!

Модели корпоративной архитектуры. TOGAF10 и Archimate3.2

https://www.youtube.com/live/oRy6lhIvHcU?si=HyPzC4jP7FZKpYLD

Развилки архитектурных решений (пример)

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

Solution architect Семён получил новую задачку: расширить функционал простенького сервиса обработки заявок. Ничем не примечательный сервис предоставляет HTTP API, с коллекцией request, в которую можно опубликовать заявку. Проведя пару проверок и обогатив заявку данными из внешних систем, сервис отправляет заявку в очередь сообщений. Семён недавно работает в компании и хотя, по его мнению, задачка довольно простая, решает посоветоваться с Enterprise architect-ом Евгением. Тем более, что на днях Евгений собрал всех solution-ов и рассказал им о записях архитектурных решений (architecture decision record). Теперь каждый архитектор должен не только набросать небольшой эскиз, но и выложить набор решений в виде adr-файлов в версионное хранилище. Читать далее Развилки архитектурных решений (пример)

Теория когнитивной нагрузки и архитектура предприятия

Теория когнитивной нагрузки (Cognitive load theory) Джона Свеллера, популяризированная в мире ИТ книжкой про командные топологии, не только и не столько о том, как правильно выстроить обучение и не перегрузить людей избыточной информацией. Рассуждения о том, что способствует обучению, а что мешает, безусловно, важны, но начинается теория когнитивной нагрузки с описания некоторой (путь и крайне простой) модели организации памяти. В ней память человека делится на рабочую, используемую в данный конкретный момент и отвечающую за обработку информации для текущего действия, и долгосрочную, которая хранит уже имеющуюся информацию и обогащает ей новыми знаниями. Читать далее Теория когнитивной нагрузки и архитектура предприятия

Platform Engineering. Архитектура цифровой платформы

Обсуждаем модный термин #PlatformEngineering. Пытаемся понять о чем речь:

  1. Правда ли, что Platform Engineering это для тех, у кого не все получилось с DevOps
  2. Или же это про внутреннюю платформу разработки (Internal Developer Platforms, IDPs). Что-то похожее на https://backstage.io/ от Spotify
  3. А может портал разработчика это только дверь, а платформой является все то, что скрывается за этой дверь. Похоже на холст с очагом, не правда ли?
  4. Причем здесь решения от Cloud Native Computing Foundation (CNCF) и правда ли с ними так много проблем, как об этом недавно написал Сэм Ньюман? 5. Как не влипнуть в очередной бестолковый проект и увидеть в платформе ценность

Слайды: telegram-канал Архитектура ИТ-решений

Ссылки:

  1. Getting started with Team Topologies — infographic
  2. Platform Engineering 101
  3. What I Talk About When I Talk About Platforms
  4. Digital Platform Strategy 
  5. The State of DevOps Report 2020. Internal Platforms & Change Management
  6. Backstage System Model
  7. Open Application Model
  8. Team Cognitive Load. By Matthew Skelton, Manuel Pais