Чем корпоративный архитектор отличается от архитектора решений сбер

Обновлено: 23.04.2024

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

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

обновление 1/5/2018будущее в наших технологическая индустрия одна в основном без архитекторов. Если это звучит безумно для вас, подождите несколько лет, и ваша компания, вероятно, догонит, или ваши конкуренты, которые это поймут, догонят (и пройдут) вас. Фундаментальная проблема заключается в том, что" архитектура " - это не что иное, как сумма всех решений, которые были приняты в отношении вашего приложения/решения/портфолио. Так что название " архитектор "на самом деле означает"решающий". Это говорит о многом, и тем, что это не сказать. Там не написано "строитель". Создание карьерного пути / иерархии, которая неявно говорит людям, что " строительство "ниже, чем" решение", а" решатели "не несут прямой ответственности (по разнице в названии) за"строительство". Люди, которые все еще цепляются за свой титул архитектора, будут раздражаться на это и протестовать: "но я практический!- Отлично, если ты всего лишь строитель, тогда откажись от своего бессмысленного титула и перестань выделяться среди других строителей. Компании, которые подчеркивают "все строители решатели, а все решатели-строители " будут двигаться быстрее своих конкурентов. Мы используем название " инженер "для всех, а" инженер " означает принятие решений и строительство.

оригинальный ответ:

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

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

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

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

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

Примечание: многочисленные другие ответы сказали, что" нет стандарта " для этих названий. Это неправда. Перейдите в ИТ-отдел любой компании Fortune 1000, и вы найдете эти названия, используемые последовательно.

два наиболее распространенных заблуждения о "архитекторе":

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

эти заблуждения исходят от многих архитекторов, выполняющих довольно плохую работу, и организаций, выполняющих ужасную работу по пониманию того, для чего нужен архитектор. Принято продвигать топ-программиста на роль архитектора, но это неправильно. У них есть некоторые перекрытия, но не идентичные навыки. Этот лучший программист часто может быть, но не всегда, идеальным архитектором. Хороший архитектор имеет хороший понимание многих технические аспекты ИТ-индустрии; a лучше понимание бизнес-потребности и стратегии чем разработчик должен иметь; отличное коммуникативные навыки и часто некоторые навыки управления проектами и бизнес-анализа. Для архитекторов важно держать руки грязными с кодом и оставаться острый технически. Хорошие-да.

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

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

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

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

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

технические архитекторы, как правило, играют роль архитекторов решений с меньшим акцентом на деловой аспект и больше на технологии аспект.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Родоначальником формализации архитектуры корпоративных информационных систем можно счита т ь Джона А. Захмана со статьями «A framework for information systems architecture» и «Extending and formalizing the framework for information systems architecture» , в которых и было описано то, что получило название модель Захмана .

Данная модель, несмотря на сложный вид, продвигает достаточно простую концепцию. Для разных людей при описании разных частей системы (под системой здесь понимается все предприятие) необходимо использовать разные модели, главное, чтобы они согласовывались между собой. Сам Захман пояснял это на примере строительства загородного дома. Архитектор садится с заказчиком и высокоуровнево обсуждает, что должно быть на участке и в доме. Результатом такой работы является концептуальный план, который в процессе работы архитектора превратиться в план водоснабжения для сантехников, архитектурный план для строителей, план электропроводки для электриков. И задача архитектора следить, чтобы все эти планы были между собой согласованы (чтобы не получилось, что водоснабжение придет в спальню, вместо санузла).

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

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

Еще лет 10 лет назад роль архитектора решений (Solution Architect) на проектах выполняли сами разработчики. Теперь это отдельная профессия, довольно востребованная и активно обсуждаемая. Вместе с коллегами-архитекторами подробно разбираемся во всех деталях и рассказываем, как стать архитектором в EPAM.

Начнем с азов: что означает слово «решение» в контексте IT?

Это продукт или комплекс продуктов, который решает конкретную техническую или бизнес-задачу. Решение нужно бизнесу, чтобы увеличить прибыль: оно либо повышает доходы, либо снижает издержки — к примеру, автоматизирует бизнес-процессы и тем самым снижает расходы на оплату труда. Решение встраивается в архитектуру предприятия и связывается с другими ее компонентами. Большинство проектов EPAM направлены на создание решений: разработка от начала и до конца или отдельных компонентов.

