Архитектура ИТ-решений
15.9K subscribers
331 photos
2 videos
34 files
1.21K links
Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений).

Регистрация в перечне РКН: https://knd.gov.ru/license?id=6735f4cd97de7d1d1953c457&registryType=bloggersPermission
Download Telegram
Четвертое измерение процессного подхода в ИТ. Свежие сообщения Кента Бека на Medium https://medium.com/@kentbeck_7670/inefficient-efficiency-5b3ab5294791 натолкнули меня на мысль о том, что в модели рассуждения о нарезке изменений на команды и фичи (feature teams vs. component teams) обычно игнорируется одна важная составляющая: как производится нарезка пожеланий заказчиков на элементы бэклога. Проще говоря, имея запрос на изменение с низким приоритетом от одного заказчика, мы можем спросить у других заказчиков: не нужно ли им тоже самое. Иногда ответ будет положительным, что позволит нам увеличить ценность (и приоритет) этого изменения.
Другими словами, преимущество feature teams перед component teams строится на наборе весьма шатких допущений: 1) мы можем сделать такие команды; 2) поток изменений неисчерпаем и достаточно плотен (нет простоев); 3) технологическими компетенциями можно пренебречь …
Все туториалы по k8s на одной странице https://www.magalix.com/blog/the-best-kubernetes-tutorials
Говорят, что вчера всех из торгового центра интернета эвакуировали по пожарным лестницам https://www.kommersant.ru/doc/4205926

UPD: а вот существенное дополнение https://t.me/c/1304614627/1944
Оффтопик: Освобождающие структуры - паттерны групповых видов деятельности на работе или в ходе обучения https://liberating-structures.ru/ Но мне, как ИТ-тренеру, было довольно интересно это посмотреть. Делюсь. Оригинал: http://www.liberatingstructures.com/
Решил выделить в отдельный канал всё, что связано с ИТ-обучением https://t.me/quest42
Всё! Закрываем канал на праздники. Спасибо, что вы с нами! Встретимся в 2020-м
Поздравляю всех с наступающим Новым годом! Желаю счастья, успехов и весёлых новогодних каникул 🍾🎄🎉
Forwarded from Denis Beskov
Я написал статью о том, зачем нужна контекстная диаграмма, как её создавать и тестировать, как использовать: http://systems.education/context-diagram

Спасибо за комментарии Николаю Судникову, Денису Мишарину, Рафику Ямолееву и Максиму Смирнову
Новая книжка от Нила Форда и Марка Ричардса Основы архитектуры программного обеспечения (февраль 2020). Ознакомительный фрагмент на O'Reilly наводит меня на мысль о необходимости её почитать https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/
Netflix пообещал в 2020 году открыть исходники DBLog - собственного Change-Data-Capture (CDC) решения https://medium.com/netflix-techblog/dblog-a-generic-change-data-capture-framework-69351fb9099b
Пару дней назад в чате ИТ-архитекторов https://t.me/itarchitect была дискуссия про физические и логические модели данных. Какой аналитик какую из них и когда делает, аналитик ли это делает и нужно ли их вообще разделять. Последовательность сообщений я сейчас уже не воспроизведу, но свои три копейки внести хочу:

Если мне память не изменяет, то еще Джон Захман в своих ранних статьях говорил (и в матрице рисовал) о том, что необходимость логической модели возникает при декомпозиции решения на компоненты и команды(субконтракторов), возможно использующих разные технологии. Возникает из-за необходимости им между собой договориться. Грубо говоря: надо как-то формат файла отобразить на реляционную модель данных, вот вам и появляется логическая модель поверх двух физических, принципиально разных. Т.е. логическая модель - некоторый аналог интерфейса. Интерфейса, который скрывает реализацию. Кто её делает? Тот, кто, как минимум, владеет всеми задействованными технологиями. Может я путаю, и это не Захмана рассуждения, но мне они кажутся вполне разумными и обоснованными. А иначе зачем весь этот огород городить?
Ну, и моя история про матрицу Захмана здесь: https://mxsmirnov.com/2018/03/23/zachman/
Вот оно оказывается как! После перехода от проектной организации работ к продуктовой, вдруг оказывается, что нужны программы. Новая статья на martinfowler.com: https://martinfowler.com/articles/programs-in-product-mode.html
Довольно неоднозначная, но полезная история https://www.codeproject.com/Articles/4043134/Message-Driven-Business-Process-Orchestration-usin Неоднозначная потому, что я бы повыкидывал бы половину БД на картинках (например на Figure 4. одна из стрелок точно лишняя, ну да ладно). Почему интересная: системы управления бизнес-процессами явный тормоз развития микросервисов: транзакции, состояния и т.п. О таких темах, как S-BPM, вроде бы, все уже давно забыли. Zeebe - чем-то принципиально новым не считаем, она о другом.

Но в тоже время в современных нам ИТ-архитектурах появилось столько всяких новых вещей. Например, а не пора ли включать в BPMN пиктограмму circuit breaker? Ну и вообще, что может быть более похожим на паттерн event sourcing, чем позиции из сетей Карла Петри. Сети Петри, вроде как для моделирования процессов придумали, разве нет?

В общем, митап пора делать о бизнес-процессах и микросервисах
Подарок архитектору предприятия от YouExec Бесплатный шаблон для Google slides или PowerPoint (и не говорите, уважаемые EA, что вы его не используете) из семи анимированных слайдов презентации бигбоссам стратегических карт https://youexec.com/strategy-maps-3e2djzvibo
Завтра в 10:30 MSK приглашен на запись очередного подкаста linkmeup Весь выпуск будет целиком посвящен ИТ-архитектуре https://linkmeup.ru/blog/528.html Слушать можно непосредственно в ходе записи или скачать позже. На то это и подкаст ;-)
А тем временем на Хабре появилось несколько переводов про REST. Первый: "REST API должен основываться на гипертексте" https://habr.com/ru/post/483528/ одного из сообщений Роя Филдинга в его блоге и нескольких комментариев к нему (Оригинал 2008 года: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven)