#архитектура_решений — Public Fediverse posts

Мифы об ИТ-архитектуре, из-за которых ваш проект стоит дороже

Всем привет. Меня зовут Александр Виноградов, я главный архитектор Ви.Tech – ИТ-дочки ВсеИнструменты.ру. Последние 9 лет занимаюсь ИТ-архитектурой и менеджментом в архитектуре, и сегодня бы хотел поделиться с вами своим топом заблуждений про эту самую архитектуру из серии: «если бы мне каждый раз давали рубль, когда я слышу...». Кому будет полезна эта статья: ● Тимлидам и РП, которые смогут чуть лучше понять, почему архитектор так долго возится со своими картинками. ● Продактам, которых пугают словами «ну здесь нам нужен корпоративный архитектор». ● Разработчикам, которые считают, что архитекторы занимаются исключительно рисованием квадратиков и стрелочек. ● Самим архитекторам, чтобы почерпнуть дополнительные аргументы для дискуссий с коллегами. Вы узнаете, что: ● Не существует «правильных» технологий (и postgres не лучше mysql). ● Архитектор не должен писать код (и почему). ● Что покупка коробочных решений не избавляет от проблем. Миф 1, или «Ты ж архитектор» Да, и что? Под этой фразой могут скрываться аж два заблуждения. Обсудим сначала первое. К примеру, ваш собеседник может думать, что любой человек с должностью/ролью, в которой есть «архитектор», обязан ответить на очень широкий спектр вопросов. И это будут вопросы от «как построить ИТ-стратегию» и «как сделать метамодель» до «как настроить вакуум в постгре под какой-то специфический сценарий». Но очень важно понимать, что видов архитекторов в разных таксономиях много (обычно 4-7). Кратко: ● Enterprise Architect (EA, Архитектор предприятия) – работает на уровне стратегии компании, связывает бизнес-процессы и ИТ.

https://habr.com/ru/articles/932640/

#итархитектура #solution_architect #системный_архитектор #проектирование #enterprise_architect #выбор_технологии #командная_разработка #архитектура_решений #мифы_в_ит

Мифы об ИТ-архитектуре, из-за которых ваш проект стоит дороже

Всем привет. Меня зовут Александр Виноградов, я главный архитектор Ви.Tech – ИТ-дочки ВсеИнструменты.ру. Последние 9 лет занимаюсь ИТ-архитектурой и менеджментом в архитектуре, и сегодня бы хотел поделиться с вами своим топом заблуждений про эту самую архитектуру из серии: «если бы мне каждый раз давали рубль, когда я слышу...». Кому будет полезна эта статья: ● Тимлидам и РП, которые смогут чуть лучше понять, почему архитектор так долго возится со своими картинками. ● Продактам, которых пугают словами «ну здесь нам нужен корпоративный архитектор». ● Разработчикам, которые считают, что архитекторы занимаются исключительно рисованием квадратиков и стрелочек. ● Самим архитекторам, чтобы почерпнуть дополнительные аргументы для дискуссий с коллегами. Вы узнаете, что: ● Не существует «правильных» технологий (и postgres не лучше mysql). ● Архитектор не должен писать код (и почему). ● Что покупка коробочных решений не избавляет от проблем. Миф 1, или «Ты ж архитектор» Да, и что? Под этой фразой могут скрываться аж два заблуждения. Обсудим сначала первое. К примеру, ваш собеседник может думать, что любой человек с должностью/ролью, в которой есть «архитектор», обязан ответить на очень широкий спектр вопросов. И это будут вопросы от «как построить ИТ-стратегию» и «как сделать метамодель» до «как настроить вакуум в постгре под какой-то специфический сценарий». Но очень важно понимать, что видов архитекторов в разных таксономиях много (обычно 4-7). Кратко: ● Enterprise Architect (EA, Архитектор предприятия) – работает на уровне стратегии компании, связывает бизнес-процессы и ИТ.

https://habr.com/ru/articles/932640/

#итархитектура #solution_architect #системный_архитектор #проектирование #enterprise_architect #выбор_технологии #командная_разработка #архитектура_решений #мифы_в_ит

Мифы об ИТ-архитектуре, из-за которых ваш проект стоит дороже