Выходит, на каждом проекте по разработке нужен архитектор?

Да. Архитектор отвечает за видение будущей системы. Он придумывает, как построить решение, чтобы оно работало эффективно и соответствовало потребностям заказчика.

Алексей Кожемякин (Director, Technology Solutions, EPAM Belarus):
«Как только инженер задумался о нуждах бизнеса — он ступил на путь Solution Architect».

Почему раньше обходились и без архитекторов?

Роль архитектора решений на проектах играла вся команда целиком, несколько ее членов или один разработчик с высокой квалификацией. Он мог быть сразу и разработчиком, и проектным менеджером, а заодно и архитектором. Со временем (и опытом) пришло понимание, что создание архитектуры слишком важная и объемная задача, чтобы заниматься ей по остаточному принципу.

В отличие от разработчика, архитектор мыслит абстракциями более высокого уровня. Он размышляет не о взаимодействии классов, а о взаимодействии компонентов решения – приложений, веб-сервисов и так далее. Хотя, если требуется, он должен без проблем «провалиться» в детали кода. Кроме этого, бизнес-сторона решения для архитектора важна так же, как и техническая. Разработчики часто фокусируются на технологиях и новых библиотеках, с которыми хочется познакомиться; архитектор же отталкивается от интересов и потребностей заказчика.

Так кто главнее: архитектор или разработчик?

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

Конкретнее: какими задачами занимается архитектор решений?

В первую очередь архитектор анализирует бизнес-цели заказчика, связанные с новым продуктом. Фокусируется на требованиях, которые повлияют на архитектуру, на программную часть решения и его компоненты. Затем проектирует решение и продумывает его дизайн. Архитектор определяет, из каких компонентов будет состоять продукт, нужно ли разрабатывать его составляющие с нуля или будет уместнее использовать готовые компоненты «из коробки».

Для некоторых частей решения SA делает proof-of-concept – небольшую экспериментально-исследовательскую задачу, чтобы понять, возможно ли реализовать тот или иной функционал.
Архитекторы участвуют в предпродажах, консультируют клиентов, проводят аудит архитектуры существующего решения – оценивают, насколько она эффективна для поставленных задач, можно ли ее оптимизировать, и если да, то как.

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

Владимир Казакевич (Senior Solution Architect, EPAM Belarus):
«Каждый понимает слово «бизнес» по-своему. И задача архитектора решений — вникнуть в бизнес заказчика настолько глубоко, насколько это возможно, а главное — результатом его работы должны быть решения, «заточенные» под конкретных заказчиков и их конкретные бизнес-проблемы».

А есть ли какие-то еще архитекторы?

Помимо архитекторов решений это:
Enterprise Architect – создает и поддерживают архитектуру целого предприятия, которая состоит из множества решений.
System Architect – выстраивает инфраструктурную сторону решения, фокусируясь на инфраструктурных облачных сервисах, на ПО, необходимом для поддержки решения после его развертывания.
Quality Architect – выстраивают стратегию тестирования и определяет подход к управлению качеством создаваемого продукта.

В EPAM, например, архитекторы решений пока в большинстве.

Кто может стать архитектором решений?

Как правило, в архитекторы решений вырастают ведущие разработчики. Кандидату следует иметь солидный багаж технических знаний, широкий кругозор, а также опыт руководства командой и проектом. Лидерство и отличные коммуникационные навыки – мастхэв архитектора, который часто становится связующим звеном между командой заказчика и компании. Одна сторона ожидает, что архитектор придет, вникнет в положение дел, все объяснит и поможет с принятием решения. Проектная команда, в свою очередь, ждет от SA решения о том, что и как нужно делать, и в какой последовательности.

Роман Шрамков (Director, Technology Solutions, EPAM Ukraine):
«Для того, чтобы бизнес и менеджмент увидел возможности для применения технологий, нужен настоящий гик, который объяснит им какие в этом преимущества и как это можно сделать».

Помимо разработчиков, попробовать себя в архитектуре решений могут бизнес-аналитики, деливери-менеджеры, проектные менеджеры, ресурсные менеджеры, а также тестировщики-автоматизаторы: для них есть даже специальная поддисциплина — Solution Architecture in Test Automation.

