Ссылка на перевод: 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), объяснил людям, что и парадокса то никакого нет, просто смотрят они на проблему каждый со своей точки зрения.

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

Закрыл опрос. Большое спасибо за участие! Ожидаемые для меня ответы о том, что избежать рисования картинок ИТ-архитектору практически нереально (37%), картинку проще нарисовать (30%) и про то, что архитектура это модель, а не картинка (18%), а вот неожиданные:

- эскизы на белой доске (2%) – думал будет существенно больше

- мне это нравится (21%) – думал будет меньше. Этот вариант ответа заставляет задуматься, а правы ли авторы утверждений, что свидетельством большого ума является способность выразить мысль в формате русскоязычной прозы. Без картинок. «Визуальное мышление» (в кавычках) вещь оказывается полезная. Не то мышление, о котором пишут в популярных книжках. Я бы даже назвал его топологическое или чанковое, т.е. позволяющее структурировать наборы объектов в некоторый типовые рисунки, созвездия если угодно

Вот не понимаю я, почему некоторые архитекторы предприятия недолюбливают agile. Тем более, почему вместо улучшения своих процессов, они пытаются исправить процессы разработчиков. Не надо этого делать, лучше заняться своими задачами. Гибкие методологии насоздавали множество полезных подходов, которые пригодятся и в архитектуре.

Возьмем, например, что-нибудь попроще, тот же Scrum Guide. Там русским по белому написано, что базируется он на эмпирической теории управления процессами, т.е. знания приходят не из TOGAF ADM или научно-популярных статей по архитектуре, а из опыта. Придумали или вычитал где-нибудь архитектор идею серебряной пули – проверь!

Для этого нам в помощь принципы транспарентности (значимые аспекты процесса должны быть видимы ответственным за результат) и инспектируемости. А принцип адаптируемости побуждает нас выстраивать собственный архитектурный процесс. Могут быть разные причины того, почему те или иные best practices у нас не работаю. Может быть они не подходят для нашей конкретной задачи, а может мы что-то не так поняли или не так сделали. Пробуем еще раз, смотрим что получилось, корректируем...

В свое время пропустил перевод https://habr.com/ru/post/441538/ вот этого замечательного текста https://panoply.io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud/
Билл Инмон против Ральфа Кимбалла (Естественно, я за второго, а вы?) "Звездочка" или "Снежинка, ETL vs. ELT, облачное хранилище от Amazon и BigQuery от Google. ... что там ещё?

Впрочем и этих vs. вполне хватит :-)

Да, еще вот! Если вы не знаете кто такой Кимбалл, то почитайте Манифест многомерного моделирования https://www.kimballgroup.com/1997/08/a-dimensional-modeling-manifesto/ Надолго отбивает охоту [выключить мозг] сесть и изложить предметную область в виде ER-модели на пару десятков сущностей

По большому счету, эта книжка еще и о том, что организации бывают плохие, хорошие и выдающиеся. И если разница между первыми и вторыми не так уж и велика, то выдающиеся компании существенно оторвались от всех остальных. В таких компаниях и архитектура слабосвязная и непрерывная интеграция работает и продуктовое мышление преобладает, сотрудники счастливы, а безопасность на высоте и никому не мешает.

В общем, грустная книжка о тщетности усилий по эволюционному преобразованию плохого в хорошее