Size: a a a

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

2019 December 08

AP

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

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
вот только... Кажется. в этом описании ничего не говорится про техническую сторону. Не хватает ещё упоминания аналогичного канала коммуникации в сторону ИТ
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Не совсем понятно про architecture initiatives и reusable assets. Какие-то вещи в себе?
На мой взгляд современные требования к SolA должны базироваться на Evolutionary architecture.
Да и казенный язык кадровиков уже поднадоел. Пора бы понять что искать нужно не функцию, а людей.
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
А давайте плясать от базы. Я, f.e. способен управлять 8-10 сотрудниками (прямое управление) на полугодичном интервале. Кто какую норму  себе ставит/задаёт?
источник

d

dreamore in Архитектура ИТ-решений
Phil Delgyado
Ну, тонкости есть. В java есть решения по embedded cloud (всякий нетфликс), а под go, вроде бы, нет. Но под го есть асинхронные драйвера к pg, а под джаву пока не очень production ready
rjdbc релизнулся
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Andrei Soloschak
Не совсем понятно про architecture initiatives и reusable assets. Какие-то вещи в себе?
На мой взгляд современные требования к SolA должны базироваться на Evolutionary architecture.
Да и казенный язык кадровиков уже поднадоел. Пора бы понять что искать нужно не функцию, а людей.
а почему именно на ней?
источник

SK

Sergey Kompaniets in Архитектура ИТ-решений
Арх. принцип в моём понимании - это отражение неких высокоуровневых целей  в конкретных правилах, нарушение которых приводит к конкретным рискам. Каталог арх.принципов - шпаргалка для архитекторов. Success stories когда и чем удалось отбиться от дичи.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Alexey Pryanishnikov
а почему именно на ней?
Отвечу по-еврейски, а в чем вообще задача архитектуры? Создание reusable artifacts для повышения эффективности? Эффективности чего, бизнеса?
источник

AP

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

AP

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

IN

Igor Nikolskiy in Архитектура ИТ-решений
Alexey Pryanishnikov
имхо, любая позиция "делать надо согласно вот этому принципу" - однобокая.
Делать надо так, как наименее больно в данных условиях, включая прошлое и будущее.
Я поддержу Сергея. Есть у подчинённого определённый уровень экспертизы, если он ему не удовлетворяет, то его надо выводить из процесса, нет?
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Andrei Soloschak
Отвечу по-еврейски, а в чем вообще задача архитектуры? Создание reusable artifacts для повышения эффективности? Эффективности чего, бизнеса?
А нет, Андрей. Не в этом дело. Дело менеджеров следить за эффективностью процесса, а дело архитектора следить за метриками 'железа'
источник

V

Valeriy in Архитектура ИТ-решений
Andrei Soloschak
Отвечу по-еврейски, а в чем вообще задача архитектуры? Создание reusable artifacts для повышения эффективности? Эффективности чего, бизнеса?
Таки архитектура это базар за деньги
источник

SK

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

AB

Aleksey Bondarev in Архитектура ИТ-решений
Igor Nikolskiy
Я поддержу Сергея. Есть у подчинённого определённый уровень экспертизы, если он ему не удовлетворяет, то его надо выводить из процесса, нет?
Наличие экспертизы далеко не всегда гарантирует что будет результат.
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Valeriy
Таки архитектура это базар за деньги
Нет. Архитектура точно не базар.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Igor Nikolskiy
А нет, Андрей. Не в этом дело. Дело менеджеров следить за эффективностью процесса, а дело архитектора следить за метриками 'железа'
Это называется локальная оптимизация. У всех все хорошо, а в целом дело дрянь.
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Aleksey Bondarev
Наличие экспертизы далеко не всегда гарантирует что будет результат.
Сейчас картинку кину из "Good to Greate", все читали, а не все используют.
источник

SK

Sergey Kompaniets in Архитектура ИТ-решений
Andrei Soloschak
Не совсем понятно про architecture initiatives и reusable assets. Какие-то вещи в себе?
На мой взгляд современные требования к SolA должны базироваться на Evolutionary architecture.
Да и казенный язык кадровиков уже поднадоел. Пора бы понять что искать нужно не функцию, а людей.
Как я понимаю эти термины - они про бизнес-партнёрство, то есть когда IT не просто закрывает сиюминутную потребность, а проектирует что-то, что в дальнейшем заинейблит что-то для самого бизнеса, о чём он может даже не мечатет.
Про кадровиков хорошее замечание, спасибо. Разных людей и хантить нужно по-разному!
источник

V

Valeriy in Архитектура ИТ-решений
Igor Nikolskiy
Сейчас картинку кину из "Good to Greate", все читали, а не все используют.
Имхо это бессмысленно просто пытаться использовать прочитанное. Прочитанное не значит осмысленное и усвоенное
источник