Дмитрий Гурский (Lead Solution Architect, EPAM Belarus):
«У того, кто хочет стать архитектором, прежде всего, должно быть желание что-то создавать, строить. И это не навык, который можно прокачать, это внутренняя потребность — либо она есть, либо нет».

Какие образовательные программы для будущих архитекторов есть в EPAM?

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

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

Для начала можно присоединиться к Architecture Excellence Initiative – глобальному архитектурному сообществу EPAM, чтобы быть в курсе последних новостей и тенденций в области архитектуры. Участники комьюнити еженедельно общаются с архитекторами из более чем 25 стран. Оперативный обмен кейсами, доступ к обширной библиотеке и вебинарам, собранной коллегами – это сюда.

Дальше – обучение в Solution Architecture School. Это уникальная программа, которую в компании создавали с нуля: групповые занятия с лекциями и практикой ведут действующие архитекторы компании. Здесь все как в обычной школе – домашние задания, включающие разработку дизайна, постоянное общение с преподавателями и защита контрольной выпускной работы.

Что делать, если пришел в EPAM уже архитектором?

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

Архитекторам буду рады в Global Solution Architecture Team – команде экспертов, которые активно участвуют в развитии дисциплины: разрабатывают лучшие практики в компании, координируют глобальные образовательные программы для архитекторов, консультируют коллег и клиентов.

Ну, а если не хочется останавливаться на достигнутом, можно стать студентом Solution Architecture University — трёхуровневой программы, которая помогает опытным архитекторам синхронизировать знания и заговорить на едином языке. У студентов есть возможность пройти сертификации в Software Engineering Institute, IASA Global и других ассоциациях, с которыми сотрудничает EPAM.

Еще одна инициатива — Solution Architecture Mentoring — менторами в которой выступают опытные архитекторы, технические директора и CTO компании. Менти вовлечены в переговоры с клиентами, вместе с наставниками работают над реальными проектами и задачами. Программа помогает архитекторам «прокачаться» в профессии и даже вырасти до уровня CTO.

Вот работаешь ты в IT как молодец. Проходишь, как все смертные, уровни джуниор, мидл, сеньор. Но есть ещё Олимп. Ореол загадочности и элиты вокруг этой профессии не даёт покоя амбициям юных разработчиков. Кто такой IT-архитектор и как им стать читай ниже.

Кто такой IT-архитектор

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

Если чуть длиннее:

это главный герой при создании сложных IT-решений. Он не только решает что делать, но и контролирует как. Архитектор обеспечивает гибкость решений и следит за рисками, сокращает time to market как может.

В народе - он же Архитектор ПО, он же Software Architect, он же системный/функциональный архитектор.

Когда нужен

Главная задача IT-архитектора — найти оптимальное решение, по потребностям заказчика и возможностям команды.

«Впихнуть решение в бюджет и заложить прогноз на развитие

— вот основные задачи архитектора».

В основном, он приходит когда надо:

разработать ПО или систему;

определить архитектуру и эволюцию проекта;

выбрать технологию для каждого элемента системы (монолит или микросервисы, коробочное или комбинированное решение);

провести ревью бизнес-требований;

помочь выбрать фреймворк;

определить стандарты кодирования, создать каталог паттернов/антипаттернов для проекта;

указать риски проекта;

обеспечить баланс в системе «стоимость разработки - гибкость решения - быстрое внедрение новых требований»;

разобраться в документах проекта;

Какие бывают архитекторы (типы и виды)

По типам: функциональный и технический.

Функциональный (или системный) архитектор - выясняет требования к проекту и накидывает черновик архитектуры для системы или ПО. Координирует процесс. Гуру в железе, ЦОДах, сети, системах хранения и серверных платформах.

Технический архитектор - общается с разработчиками, создаёт систему.

Но на практике это 2 в 1.

Enterprise архитектор (отвечает на вопрос «что делать?»)

Решает стратегические проблемы – анализирует ключевые требования, потоки данных, пишет конституцию проекта. Разрабатывает архитектурные стандарты и требования.

Solution архитектор ( «а как делать?»)

