Size: a a a

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

2020 March 17

YB

Yury Batsyuro in Архитектура ИТ-решений
Andrey
Дело в том что четких критериев для проведения границы ведь нет. Почти как и между тактикой и стратегией кстати))
Да. Просто ощущаю согласие в плане inproc и crossproc.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Хотя опять же, когда unit of delivery является не процесс, а контейнер, в котором может играться несколько процессов, грань что есть inproc, а что есть crossproc хочется стереть, и нарисовать её где-то между разными контейнерами.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Или разными вендорами.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Yury Batsyuro
ГОСТ vs здравый смысл, первый раз, чтоли?
Я бы переформкулировал:
соблюдаем ритуалы или решаем задачу?

По ГОСТ можно составить документы очень разного объема и содержимого, этож очевидно
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Yury Batsyuro
Уместно ли стартовать архитектурный процесс при написании Notepad++? А при разработке Azure?
Кому уместно? Имхо, это всегда уместно
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Roman Tsirulnikov
Я бы переформкулировал:
соблюдаем ритуалы или решаем задачу?

По ГОСТ можно составить документы очень разного объема и содержимого, этож очевидно
++
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Daria Kaftan
Кому уместно? Имхо, это всегда уместно
Ну, может, он и в случае с Notepad++ какой-то есть, но смысла выделять его как процесс вообще нет. Оверхэд дикий.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Yury Batsyuro
Уместно ли стартовать архитектурный процесс при написании Notepad++? А при разработке Azure?
Я сейчас сталкиваюсь с задачей передачи знаний при масштабировании компании на новые виды проектов,
включение новых людей. Все эти ваши квадратики-стрелочки должны стать понятными для новых людей.
Архитектура тесно сплетена с knowledge management, с фиксацией и передачей знаний.
Даже Notepad++ закончит плохо, если знания не документированы и в разработчку вовлекается множество людей.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Roman Tsirulnikov
Я бы переформкулировал:
соблюдаем ритуалы или решаем задачу?

По ГОСТ можно составить документы очень разного объема и содержимого, этож очевидно
Есть ритуалы, покладательство на которые в известных масштабах может всерьёз разгневать богов. Так что вопрос в том примерно и есть, когда достаточно один раз на салфетке нарисовать два квадратика и сцепить их через REST API, а когда надо всерьёз запускать архитектуру как именно процесс, а не просто явление.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Roman Tsirulnikov
Я сейчас сталкиваюсь с задачей передачи знаний при масштабировании компании на новые виды проектов,
включение новых людей. Все эти ваши квадратики-стрелочки должны стать понятными для новых людей.
Архитектура тесно сплетена с knowledge management, с фиксацией и передачей знаний.
Даже Notepad++ закончит плохо, если знания не документированы и в разработчку вовлекается множество людей.
Ну вот вопрос только в том, реально ли в разработку Notepad++ всё это вовлекается...
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Yury Batsyuro
Есть ритуалы, покладательство на которые в известных масштабах может всерьёз разгневать богов. Так что вопрос в том примерно и есть, когда достаточно один раз на салфетке нарисовать два квадратика и сцепить их через REST API, а когда надо всерьёз запускать архитектуру как именно процесс, а не просто явление.
Крайне опасна подмена целей процессом
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Alexey Pryanishnikov
тоже как математик не могу не ввернуть, что матмодель архитектуры (а чат про архитектуру) это примерно такая же невероятно нужная и практически применимая вещь, как собаке пятая нога )
Как только вы вводите рационализацию (рациональные обоснования) принимаемых решений вы обязаны строить утверждения. При этом любое утверждение должно быть проверяемо. А проверяемость вы никак кроме как при помощи логики высказываний проверить не сможете.

И да, если у вас допускается нерациональное обоснование решения - можно без мат. моделей.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Могу сказать как контрибютор в экосистему react и rxjs, что все эти квадратики даже при прямо скажет толпе сообщества не особо то и нужны.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Roman Tsirulnikov
Крайне опасна подмена целей процессом
Есть люди, которые держат цели в голове и даже документируют их, но на места передают процессы. На самом деле, объяснять мотивацию — это один из ритуалов, покладательство на который может привести к тому, что на процессы забьют.
источник

YB

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

DK

Daria Kaftan in Архитектура ИТ-решений
Процессы могут быть короткими и простыми. Скажем так, они всегда есть, но иногда они не осознаются и не управляются
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Daria Kaftan
Процессы могут быть короткими и простыми. Скажем так, они всегда есть, но иногда они не осознаются и не управляются
Не-е-е, процесс - это явно означенный и повторяемый набор действий. И суть того же TOGAF не в том, чтобы применять практики по обстоятельствам, а чтобы выстроить процесс, количество исключений из которого было существенно меньше количества случаев, когда процесс таки удалось соблюсти.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Этот процесс стоит денег, поэтому надо взвешивать бенефиты.
источник
2020 March 18

ОИ

Олег Игонин in Архитектура ИТ-решений
Andrey
Я считал, что результатом работы архитектора является проект архитектуры 🤔
Результатом работы архитектора является реализованная в реальном мире система, которая приносит business value. Подобный вашему подход говорит о неправильном выборе целевой системы. "Нам нужно доводить мысль до изменения реальности, а не до описания изменения реальности! Описать - не сделать!" (с) Левенчук, Системное мышление,2018, 187 стр,
источник

ОИ

Олег Игонин in Архитектура ИТ-решений
Олег Игонин
На моём опыте зачастую менеджеры не умеют определять цели. Окончательные цели, которые выражаются в определённом денежном эквиваленте заработанных или сэкономленных средств для конкретного пула заказчиков, подменяются иными целями. Какие они могут быть:
1. Политические цели (продвижение по службе, повышение заработной платы, прочее);
2. Цели артефактов проекта (то, о чём говорил Роман);
3. Цели самосовершенствования (в этом случае цели проекта лишь сторонний инструмент достижения своих целей);
4. Цель минимизации работы (сидеть из дома и втыкать в телек с чипсонами - наивысший приоритет).
5. Цели компании-исполнителя.
6. Прочие.

Это самый первый уровень факапа у менеджеров. После этого идут подуровни:
- Недостаток квалификации
- Недостаточность входящих данных
- Управленческие блоки
- Недостаток ресурсов
- Прочие
"2. Цели артефактов проекта (то, о чём говорил Роман);" - подобно этой фразе, вы как менеджер, который считает, что в количестве и качестве стендапов, ретроспектив, прочих артефактов своей работы, вычисляется успешность его работы.

Из собственного опыта могу сказать, что вы можете быть трижды классным аджайл-коучем или архитектором, который пишет классные модели, но если вы не заставили внешний мир измениться (защитить и реализовать архитектуру, выбить ресурсы на рефакторинг, проследить за командами, чтобы они не писали абы-что), то грош вам цена.
источник