Всем привет. Меня зовут Александр Виноградов, я главный архитектор Ви.Tech – ИТ-дочки ВсеИнструменты.ру. Последние 9 лет занимаюсь ИТ-архитектурой и менеджментом в архитектуре, и сегодня бы хотел поделиться с вами своим топом заблуждений про эту самую архитектуру из серии: «если бы мне каждый раз давали рубль, когда я слышу...». Кому будет полезна эта статья: ● Тимлидам и РП, которые смогут чуть лучше понять, почему архитектор так долго возится со своими картинками. ● Продактам, которых пугают словами «ну здесь нам нужен корпоративный архитектор». ● Разработчикам, которые считают, что архитекторы занимаются исключительно рисованием квадратиков и стрелочек. ● Самим архитекторам, чтобы почерпнуть дополнительные аргументы для дискуссий с коллегами. Вы узнаете, что: ● Не существует «правильных» технологий (и postgres не лучше mysql). ● Архитектор не должен писать код (и почему). ● Что покупка коробочных решений не избавляет от проблем. Миф 1, или «Ты ж архитектор» Да, и что? Под этой фразой могут скрываться аж два заблуждения. Обсудим сначала первое. К примеру, ваш собеседник может думать, что любой человек с должностью/ролью, в которой есть «архитектор», обязан ответить на очень широкий спектр вопросов. И это будут вопросы от «как построить ИТ-стратегию» и «как сделать метамодель» до «как настроить вакуум в постгре под какой-то специфический сценарий». Но очень важно понимать, что видов архитекторов в разных таксономиях много (обычно 4-7). Кратко: ● Enterprise Architect (EA, Архитектор предприятия) – работает на уровне стратегии компании, связывает бизнес-процессы и ИТ.

https://habr.com/ru/articles/932640/

#итархитектура #solution_architect #системный_архитектор #проектирование #enterprise_architect #выбор_технологии #командная_разработка #архитектура_решений #мифы_в_ит

Мифы об ИТ-архитектуре, из-за которых ваш проект стоит дороже

Всем привет. Меня зовут Александр Виноградов, я главный архитектор Ви.Tech – ИТ-дочки ВсеИнструменты.ру. Последние 9 лет занимаюсь ИТ-архитектурой и менеджментом в архитектуре, и сегодня бы хотел поделиться с вами своим топом заблуждений про эту самую архитектуру из серии: «если бы мне каждый раз давали рубль, когда я слышу...». Кому будет полезна эта статья: ● Тимлидам и РП, которые смогут чуть лучше понять, почему архитектор так долго возится со своими картинками. ● Продактам, которых пугают словами «ну здесь нам нужен корпоративный архитектор». ● Разработчикам, которые считают, что архитекторы занимаются исключительно рисованием квадратиков и стрелочек. ● Самим архитекторам, чтобы почерпнуть дополнительные аргументы для дискуссий с коллегами. Вы узнаете, что: ● Не существует «правильных» технологий (и postgres не лучше mysql). ● Архитектор не должен писать код (и почему). ● Что покупка коробочных решений не избавляет от проблем. Миф 1, или «Ты ж архитектор» Да, и что? Под этой фразой могут скрываться аж два заблуждения. Обсудим сначала первое. К примеру, ваш собеседник может думать, что любой человек с должностью/ролью, в которой есть «архитектор», обязан ответить на очень широкий спектр вопросов. И это будут вопросы от «как построить ИТ-стратегию» и «как сделать метамодель» до «как настроить вакуум в постгре под какой-то специфический сценарий». Но очень важно понимать, что видов архитекторов в разных таксономиях много (обычно 4-7). Кратко: ● Enterprise Architect (EA, Архитектор предприятия) – работает на уровне стратегии компании, связывает бизнес-процессы и ИТ.

https://habr.com/ru/articles/932640/

#итархитектура #solution_architect #системный_архитектор #проектирование #enterprise_architect #выбор_технологии #командная_разработка #архитектура_решений #мифы_в_ит

Архитектурные особенности on-premises продуктового решения

Несмотря на активно развивающийся SaaS‑сегмент рынка и кажущееся стремление компаний использовать облачные ресурсы, отдельные направления IT‑продуктов на рынке продолжают оставаться востребованными крупным бизнесом в виде дистрибуций, разворачиваемых в собственных дата‑центрах (англ. on‑premises) и под собственным контролем. Программные решения, адаптированные к такому способу поставки, имеют ряд особенностей архитектурного характера, которые влияют на тиражируемость в целом, и должны учитываться на этапе первичного проектирования: топология развёртывания, сайзинг, модульность, интеграции и возможности кастомизации, а также ограничения, накладываемые на прикладное ПО . В статье рассматриваются некоторые категории архитектурно‑значимых нефункциональных требований, ценность которых неочевидна для конечного функционального заказчика, но неоспорима для удовлетворения бюрократического формализма в лице внутренних ЛНА заказчика (IT, ИБ), варьируемых в широких пределах от заказчика к заказчику, и даются рекомендации по управлению ими с помощью гибких архитектурных принципов.