Выбирает фреймворки, формулирует альтернативные варианты решений, обозначает риски, решает спорные ситуации. Тестирует производительность и безопасность. Он чётко представляет воплощение идеи в жизнь и доносит до команды. Держит команду разработки в рамках тз. Знает какие ресурсы требуются и как быстро поднять упавший сервис.

Архитекторы инфраструктуры («а чем и зачем делать?»)

Занимается серверным оборудованием (серверы приложений, поддержки), базами данных, архитектурой безопасности (авторизация, аутентификация), облачными сервисами.

Этот архитектор может делиться на:

Security architect — специалист по вопросам безопасности (закрытие доступов на уровне оборудования, шифрование каналов передачи данных и прикладная защита на уровне приложений, почта или корпоративные приложения).

Сетевой архитектор — сопровождает инфраструктуру передачи данных.

Архитектор облачных систем — указывает, какие ресурсы и в каком объёме брать из AWS, AZURE, Google, Yandex.

Data-архитекторы ( «а по полочкам кто разложит?»)

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

А как в жизни?

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

Где нужен такой архитектор

Да везде. IT-специалисты супервостребованы, это профессия будущего. У них большие проекты и сложные задачи, но и ставки высоки. Роботизация процессов (считай жизни сегодня) - вот их работа. Решения, которые принимают IT-специалисты, влияют на жизни миллионов потребителей. К айтишникам высокие требования, но и большие возможности для развития карьеры.

Где учат на него (спойлер - почти нигде)

Этой профессии не учит ни один вуз. Фишка в том, что IT-архитекторы невероятно востребованы и без них не может работать крупный бизнес.

Что можно сделать:

Хороший IT-архитектор постоянно учится и готов инвестировать в обучение время и деньги.

Откуда тогда они берутся

Так утверждают сами архитекторы © :

«Software architects - бывшие тим лиды или тех лиды или ведущие разработчики»;

«Архитекторы берутся из проектировщиков и разработчиков по мере накопления опыта и расширения кругозора»;

«Разработчик умеет говорить и рисовать презентации - solution архитектор»;

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

IT-архитектор Грегори Хопп использует метафору лифта для описания своей профессии. Каждый этаж, где останавливается лифт, это уровень в организации: первый этаж - машинный зал - это разработчики, производство, последний этаж - руководство организации. Воплощая проект в жизнь, архитектор двигается по этажам (с первого до последнего) и на каждом этаже он должен справляться с различными трудностями - технологическими, политическими, коммуникационными.

Топ-5 скиллов профессии

Рeople management

В проекте обычно фигурирует большое количество участников - кому-то необходимо искать компромиссы между ними, находить решения, оптимальные для каждого.

IT-архитектор собирает на проект специалистов разных направлений. Он ставит задачи конкретным специалистам, следит за качеством и сроками исполнения работ. В итоге он отвечает за то, чтобы проект выдерживал планируемую нагрузку и имел запас прочности для развития.

Time management

Ключ к успеху IT-архитектора и человека в целом. Сдавать проект не за день до дедлайна, заниматься самообразованием, уделять время себе, семье, хобби - всё возможно. Хочешь стать Гераклом на IT-Олимпе - овладей этим скиллом.

Long life learning

Постоянное обучение. IT включает в себя столько направлений, что быть экспертом в каждом из них нереально. Хороший IT-архитектор может разобраться в любой теме, даже в совершенно новой.

Strategist

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

Speaker

Что по деньгам

Хабр Карьера проанализировала больше 10 000 зарплат айтишников за второе полугодие 2020 года, и вот что получилось →.

медианная зарплата в IT-индустрии сейчас 113 000 ₽.

разработчики в среднем получают 120 000 ₽.

среди разработчиков традиционно больше всех зарабатывают архитекторы ПО (200 000 ₽).

Вывод

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

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

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

P.S. Если хочешь проникнуться IT-архитектурой и областью в целом, то приключения Нео из «Матрицы» наглядно иллюстрируют профессию.

Автор выражает благодарность за помощь в написании статьи настоящим IT-архитекторам:

Антон Прибора, IT-архитектор IBC Corporate Travel,

Максим Кириллов, руководитель отдела ИТ архитектуры и системного анализа МФК «МигКредит».

