В чем разница между "архитектором решений" и "архитектором приложений"? [закрытый]


насколько я вижу Архитектор Решений это просто другой "маркетинговый" термин для Архитектор Приложений. Это правильно или роли на самом деле разные? Если да, то как?

и да, я искал это как на StackOverflow, так и на Google.

11 86

11 ответов:

обновление 1/5/2018

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

существуют допустимые различия между типами архитекторов:

корпоративные архитекторы смотрят на решениях для предприятий жестко aligining с корпоративной стратегией. Например, в банке, они будут смотреть на полный ИТ-ландшафт.

архитекторы решений фокусируются на конкретном решении, например на новой системе эквайринга кредитных карт в банке.

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

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

нет, архитектор имеет другую работу, чем программисту. Архитектор больше волнует нефункциональным ("илиты") требования. Как надежность, ремонтопригодность, обеспеченность, и так далее. (Если вы не согласны, рассмотрите этот мысленный эксперимент: сравните программу CGI, написанную на C, которая делает сложный веб-сайт, с реализацией Ruby on Rails. Они оба имеют то же самое функциональное поведение; выбор RoR архитектура что преимущества.)

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

нет стандартных отраслевых определений для названий должностей архитекторов - Application/System/Software / Solution Architect все относятся в целом к старшему разработчику с сильными навыками проектирования и лидерства. Баланс проектирования, стратегии, развития (часто основных услуг или структур) и управления различается в зависимости от организации и проекта.

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

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

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

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

оба имеют свое место, обе задачи должны быть выполнены для того, чтобы staisfy требование и в больших организациях вы будете иметь преданных людей, делающих это, в небольших магазинах dev часто раз разработчик должен будет забрать все архитектурные задачи как часть общего развития, потому что нет никого другого, ИМО его чрезмерно цинично сказать, что это просто маркетинговый термин, это реальная роль (даже если это разработчик, собирающий его ad-hoc) и особенно ценный при запуске проекта.

звучит как то же самое для меня! Хотя я не совсем согласен с Оли. Я бы дал нескольким избранным людям название архитектора программного обеспечения, если они этого хотят, но опыт говорит мне, что люди, которые действительно заслуживают титула архитектора программного обеспечения, обычно не имеют этого в названиях.

решение это будет использовать ряд компонентов, в первую очередь продукты CA, и, возможно, некоторые сторонние или ручные кодированные элементы.

теперь я более сосредоточен как разработчик, я архитектор приложений сами, поэтому я архитектор приложений.

вот как я это вижу, однако, как уже обсуждалось, существует мало на пути именования стандартов.

правописание?

серьезно, хотя-они оба BS название должности пуха. "Программист" недостаточно хорош для вас? Стать "архитектором"!

действительно... К чему идет мир?!

Edit: я явно задел чувства некоторых "архитекторов"!

Edit 2: хотя я согласен с мнением, что фразировка может быть истолкована как означающая, что некоторые люди имеют дело со всей проблемной областью (например, аппаратное обеспечение, программное обеспечение, развертывание, поддержка), большинство людей кто хочет удовлетворить клиента (и заработать больше денег) предоставит полный сервис, если потребуется, независимо от их названия.

в реальной жизни, это просто маркетинговый пух.

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

например, программирование / ИТ / управление проектами / стратегия / бизнес-аналитика

другие способы получить звание Архитектора:

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