Size: a a a

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

2021 January 14

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Легаси потому и Легаси, что они непознаваемы.

Решение без релевантной документации не Легаси до тех пор, пока его архитектура в головах у команды.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
As is часто Big Ball of Mud или Legacy. Не надо там ничего проектировать и отображать нечего
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Gennadiy Kruglov
As is часто Big Ball of Mud или Legacy. Не надо там ничего проектировать и отображать нечего
AS IS когда то был TO BE...
источник

A

Alex in Архитектура ИТ-решений
Igor Nikolskiy
AS IS когда то был TO BE...
А может TO BE и не существовал никогда
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Alex
А может TO BE и не существовал никогда
Точно
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Как-то наслоилось
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Alex
А может TO BE и не существовал никогда
Плохо спроектированный to be, всё равно to be
источник

A

Alex in Архитектура ИТ-решений
agile вообще не предполагает TO BE
источник

A

Alex in Архитектура ИТ-решений
sh*t up and make increment!
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Хорошо, давно забытый и/или изначально не осмысленный To Be
источник

A

Alex in Архитектура ИТ-решений
бизнес-TO-BE почти никогда не существует, а ИТ как отображение бизнеса, соответственно, тоже не может его иметь
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Gennadiy Kruglov
Хорошо, давно забытый и/или изначально не осмысленный To Be
Т.е. ты предполагаешь изначально, что ошибки Legacy ты не повторишь? Даже если они "родовые пятна" бизнеса организации? Или коллектива? Или топов? Или все в твоей команде с серебряной пулей за пазухой?
источник

VN

V N in Архитектура ИТ-решений
Тогда чем мы все здесь занимаемся если будущая архитектура это химера :) а прошлую не стоит  документировать?
источник

A

Alex in Архитектура ИТ-решений
V N
Тогда чем мы все здесь занимаемся если будущая архитектура это химера :) а прошлую не стоит  документировать?
А это правильный вопрос, и реальность в крупных организациях в снг (другого не знаю) показывает, что архитекторы строят свои замки параллельно с тем как разработка делает "как-то". Между замком и "как-то" низкая корреляция.
источник

A

Alex in Архитектура ИТ-решений
А уже когда появляется понимание низкой корреляции появляется следом и желание нарисовать as-is, а потом построить еще один замок to-be
источник

A

Alex in Архитектура ИТ-решений
Много организаций достигло в своих проектах to-be?
источник

A

Alex in Архитектура ИТ-решений
я не знаю
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Igor Nikolskiy
Т.е. ты предполагаешь изначально, что ошибки Legacy ты не повторишь? Даже если они "родовые пятна" бизнеса организации? Или коллектива? Или топов? Или все в твоей команде с серебряной пулей за пазухой?
Нет. Я не это хотел сказать. Если уже есть Легаси, то не стоит пытаться восстановить As Is. Просто "чёрный ящик".
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
V N
Тогда чем мы все здесь занимаемся если будущая архитектура это химера :) а прошлую не стоит  документировать?
Продлением жизни
источник

MS

Maxim Smirnov in Архитектура ИТ-решений
У меня тут слайдик завалялся относительно характеристик to-be архитектуры
источник