В этой книге главный Архитектор Департамента Архитектуры Управления Технической Архитектуры Центра Облачных Компетенций Cloud Native и Solution архитектор автоматизированных систем Сбербанка делится знанием и опытом с читателей, накопленным при разработке своих и оценке чужих архитектур, предоставляя базис для профессионального и карьерного роста.

О книге
Об авторе
Архитектура
Solution Architect и микросервисы
Отличия архитектур и архитекторов (NEW)
Бизнес модель
Редизайн пользовательких путей с помощью CJM
Разработка процессов и их технологических карт
Моделирование данных
Интеграционная архитектура

Приведённый ознакомительный фрагмент книги Роль ИТ-архитектор предоставлен нашим книжным партнёром — компанией ЛитРес.

Отличия архитектур и архитекторов (NEW)

В общем, архитектура достаточно большой компании называется в целом назвается корпоративной архитектурой Enterprise архитектурой. Она описывает все уровни детализации и весь объём компании. Для любого архитектора связанного с ИТ важно взаимодействие ИТ с остальным бизнесом компании. Для большинства компаний бизнес зарабатывает, а ИТ обеспечивает эту возможность, и понимание как это происходит и что нужно поменять задача корпоративного архитектора. Для этого корпоративный архитектор работает с двумя слоями, составляющих корпоративную архитектуру: архитектурой бизнеса (бизенесс уровень) и ИТ-архитектурой (ресурсный уровень). Эти уровни взаимодействую через сервисы, предоставляемые ресурсным уровнем для бизнес уровня. Очень важно понять, что в большинстве случаев ИТ является обеспечивающей функцией компании (ресурсный уровень), и архитектор описывает текущую бизнес архитектуру компании (бизнес уровень) и подстраивает ИТ архитектуру, чтобы описанная бизнес архитектура функционировала как задумано её создателями. Создателями бизнес — архитектуры являются руководители отделов, функциональных блоков и подразделений. Именно они в точности знают, как должны работать их отделы. При этом они тоже, часто её берут не из головы, а опираются на уже существующие процессы, например, отдел продаж опирается на клиентский опыт, который они получили в других компаниях и к которому привыкли, или в результате переговоров. Уже сформированные процессы в бизнес — архитектуре используют возможности ИТ, но это не означает, что корпоративному архитектору нужно сделать ИТ архитектуру зеркальным отображение бизнес архитектуры. Напротив, если несколько процессов имеют схожие требования, то ИТ архитектура должна это унифицировать, если это возможно, обеспечить гибкость и масштабируемость в коротки сроки в след за изменения и ростом процесс, а также предлагать более эффективные пути решения задач.

