Архитектура ИТ-решений
16K subscribers
330 photos
2 videos
34 files
1.21K links
Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений).

Регистрация в перечне РКН: https://knd.gov.ru/license?id=6735f4cd97de7d1d1953c457&registryType=bloggersPermission
Download Telegram
В одной из компаний, в которой я когда-то работал, ИТ-архитекторы делились на два вида: системные и бессистемные.

Системными называли тех, кто отвечал за развитие какой-то конкретной информационной системы, а бессистемными – архитекторов, проектировавших решения и интеграционные взаимодействия. Я еще шутил, что им просто своей системы не досталось. Возможно, термин этот был немного обиден, но мне он нравился. Да и архитекторов этих вскоре стали называть solution architect.

А вспомнил я о том, прочитав свежую реплику Анатолия Левенчука, которой хочу поделиться с вами https://ailev.livejournal.com/1557247.html Сразу скажу, что мне порой доводилось встречать еще одно, третье понимание системного мышления, не совпадающее с рассмотренными в этом тексте. Но обобщение, которое я для себя принял исходя из этого и подобных рассуждений в том, что при встрече с термином системный, или производными от него, лучше проявить некоторую настороженность
Архитектура ИТ-решений
В одной из компаний, в которой я когда-то работал, ИТ-архитекторы делились на два вида: системные и бессистемные. Системными называли тех, кто отвечал за развитие какой-то конкретной информационной системы, а бессистемными – архитекторов, проектировавших…
Сейчас просто предложение договориться о терминах для людей, хоть чуть-чуть знакомых с тем же DDD, выглядит несколько стрёмно. Оно может рассматриваться как приглашение в чужой ограниченный контекст или же попытка нарушить границу вашего (Пришли тут инженеры учить айтишников программы писать)

Да никогда мы, в полной мере, не договоримся о терминах! Мы можем договориться о следовании к общей цели и это позволит нам временно закрыть глаза на несоответствия в терминах и смыслах соратника. Чтоб действовать не разобщенно, а согласовано. Временно войти в некоторую игру, принять её правила, оставаясь частично вне игры. Соблюдать эти правила мы будет ровно до момента достижения цели и ни секундой дольше

Так стоит ли договариваться о терминах? Давайте отдадим предпочтение пониманию
Поделюсь приглашением из чата
Forwarded from Катерина
Приглашаем 16 марта в 18:00 на митап по архитектуре продуктов — поговорим о микросервисной архитектуре и использовании git submodules.

В программе выступления спикеров от Банка «Санкт-Петербург» и Lipt-Soft, интерактив и подарки за классные вопросы спикерам.

На игру мы приглашаем специалистов уровня миддл и выше. Участие бесплатное, но нужно зарегистрироваться. Мы пришлем вам приглашение после модерации: https://bit.ly/3c1VCvu
Поздравляю подписчиц канала с праздником 8-марта (вместо банального сообщения с картинкой я предлагаю вам присоединиться к голосованию)
Final Results
76%
🌷Присоединяюсь к поздравлениям, с праздником!
15%
Спасибо :-)
9%
А я вот промолчу 😶
В чате это сообщение может потеряться, поэтому поделюсь здесь
Я, как это всегда и бывает, пропустил самое интересное. На этот раз речь о серии из шести прошлогодних заметок, которые Gregor Hohpe озаглавил Thinking Like An Architect. Мне на глаза попалась только пятая Architects Zoom In and Out, See Different Things в которой он пошагово улучшает ;) картинку из книжки Марка Ричардса и Нила Форда The Fundamentals of Software Architecture.

Естественно, я посмотрел и остальные. Серия начинается здесь: https://architectelevator.com/architecture/famous-architects-sketch/ А посетовать я хочу на то, что мне более чем симпатичны идеи автора, но, почему-то, совершенно не нравятся его тексты. Может у кого-то сходные ощущения?
Архитектура ИТ-решений
Я, как это всегда и бывает, пропустил самое интересное. На этот раз речь о серии из шести прошлогодних заметок, которые Gregor Hohpe озаглавил Thinking Like An Architect. Мне на глаза попалась только пятая Architects Zoom In and Out, See Different Things …
А теперь время согласиться и одновременно поспорить с уважаемым Грегором Хоупом. В первой статье цикла Мыслить как архитектор он замечает, что архитекторы (не айтишные, проектирующие дома), создающие эскизы зданий, иногда в виде скетчей на салфетке, зарабатывают много больше инженеров, разрабатывающих чертежи поэтажных планов и схем электропроводки. Но автор никак не может ухватить слово, описывающее их деятельность: abstraction не abstraction, illusion, gestalt… Хотя, на мой взгляд, здесь вполне подошло бы слово ideation, т.е. концептуализация – формирование понятий или представлений. И все дальнейшие разговоры об «устранении шума» в эскизах, выделении главного и пр., встречающееся и в первой, и в пятой заметке цикла, выражаются этим словом.

Архитектор занимается концептуализацией, тратя порой значительные силы и время, чтоб выразить идею решения понятной и лаконичной метафорой. А чертежи нам потом специально обученные алгоритмы нарисуют, ну или пока люди, освоившие нотации моделирования на соответствующих учебных курсах
Просто не могу не поделиться этой жизнерадостной рекламой. Если так и дальше пойдет, то и про ИТ-архитекторов начнут писать что-то подобное
Вчера появилась новая версия 1.4 Enterprise Architecture on a Page от Svyatoslav Kotusev http://eaonapage.com/ Впервые она стала цветной
22 марта в 15:00MSK - хорошее время провести первый голосовой чат в нашем новом телеграмхаусе. Прямо здесь, на этом канале, мы немного поговорим о вещах, которые связаны с Domain Driven Design, но полезны и в более широком контексте. В общем, разговор будет на тему NoDDD.

Делитесь этим приглашением и присоединяйтесь!
(Ссылка на FB: https://fb.me/e/bVMiI2xKL)
Великолепно!
Philippe Kruchten с соавторами представили нам небольшую теорию архитектурного технического долга. Я было повелся на фразу a little theory (=conceptual model), тем более, что работа в открытом доступе https://www.sciencedirect.com/science/article/pii/S0164121221000224, но через пару страниц понял, что наскоком этот текст не осилить, даже если пропустить первые два раздела, описывающие само исследование и сразу перейти к модели. В общем, объемное описание причин, симптомов и последствий архитектурного тех.долга для вдумчивого чтения и перечитывания