Size: a a a

Архитектура ИТ-решений

2020 October 14

EI

Eugene Istomin in Архитектура ИТ-решений
Phil Delgyado
Архитектор, которые не умеет работать поперек бизнес-процессов - бесполезен
Читаю чат, огонь фраза!
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Ivan
Мое видение о том, зачем архитектору уметь кодить заключается прежде всего в итеративности разработки. В BDUF это не критично. А в итеративных разработках - критично.

Многие знатоки архитектуры утверждают (и я убедился в этом на практике), что, если velocity начал проседать, то он проседает с быстротой экспоненты. Если velocity проседает, то значит есть проблемы на уровне системной архитектуры. Именно об этом и говорит 9-й принцип Agile Manifesto (обсуждали в соседнем чате). И эти проблемы должен кто-то исправить, иначе в бюджете может образоваться дыра неуправляемых масштабов. За кривую экономики разработки отвечает архитектура.

Вторая причина зачем нужно уметь кодить - чтобы помогать разработчикам реализовывать решения. У разработчиков часто возникает страх перед неизведанным, и они стараются ходить обходными путями, когда испытывают неуверенность. Скажем так, среднестатестический разработчик на рынке не сделает Event Sourcing самостоятельно в разумные сроки. Ему минимум месяц-два нужно только готовиться к подобной реализации. И архитектор должен или подготовить команду заблаговременно, чтобы команда успела ознакомиться с теорией и типовыми реализациями, или подключиться к процессу разработки, чтобы команда не завалила сроки. Не обязательно кодить, но он должен понимать и предвидеть потребности команд, и быть готовым выступить куратором, или снабдить информацией, требуемой для реализации.

Из моего личного опыта - когда проект имеет неплохое внутреннее качество (в РФ бывают неплохие проекты), то velocity обычно можно увеличить в течении года раз в 5. Т.е. на ту же сумму можно доставить в 5 раз больше business value. А если проект имеет неудовлетворительное внутреннее качество (что я часто наблюдал на заокеанском рынке), то там только за первые полгода зачастую можно улучшить экономику разработки на пару порядков.

Если velocity слишком низкое - то кто будет тогда реализовывать принимаемые решения? А за кривую velocity отвечает, как я говорил уже ранее, - архитектура.

Самый лучший руководитель, которого я когда либо встречал в своей жизни, был главный инженер одного горно-обогатительного комбината. Невероятно эрудированный человек и тиран. Его все уважали и боялись одновременно. Как-то раз я наблюдал, как он в оперативной диспетчерской комбината разговаривал по телефону со слесарем аварийного водоподъема, и рассказывал ему каким гаечным ключом и какую гайку тот должен открутить. Кстати, интересный момент, который его характеризует - он жил в предоставленном комбинатом жилье, ездил на служебной машине (своей у него не было), и в возрасте 65 лет он каждое утро в 6 утра пробегал несколько километров. Я от этого человека многому научился.
» Вторая причина зачем нужно уметь кодить - чтобы помогать разработчикам реализовывать решения

» И архитектор должен или подготовить команду заблаговременно, чтобы команда успела ознакомиться с теорией и типовыми реализациями

Да, активно исповедую этот подход.
Если говорить не "архитектор" тут, а "играющий тренер" - то это ок, архитектурной составляющей не так много - но много R&D с связанного с ним.
Использую, когда важен результат - но явно видно, что команда не будет готова говорить про "то, что не относится к CJM/USM".

Другими словами, когда замечаешь "туннельный синдром" у команды, и есть время и ресурс - то стоит помочь ребятам увидеть "то, что тебе никогда не расскажет заказчик, так как сам про это не знает".
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Прочитав 4 дня чата вижу, что "архитектор" - это для многих "целый человек", должность.
Есть тема с тем, что это "роль".

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

Абсолютизм "архитектора" заставляет игнорировать контекстные слова (такой-то архитектор), все прутся к шильдику "я архитектор" по причине ... вот по какой?

Тут есть и папы, и мамы. Есть папы Насть, а есть мамы Вань. Какие лучше? Какие правильные?
Те, которые отслеживают контекст взаимоотношений с ребёнком. Например.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Eugene Istomin
» Вторая причина зачем нужно уметь кодить - чтобы помогать разработчикам реализовывать решения