* Политическая архитектура (или слой заитересованных лиц) — слой заинтересованных сторон, их функциональных и личных интересов и договорённостей между ними. Важно заметить, что заинтересованные стороны — это стороны, то есть защищающие свои интересы, которыми являются личные интересы, например, личный KPI, интересы отдела за которые они отвечают. В связи с этим, архитектор не может подчиняться IT диретору, так как у него свои интересы, которые могут находится в аппозиции с интересами с директорами других подразделений. С другой стороны архитектору необходим политический покравитель, иначе артефкты не будут полностью реализованы. Генеральный дерекор тоже не может руководить архитектором, так как он не погружён в текущую внутреннюю действительность и у он занят в первую очередь внешней политикой и дипломатией. Наиболее погружёнными и компетентными являются директора, а коллегия их (архитектурный совет) уравновешивает интересы и синергирует компетенции. Империческим методом выяснено, что для архитектора на 50% важно сбор информации, ещё на 30% вести договариваться, и только на 20% выбор техничеких решений. Главным заинтересованной стороной является спонсор — тот человек, который заинтересован в проекте и обеспечивает его внешнюю защиту и внешнее продвижение. Спонсор на вмешивается в работу архитектора или менеджера, а решает проблемы, как миинимум связанные с выделением (приоритизации) ресурсами, с приоритизацией бэклога смеждных команд для интеграции и с противниками. Важно не путать спонсора, как силы придающей дижению проекту с теми, на кого возложена обязанность в обеспечении прокта, например, в случае фининсрования — бухгалтерия, а вслучае кадров — другие подразделения и кадровая служба. Именно спонсор своиим влиянием это обеспечивает и договариваться имеет смысл имеенно с ним, а не с теми, на кого спущено указание, так как они могут даже быть не заинтересованы, но не могут не сделать требуемое, и конечно же только в объёме спущенным спонсором. Важно, чтобы время у спонсора хватало для решения сложностей проекта, но при этом не слишком ного, чтобы самому руководить процессом этого проекта. Как и проект без спонсора, так и корпоративная архитектура без спонсора обречены на провал. О последнем говорится и в TOGAF, и в COBIT. Изменение архитектуры подразумевает проект, а следовательно процесс выявление заинтересованных сторон сопособные на него влиять. Выявление заинтересованных сторон можно взять из проектного упраления. Если заинтересованные стороны не выявлены или ника ещё себя не проявили — это может повлеч затраты, когда это заинтересованное лицо начнёт оказывать влияние и прийдётся на последних этапах подстраивать результат под него. Систематитизировать заитересованные стороны поможет матрица коммуникации. Матрица коммуникации представляет из себя таблицу заинтересованных сторон и их параметров. Часто, колючевые заитересованные стороны не заинтересованные в успешном завершении проэкта выбирают стратегию избегания, но без них проект не сможет завершиться. При выявлени заинтересованных сторон важно различать формальную организационную стуктуру и фактическую — ролевую. В проектах очень много задейсвуются горизонтаотных и диагональных связей. Выявить их можно, зачастую, только при общении, так как сформированны они были при общении. Например, сотрудник может быть"припаркован"в другом отделе. При наличии информации об интересах переговоры проходят гораздо легче, так как не нужно во время них их искать, и их результат проще зафиксировать в протоколе. При поиске данных нужно находить различные решения. Это отдельный навык — на искомых данных писк альтернативных решений, именуемый дивергентное мышлением. На переговорах важно услышать собеседников, предложить различные варианты сделав акцент (продать) не лучшие решения, найти компромисное решение. На уже имеющихся данных из большого числе решений нужно найти лучшее решение, что у технических специалистов, обычно, не вызывает сложностей, так как им привычно конвергентное мышление. Для архитектора основными контрагентом (основным стейкхолдером) являются владелец продукта для которого делается архитектура. Исключение одно, если решения принимают другие стейкхолдеры, а владелец продукта транслирует эти решения. Другие заинтересованные стороны: заказчик (или владерел продукта, как его представитель), разработчики (минимизация работы, четкую постановку задач, Time2Market), сервисные подразделения (выполнение их стандартов), архитектор сервиса (гарантированная работа сервиса), корпоративный архитектор (поддержания ландшафта). Если же не достигается взаимопонимание, то экскалировать нужно или архитектору данной области, или владельцу данной области. Наример, если не находится общий язывк с командой сервиса, можно эскалировать или владельцу сервиса, или архитектору сервиса. Если же не находится язык с владельцем сервиса, то эскалируется архитектору сервиса, если с архитектором сервиса, то владельцу это сервиса. Если же не находится общий язык ни с тем, ни с другим, стоит задаться вопросом, чьи интересы Вы отстаиваете. Заказчик хочет для бизнеса:

** движение к цели.

* Бизнес архитектура — это отображение деятельности предприятия и связи. Состоит она по TOGAF из ряда архитектр, а поскольку они является описательными, их часто:

** организационной архитектуры (бизнес цели, люди, роли),

** продуктовой архитектуры (продукты, каналы сбыта, клиентский путь),

** процессной архитектуры, связывающей организационную с продуктовой, как продавца и покупателя процессами.

* ИТ архитектуру делят на:

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

* Информационная архитектура — это совокупность информации (данных), которыми обмениваются люди или приложения в рамках выполнения процессов. Более подробно в разделе об моделировании данных.

