Возможно, не самый убедительный текст среди остальных статей Диона Хинчклиффа относительно 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

Флант продолжает радовать историями на хабре про новые продукты в "песочнице" CNCF (Cloud Native Computing Foundation) На этот раз - распределённая, транзакционная база данных типа ключ-значение TiKV https://habr.com/company/flant/blog/421903/

Grady Booch, Simon Brown и другие уважаемые архитекторы ПО обсуждат в твиттере enterprise architecture https://twitter.com/Grady_Booch/status/1038075643169103874

The Tragedy of Craftsmanship Большой комментарий Uncle Bob к недавнему выступлению Martin Fowler The State of Agile in 2018. Основная мысль: проектные менеджеры вытеснили разработчиков из agile https://blog.cleancoder.com/uncle-bob/2018/08/28/CraftsmanshipMovement.html

Меньше чем через час начинаем вебинар "Архитектура ИТ-решений" Для тех, кто не успел зарегистрироваться или по каким-то причинам не получил ссылку, заходите прямо на https://attendee.gotowebinar.com/register/2904526384319732235

Как-то не радует сегодня меня новостной поток архитектурными инсайтами. Скорее наоборот. Статья в InfoQ How the TOGAF Standard Serves Enterprise Architecture https://www.infoq.com/articles/TOGAF-enterprise-architecture раздосадовала (см. картинку о том, как умело синхронизируется завершение фазы –D- TOGAF ADM со спринтами – какая свежая мысль, однако :-О Потому один тезис о вчерашнем вебинаре. Я пытался донести одну простую, можно даже сказать банальную, мысль: сложность и запутанность ИТ-ландшафта не стоит считать результатом чьих-то ошибок, некомпетентности или злого умысла. Сформировался он в результате правильных управленческих решений: приоритизация требований и задач (сначала делаем самое нужно, а остальное – потом как-нибудь), выбор оптимальных технологий и поставщиков, митигация риска зависимости от единственного разработчика или системного интегратора, параллельное проведение изменений и т.д. Менеджеры так всегда делали и буду делать впредь. Отсюда и неизменная потребность в наличии ИТ-архитектора, способного сбалансировать эту непростую систему. По-моему, очевидно! Но рад за слушателей, которых эта мысль зацепила