» И архитектор должен или подготовить команду заблаговременно, чтобы команда успела ознакомиться с теорией и типовыми реализациями

Да, активно исповедую этот подход.
Если говорить не "архитектор" тут, а "играющий тренер" - то это ок, архитектурной составляющей не так много - но много R&D с связанного с ним.
Использую, когда важен результат - но явно видно, что команда не будет готова говорить про "то, что не относится к CJM/USM".

Другими словами, когда замечаешь "туннельный синдром" у команды, и есть время и ресурс - то стоит помочь ребятам увидеть "то, что тебе никогда не расскажет заказчик, так как сам про это не знает".
Мне "по фану" было быть играющим тренером - и я играл. Был ли я "правильным архитектором, который не должен или должен писать код?"

Да какая разница! Концептуальная упоротость на одной истине - это то, что объединяет "тех, кто ищет в архитектуре спасение".
Проблема "архитектор и эмоциональный интеллект" - самая большая проблема, а не "должен ли он писать код"
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Другими словами, позиция "я знаю, как правильно - и скажу вам, я же архитектор" - она годится для тех, кто хочет обыгрывать разницу в понимании между собой и "теми, кто ещё не понял".
А это провальная стратегия, это не win-win, это не "взрослый-взрослый".

Отыгрывание "родитель - ребёнок" в проф.смысле довольно вредная практика для обоих, так как возникает привыкание.
Именно поэтому Взрослый должен уметь писать PoC, так как это как "Привет, я взрослый".
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Таким образом, всё что можно сказать про Ivory Tower архитектора (фу таким быть, верно?), про Powerpoint архитектора (аналогично), про "владельца единственно верной концепции" или про "я тут вам всё расскажу, как правильно" - это то, что они играют в семейную драму, становясь "тем правильным взрослым, который точно знает, как нужно - и может рассказать ребёнку".

И тут стоит помнить, что этот ребёнок - тот же архитектор, и не путать "своего ребёнка" и команду, с которой работаешь.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Тут мы приходим к вопросу "что же эволюционирует в эволюционной архитектуре?"

Отношения. И всё.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
источник

F

Fagor in Архитектура ИТ-решений
Во всем это, есть нюанс. Работник работает (выполняет ограниченный объем работ во времени, создающие ограниченный набор результатов) на работадателя за, кто бы мог подумать, Деньги. И все это (имеется в виду хорошая, правильная, стройная система) летит к чертям, так как он выполняет не объем, не результат, а функции. Любые попытки договориться про объем и результат за приемлемую компенсацию вложенных усилий, если вы не аутсорсер, обречены на провал. Сегодня базис построен на уровне основ трудовых отношений - "Капитал". Другая структура, где возникает потребность и возможность функциональной роли, в трудовых отношениях, Архитектор, при капитализме пока не существует.
источник

F

Fagor in Архитектура ИТ-решений
Так что выходит все очень хорошо, но не жизнеспособно. Каждое ведомство должно заниматься своим делом. CEO не должен копать собственоручно, в рамках трудовых отношений, даже если копающие в ступоре и устали, а у него есть свободное время.
источник

AM

Andrei Moiseev in Архитектура ИТ-решений
Phil Delgyado
Понятия не имею. Я cadence не использую, мы свое написали
А ты про это решение нигде не писал?) Мне вот сейчас тоже нужно в проект оркестрацию процессов заносить и пока тоже склоняюсь к тому, чтобы свое написать. Но интересно на чужой опыт посмотреть.
источник

AT

Al T in Архитектура ИТ-решений
ну AWS step functions есть если религия позволяет
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Andrei Moiseev
А ты про это решение нигде не писал?) Мне вот сейчас тоже нужно в проект оркестрацию процессов заносить и пока тоже склоняюсь к тому, чтобы свое написать. Но интересно на чужой опыт посмотреть.
Увы. Может расскажу на каком-нибудь РИТ или хайлоаде в следующем году.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Но вообще там все довольно просто. Процесс есть набор почти-идемпотентных лямбд. После выполнения каждой сохраняешь результат.
При рестарте процесса проходишь по цепочке и вместо выполнения - подставляешь сохраненный результат.
Последний раз делали на котлине+fdb, все заняло где-то 90чд (с документацией, отладкой и так далее).
Основная сложность - сделать красиво и удобно для программиста.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Гм. Интересно на вас covid каникулы подействовали.
источник

