Size: a a a

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

2021 February 04

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Олег Игонин
Я не предлагаю их считать. Только в некоторых случаях, когда это НЕОБХОДИМО, чтобы ДОКАЗАТЬ их влияние в СЛУЧАЕ если это ВАЖНО. Чтобы поменять решение или отказаться от него.
А, ну тогда о чём мы спорим)
источник

ОИ

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

Но в целом, большое спасибо за ответы! 🙏
Это было полезно. Теперь надо понять, как это можно применять в практике.
Я хз, но я уже писал.
источник

GK

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Есть ощущение, что нужно прояснить. Риски нужно считать и оценивать, чтобы их потом митигировать. Самый простой способ митигировать риски - заложить запасы. Можно просто сразу без углубления в формулы качественно оценивать риски и закладывать запасы.
источник

GK

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

ОИ

Олег Игонин... in Архитектура ИТ-решений
Кажется, ты говоришь про риски проекта - времени и ресурсов. Но разве это зона ответственности архитектора?
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Зона арха - это то, что система, её наполнение, будет работать как надо. И будет расти с меньшими затратами?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Есть правда риски, которые митигировать нельзя или очень трудно, это критические риски, которые могут привести к фатальному исходу. Вот о них нужно кричать. Наример, падение после обновления критически важной системы и наступление санкций со стороны регулятора
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
А вы не РП?
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Gennadiy Kruglov
Есть правда риски, которые митигировать нельзя или очень трудно, это критические риски, которые могут привести к фатальному исходу. Вот о них нужно кричать. Наример, падение после обновления критически важной системы и наступление санкций со стороны регулятора
Вот это больше похоже на риски, за которые отвечает архитектор.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Олег Игонин
Кажется, ты говоришь про риски проекта - времени и ресурсов. Но разве это зона ответственности архитектора?
Не обязательно. Запас по ресурсам и нефункциональным требованиям, например. То есть можно заложить больше железа, добиться более удобного SLA

И конечно архитектура влияет на бюджеты и время. В том числе выбор стека.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Gennadiy Kruglov
Не обязательно. Запас по ресурсам и нефункциональным требованиям, например. То есть можно заложить больше железа, добиться более удобного SLA

И конечно архитектура влияет на бюджеты и время. В том числе выбор стека.
Он даёт экспертную оценку времени и денег на свою часть работы. Но закладывает риски (запасы) всё равно ПМ?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
То есть при одном и том же решении, но разных аппаратных ресурсах и SLA, может наступить падение и санкции, а может и нет.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Олег Игонин
Он даёт экспертную оценку времени и денег на свою часть работы. Но закладывает риски (запасы) всё равно ПМ?
Все дают оценки и закладывают запасы, а PM сверху закладывает свои запасы. Либо PM требует считать без запасов, а потом уже сам добавляет иксы.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Чем более детально будет спроектировано и запилотировано решение, тем меньше нужен запас (ниже неопределённость) по аппаратным ресурсам. Если речь об автомасштабировании в облаке, то по деньгам.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
И тут на самом деле вопрос тоже в ресурсах. Времени и деньгах на проектирование и на пилот.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Я видел одно решение, где вообще не прорабатывали безопасность, но закладывались на суды и юристов.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Gennadiy Kruglov
Я видел одно решение, где вообще не прорабатывали безопасность, но закладывались на суды и юристов.
Огонь
источник

GK

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

ОИ

Олег Игонин... in Архитектура ИТ-решений
Gennadiy Kruglov
Видите, вопрос рисков многогранный
Ну, мне печально почти ничего не знать об этом аспекте. Именно отсюда и возник вопрос.
источник