К сожалению, самые интересные на мой взгляд вопросы о том, почему ряд трендов прошлогоднего отчета, таких как CQRS, преодолели пропасть между ранними последователями и большинством, а  другие, например Evolutionary Architecture, потерялись. Возможно, застряли в "пропасти"?

Как кризис повлиял на денежные потоки в телеком и IT

Мне довольно утомительно повторять идею, которую мне внушили еще лет десять назад: digital disruption – это не о том, что надо всю деятельности перевести в цифру, а скорее о том, что завтра придет какая-то неизвестная ранее компания и начнет делать некоторую, очень малую часть вашей цепочки создания ценности в десять раз эффективней, чем вы это делали сами. При этом, скорее всего платить ей за использование этой фичи вы будете в десять раз больше, чем тратили на этот шаг цепочки раньше. Потому, что это капитализм. Отказаться будет можно только потеряв часть клиентов, возможно значительную часть. Ну, просто клиенты начнут орать: почему вы не продаёте айфоны или еще что-то подобное. Главное, что требуется от компаний (и от их айтишников), четко и экономически выгодно на это отреагировать. Т.е. не раздавать айфоны бесплатно у метро, а сделать что-то чуть более осмысленное

Что-то мне подсказывает, что уже очень скоро вместо разработки и проведения учебных курсов по архитектуре ИТ-решений мне придется рисовать карточки для подготовке к собеседованиям. Как-то так: https://github.com/donnemartin/system-design-primer Ну, и еще по стопочкам их раскладывать:
- быстро,
- чуть подробнее,
- некуда спешить

В группе "Архитектура ИТ-решений" опрос о том, кто сегодня работает. На текущий момент 52 голоса. Половина ответивших не работает, а другая очень даже трудится. Причем 11% делает это в офисе

Ссылка на перевод: https://docs.google.com/document/d/1w3qb6SS1Hycyce5Fg5mVMdzkGYXTRskSf57IoD98ZQw/edit?usp=sharing Он, конечно, немного странный. Чего стоит термин "мастер-раб", но может кому пригодится

А забавное чтиво. Там и перевод на русский язык есть. В git и docs.google.

Самой туманной областью архитектуры решений (Solution architecture) является выбор варианта реализации решения на основании сравнения набора альтернатив. Многие solution architects отлично владеют этим навыком, но никто его внятно не описал :(

Очень такой типичный подход к ИТ-обучению от Бориса Бобровникова в интервью РБК 30.04.2020: https://youtu.be/7CuJ6bb3Vc4?t=554

у нас хорошо сегментированный бюджет (можно было бы добавить: оргструктура, бизнес-процессы, приложения), мы знаем что можно сдать, это, например, обучение; онлайн в разы дешевле...

Вот так этот самый digital и работает :-)

Свежая статья о том, что данные из микросервисов, ну или по крайней мере часть данных, всё же придется выносить в отдельные конструкции https://www.infoq.com/articles/data-gateways-cloud-native/ В общем, все об этом так или иначе умалчивали несколько лет, но, похоже, пришла пора обсудить

Мне очень нравится эта лекция Алана Кея https://www.pvsm.ru/programmirovanie/276228

Но я абсолютно не понимаю как включить в современный онлайновый курс рассуждения о том, что Computer Science - это наука о процессах, а не компьютерах. Она не изучает компьютеры, т.е. не занимается их описанием, классификацией и т.д. Точно так же программная инженерия не исчерпывается инженерией или программированием, она о другом...

Chris Richardson, безусловно, авторитетный эксперт. И я рад, что его шаблон описания микросервисов теперь есть и для GoogleDoc (Здесь: https://github.com/cer/microservice-canvas описание шаблона см. здесь: http://chrisrichardson.net/post/microservices/general/2019/02/27/microservice-canvas.html), но почему-то меня сильно смущают в описании API слова
createOrder(), reviseOrder(), cancelOrder()
Может быть RPC снова в моде?

Принято считать, что архитектура предприятия начинается с работы Джона Захмана A framework for information system architecture, 1987. Но двумя годами позже, другой человек придумал не только подход, но и предложил инструмент такого описания.

Тим Бернес-Ли в "Information Management: A Proposal" https://www.w3.org/History/1989/proposal.html пишет: CERN – удивительная организация. В ей деятельности участвует несколько тысяч человек, многие из которых очень креативны и работают на достижение общих цели. Хотя они номинально организованы в иерархическую структуру управления, это не ограничивает способ общения между людьми и обмен информацией, оборудованием и программным обеспечением между группами. Фактически структура организации представляет собой многосвязную «сеть», которая развиваются с течением временем. В этой среде новому человеку, обычно дают несколько советов о том, с кем можно было бы поговорить. Информация о существующих возможностях публикуется в периодических информационных бюллетенях, но чаще передается в коридорах в виде сплетен. Учитывая все обстоятельства, результат является удивительно успешным, несмотря на случайные недоразумения и дублирующиеся усилия...

В чём важность этой истории. Многие организации, да и государство в целом, не первый год пытаются внедрить архитектуру предприятия as a governance. Ну, т.е. мы будем говорить вам какие технологии правильные, как структурировать и где хранить данные и т.д. Но ни у кого я не видел архитектуру предприятия as a service. Может инструменты не те используются, а может подход не те головы придумывают

Демистификация ИТ-архитектуры
В рамках одного корпоративного курса по ИТ-архитектуре началось обсуждение, которое мне хочется вынести на более широкую аудиторию

В ИТ-архитектуре есть много практик, которые при внешнем сходстве довольно сильно различаются между собой. Например, описание текущей архитектуры вещь более-менее формализуемая. Здесь подходят строгие нотации, всякие UML, archimate, формальные языки описания aka ADL, да и вызывающее все больший интерес architecture-as-a-code – тоже сюда. А вот проектирование, особенно верхнеуровневое и концептуальное, решительно восстает против всех этих скучных вещей. Здесь нужны эскизы, быстрые наброски для обсуждений и непрерывной переделки.  Нотация здесь: boxes and arrow. Все это как-то более или менее понимают, ну или воспринимают на уровне ощущений.

Таких противопоставлений можно насобирать десяток, может больше. Кроме fact-decision (он же as is против to be), есть еще противопоставление контекста и внутренней структуры, анализа и проектирования и т.д.

Но самое интересное происходит дальше. В какой-то момент противоречивые практики начинают сливаться в единое целое. Так в архитектуре решений (solution architecture) мы делаем карандашные наброски, элементами которых является вполне себе реальные приложения из CMDB, документированные вдоль и поперек API и описанные источники данных. Если делать не так, а просто рисовать произвольные фигурки со стрелочками, то архитектура решения не сложится. Нельзя так делать. Архитектура решения - это  набросок изменения, нарисованный от руки поверх строгих, актуальных и выверенных  as-is диаграмм.  При этом, специфицировать  решение с точностью до последнего гвоздя, да еще в правильных нотациях тоже никто не будет…

Не это ли в ИТ-архитектуре самое интересное?

А кто-нибудь читает этот регулярно обновляемый (пополняемый) пост Мартина Фаулера? https://martinfowler.com/articles/branching-patterns.html (Посмотрите Significant Revisions внизу сообщения)

Мне стало совсем не интересно комментировать технологический радар https://www.thoughtworks.com/radar (на самом деле, еще с предыдущей версии). То ли технологическая граница уехала так далеко, что я уже не различаю её черты, то ли вектор у ThoughtWorks направлен так. Но я был бы рад комментариям. Вдруг кого-нибудь что-то зацепит из очередного списка