IA

Igor A in Архитектура ИТ-решений
Eugene Istomin
Таким образом, всё что можно сказать про Ivory Tower архитектора (фу таким быть, верно?), про Powerpoint архитектора (аналогично), про "владельца единственно верной концепции" или про "я тут вам всё расскажу, как правильно" - это то, что они играют в семейную драму, становясь "тем правильным взрослым, который точно знает, как нужно - и может рассказать ребёнку".

И тут стоит помнить, что этот ребёнок - тот же архитектор, и не путать "своего ребёнка" и команду, с которой работаешь.
Ого. +1 к многобуквам. Доставило
источник

СБ

Сергей Бирюков... in Архитектура ИТ-решений
Очень интересные мысли
источник

NK

Nikolay Korolev in Архитектура ИТ-решений
Fagor
Во всем это, есть нюанс. Работник работает (выполняет ограниченный объем работ во времени, создающие ограниченный набор результатов) на работадателя за, кто бы мог подумать, Деньги. И все это (имеется в виду хорошая, правильная, стройная система) летит к чертям, так как он выполняет не объем, не результат, а функции. Любые попытки договориться про объем и результат за приемлемую компенсацию вложенных усилий, если вы не аутсорсер, обречены на провал. Сегодня базис построен на уровне основ трудовых отношений - "Капитал". Другая структура, где возникает потребность и возможность функциональной роли, в трудовых отношениях, Архитектор, при капитализме пока не существует.
На мой взгляд, такие установки длят UX рабовладения как технологию управления, которую даже не надо осознавать, которой не надо специально с уровня сознания научать себя. Человек «просто принимает» внутреннюю моральную позицию общения в «соответствующем репозитории» и «оформляет подписку на канал».

«Проблема» в том, что в дискурсе «архитектура IT решений» слова «архитектура» и «IT» легально в историческом контексте замыкают на себя знания о процессах, которые существуют много много много дольше «computer science» и которые computer science обслуживает, но внутри самой computer science свои внутренние миры и их обитатели. Рынок заинтересован и рынок будет продолжать платить за то, чтобы позволить брату не прокидать границу внутренних миров computer science. Поэтому работник работает на работодателя, а робот работает на роботодателя и все выполняют функции, а любые попытки договориться - это война миров, восстание машин, neverland и повелитель мух, а детей находят в капусте.

Сегодня, вчера и завтра базис работает по закону Конвея и все пожинают тот дизайн, которые они себе думают, но вероятно спанчбоб не может нести за это никакой ответственности, потому что он не на аутсорсе.


Из-за это и происходят когнитивные прокрастинации соизмерения совы и глобуса в парадигме гибкого мышления.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Изменил своему принципу, сначала прочитал, и только потом пишу. Женя, огонь!)
источник

F

Fagor in Архитектура ИТ-решений
Nikolay Korolev
На мой взгляд, такие установки длят UX рабовладения как технологию управления, которую даже не надо осознавать, которой не надо специально с уровня сознания научать себя. Человек «просто принимает» внутреннюю моральную позицию общения в «соответствующем репозитории» и «оформляет подписку на канал».

«Проблема» в том, что в дискурсе «архитектура IT решений» слова «архитектура» и «IT» легально в историческом контексте замыкают на себя знания о процессах, которые существуют много много много дольше «computer science» и которые computer science обслуживает, но внутри самой computer science свои внутренние миры и их обитатели. Рынок заинтересован и рынок будет продолжать платить за то, чтобы позволить брату не прокидать границу внутренних миров computer science. Поэтому работник работает на работодателя, а робот работает на роботодателя и все выполняют функции, а любые попытки договориться - это война миров, восстание машин, neverland и повелитель мух, а детей находят в капусте.

Сегодня, вчера и завтра базис работает по закону Конвея и все пожинают тот дизайн, которые они себе думают, но вероятно спанчбоб не может нести за это никакой ответственности, потому что он не на аутсорсе.


Из-за это и происходят когнитивные прокрастинации соизмерения совы и глобуса в парадигме гибкого мышления.
Толсто. Можно было еще завуалировать. Про деньги не нашел :(.
источник