* Архитектура приложений — архитектура управления ландшафтом решений (приложений, систем) и их составом. Корпоративный архитектор заботится на этом уровне над встраиванием новых систем и унификации технологий, на которых они построены. Для этого он пользуется ландшафтом (картой) бизнес решений компании, проектирует платформенные решения, проводит унификацию применяемые технологий при реализации решений и создаёт стандарты их применения. Системными драйверами изменения могут быть экономические показатели, показатели безопасности, скорости роста или адаптации на изменения. Примером подобной унификации может быть выбор минимально достаточного набора языков закрывающего основные потребности для уменьшения стоимости сопровождения систем как с технической точки зрения, так и с кадровой. Примерами трансформации архитектуры может быть переход с монолитных систем на компонентные (SOA), или с SOA на микросервисные, для всего этого требуется разработка стандартов и выбора соответствующих технологий, что позволяет увеличить Time2Market и перейти на более дешёвые аппаратные системы (x86) и отказаться от оплаты лицензий за проприетарное программное обеспечение. Архитектор решения проектирует само решение, согласуя встраивание его в корпоративный ландшафт решений и следование стандартам унификации технологий, применяемый при проектировании решений.

* Интеграционная архитектура связывает различные компоненты системы и именно эти связи и описывает интеграционная архитектура.

* Техническая архитектура описывает реализацию предыдущих слоёв. Сама она тоже делятся на слои, но эти слои не абстракции, а являются технической реализацией относительно клента. Эти слоит также называются технологическим стеком, так как они располагаются от пользователя бизнес слоя один за другим в определённом порядке и ни одни слой не может быть пропущен, в то время, как слои архитектуры описывают архитектуру под разным способом, могут дополняться и изменяться, но мы придерживается принятому в TOGAF набору слоёв. Так, стек WEB приложений состоит из:

** Слой приложений — тот слой с которым непосредственно взаимодействуют пользователи и которые обеспечивают процессы и реализуется с помощью WEB интерфейсов в браузерах. Выполенине же бизнес логики на уровне WEB интерфейсов недопустимо — вся работа делегируются нижележащему слою.

** Сетевой слой обеспечивает работу WEB интерфейсов в браузерах пользователях, передавая данные. Вышестоящий слой приложений нужен пользователям, которым удобно пользоваться графическим интерфейсом и чтобы за них выполнялись какие либо рутинные действия. Сетевой слой обеспечивает коммуникацию серверных приложений, таких как WEB-сервера и СУБД.

** Аппаратный слой представлен устройствами выполннения. Эти устройства могут аппаратными с разной степенью универсальность. Например, балансировщик может быть чисто аппартным, может быть аппаратным с изменяемой прошивкой, может быть программным исполняемым на универсальной вычислительной машине типа x86, может быть запущен как непосредственно, так на виртуальной машине, так и в контейнере — всё это детали реализации.

** Слой хранения данных состоит из устройств хранения данных. Этими устройствами могут быть специализированные устройства типа IBM DataPower или же обычный RAID с управляющим модулем. Данные в нём полностью описывают состояние и является результатом работы, а предыдущие слоит только нужны для изменения и предоставления удобного доступа пользователям.

При необходимости, могут быть внедрены и другие слои, например:

* слой информационной безопасности реализуемый файрволл;

* слой базовых образов контейнеров;

* слой локальной отказоустойчивости (HA) на примере слоя Kubernetes;

* слой устойчивости к авариям реализуемый балансировщиками на разные DataCenter.

В любом случае количество слоёв стандартизируется на уровни компании, чтобы каждый слой относился с определённым инфраструктурным отделом и отделом эксплуатации. Возможно, в технологическом стеке указывают только те, которые отличаются для акцента на них. Так, если все построены на x86 или Linux, то нет смысла это указывать, но чтобы сохранить историчность, когда это было не так, их можно объединить. Также можно объединить, если верхние слои строются исключительно на определённых слоях нижнего. Так, в стеке для OpenShift нет смысла указывать операционную систему или тип контейнеризации, так как он определён самой платформой OpenShift и для корпоративного архитектора это не имеет значение.

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

* корпоративный архитектор представляет интересы всего IT ландшафта;

* архитектор решения преследует интересы конкретного решения и его заказчика.

С одной стороны может показаться, что корпоративный архитектор главнее архитектора решения, или как миниму его интересы есть сумма интересов всех архитекторов ршений, но это не так. С точки зрения роста из разработчика такая лесенка имеет место быть: Junior Developer, Developer, Sinir Developer, Lead Developer, Software Architect, Solution Architect, Enterprise Architect. Это так называемый путь I-T-E форма:

