Size: a a a

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

2021 January 09

AL

Alexander Luchkov in Архитектура ИТ-решений
Vitaly U
Это перевод
Ну так источник то можно?
источник

VU

Vitaly U in Архитектура ИТ-решений
Alexander Luchkov
Ну так источник то можно?
Саш я не помню, к сожалению
источник

VU

Vitaly U in Архитектура ИТ-решений
А мотать чат тяжкий труд
источник

VU

Vitaly U in Архитектура ИТ-решений
Ну да, там вопросы есть, но в целом то отражает суть
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Vitaly U
Ну да, там вопросы есть, но в целом то отражает суть
Ну может быть какую-то суть и отражает. В общем буду признателен за исходник.
источник

VU

Vitaly U in Архитектура ИТ-решений
Alexander Luchkov
Ну может быть какую-то суть и отражает. В общем буду признателен за исходник.
Просто это уже все обсуждали, даже перевод сделали
источник

VU

Vitaly U in Архитектура ИТ-решений
Я надеюсь кто-то вспомнит и пришлёт
источник

VI

Vladislav Isaykin in Архитектура ИТ-решений
с таким подходом сам архитектор становится узким местом в бизнесе, потому что на нем судя по картинке все замыкается)
источник

GK

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

Неправильные решения, часто конъюнктурные, приводят к потере лет разработки, тысяч человеко-часов и провалу стратегических программ.

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

VI

Vladislav Isaykin in Архитектура ИТ-решений
Gennadiy Kruglov
Архитектурная функция становится такой же важной как врачебная или юридическая, потому что от архитектурных решений и ошибок зависит многое.

Неправильные решения, часто конъюнктурные, приводят к потере лет разработки, тысяч человеко-часов и провалу стратегических программ.

Когда топы жонглирует технологиями, ни к чему хорошему это не приводит.
это если мы считаем что архитектор принимает верное решение, а если нет)

есть технология а и б и архитектор может выбрать (как правило) ту которая будет е у ближе, с которой он возможно уже имел опыт, а не ту которая лучшерешает задачу.
Да и за частую в IT много "грязных проблем" которые пока не решишь (внедришь какое то решение) не узнаешь хороша ли та или иная иехнология, на сколько хорошо она решает проблему.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Vladislav Isaykin
это если мы считаем что архитектор принимает верное решение, а если нет)

есть технология а и б и архитектор может выбрать (как правило) ту которая будет е у ближе, с которой он возможно уже имел опыт, а не ту которая лучшерешает задачу.
Да и за частую в IT много "грязных проблем" которые пока не решишь (внедришь какое то решение) не узнаешь хороша ли та или иная иехнология, на сколько хорошо она решает проблему.
Не так, сначала надо узнать технологию, а потом внедрять

Нужно подготовить почву для внедрения
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
На самом деле и внедрять ничего не нужно. Это ключевая ошибка.

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

Время внедрений уходит. Я говорю о ERP, ECM, ESB и так далее. Внедрении на всю компанию и натягиванию бизнес-процессов на этот внедрёж.

То же можно сказать и о блокчене, гридах, доморощенных платформах.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
И даже не так.

Нужно правильно проектировать решения. То есть проектировать решения способные удовлетворить потребности клиентов/заказчиков.

Выбор технологий - часть проектирования/архитектуры.

А для этого архитектор должен общаться с бизнесом и понимать, а иногда и помогать формулировать потребности клиента и УЦП. При этом, буквально на лету предлагать концепты архитектуры. Этим я занимаюсь сейчас и занимался в самых успешных своих проектах.

Но для этого архитектор должен постоянно учиться, знать мат часть, плотно взаимодействовать с командами R&D и экспертами в технологиях.
источник

GK

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

Если топы погружаются в технологии, это опасно. Опасно потому, что у них создаётся иллюзия интуиции в этих вопросах.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Вопрос, а зачем нужны EA?

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

N

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

EI

Eugene Istomin in Архитектура ИТ-решений
Nikolay
Такая картина получается, что условно архитектор и программировать не обязан уметь. И разбираться ни в каких базах/брокерах/кешах не должен. Но самое главное  должен уметь  наводить мосты.
Все шире, смотри как в Value Stream описывается bridges the gap
источник

EI

Eugene Istomin in Архитектура ИТ-решений
источник

AV

Alex V in Архитектура ИТ-решений
Gennadiy Kruglov
И даже не так.

Нужно правильно проектировать решения. То есть проектировать решения способные удовлетворить потребности клиентов/заказчиков.

Выбор технологий - часть проектирования/архитектуры.

А для этого архитектор должен общаться с бизнесом и понимать, а иногда и помогать формулировать потребности клиента и УЦП. При этом, буквально на лету предлагать концепты архитектуры. Этим я занимаюсь сейчас и занимался в самых успешных своих проектах.

Но для этого архитектор должен постоянно учиться, знать мат часть, плотно взаимодействовать с командами R&D и экспертами в технологиях.
Все так. Только общаться с бизнесом и помогать формулировать потребности должен RE (requirements engineer). Архитектор конечно тоже может вставать в эту роль, но лучше пусть в башне сидит и основную свою практику пилит.
источник

P

Petr in Архитектура ИТ-решений
По опыту не так легко применить Value Streams: многие продающие подразделения с не сразу воспринимают процессный подход. Комбинация организационных функций и бизнес-сервисов может быть полезней, а потоки ценности применить уже в их контексте. Как считаете?
источник