Мне довольно утомительно повторять идею, которую мне внушили еще лет десять назад: 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 направлен так. Но я был бы рад комментариям. Вдруг кого-нибудь что-то зацепит из очередного списка

Еще про технологический радар. Вот прям с самого начала: Applying product management to internal platforms https://www.thoughtworks.com/radar/techniques/applying-product-management-to-internal-platforms Мне кажется эту идею уже несколько лет назад обсудили и... перевели в раздел магии. Есть несколько обзоров в интернет. Один из неплохих вот этот: https://www.thoughtworks.com/radar/techniques/applying-product-management-to-internal-platforms Впрочем, достаточно будет и этого твитта:
To be a Customer you have to:
a) have a Choice
b) Exchange something of value.
https://twitter.com/joshuajames/status/891432826817478657

Так зачем она в радаре v.22 от 2020г.?

PS: Тема нужная. Но до попадания в категорию ADOPT её еще трясти и трясти. Может что полезное и обнаружится

Демистификация ИТ-архитектуры
Говорят, что хороший проектный менеджер – это эксперт по управлению дефицитами. Не хватает людей в проекте, менеджер привлекает в команду новых людей. Не хватает денег – находит бюджет. Не укладывается проект в сроки, менеджер сужает рамки проекта. Заказчик начал выказывать неуверенность в результате, менеджер обнаруживает и митигирует риски, ну и т.д.

В этой логике ИТ-архитектор эксперт по управлению парадоксами. Стоит кому-либо усомниться в разрабатываемом решении, тут же зовут архитектора приводить частную точку зрения к единому видению. Возникли среди заинтересованных лиц взаимоисключающие суждения – снова зовут архитектора, чтоб он такие суждения развел по представлениям(views), объяснил людям, что и парадокса то никакого нет, просто смотрят они на проблему каждый со своей точки зрения.

В общем, роль важная, как ни крути. Не эксперт по дефицитам, конечно, но персонаж тоже полезный…