* Узкий специалист сперва осваивает в глубину свой узкую область, например, разработку на Java приложений.

* Потом осваивает свой кругозор в ширину (T) соседние области, повышая свой кругозор, чтобы задействовать другие технологии, например, Front-end для Java back-end. Это характерно для Software Architect, например, Java.

* затем появляется наращивание компетенций в бизнес фокусировке и управленческих навыках, так как большой проект создаётся для решения бизнес потребностей и им нужно управлять, что уже характерно для Solution Architect.

* следующим этапом является накопление навыков по бизнес стратегии, что необходимо для подготовки и корректировки развития IT ландшафта.

* доменно развитием методологий и стандартов (технологий, архитектур);

* на уровне данных: разрабатывает концептуальную и логическую корпоративную модель данных;

* на уровне приложений: разрабатывает целевой ландшафт (карту) приложений;

* на уровне бизнеса: разарабатывает карту компетенций;

* осуществляет архитектурный консалтинг для архитекторов;

* разрабатывает архитектуру экосистемы;

* осуществляе архитектурный контроль на уровне компании;

* корректирует архитектуру по трендам, бизнес и технологическим статегиям;

* балансирует скороть и контроль.

* транслирует бизнес идей в решения;

* защищает ахитектуру сквозных процессов вплоть до правления;

* учавствует в согласовании архитектур (бизнес процессов, приложений);

* разрабатывает концептуольнве архитектуры (интеграционные на разных уровнях);

* связывает системы в единое решение (процесс, продукт);

* синхронизирует работу архитекторов систем бизнес процесса;

* согласует решение с корпоратиными архитеторами на добавления в ландшафт;

* на собеседовании в основном вопросы по согласованию и поиску информации о различных системах.

* разрабатывает архитектуру решения;

* осуществляе архитектурный контроль решения;

* часто является экспертом;

* на собеседования вопросы по доменной области, портфолио — описания систем.

По заинтересованным лицам архитекторы отличаются:

* Software Architect — разработчики и пользователи этой программы;

* Domain Architect — все пользователи этого домена, например, баз данных;

* Solution Architect — бизнес заказчики процесса, в рамках которого нужно согласовать работу систем, обеспечивающих его;

* Enterprise Architect — все бизнес заказчики, владельцы платформы и систем, менеджеры, все другие заинтересованные лица.

Отличается и назначение:

* архитектор приложения сфокусирован на выбора технологий и проектировании;

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

* корпоративный архитектор сфокусирован на целях компании, например, на уменьшение затрат на поддержку и содержание всех решений компании за счёт унификации технологий, уменьшении общего Time2Market за счёт автоматизации в DevOps или увеличении утилизации за счёт перевода всех решений в облако.

По целям отличаются:

* Архитектор решения стремится удовлетворить заказчика этого решения. Если он не использует платформенные решения и экосистему, то корпоративная архитектура для него накладные расходы. Да, ситуация изменится при эксплуатации и поддержке.

* Корпоративный архитектор забоится о компании в целом, даже у ущерб отдельным проектам. Так, использование определённых технологий может помочь проекту, но это повысит содержание и усложнит управление в целом для компании.

Также корпоративный архитектор подключается на этапах целепологания и планирования сервиса, а архитектор решения — на этапе проектирования и реализации.

Отличаются по навыкам:

* Software Architect — сфера влияния — команда разработки, а принимаемые решения, обычно, это чисто технические на основе спущенных требований;

* Domain Architect — требуется выполнять поручение заинтересованных сторон, поэтому достаточно уметь выслушать;

* Solution Architect — требуется согласовать работу нескольких систем участвующих в процессе, необходимо инициировать коммуникацию с владельцами этих систем, уметь понимать требования бизнеса;

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

Отличии в работе:

* Software Architect — проектирование приложение используя шаблоны проектирования, такие как GRASP;

* Domain Architect — проектирует и развивает свой домен;

* Solution Architect — проектирует изменения в продуктах и процессах, согласовывает работу архитекторов по слаженной работе;

* Enterprise Architect — определяет архитектурную стратегию развития направлений, архитектруные концепции, архитектурный ландшафт компании, презентует топ-менеджументу в презентациях, регулирует работу компании стандартами и другими активностями.

Автор статьи

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

Читайте также: