Size: a a a

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

2021 February 19

AL

Alexander Luchkov in Архитектура ИТ-решений
Есть ещё Олег Кировский в Яндексе крутой парень по функциональной безопасности. Автопилоты для машин делает.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
@GKruglov Я как в Доводе (Tenet) сделал — прочитал весь тред в обратную сторону к началу, очень интересно ))

Я правильно понял, что боль, условно, про ArchOps? А трекер просто выступил примером фокусировки исключительно на реализации?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Alexey Mergasov
Цель управления изменениями.
А вот тут уже все сложнее.
Так как варианты A и B - это всегда не про "текущее состояние", а про "идеальное". И в реальной системе нет ни A, ни B, есть какой-то процесс перехода. И удобных инструментов для отслеживания и управления архитектурой именно как процессом, а не артефактом - вроде бы и нет.
Версионирование чуть-чуть помогает, но не сильно. А уж как оно связано с трекером - мне совсем не понятно.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Phil Delgyado
А вот тут уже все сложнее.
Так как варианты A и B - это всегда не про "текущее состояние", а про "идеальное". И в реальной системе нет ни A, ни B, есть какой-то процесс перехода. И удобных инструментов для отслеживания и управления архитектурой именно как процессом, а не артефактом - вроде бы и нет.
Версионирование чуть-чуть помогает, но не сильно. А уж как оно связано с трекером - мне совсем не понятно.
Ну я бы предположил, что в трекере должны быть инструменты типа "Доска для управления изменениями" где куча всяких ништяков про процессы утверждения документации, внесения изменений в техпроцесс и прочей фигни.
Типа автоматизация разбиения работ по внесению и учёту изменений.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Phil Delgyado
А вот тут уже все сложнее.
Так как варианты A и B - это всегда не про "текущее состояние", а про "идеальное". И в реальной системе нет ни A, ни B, есть какой-то процесс перехода. И удобных инструментов для отслеживания и управления архитектурой именно как процессом, а не артефактом - вроде бы и нет.
Версионирование чуть-чуть помогает, но не сильно. А уж как оно связано с трекером - мне совсем не понятно.
Теоретически, ты можешь diff (текущее идеальное — текущее реальное) раскладывать в набор тасков реализации, которые как раз выгребут разницу.
Но это, конечно, в реальной жизни не будет работать — из-за характера изменений будущего, отставания самого диффа и из-за адской неустойчивости этого gap-backlog'а к любым изменениям.

Но такое пытаются советовать все равно; в том числе бизнес / клиенты
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Denis Zarin
Теоретически, ты можешь diff (текущее идеальное — текущее реальное) раскладывать в набор тасков реализации, которые как раз выгребут разницу.
Но это, конечно, в реальной жизни не будет работать — из-за характера изменений будущего, отставания самого диффа и из-за адской неустойчивости этого gap-backlog'а к любым изменениям.

Но такое пытаются советовать все равно; в том числе бизнес / клиенты
Это да и приходится примерно так и жить - иметь кучку картинок и размахивать руками "типа мы сейчас примерно тут, это уже отмирающая часть, а это вот только родилась". Но при этом в голове все равно картинка "процессов изменения", которую очень сложно положить на диффы.
Я хочу мультики рисовать и привязывать процессы к мультику )
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
Phil Delgyado
А вот тут уже все сложнее.
Так как варианты A и B - это всегда не про "текущее состояние", а про "идеальное". И в реальной системе нет ни A, ни B, есть какой-то процесс перехода. И удобных инструментов для отслеживания и управления архитектурой именно как процессом, а не артефактом - вроде бы и нет.
Версионирование чуть-чуть помогает, но не сильно. А уж как оно связано с трекером - мне совсем не понятно.
Видимо мы с вами имеем дело с системами разного масштаба и критичности. В моём случае нахождение системы в недетерминированном состоянии с точки зрения архитектуры, это равносильно катастрофе. Что собственно системы безопасности выявляют давольно быстро.
источник

DC

Dmitriy Chernyak in Архитектура ИТ-решений
Alexander Luchkov
Есть ещё Олег Кировский в Яндексе крутой парень по функциональной безопасности. Автопилоты для машин делает.
Наверное, тот же самый Олег, про которого я вспомнил, когда речь про железо пошла. На одной встрече аналитиков как-то оказались, он рассказывал про предыдущий опыт за пределами РФ и про работу аналитика в контексте датчиков и сенсоров в автопроме.
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
Даже конфиги апп серверов находятся под контролем систем безопасности
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Dmitriy Chernyak
Наверное, тот же самый Олег, про которого я вспомнил, когда речь про железо пошла. На одной встрече аналитиков как-то оказались, он рассказывал про предыдущий опыт за пределами РФ и про работу аналитика в контексте датчиков и сенсоров в автопроме.
Если большой и бородатый - да, он.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Alexey Mergasov
Видимо мы с вами имеем дело с системами разного масштаба и критичности. В моём случае нахождение системы в недетерминированном состоянии с точки зрения архитектуры, это равносильно катастрофе. Что собственно системы безопасности выявляют давольно быстро.
У меня более-менее стандартный финтех, ничего life critical
Но система при этом всегда в состоянии изменения, увы.
источник

DC

Dmitriy Chernyak in Архитектура ИТ-решений
Alexander Luchkov
Ну я бы предположил, что в трекере должны быть инструменты типа "Доска для управления изменениями" где куча всяких ништяков про процессы утверждения документации, внесения изменений в техпроцесс и прочей фигни.
Типа автоматизация разбиения работ по внесению и учёту изменений.
У меня на текущем проекте в Jira+Конфа+большой нудный регламент-процесс за счет кучи плагинов реализовано так - связка стори с артефактами, версионирование артефактов, отправка на согласование и т.д. Долго, нудно, больно.
источник

DC

Dmitriy Chernyak in Архитектура ИТ-решений
Alexander Luchkov
Если большой и бородатый - да, он.
Да, он))
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Dmitriy Chernyak
У меня на текущем проекте в Jira+Конфа+большой нудный регламент-процесс за счет кучи плагинов реализовано так - связка стори с артефактами, версионирование артефактов, отправка на согласование и т.д. Долго, нудно, больно.
Ну вот так и живём...
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
Phil Delgyado
У меня более-менее стандартный финтех, ничего life critical
Но система при этом всегда в состоянии изменения, увы.
Финтех финтеху рознь, но ок. Если удалось выжить без версионирования , можно только порадоваться
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Alexey Mergasov
Финтех финтеху рознь, но ок. Если удалось выжить без версионирования , можно только порадоваться
Ну, кроме крупных банков - а зачем вообще сложная архитектурная работа? Финтех все-таки достаточно простая штука.
По тому, что я вижу - даже спаркс не очень нужен.
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
финтех - это просто, согласен
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Denis Zarin
@GKruglov Я как в Доводе (Tenet) сделал — прочитал весь тред в обратную сторону к началу, очень интересно ))

Я правильно понял, что боль, условно, про ArchOps? А трекер просто выступил примером фокусировки исключительно на реализации?
Да, Денис, именно)
источник

NZ

Nick Z in Архитектура ИТ-решений
Phil Delgyado
Ну, кроме крупных банков - а зачем вообще сложная архитектурная работа? Финтех все-таки достаточно простая штука.
По тому, что я вижу - даже спаркс не очень нужен.
В любой распределенной и многослойной системе.
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
а зачем оно в финтехе?
источник