PT
Вопрос в том, что бы оценить outcome, эффект от предполагаемых изменений. В частности чтобы приоритезировать и выбрать.
Size: a a a
2021 March 03
АЛ
составляете карточку архитектурного решения, описываете проблему, описываете варианты решения, смотрите какие у выбранного решения есть плюсы и минусы, сравниваете с текущей ситуацией, добавляете риски которые возникнут в процессе перехода и после реализации решения. если все плюсы, минусы, риски сможете оценить в деньгах по той или иной модели - то супер. если не можете в деньгах, то оценивайте качественно.
AZ
измельчали архитекторы )
AZ
Вопрос в том, что бы оценить outcome, эффект от предполагаемых изменений. В частности чтобы приоритезировать и выбрать.
Смотрите какой момент - на чисто инфраструктурном уровне я например могу реализовать чертову кучу вариантов показателей и их сочетаний. Ценник при этом может меняться в 100Х и более.
Отталкиваться от вариантов решений, если не ясна задача - бессмысленно. Надо формулировать задачу, причем в деньгах
Отталкиваться от вариантов решений, если не ясна задача - бессмысленно. Надо формулировать задачу, причем в деньгах
AZ
А потом придет ИБ с комплаенсом и ФЗ 152 и скажет "а теперь переделывай"
p
А потом придет ИБ с комплаенсом и ФЗ 152 и скажет "а теперь переделывай"
А теперь на российском оборудовании (c)
AZ
А теперь на российском оборудовании (c)
Можно и на российском. Но вообще это лучше сразу в ТЗ записывать на разработку решения
p
составляете карточку архитектурного решения, описываете проблему, описываете варианты решения, смотрите какие у выбранного решения есть плюсы и минусы, сравниваете с текущей ситуацией, добавляете риски которые возникнут в процессе перехода и после реализации решения. если все плюсы, минусы, риски сможете оценить в деньгах по той или иной модели - то супер. если не можете в деньгах, то оценивайте качественно.
а как можно оценивать варинты решения не имея соответствующей экспертизы? может, вам свой цод строить придется
p
ну т.е. имея бюджет в 1 млрд долларов мир выглядит несколько иначе
АЛ
а как можно оценивать варинты решения не имея соответствующей экспертизы? может, вам свой цод строить придется
Без экспертизы - никак. Если нет внутренних экспертов, ищите внешних. Но если у вас нет экспертов, то как вы вырабатывание решение? Без экспертов до оценки даже не дойдет...
AZ
Без экспертизы - никак. Если нет внутренних экспертов, ищите внешних. Но если у вас нет экспертов, то как вы вырабатывание решение? Без экспертов до оценки даже не дойдет...
Говорят это размытие ответственности :)
I
Привет.
Случай с микросервисами понятен. А вот как понять, насколько лучше станет? По хорошему, откуда-то бы процент уменьшения t2m взять.
Случай с микросервисами понятен. А вот как понять, насколько лучше станет? По хорошему, откуда-то бы процент уменьшения t2m взять.
Time2market не есть цель. Микросервисы дают такую возможность за счет решения проблемы Брукса, но эту возможность еще нужно реализовать и оправдать. А реализовать ее можно в условиях, при которых эта самая проблема проявляется - т.е. когда нужно сразу задействовать большое количество людей. В противном случае, микросервисы, наоборот, будут не улучшать, а ухудшать t2t, так как будут затруднять изменение контуров, которое, с высокой долей вероятности, появится из-за Knowledge Crunching.
Но даже когда t2t реализован, он должен быть еще и оправдан, т.е. бизнес должен извлечь из него выгоды больше, чем затраты на оверхед от microservices first.
Иными словами, когда команда маленькая, а ущерб упущенной выгоды из-за более позднего выхода на рынок незначительный, тогда экономически более целесообразен monolith first. Я пару месяцев назад делал серию постов на эту тему, - этот пост заключительный, если интересно.
Но даже когда t2t реализован, он должен быть еще и оправдан, т.е. бизнес должен извлечь из него выгоды больше, чем затраты на оверхед от microservices first.
Иными словами, когда команда маленькая, а ущерб упущенной выгоды из-за более позднего выхода на рынок незначительный, тогда экономически более целесообразен monolith first. Я пару месяцев назад делал серию постов на эту тему, - этот пост заключительный, если интересно.
АЛ
Говорят это размытие ответственности :)
"Любая домохозяйка может управлять государством"?
PT
Time2market не есть цель. Микросервисы дают такую возможность за счет решения проблемы Брукса, но эту возможность еще нужно реализовать и оправдать. А реализовать ее можно в условиях, при которых эта самая проблема проявляется - т.е. когда нужно сразу задействовать большое количество людей. В противном случае, микросервисы, наоборот, будут не улучшать, а ухудшать t2t, так как будут затруднять изменение контуров, которое, с высокой долей вероятности, появится из-за Knowledge Crunching.
Но даже когда t2t реализован, он должен быть еще и оправдан, т.е. бизнес должен извлечь из него выгоды больше, чем затраты на оверхед от microservices first.
Иными словами, когда команда маленькая, а ущерб упущенной выгоды из-за более позднего выхода на рынок незначительный, тогда экономически более целесообразен monolith first. Я пару месяцев назад делал серию постов на эту тему, - этот пост заключительный, если интересно.
Но даже когда t2t реализован, он должен быть еще и оправдан, т.е. бизнес должен извлечь из него выгоды больше, чем затраты на оверхед от microservices first.
Иными словами, когда команда маленькая, а ущерб упущенной выгоды из-за более позднего выхода на рынок незначительный, тогда экономически более целесообразен monolith first. Я пару месяцев назад делал серию постов на эту тему, - этот пост заключительный, если интересно.
Вопрос не в аргументации, понимание важности есть. Вопрос именно в количественной оценке эффекта выполнения задач.
AM
Цель продать движуху по архитектуре?
PT
Alexey Mergasov
Цель продать движуху по архитектуре?
В точку.
I
Вопрос не в аргументации, понимание важности есть. Вопрос именно в количественной оценке эффекта выполнения задач.
Ну, в случае с t2t можно вывести конкретный экономический ущерб от неверно выбранной модели. В остальных случаях, нужно опираться на требования, которые должны трассироваться на бизнес-цели. Бизнес-цели тоже выражаются экономически, на языке, понятном бизнесу. Соответственно, бизнес сможет оценить финансово ущерб от недостижения требования.
I
Мы писали сервис на платформе версии X, у которой уже не выходят security issues patch'и, по хорошему надо обновиться на версию Y.
Как это обосновать?
Вот тут я легко смогу вычислить в деньгах необходимые работы.
А вот как уменьшение риска вычислить - я не знаю.
Статистикой штрафов за утечку персональных данных.
GK
Time2market не есть цель. Микросервисы дают такую возможность за счет решения проблемы Брукса, но эту возможность еще нужно реализовать и оправдать. А реализовать ее можно в условиях, при которых эта самая проблема проявляется - т.е. когда нужно сразу задействовать большое количество людей. В противном случае, микросервисы, наоборот, будут не улучшать, а ухудшать t2t, так как будут затруднять изменение контуров, которое, с высокой долей вероятности, появится из-за Knowledge Crunching.
Но даже когда t2t реализован, он должен быть еще и оправдан, т.е. бизнес должен извлечь из него выгоды больше, чем затраты на оверхед от microservices first.
Иными словами, когда команда маленькая, а ущерб упущенной выгоды из-за более позднего выхода на рынок незначительный, тогда экономически более целесообразен monolith first. Я пару месяцев назад делал серию постов на эту тему, - этот пост заключительный, если интересно.
Но даже когда t2t реализован, он должен быть еще и оправдан, т.е. бизнес должен извлечь из него выгоды больше, чем затраты на оверхед от microservices first.
Иными словами, когда команда маленькая, а ущерб упущенной выгоды из-за более позднего выхода на рынок незначительный, тогда экономически более целесообразен monolith first. Я пару месяцев назад делал серию постов на эту тему, - этот пост заключительный, если интересно.
Иван, лично я убеждён, что может быть только MonolithFirst, а если быть точнее - модульное решение. Разумеется, оно должно проектироваться так, чтобы можно было выносить модули по необходимости, то есть придавать им автономность.
Основная причина - даже если команды зрелые, "угадать" с границами модулей практически не возможно сразу. То есть придётся их перемещать, делать редизайн и рефакторинг, а это намного удобнее внутри одной единицы разработки и развёртывания.
И вообще, убеждён, придавать автономность модулям нужно только если для этого есть реальная необходимость.
Нам в каком-то смысле повезло, потому что мы так делали всегда и ещё до того как появились понятия MonolithFirst, Microservices и так далее.
Основная причина - даже если команды зрелые, "угадать" с границами модулей практически не возможно сразу. То есть придётся их перемещать, делать редизайн и рефакторинг, а это намного удобнее внутри одной единицы разработки и развёртывания.
И вообще, убеждён, придавать автономность модулям нужно только если для этого есть реальная необходимость.
Нам в каком-то смысле повезло, потому что мы так делали всегда и ещё до того как появились понятия MonolithFirst, Microservices и так далее.
GK
Коллеги, мы с парнёрами замутили стартап, это правда громко сказано.
Спич такой:
Спич такой: