Архитектура ИТ-решений
14.7K subscribers
297 photos
33 files
1.12K links
Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений, микросервисы).

Регистрация в перечне РКН: https://knd.gov.ru/license?id=6735f4cd97de7d1d1953c457&registryType=bloggersPermission
Download Telegram
Для вакансий ИТ-архитекторов стало характерно отсутствие больших идей. Даже хайпы стали упоминаться реже. Сохранились одни трансформации. Трансформации из априори плохого настоящего в сторону всё равно какого будущего. Почему так? Может с ИТ-директорами что-то случилось?
Не знаю, доберется ли до корпоративного мейнстрима идея поставки программного обеспечения в виде sidecars контейнеров, но контуры этой темы проступают всё более и более чётко: минимальные накладные расходы на межпроцессное взаимодействие в сочетании с независимостью от используемых технологий https://thenewstack.io/operators-and-sidecars-are-the-new-model-for-software-delivery/
Недавно случился подкаст, на который Gene Kim пригласил Michael Nygard, известного, в частности, знаменитой книжкой Release It! К аудиозаписи этого полуторачасового разговора добавили расшифровку(транскрипт).

В общем, слушайте и читайте здесь: https://itrevolution.com/idealcast-episode-8/
PS: картинка, как это часто уже случается в моём канале, неправильная :-)
20 августа, 20:00 MSK
Веб-ресурсы – новая интеграционная среда?

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

Приглашаю обсудить эту тему, в ближайший четверг, в zoom: https://us02web.zoom.us/j/89019160706?pwd=dXF2ZFVFUWh2NDUwbTlaMFM3M09Xdz09 Идентификатор конференции: 890 1916 0706 Код доступа: 513901
Можем ли мы простыми словами рассказать неайтишнику о том, что у нас происходит? Объяснить некоторые базовые концепции, приложив их к текущему состоянию дел. Раньше, очевидно, могли. И получаса хватит, чтоб растолковать практически кому-угодно что такое реляционные базы данных и даже порисовать с ним таблички, рассказать об устройстве хранилища данных или, например, корпоративной сервисной шины.

Сегодня, боюсь, что нет. Мы, конечно, можем попробовать, но вряд ли уложимся в полчаса и то, выйдет у нас слишком поверхностно (Расскажите про CQRS за пять минут). Впрочем, слушать нас скорее всего никто не станет. Обстоятельные истории об устройстве технологий уступили место бестолковым журнальным заголовкам. А в реальной работе понимание достигается за счет плотных регулярных коммуникаций. Показать мы можем намного больше чем объяснить. Потому и без agile никуда.

В общем, снова архитекторы виноваты, как ни крути! Ну, а кто еще должен простыми словами объяснять людям сложные вещи?
Чем радует меня закат микросервисного хайпа, особенно в корпоративном контексте, так это предложением вернуться назад, типа к монолиту. Прям рисуется картина маслом, как мы берем ERP, CRM, системы дистанционного обслуживания и всё прочее и собираем в один большой процесс и развертываем его в сотнях экземпляров на всех серверах компании.

Не было у вас никакого монолита. Вернее, их было много с разными технологическими стеками, разными структурами данных и непосредственно данными, разными фрагментами функционала, перевязанного в сквозные бизнес-процессы интеграционными средами. В общем кусочно-лоскутная автоматизация во всей красе. Мы к ней возвращаться будем?
- Нет, не будем – отвечают ревизионисты микросервсиной архитектуры – мы новые системы станем писать не в виде набора сервисов, а как единый процесс.

Ну, правильно! Предыдущие тридцать лет все так и делали. Начиналось обычно словами: сейчас мы все перепишем и будет одно новое и хорошее. Заканчивалось появлением еще одного булыжника в дополнение к существующему ИТ-ландшафту. Со своей технологией, со своими данными, как-то криво и косо синтегрированного со всем остальным
Архитектура ИТ-решений
Чем радует меня закат микросервисного хайпа, особенно в корпоративном контексте, так это предложением вернуться назад, типа к монолиту. Прям рисуется картина маслом, как мы берем ERP, CRM, системы дистанционного обслуживания и всё прочее и собираем в один…
Микросервис от приложения отличают два важных преимущества: у него есть API и у него нет GUI. Помните как раньше пользователи ходили и орали:
- Сделайте нам единое окно! Мы не хотим работать в десятках систем!... А еще мы хотим быстрый поиск по данным из всех систем и чтоб ничего никогда не тормозило!

Хайп твоего счастья заканчивается, дорогой пользователь!
Вспоминай старые навыки: запускаем в начале рабочего дня все нужные приложения и копи-пастим данные между ними через клипборд и ждем ...
Начав читать транскрипт этого выступления https://www.infoq.com/presentations/microservices-monolith-antipatterns/ я решил, что оно относится к разделу "сатира и юмор". Однако ни после истории с потребностью в webhooks, ни после злоключений с shared libraries в транскрипте не было отметок о смехе в зале. Пришлось включить запись. С изумлением я обнаружил, что по ходу выступления вообще никто не смеется... Может это считается неполиткорректным, не знаю. Почему-то мне кажется, что девушка собиралась сделать веселую презентацию, но вошла в другой образ и веселыми получились лишь смайлики на последнем слайде
Раз уж я переименовал этот канал в "Архитектура ИТ-решений", то позволю себе иногда публиковать некоторые определения. Сегодня термин solution (решение) из руководства бизнес-аналитиков BABOK Guide v3
Solution:
A specific way of satisfying one or more needs in a context.
A solution satisfies a need by resolving a problem faced by stakeholders or enabling stakeholders to take advantage of an opportunity
Давайте продолжим с определениями:
Solution Architecture
A description of a discrete and focused business operation or activity and how IS/IT supports that operation.
Note: A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks
[ TOGAF 9.2: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_69 ]
А вот вам состав описания архитектуры решения из прошлогодней книжки
Alan McSweeney, Introduction to Solution Architecture
Собрал в один плейлист вебинары, проведенные на канале IT Expert https://www.youtube.com/playlist?list=PLDwZgqHLFBe5B4Dt3dFszxo-p3xMalN8e

#youtube
Я всё ждал, а не перерисует ли кто-нибудь знаменитую картинку Джона Захмана 1987 года в приемлемом разрешении
Архитектура ИТ-решений
+1 canvas, конечно же про микросервисы https://www.apiacademy.co/articles/2017/06/the-microservice-design-canvas
The OpenAPI Specification (OAS) - стандарт описания REST API в виде YAML-файла.

Но YAML можно использовать и для описания микросервисов в Microservice Design Canvas. Прототип такого решения см. https://solusoftsl.github.io/microservices-design-canvas-editor/
Нашел свой довольно старый текст https://mxsmirnov.com/2014/03/20/why-ea/ и подумал, что вместо него следовало бы создать для архитекторов предприятия страничку ответов на часто задаваемые руководителями и заказчиками вопросы. Может кто видел такую штуку именно для EA?