Size: a a a

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

2020 June 17

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Вообще, тут некоторые высказываются, как будто в каждой ИТ компании есть разработка. Это ж далеко не всегда так и я очень глубоко согласен, что 90+% всех технических задач это таки сопровождение (чёрных недокументированных ящиков без доступа к коду)
источник

F

Fagor in Архитектура ИТ-решений
Alexey Pryanishnikov
Вообще, тут некоторые высказываются, как будто в каждой ИТ компании есть разработка. Это ж далеко не всегда так и я очень глубоко согласен, что 90+% всех технических задач это таки сопровождение (чёрных недокументированных ящиков без доступа к коду)
Работа с проектами, потому без кода никуда. Никаких blackBox, они только как интеграционный контур, т.е. в апи вечно чего то не хватает. Каждый со своей колокольни видит. Я так же.
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Dmitriy Stolyarov
Да, но и инициатива снизу тоже важна. В итоге локализуется сопротивление на уровне начальников отделов, которых заменяют при выявлении таких фактов саботажа. Сверху - ит-директор, начальники управлений, снизу - сотрудники.
Звучит так, что на всех уровнях иерархии набралось достаточное количество компетентных людей. Что и позволило провести преобразования. Если это стечение обстоятельств, то рад за такое везение. Если это кем-то организовано с 0,со старта "один в поле воин", то этот кто-то крут.
источник

F

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

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Maxim Smirnov
Всем привет!

Вчера на zoom-е группы были озвучены следующией темы:
1. Alexander Samarin : ISO/IEC/IEEE 42010:2011 viewpoints, views,  model-kinds and models for Enterprise Architecture (Smart Cities as an example)
2. Aleksey Senkov : Как организовать обмен данными и знаниями (обученными интеллектуальными моделями / системами)  между заинтересованными сторонами? Какие особенности и варианты решения?
3. Gennady Kruglov : - трансформация роли архитектора в технологического партнёра бизнеса (сейлов, топов, лпр)
4. Gennady Kruglov : - взаимосвязь арх паттернов (микросервисная архитектура, событийно ориентированная архитектура, озеро данных, лямбда архитектура) при построении транзакционно-аналических решений
5. Gennady Kruglov : - референсная архитектура (композитный арх стиль?) построения транзакционно-аналитических решений в рамках продуктово-платформенного подхода
6. Alexander Luchkov : Пет-проекты для студентов и магистрантов. Втаскивание студентов в реальную деятельность.
7. Alexander Luchkov : Исследования в области "хороших" практик проектирования вывод. Методики организации проектирования.
8. Alexander Luchkov : Документирование эскизных и технических проектов при поддержке средств моделирования.
9. Дарья Кафтан : Культура документирования проектных решений и наполнение базы знаний. Методики определения степени детализации документации, которая принесет максимальный профит для эффективного внесения изменений. Как убедить команду, что это действительно нужно, и привить культуру документирования в команде и компании.

Спасибо всем за участие. Надеюсь, ничего не забыл. Задавайте уточняющие вопросы инициаторам. Через пару дней устроим голосование по приоритетности тем
Записи нет случайно?
Вообще, будет полезно определить какое-то регулярное время для таких митапов, чтобы было привычно для аудитории и можно было бы встроить в расписание
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Fagor
Не понимаю как сопровождать BlackBox. Просто вне рамок, я сбегу от такого.
По чек-листам. Что-то сложнее перезагрузки пк или сброса кэша - перенаправлять на команду развития продукта. :D
источник

DS

Dmitriy Stolyarov in Архитектура ИТ-решений
Vsevolod Shulaev
Звучит так, что на всех уровнях иерархии набралось достаточное количество компетентных людей. Что и позволило провести преобразования. Если это стечение обстоятельств, то рад за такое везение. Если это кем-то организовано с 0,со старта "один в поле воин", то этот кто-то крут.
Автор идеи - один, остальное - удачное стечение обстоятельств.
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Vsevolod Shulaev
По чек-листам. Что-то сложнее перезагрузки пк или сброса кэша - перенаправлять на команду развития продукта. :D
При отсутствии контроля качества работы - может жить годами. :D
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Vsevolod Shulaev
Звучит так, что на всех уровнях иерархии набралось достаточное количество компетентных людей. Что и позволило провести преобразования. Если это стечение обстоятельств, то рад за такое везение. Если это кем-то организовано с 0,со старта "один в поле воин", то этот кто-то крут.
"набралось" - звучит, как будто "мы не нажимали, оно само". Но надо нажимать, иначе само никуда не наберется.
источник