https://habr.com/ru/articles/859740/

#onpremises #архитектура_решений #архитектура_программных_продуктов #нефункциональные_требования #нфт #тиражируемость

Архитектурные особенности on-premises продуктового решения

Несмотря на активно развивающийся SaaS‑сегмент рынка и кажущееся стремление компаний использовать облачные ресурсы, отдельные направления IT‑продуктов на рынке продолжают оставаться востребованными крупным бизнесом в виде дистрибуций, разворачиваемых в собственных дата‑центрах (англ. on‑premises) и под собственным контролем. Программные решения, адаптированные к такому способу поставки, имеют ряд особенностей архитектурного характера, которые влияют на тиражируемость в целом, и должны учитываться на этапе первичного проектирования: топология развёртывания, сайзинг, модульность, интеграции и возможности кастомизации, а также ограничения, накладываемые на прикладное ПО . В статье рассматриваются некоторые категории архитектурно‑значимых нефункциональных требований, ценность которых неочевидна для конечного функционального заказчика, но неоспорима для удовлетворения бюрократического формализма в лице внутренних ЛНА заказчика (IT, ИБ), варьируемых в широких пределах от заказчика к заказчику, и даются рекомендации по управлению ими с помощью гибких архитектурных принципов.

https://habr.com/ru/articles/859740/

#onpremises #архитектура_решений #архитектура_программных_продуктов #нефункциональные_требования #нфт #тиражируемость

Архитектурные особенности on-premises продуктового решения

Несмотря на активно развивающийся SaaS‑сегмент рынка и кажущееся стремление компаний использовать облачные ресурсы, отдельные направления IT‑продуктов на рынке продолжают оставаться востребованными крупным бизнесом в виде дистрибуций, разворачиваемых в собственных дата‑центрах (англ. on‑premises) и под собственным контролем. Программные решения, адаптированные к такому способу поставки, имеют ряд особенностей архитектурного характера, которые влияют на тиражируемость в целом, и должны учитываться на этапе первичного проектирования: топология развёртывания, сайзинг, модульность, интеграции и возможности кастомизации, а также ограничения, накладываемые на прикладное ПО . В статье рассматриваются некоторые категории архитектурно‑значимых нефункциональных требований, ценность которых неочевидна для конечного функционального заказчика, но неоспорима для удовлетворения бюрократического формализма в лице внутренних ЛНА заказчика (IT, ИБ), варьируемых в широких пределах от заказчика к заказчику, и даются рекомендации по управлению ими с помощью гибких архитектурных принципов.

https://habr.com/ru/articles/859740/

#onpremises #архитектура_решений #архитектура_программных_продуктов #нефункциональные_требования #нфт #тиражируемость

Архитектурные особенности on-premises продуктового решения

Несмотря на активно развивающийся SaaS‑сегмент рынка и кажущееся стремление компаний использовать облачные ресурсы, отдельные направления IT‑продуктов на рынке продолжают оставаться востребованными крупным бизнесом в виде дистрибуций, разворачиваемых в собственных дата‑центрах (англ. on‑premises) и под собственным контролем. Программные решения, адаптированные к такому способу поставки, имеют ряд особенностей архитектурного характера, которые влияют на тиражируемость в целом, и должны учитываться на этапе первичного проектирования: топология развёртывания, сайзинг, модульность, интеграции и возможности кастомизации, а также ограничения, накладываемые на прикладное ПО . В статье рассматриваются некоторые категории архитектурно‑значимых нефункциональных требований, ценность которых неочевидна для конечного функционального заказчика, но неоспорима для удовлетворения бюрократического формализма в лице внутренних ЛНА заказчика (IT, ИБ), варьируемых в широких пределах от заказчика к заказчику, и даются рекомендации по управлению ими с помощью гибких архитектурных принципов.

https://habr.com/ru/articles/859740/

#onpremises #архитектура_решений #архитектура_программных_продуктов #нефункциональные_требования #нфт #тиражируемость

ИИ vs Программист: кто кого? Начало эры «одиночных» стартапов

