Size: a a a

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

2020 April 11

ОИ

Олег Игонин in Архитектура ИТ-решений
Я понял, это Катамаранов из Лапенко. Сейчас возьмёт бутылку и уйдёт в закат. =)
источник
2020 April 12

DK

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

K

Kostya in Архитектура ИТ-решений
Олег Игонин
Но тут может справиться и разработчик. Но что делать, если команд 10? Или 15... Тогда у этого разработчика не будет времени писать код. ему придётся разбираться в деталях архитектуры и нюансах технологий. И вот он уже в роли архитектора.
Да иногда даже не команд
Иногда способов сделать больше двух
А система большая
И стыковать ее планируется с чуть больше полахулиарда всяких внешних клиентов и партнеров ... ну короче, тока допусти ошибку на уровне фундамента
источник

K

Kostya in Архитектура ИТ-решений
Fagor
Я предлагаю себе не врать, вот и все. Себе не врать, ну и наружу не врать, тут уже норм, когда себе не врешь, и наружу не будешь, и работу лучше сделаешь.
Никому верить нельзя
Даже себе
Мне - можно (с), Мюллер
источник

K

Kostya in Архитектура ИТ-решений
Fagor
не нужно, каждому свое. себе не врите, я только это доношу, хотите качать денег с бизнеса - все нормально 99% хотят, притом делая что то, это уже хорошо, что то полезно или нет да кто его знает...
А, вам денег надо.
Тогда в бизнес идти надо было (с), Медведев
источник

K

Kostya in Архитектура ИТ-решений
Да, ИТ - это деньги.
Но крутое ИТ - это уже далеко не «сначала деньги», далеко.
источник

I

Ivan in Архитектура ИТ-решений
Олег Игонин
Я против односторонних подходов. Литература не показывает частностей. В ней нет примеров из жизни. В ней нет неправильных вариантов. Литературу придётся читать в любом случае. Просто если вы прочитали пару книжек и думаете, что теперь можете выполнять роль без полевого опыта - это странно.
На тему литературы мне нравятся слова Теплякова: "Полноценное обучение – это не теория vs. практика. Это комбинация этих вещей, при этом процент одного и другого зависит от человека и изучаемой темы."

https://sergeyteplyakov.blogspot.com/2017/02/reading-books-considered-harmful.html
источник

I

Ivan in Архитектура ИТ-решений
Олег Игонин
Ну, мой подход такой, что моя работа должна быть выгодна для бизнеса. Я должен приносить business value, которое будет адекватной моим запросам. Если ты работаешь в стол или работаешь без эффекта, то лучше сменить место или профессию.
Я добавлю:
"Архитектура отражает важные проектные решения по формированию системы, где важность определяется стоимостью изменений." - Гради Буч.
источник

ОИ

Олег Игонин in Архитектура ИТ-решений
Ivan
На тему литературы мне нравятся слова Теплякова: "Полноценное обучение – это не теория vs. практика. Это комбинация этих вещей, при этом процент одного и другого зависит от человека и изучаемой темы."

https://sergeyteplyakov.blogspot.com/2017/02/reading-books-considered-harmful.html
Я всегда говорил, что книга должна быть проверена в бою
источник

I

Ivan in Архитектура ИТ-решений
Олег Игонин
Но тут может справиться и разработчик. Но что делать, если команд 10? Или 15... Тогда у этого разработчика не будет времени писать код. ему придётся разбираться в деталях архитектуры и нюансах технологий. И вот он уже в роли архитектора.
Не совсем уловил как роль архитектора относится к тому, "писать код" или нет? Ivory tower?
источник

ОИ

Олег Игонин in Архитектура ИТ-решений
Ivan
Не совсем уловил как роль архитектора относится к тому, "писать код" или нет? Ivory tower?
Тут речь о представлении архитектора в голове у того человека. Он не понимает зачем архитектор нужен, ведь может справиться и разработчик. И он прав, до определённого уровня сложности системы разработчик может выполнять роль архитектора.
источник

I

Ivan in Архитектура ИТ-решений
Олег Игонин
Я всегда говорил, что книга должна быть проверена в бою
А пишутся они, получаются, не в бою... Сэм Ньюман, Эрик Эванс, Гради Буч, Кент Бек и др. "в бою", разумеется, никогда не были...
источник