F

Fagor in Архитектура ИТ-решений
Vsevolod Shulaev
По чек-листам. Что-то сложнее перезагрузки пк или сброса кэша - перенаправлять на команду развития продукта. :D
А на листы есть отвественные, что их обновляют, в общем управляют изменениями?
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Fagor
А на листы есть отвественные, что их обновляют, в общем управляют изменениями?
Конкретно в печальном кейсе о котором говорю? :) Команда развития продукта. Если вдруг захочет чтобы что-то делалось без её участия.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Fagor
Не понимаю как сопровождать BlackBox. Просто вне рамок, я сбегу от такого.
Ну как, пишешь вендору требования, платишь кучу денег, получаешь вместо реализации требований хреномуть про "у нас есть видение продукта, поэтому мы сделали не то и не так, но денег не вернём", посылаешь вендора к чёрту... "Намылить, смыть, повторить" как в известном анекдоте
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Gennadiy Kruglov
Мы на самом деле говорим о TTM (проход) и TCO. Вместо затрат приходит на ум утилизация.

Отсутствие дизайна, документирования, наличие тех. долга и пр., приводит в конечном итоге к снижению TTM и росту TCO.

Фокусируясь на утилизации упускается из виду TTM и TCO. То есть вроде бы все заняты (затраханы до предела), а фичи выводятся всё медленнее и стоят всё дороже.

А самое главное - менеджеры этого не видят и сами не понимают, что делать. Отчасти потому что многие из них "эффективные менеджеры общего назначения" и не понимают в производстве ПО.
Вертикальная организация команд и микросервисы помогают:
1. развитие и поддержку можно сосредоточить в одном орг.юните. Если дальнейние изменения начинат тормозить, гораздо проще ткнуть пальцем в конкретный проект “потому что вот тут было насрато”.
2. “плохие” проекты можно огородить от остальной системы и дать им тихо сгореть в своем маленьком аду
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Vsevolod Shulaev
По чек-листам. Что-то сложнее перезагрузки пк или сброса кэша - перенаправлять на команду развития продукта. :D
У меня было в опыте следующее: сопровод, где черным ящиком была бизнес-логика, и поддержке были доступны фронт (естественно, без кода) и база (схемы и содержимое). Соответственно, они работали с ними - и получались консультации и коррекция (первое - по интерфейсу, отбивалось первой линией, просто рассказать, где пользователь неправ), и коррекция (отбивалось второй линией, вносились скриптами изменения). Все, что касалось бизнес-логики, отправлялось на команду развития.
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Daria Kaftan
"набралось" - звучит, как будто "мы не нажимали, оно само". Но надо нажимать, иначе само никуда не наберется.
В моём исходном сообщении вилка про стечение обстоятельств / сознательную организацию. Вы или что-то другое комментируете, или я вас неправильно понимаю.
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Daria Kaftan
У меня было в опыте следующее: сопровод, где черным ящиком была бизнес-логика, и поддержке были доступны фронт (естественно, без кода) и база (схемы и содержимое). Соответственно, они работали с ними - и получались консультации и коррекция (первое - по интерфейсу, отбивалось первой линией, просто рассказать, где пользователь неправ), и коррекция (отбивалось второй линией, вносились скриптами изменения). Все, что касалось бизнес-логики, отправлялось на команду развития.
Под коррекцией внесение изменений в бизнес-данные скриптами или что-то другое?
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Roman Tsirulnikov
Вертикальная организация команд и микросервисы помогают:
1. развитие и поддержку можно сосредоточить в одном орг.юните. Если дальнейние изменения начинат тормозить, гораздо проще ткнуть пальцем в конкретный проект “потому что вот тут было насрато”.
2. “плохие” проекты можно огородить от остальной системы и дать им тихо сгореть в своем маленьком аду
А как же влияние орг юнитов друг на друга и взаимодействие микросервисов? Насрато может быть в дизайне верхнего уровня, и изменения вносятся тоже начиная с него, до микросервисов еще опуститься надо.
источник

DK

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

RT

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

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Риски не ниже, они просто иначе перераспределены
источник