Я — fullstack‑разработчик с более чем четырьмя годами коммерческого опыта. Сейчас работаю в BPA Solutions, где проектирую и развиваю микросервисные backend‑решения на Node.js/NestJS, а также отвечаю за frontend‑приложения на React/Vue. Автоматизирую рутину и выстраиваю гибкие, легко масштабируемые архитектуры. Заменит ли ИИ программистов?

https://habr.com/ru/articles/913202/

#ии_чатбот #ииагенты #программист #алгоритмы #автоматизация #автоматизация_рутины #стартапы #будущее_программирования #solo #архитектура_решений

ИИ vs Программист: кто кого? Начало эры «одиночных» стартапов

Я — fullstack‑разработчик с более чем четырьмя годами коммерческого опыта. Сейчас работаю в BPA Solutions, где проектирую и развиваю микросервисные backend‑решения на Node.js/NestJS, а также отвечаю за frontend‑приложения на React/Vue. Автоматизирую рутину и выстраиваю гибкие, легко масштабируемые архитектуры. Заменит ли ИИ программистов?

https://habr.com/ru/articles/913202/

#ии_чатбот #ииагенты #программист #алгоритмы #автоматизация #автоматизация_рутины #стартапы #будущее_программирования #solo #архитектура_решений

ИИ vs Программист: кто кого? Начало эры «одиночных» стартапов

Я — fullstack‑разработчик с более чем четырьмя годами коммерческого опыта. Сейчас работаю в BPA Solutions, где проектирую и развиваю микросервисные backend‑решения на Node.js/NestJS, а также отвечаю за frontend‑приложения на React/Vue. Автоматизирую рутину и выстраиваю гибкие, легко масштабируемые архитектуры. Заменит ли ИИ программистов?

https://habr.com/ru/articles/913202/

#ии_чатбот #ииагенты #программист #алгоритмы #автоматизация #автоматизация_рутины #стартапы #будущее_программирования #solo #архитектура_решений

ИИ vs Программист: кто кого? Начало эры «одиночных» стартапов

Я — fullstack‑разработчик с более чем четырьмя годами коммерческого опыта. Сейчас работаю в BPA Solutions, где проектирую и развиваю микросервисные backend‑решения на Node.js/NestJS, а также отвечаю за frontend‑приложения на React/Vue. Автоматизирую рутину и выстраиваю гибкие, легко масштабируемые архитектуры. Заменит ли ИИ программистов?

https://habr.com/ru/articles/913202/

#ии_чатбот #ииагенты #программист #алгоритмы #автоматизация #автоматизация_рутины #стартапы #будущее_программирования #solo #архитектура_решений

Про интеграции. Часть 1. Интеграционные подходы

Динамика развития межсистемных интеграций в крупных компаниях в чём-то повторяет известный закона Мура, примерно каждые 1.5-2 года в них происходит, по меньшей мере, двукратное увеличение межсистемных интеграций. По большей части это эмпирическое наблюдение, но внутренние статистики пары крупных компаний его подтверждают. Причины этого разнообразны, где-то произошла декомпозиция уже работающих ИТ-систем, где-то изменились бизнес-процессы и выяснилось, что их можно более полно автоматизировать, таким образом родились новые ИТ-решения. Список причин возникновения новых интеграций большой и для любой крупной компании, вопрос контроля интеграций, централизованных инструментов, паттернов и подходов по их реализации становится всё более актуальным.

https://habr.com/ru/articles/791186/

#Интеграции #Интеграционная_Архитектура #Системный_анализ #архитектура_решений

Про интеграции. Часть 1. Интеграционные подходы

Динамика развития межсистемных интеграций в крупных компаниях в чём-то повторяет известный закона Мура, примерно каждые 1.5-2 года в них происходит, по меньшей мере, двукратное увеличение межсистемных интеграций. По большей части это эмпирическое наблюдение, но внутренние статистики пары крупных компаний его подтверждают. Причины этого разнообразны, где-то произошла декомпозиция уже работающих ИТ-систем, где-то изменились бизнес-процессы и выяснилось, что их можно более полно автоматизировать, таким образом родились новые ИТ-решения. Список причин возникновения новых интеграций большой и для любой крупной компании, вопрос контроля интеграций, централизованных инструментов, паттернов и подходов по их реализации становится всё более актуальным.

https://habr.com/ru/articles/791186/

#Интеграции #Интеграционная_Архитектура #Системный_анализ #архитектура_решений