Уж не является ли шум вокруг так называемых 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/

Очень много букв, очень узкий класс задач, но, тем не менее познавательно и полезно https://proglib.io/p/graph-theory/

Идея использования архитектурных диаграмм, особенно карт, в качестве "фона" для дашбордов - она, конечно, правильная. Но рисовать карту ИТ ландшафта, как это сделано в примере от 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 как альтернативу заблокированному вместе с LinkedIn Slideshare.net?

Выложил пару презентаций: https://speakerdeck.com/mxsmirnov

Успейте бесплатно скачать новую версию книжки Google по SRE (нижняя ссылка) https://landing.google.com/sre/book.html Написано, что она будет бесплатно доступна для скачивания только до 23 августа, но пока ссылка еще работает

Упс... Халява закончилась. Ссылка, действительно, пропала :(

Применима ли CAP теорема к командам гибкой разработки? Можно ли организовать их взаимодействие так, чтоб для функционала, отданного разным командам, сохранялась согласованность и восприимчивость к изменениям? Более философский вопрос: а как насчет CAP теоремы для бизнес-процессов?

Беспокойства Мартина Фаулера https://martinfowler.com/articles/agile-aus-2018.html

Ну, вот, теперь и ardoq решил рассказывать нам на регулярной основе что такое настоящий EA https://blog.ardoq.com/ А помните, как мы рассказывали вам что такое ardoq? https://youtu.be/4dZ1vNbSFVY

Не успел внимательно разобраться в новой истории о том, как надо разбивать монолит на части https://martinfowler.com/articles/extract-data-rich-service.html но чувствую подвох. И дело здесь не только в фразах, типа to spot opportunities to move logic into the database query and thus make the code more performant Нельзя вот так вот прямолинейно выдрать цены из исходной таблицы и рассказать об этом всему миру на martinfowler.com Совсем какой-то неряшливый консалтинг-консалтинг

#Первоесентября Новый учебный год в ВШБИ ВШЭ мы открываем круглым столом "Архитектор ИТ-проекта" https://hsbi.hse.ru/events/open_lectures/kruglyy-stol-arkhitektor-it-proekta/ Вопросы к участникам, предложения по проведению ваших семинаров и вебинаров по архитектурной тематике пишите мне @mxsmirnov

Перевод статьи Top 33 JavaScript Projects on GitHub https://proglib.io/p/github-js-projects/ По звездам на GitHub: D3.js - 4-ое место, сразу после react, текстовый редактор atom - 13, фреймворк для HTML презентаций reveal.js - 19

Это неплохо :)

Корпоративные архитекторы делятся на две категории. У первых картинки текущей архитектуры страшные и запутанные, этакие кусочно-лоскутные, а целевой - симметричные, с аккуратными квадратиками. Мол всё выровняем, оставим оптимальное число целевых приложений, дублирующий функционал устраним, перекосы и дисбалансы поправим. У второй категории архитекторов всё ровно наоборот. И говорят они слова о том, что что-либо из ничего не возьмется, решить одну проблему можно только за счет [потенциального] возникновения другой и вообще, что архитектура это разделение целого на части для достижения локальных оптимизаций. Одним словом, чтоб вскипятить воду из озера, сначала отлейте маленький кусочек этого озера в чайник. Какой подход правильный - каждый решает для себя сам

Ну как не поделиться концептуальными картами наших коллег бизнес-аналитиков: https://www.artofba.com/blog/a-guide-to-the-babok-ver-3-of-iiba-in-custom-diagrams