Size: a a a

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

2020 February 27

SV

Sergey V in Архитектура ИТ-решений
Daria Kaftan
а зачем синхронизировать команды на разных продуктах?
Проблема когда с точки зрения бизнеса это один продукт, но пилят его 1к человек. И планы / KPI общие
источник

DK

Daria Kaftan in Архитектура ИТ-решений
а, понятно.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
up-front design:
- это артефакт СА или архитектора
- задает верхнеуровневую декомпозицию задачи
- определяет правила взаимодейсвия сервисов

а дальше - учитесь общаться и договариваться о деталях
источник

SV

Sergey V in Архитектура ИТ-решений
Roman Tsirulnikov
up-front design:
- это артефакт СА или архитектора
- задает верхнеуровневую декомпозицию задачи
- определяет правила взаимодейсвия сервисов

а дальше - учитесь общаться и договариваться о деталях
Ну а если одна команда убежит вперёд по срокам на месяц, что делать будете?
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
так же up-front design нужен для оценки планов направления
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Sergey V
Ну а если одна команда убежит вперёд по срокам на месяц, что делать будете?
пока не сталкивались. Расхождение на недели было, тогда опереджающая команда делала другую задачу
источник

d

dreamore in Архитектура ИТ-решений
мне понравилась из опыта история с двойной структурой.
первая - скрам команды. здесь есть только команда и роли в ней.
вторая - типичная иерархия с "отдел фронтэнд разработки", здесь есть и лиды, и лидеры компетенций

одновременно конкретный разработчик, например, является частью продуктовой команды и группы фронтэнд разработки. в рамках обоих иерархий есть система управления, общие ивенты.
источник

SB

Sergei Beilin in Архитектура ИТ-решений
dreamore
мне понравилась из опыта история с двойной структурой.
первая - скрам команды. здесь есть только команда и роли в ней.
вторая - типичная иерархия с "отдел фронтэнд разработки", здесь есть и лиды, и лидеры компетенций

одновременно конкретный разработчик, например, является частью продуктовой команды и группы фронтэнд разработки. в рамках обоих иерархий есть система управления, общие ивенты.
На предыдущей работе у нас была такая двумерная структура. Опыт исключительно положительный.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
У нас аналогично. Правда “вторая” иерархия ориентирована на технологический стэк. Знания о технике распространяются уже хорошо. А вот предметные области технической иерархии совершенно неинтересны.
Наверное нужна какая-то третья иерархия, держатели экспертизы о прикладном домене.
источник

SB

Sergei Beilin in Архитектура ИТ-решений
У нас вторая иерархия распространялась на всех, не только на программистов. Другими словами, это деление было на всю компанию, включая C-Level
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Sergei Beilin
У нас вторая иерархия распространялась на всех, не только на программистов. Другими словами, это деление было на всю компанию, включая C-Level
Кто у вас был держателем знания о прикладном домене?
источник

SB

Sergei Beilin in Архитектура ИТ-решений
Тот, кто в соответствующей области наиболее компетентен :)
источник

MR

Mikhail Romashov in Архитектура ИТ-решений
Коллеги, подскажите чат админов ms, есть вопрос по ad
источник
2020 February 28

OK

Oleg K in Архитектура ИТ-решений
Набег из Анализа Систем
источник

СС

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

А

Александр in Архитектура ИТ-решений
всем привет! думал, куда бы вопрос задать, потом вспомнил, что есть же такой чатик специальный про архитектуру... вопрос сорри нубский, но буду признателен за ваше мнение.
Есть 3 сервиса. Один получает из api набор данных, к примеру новостей. Второй эти данные обогащает. Третий стоит на раздаче большому количеству пользователей. Бизнес-объект не очень простой, т.е. внутри него могут быть коллекции, например. Но сериализуемый. Поток всегда в одну сторону. Вариант 1: просто гонять между сервисами эти объекты по RabbitMQ. Вариант 2: гонять по RabbitMQ только ID этих объектов, а сами объекты хранить в какой-нибудь реактивной монге.
Какой выбрать? От чего зависит такой выбор?
источник

СС

Сергей Старцев in Архитектура ИТ-решений
Александр
всем привет! думал, куда бы вопрос задать, потом вспомнил, что есть же такой чатик специальный про архитектуру... вопрос сорри нубский, но буду признателен за ваше мнение.
Есть 3 сервиса. Один получает из api набор данных, к примеру новостей. Второй эти данные обогащает. Третий стоит на раздаче большому количеству пользователей. Бизнес-объект не очень простой, т.е. внутри него могут быть коллекции, например. Но сериализуемый. Поток всегда в одну сторону. Вариант 1: просто гонять между сервисами эти объекты по RabbitMQ. Вариант 2: гонять по RabbitMQ только ID этих объектов, а сами объекты хранить в какой-нибудь реактивной монге.
Какой выбрать? От чего зависит такой выбор?
от объема трафика, который складывается из:
1) среднего размера одного набора данных
2) среднего кол-ва наборов, передаваемых в единицу времени
источник

СС

Сергей Старцев in Архитектура ИТ-решений
есть еще вариант в какой-нить протобуф заворачивать для уменьшения объема
источник

СС

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

А

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