Архитектура ИТ-решений
15.8K subscribers
312 photos
2 videos
33 files
1.17K links
Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений).
Контакт: @maximsmirnoff

Регистрация в перечне РКН: https://knd.gov.ru/license?id=6735f4cd97de7d1d1953c457&registryType=bloggersPermission
Download Telegram
Как-то пропустил этот проект https://www.minio.io/ Кто-нибудь разбирался? Расскажете? Ведь вдруг так случится, что скоро надо будет все контентные хранилища переделывать (Привет любителям, электронного документооборота, в частности)
Похоже, медицина только приступает к хождению по хорошо известным граблям автоматизации:

выберите себе модель вашего Цифрового регионального контура здравоохранения на ближайшие 6 лет с учетом предыдущего опыта:

б) или монолитную систему одного разработчика - если вы идеалист

https://zen.yandex.ru/media/id/5bd2e38afd73ab00ad0e5a0e/i-shinoi-edinoi-i-mis-ne-odnoi-5c0813743b426800aabb5d92
... я это к тому, что пора бы уже госконтракты на поставку всяких РМИСов и прочего ПО начинать требованием о развертывании git-а и публикации открытых API для подключения расширений
Большинство подходов к моделированию бизнес-процессов, показывают, что может произойти в процессе. В ряде случаев больше подойдут примеры того, что происходит на самом деле. Перефразируя Peter Hruschka: «Три хороших примера лучше, чем плохая абстракция» http://www.domainstorytelling.org/ Слайды(немного на немецком) https://speakerdeck.com/hofstef/knowledge-crunching-mit-domain-storytelling
Вопрос-ответ. (Что-то типа новой рубрики на канале c хэштегом #FAQ ). Вчера на вебинаре меня спросили: Как убедить заказчика, что этап анализа и проектирования необходим, за него ему надо платить.

Мой вариант ответа: поставьте себя на место заказчика. Много лет ему рассказывали, что он [тупой] не может сформулировать требования на понятном разработчику языке, а разработчик не понимает язык человеческий. Конечно же, заказчик обиделся: если программисту нужно какое-то там ТЗ, то пусть он и платит… и за ТЗ и за общесистемный софт и за все остальное.

Я вижу три варианта решения: 1) Перестать торговать душами, а предлагать команду целиком. 2) Объяснять заказчику в чем состоит ценность. Например, грамотная постановка задачи позволит ему заказать софт не у вас, а там, где дешевле (шутка, но это не единственная ценность) 3) Перестать мечтать о работе на конвейере (в pipeline-е CI/CD в нашем случае). Маржа, как известно, из производства уходит в сферу услуг, идите за ней. Помогайте заказчику осознать, что и зачем он хочет, а не как это сделать
Это правда! Три месяца назад в ВШБИ ВШЭ мы провели круглый стол по ИТ-архитектуре. Подробности здесь: https://habr.com/post/432386/ Большое спасибо всем участникам и отдельный респект Кристине за обзор этого мероприятия
Микросервисы всем нравятся, но работы по выделению ограниченных контекстов несколько затянулись. K8s сумел развернуть каждый третий, а интеграция с legacy остается неясной темой. В принципе, ожидаемые результаты исследования O’Reilly от 4 декабря(14 страниц) https://www.oreilly.com/programming/free/the-state-of-microservices-maturity.csp
Из серии AI для (идиотов - зачеркнуто) enterprise architects :) ниже в pdf
Про Experience API в России: https://fb.com/1988132824598961/
По-моему, это про корпоративную архитектуру: магистр Йода зомбирует незадачливого клиента