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

Регистрация в перечне РКН: https://knd.gov.ru/license?id=6735f4cd97de7d1d1953c457&registryType=bloggersPermission
Download Telegram
Анекдот №96846
- Посмотри мою программу. Где у меня ошибка?
- Посмотрел.
- Ну, и где?
- В ДНК.

Этих людей невозможно вылечить! Они говорят о создании одного формата данных для всех ГИС и сетуют, что мол 340 ГИС это так много. На самом деле, это очень мало! Мало потому, что среди трех сотен систем пока не нашлось ни одной настолько хорошей, чтоб кто-нибудь захотел её форкнуть(к тому же исходники в нашем королевстве открывать не принято). Им нужен главный врач, а вовсе не архитектор https://www.facebook.com/mxsmirnov.arch/posts/1567668933336915
Вдогонку. Какие слова, я хотел бы услышать от лидеров цифровой экономики (вот, ведь наивный фантазёр ):
1. Мы пока не вполне понимаем какой она будет и потому начнем не с готовых рецептов, а с экспериментов и бета-версий.
2. Конкуренция – это хорошо. Поэтому у вас будет 5 разных порталов госуслуг, 3 ГИС ЖКХ и сотни других сервисов. Выбирайте. Ежегодно мы будем выключать процентов 20 из них, избавляясь от сервисов, не нашедших своего клиента
3. Министерства и ведомства не только будут тратить бюджет на ИТ, но и научатся на нём зарабатывать. Треть ИТ-бюджетов должна инвестироваться (и только попробуйте через год не суметь перепродать свой пай с премией)
4. Открытые [мета]данные, открытые исходники, открытые API
5. Безопасность не систем от людей(хакеров), а людей от некорректно работающих систем
Пора придумывать доклад на AnalystDays #9 (30 ноября - 1 декабря 2018, Москва) https://analystdays.ru/ru/index О чём бы рассказать аналитикам?
У меня в блоге очень много просмотров сообщения о курсе "Карта ИТ-ландшафта" https://mxsmirnov.com/2017/02/01/landscape-map/ Но никто, почему-то, не обращается в учебный центр с вопросами по этому курсу. Может пора назначить дату и провести его еще раз? Было бы вам это интересно и в каком формате: очном или дистанционном? (Ваши вопросы и комментарии на FB: https://www.facebook.com/mxsmirnov.arch/posts/1572297479540727)
Уж не является ли шум вокруг так называемых low-code development platforms простой попыткой поскорее забыть слово BPMS? Ну, вот случилось так, что слово это уже не так вдохновляет как прежде. Но вендора же за многие годы столько всего написали: и рисовалки пользовательских интерфейсов, и data modelers(в очередной раз, кстати), модули human task, интерфейсы ведения групп пользователей... Не выбрасывать же всё это, в самом то деле. Потому Forrester и пугает не-айтишников html-ем 😯 https://go.forrester.com/blogs/why-you-need-to-know-about-low-code-even-if-youre-not-responsible-for-software-delivery/
Ну и кто после таких обзоров будет покупать книжки и лекции из серии "Машинное обучение для чайников"? https://vas3k.ru/blog/machine_learning/
Идея использования архитектурных диаграмм, особенно карт, в качестве "фона" для дашбордов - она, конечно, правильная. Но рисовать карту ИТ ландшафта, как это сделано в примере от BizzDesign, согласитесь, не хорошо! Мы же не какие-нибудь финансовые контролеры https://bizzdesign.com/blog/data-analysis-with-dashboards-in-horizzon/
Возможно, не самый убедительный текст среди остальных статей Диона Хинчклиффа относительно back-end CX (поддержки клиентов), но очень важный разговор. Все цифровые начинания рано или поздно упираются в поддержку, которая на себе испытает многообразие несогласованных каналов взаимодействия, множество унаследованных приложений, жесточайшее давление регуляторки и показателей эффективности https://www.constellationr.com/blog-news/digital-transformation-back-end-customer-experience-what-leaders-new-c-suite-are-thinking
Еще один небольшой рассказ с картинками из серии: кто такой Solution Architect https://www.openxcell.com/important-solution-architecture-product-development Чтоб не утомлять вас чрезмерным количеством ссылок, решил под такого рода сообщениями добавлять кнопки Like-бота. Так что не стеснятесь голосовать
Кажется понял, чего мне не хватает в Strategic Domain Driven Design Авторы многих статей, например этой https://www.infoq.com/articles/ddd-contextmapping очень близко подходят к формулировке модели развития описания предметной области, но такая модель все же остается не отрефлексированной. Т.е. мы знаем как отобразить наше текущее понимание дел, но не знаем как его будем развивать в будущем. Вот в объектно-ориентированном подходе всё было просто: наследование, полиморфизм, абстрактные классы и виртуальные функции - буквально всё рассказывало о том, как мы будем развивать модель по мере появления новых знаний. В DDD это не так. В границах контекста модель остается неизменной, потому что она верная. Всё развитие происходит где-то там, за границей, в чужих контекстах, ну или межконтекстном пространстве, если можно так выразиться. Впрочем, для микросервисов такой подход очень хорош. Вопрос в том, а адекватно ли всё это реальному положению дел
Выложил пару презентаций: https://speakerdeck.com/mxsmirnov
Успейте бесплатно скачать новую версию книжки Google по SRE (нижняя ссылка) https://landing.google.com/sre/book.html Написано, что она будет бесплатно доступна для скачивания только до 23 августа, но пока ссылка еще работает
Упс... Халява закончилась. Ссылка, действительно, пропала :(
Применима ли CAP теорема к командам гибкой разработки? Можно ли организовать их взаимодействие так, чтоб для функционала, отданного разным командам, сохранялась согласованность и восприимчивость к изменениям? Более философский вопрос: а как насчет CAP теоремы для бизнес-процессов?