ОИ

Олег Игонин in Архитектура ИТ-решений
Ivan
А пишутся они, получаются, не в бою... Сэм Ньюман, Эрик Эванс, Гради Буч, Кент Бек и др. "в бою", разумеется, никогда не были...
Это сарказм был.
источник

Р

Руслан in Архитектура ИТ-решений
Fagor
не нужно, каждому свое. себе не врите, я только это доношу, хотите качать денег с бизнеса - все нормально 99% хотят, притом делая что то, это уже хорошо, что то полезно или нет да кто его знает...
Странно утрированная позиция... канает за вброс. Я к сожалению не видел в своей практике ситуаций, где в компании архитекторы (любые) как выделенная каста возникают ЗАРАНЕЕ. Они скорее следствие реальной сложности существующих и внедряемых систем в компании и как следствие стоимости решения проблем связанных с этой сложностью. Так что врядли качает из бизнеса деньги каста архитекторов. Архитекторы при правильном подходе экономят деньги компании, причем это реальная практика от экономии ресурсов команд разработки на несовершенных трудозатратах на реализацию того что не нужно, нужных функций в неправильных системах, реализации без учета НФТ, до кратных экономий на лицензиях, железе на выборе правильных технологий для реализации функций. А так в геморое размером поменьше отельного архитектора может и не быть, НО функция неминуемо кемто выполняется, возможно размазано на разные единицы... Особо въедливый аналитик задает вопросы "зачем мы это делаем, зачем мы делаем это так и тп" и уровень такого "архитектора" определяется волей донести такие вопросы на необходимый уровень в ИТ и бизнесе. Особо въедливый разраб задаст вопросы почему испольуем такую технологию, здесь нужно другую потому и тд вниз по уровням...
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Олег Игонин
Я тут в очередной раз прочитал 500 сообщений из чата за прошедшую неделю и заметил, что многие люди пытаются найти путь в архитектуру из какой-то конкретной профессии. Или ищут волшебную таблетку (курсы, книги, нотации, прочее), скушав которую сразу станут архитекторами.

Кажется, что архитектор состоит не из знаний и не из шляпы-на-которой-написано-Wizzard. Куча документов с курсов и из университетов не дадут человеку понимание сути его работы.

Позиция архитектора в первую очередь требует наработки полевого опыта работы на нескольких позициях, основными из которых является разработка, бизнес и системная аналитика, администрирование и девопс. Также требуются знания из области управления и безопасности. Только после того, как все эти куски начнут собираться воедино, начинают проглядываться системные проблемы. И вот как раз эти проблемы и есть цель архитектора.

Отсюда следует, что разным компаниям нужны разные архитекторы, т.к. у всех разные проблемы.
А знания архитектора делятся как минимум на четыре  класса:
1. Умение выявить или предсказать системную проблему
2. Произвести поиск решения
3.  "Продать"/Согласовать решение
4. Внедрить решение и, порой, проконтролировать исполнение

Основные направления работы:
1. Экспертиза
2. Поиск решений и предсказание
3. Контроль реализации
4. Коммуникация между бизнесом и разработкой, а также внутри разработки

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

Архитектор должен думать о том, как можно принести деньги в компанию через решение системных проблем, увеличение уровня качества, улучшение компетенции работников и повышение уровня коммуникации. Всё лишнее надо отрезать, тем самым облегчая самолёт.

Сейчас я я вижу два понимания своей работы у архитекторов - поверхностный и глубокий. Первый основывается на своём субъективном опыте, курсах, книгах по архитектуре. Второй зиждется на общих пониманиях работы инженера и проблемах бизнеса.

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

NK

Nikita Kiselev in Архитектура ИТ-решений
В иделае побыть и разработчиком и тестером и саппортом
источник

NK

Nikita Kiselev in Архитектура ИТ-решений
немного аналитиком и чуть чуть девопсом )
источник

NK

Nikita Kiselev in Архитектура ИТ-решений
пройтись по всем стадиям SDLC
источник

EN

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

EN

Evgeniy Nikonorov in Архитектура ИТ-решений
с таким флешроялем опыта системность из каждой поры будет сочиться
источник