архитектор программного обеспечения кто это и чем занимается

Кто такой архитектор программного обеспечения, какие у него обязанности и как им стать

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

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

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

Особенности профессии

Для начала разберемся, что же такое программное обеспечение. Если кратко, то это комплекс программ, которым вы пользуетесь на своем ПК. Провести расчеты, написать текст в электронном документе, послушать музыку, создать презентацию – это все ваши задачи. А решают их для вас Excel, Word, KMPlayer, PowerPoint и другие составные части программного обеспечения.

ПО может быть системным, прикладным и инструментальным.

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

Прикладное – это комплекс инструментов, которые решают конкретные задачи пользователя. Например, создавать электронные документы, смотреть фильмы, делать перевод текстов.

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

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

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

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

Например, производители одежды хотят предоставлять свои услуги не только в магазине, но и онлайн. Для этого нужно создать мобильное приложение. Тогда за дело берется архитектор. Он продумывает все детали по разработке функционального онлайн-сервиса для магазина.

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

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

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

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

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

Обязанности работника

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

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

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

Основные обязанности архитектора можно разделить на несколько категорий:

Кроме этого, специалист выполняет следующие задачи:

Если говорить проще, то архитектор ПО отвечает практически за все в IT-проекте.

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

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

Также IT-архитектору приходится работать с огромным объемом документов. Надо их сформировать и продумать, а также предоставить и сдать в отведенные сроки.

Требования к сотруднику

Для архитектора ПО важно понимать не только аспекты и особенности веб-разработки и IT-системы, но и разбираться в бизнес-процессах.

Специалисты должны соответствовать следующим требованиям:

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

Архитекторы ПО постоянно расширяют свой кругозор. Это должен быть “гибкий” специалист, который всегда ищет компромисс. Ему недопустимо быть узконаправленным работником, он должен уметь находить причины появления любой технической проблемы и знать, как ее устранить. Специалисту нужно принимать взвешенные решения и уметь приводить аргументы в пользу своего мнения.

Зарплата и карьера

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

Конечно же, важным пунктом при анализе какой-либо профессии является зарплата специалиста. В среднем по России уровень оплаты труда держится на отметках от 80 000 до 300 000 руб.

В регионах заработная плата может упасть до 60 000 руб., что тоже является доходом выше среднего. А максимум в таких городах, как Нижний Новгород, Воронеж, Екатеринбург, Казань, Новосибирск, Краснодар, Владивосток, предлагают 200 000 руб. Реже, но все же иногда встречаются предложения с доходом 250–300 тыс. руб.

В Москве же зарплата начинается от 100 000 руб. и может доходить до 350 тыс. руб. и выше.

Эта профессия является одной из самых высокооплачиваемых в IT-сфере.

Начинающие архитекторы уже получают от 60 000 руб. У специалистов со стажем от года зарплаты находятся на уровне 100–150 тыс. руб. А зарабатывать еще больше могут работники, которые трудились на своей должности более трех лет.

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

Но дело не только в нехватке кадров, но еще и в обязательных требованиях от работодателей крупных компаний:

Плюсы и минусы

После проведения анализа профессии можно выделить ее достоинства и недостатки. Начнем с плюсов:

Обучение на архитектора ПО

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

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

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

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

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

Говоря о курсах для архитекторов ПО, стоит упомянуть некоторые из них:

Но и этого мало для становления архитектором ПО.

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

Кроме этого, нужно постоянно читать статьи и литературу. Среди книг для архитекторов ПО в первую очередь советую изучить следующие:

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

Заключение

В этой статье мы познакомились с архитектором программного обеспечения и узнали:

Также мы поговорили о способах обучения этой профессии.

Источник

Системный архитектор. Кто этот человек?

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

Что еще? Думаю что надо как то договорится о подаче материала. Здесь, как и в первой статье, я рассмотрю конкретный пример из своей практики, который, как мне кажется, максимально точно иллюстрирует специфику работу данного специалиста. Как и раньше, в заключении, попробую ответить на следующие вопросы: кто такой Системный Архитектор, какими навыками должен обладать и т.д. Поехали?

И последнее, думаю, надо представится. Меня зовут Владимир Воловиков. Опыт работы в сфере разработки программного обеспечения более 20 лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ.

Ускорим работу

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

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

проверка наличие товара в конкретном магазине;

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

Если бы мы писали программный код, как бы это все могло выглядеть?

Мы видим три сущности: Goods, Payment, Storage. Каждая сущность имеет свои инкапсулированные методы и свойства. Как быстро все это будет работать? Да, мгновенно! Этот код весь в памяти. А теперь, давайте, сделаем из этого микросервисы. Разделим их по бизнес возможностям

Ну, что ж? Видим проблему, понимаем, откуда она взялась. Самое время заняться проектирование системной архитектуры. Дано:

Разделим “монолитный” микросервис на две части. Сделаем Микросервис для работы с внутренними потребителями и Микросервис для работы с внешними потребителями

Следующим шагом, нужно избавится или максимально исключить, количество интеграций в Микросервисе для внутреннего Потребителя. Вариантов тут два:

изучение бизнес-правил и их упрощение;

изменение архитектуры системы.

Что такое Бизнес-правила? Это, по сути, занесенные на бумагу правила, по которым работает бизнес. Это то, что отвечает на вопрос: ”Почему именно так работает, а не иначе?”. Приведу пример нескольких таких правил в разрезе нашего магазина

Номер

Описание

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

Как только товар зарезервирован, необходимо отправить уведомление Менеджеру и Клиенту

Менеджер, получив уведомление о том, что Клиент зарезервировал товар, должен внести в График Доставки зарезервированный товар

Зарезервированный товар должен быть доставлен Клиенту не позднее, чем через 24 часа с момента резервирования

Функция формирования Графика Доставки зарезервированного товара должна быть доступна сотруднику с более высокой компетенцией и ответственностью

Изменение любого пункта из данного списка автоматически влияет на всю логику работы системы. Упростив БП1, вы автоматически уменьшите количество интеграций и, как следствие, система будет работать быстрей. Упростив БП5, ваша система будет проще. Не нужны будут ни какие Ролевые модели, создание AD групп и интеграций с этим сервисом. Будет работать надежнее.

Интервальная синхронизация. Периодически, допустим, раз в сутки, производить запросы к Поставщикам информации и обновлять локальные данные.

Попросить Поставщиков информации отправлять нам уведомление о том, что информация изменилась.

В первом варианте, очевидно, что наша система будет производить неактуальные действия, основываясь на устаревшей информацией. Хорошо ли это? Системный архитектор не может на это ответить, ответ есть у бизнеса, и выглядит он как формирование и внедрение нового бизнес-правила. Принятие его. Например, вот такого

Номер

Описание

После изменения свойств товара оператором, изменение этих свойств на сайте должно появится не позднее 24 часов

Для реализации второго варианта, необходима доработка и нашего Микросервиса, и, возможно, сервиса Поставщика. Необходимо внедрение в архитектуру Шины Событий: Kafka, RabbitMQ и т.д.

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

Теперь посмотрим на Базу данных. Что было, что стало? Идеология проектирования Микросервисов, это идеология инкапсулирования в одном месте логики, данных и команды. Изолированная зона ответственности. Давайте мысленно вспомним, что происходило с данными в результате наших манипуляций проделанных ранее

Единый Микросервис-монолит мы разбили на две части

Для каждого нового Микросервиса, мы выделили отдельную базу данных, по сути, сделав две ее копии

Базу данных Микросервиса для внутреннего потребления мы дополнили двумя таблицами: Данные от поставщика 1 и Данные от поставщика 2

Давайте, попробуем нарисовать Диаграмму сущностей и отношений опять же в разрезе нашего выдуманного интернет-магазина. Как было и как стало?

Стало, после разделения “монолитного” микросервиса на два

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

Смотрим на то, что получилось и плачем. Решив одну проблему, мы породили целый ворох новых

Рассогласованность данных. Данные у Микросервиса для внешнего потребителя отличаются от данных у Микросервиса для внутреннего потребителя

Избыточность данных: по сути, две копии одного и того же

Отсутствует единый источник правды

Физическая репликация

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

Логическая репликация триггерами

Прикладная репликация

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

Схема с Прикладной репликацией с использованием шины данных

Общая база данных

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

Итоговый вариант архитектуры ИС

Подведем итоги

Кто такой Системный архитектор?

Чем отличается Программный архитектор от Системного?

Должен ли уметь программировать Системный архитектор?

Какими навыками должен обладать Системный архитектор?

Как бизнес аналитику, ему необходимо:

уметь внятно и точно выразить свои мысли

переложить их на бумагу

владеть несколькими UML нотациями, например, Диаграмма классов (Class Diagram) и Диаграмма деятельности (Activity Diagram), диаграмма последовательностей Sequence диаграмма. Возможно, также пригодиться Event Storming диаграмма

уметь выявлять бизнес правила (требования)

SOAP, REST, GRPC и т.д. Какие виды протоколов взаимодействия есть между системами. Плюсы, минусы, опыт работы с ними

Различные шины данных. Кеши и т.д. Также плюсы, минусы их

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

Схемы построения надежности баз данных

Схема построения высоконагруженных систем

Сколько лет должно быть практики, чтобы быть Системным архитектором?

Заключение

Системный архитектор, это, безусловно, топ технической специальности. Это опыт, опыт и опыт. Это очень большой кругозор. И это уже конечно хорошо развитые “софт”- скилы. Без них уже никак. Как и что должно работать? Какие взаимодействия? Какая реакция системы? Как бизнес требования переложить в систему? Все это непростые навыки, развить которые, увы, невозможно ни на каких курсах

За помощь в подготовке данной статьи автор благодарит Балахчи Анну Георгиевну, Иркутский Государственный Университет, Факультет Бизнес-коммуникаций и информатики, зав.кафедры, кандидат физико-математических наук

Источник

Архитектор ПО: зачем он нужен и в чём его проклятие

Гость нового выпуска подкаста «Сушите вёсла» — архитектор программного обеспечения Егор Тафланиди. Обсуждаем, что это за метафизическая роль такая, какие сложности есть в работе и при чём тут тёмные силы.

Артём Кулаков и Рома Чорыев — разработчики Redmadrobot. Они записывают ламповые подкасты, где вместе с гостями обсуждают разные стороны создания ИТ-продуктов. Ниже ссылка на новый выпуск и ответы на несколько насущных вопросов.

Тайминг
01:40 Егор рассказывает, как стал архитектором
12:40 Популярные мифы: архитектор — высшая ступень развития разработчика; архитектор знает всё лучше всех и больше всех; архитектор не пишет код (потому что забыл как это делать); архитектор сидит и рисует какие-то схемы
31:20 Рассуждения о современных языках программирования
39:10 System/Solution/etc Architect. Что это вообще всё значит?
47:50 Обсуждение того самого «проклятия»
50:24 Как стать архитектором (warning: немного шуток)
55:16 Time management: один рабочий день архитектора — что он делает?
01:03:39 Какие есть сложность в работе и как их преодолеть
01:13:49 А что дальше: какие есть векторы развития
01:26:59 Ответ на вопрос: какой же true way для архитектора?

Кто такой архитектор ПО?

Архитектор — специалист, который занимается построением ИТ-систем для решения бизнес-задач. Он хорошо разбирается во всех нюансах проектирования систем.

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

Архитектор должен разбираться во всём?

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

— Вся сущность сводится к двум вещам: архитектор должен решать задачи бизнеса и он должен уводить систему от ограничений. Если ты знаешь, что в системе нет физической возможности реализовать те или иные вещи, но есть бизнес-потребность, то твоя задача — придумать как и состыковать всё воедино. Можно сказать: сделать так, чтобы и овцы были целы, и волки сыты.

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

— Архитектор — это больше про ширину, чем про глубину. Например, тебе необязательно уметь в Android работать с рефлексией и с какими-то низкоуровневыми вещами, но важно понимать, как всё это работает в целом.

Пишет ли архитектор код?

Если коротко, то некоторые архитекторы кодят. Подробнее об этом — в пятиминутном рассуждении в подкасте, начиная с 22:25. Спойлер: там про идеальный код, проблемы перфекциониста и бизнес-требования.

Как стать архитектором?

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

— У нас было так: компания развивалась, росло количество людей и проектов. Качество нужно было поддерживать, поэтому настал момент, когда появилась свободная «ниша ответственности».

Архитектор — высшая ступень разработчика?

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

А что за «проклятие»?

Так объясняет этот феномен Егор:

— «Проклятие» заключается в том что, когда появляется необходимость в архитекторе, и человек занимает эту должность, то в этой компании больше никто не может стать архитектором.

Он рассказал, что специалист, занявший должность, вряд ли сможет заняться чем-то другим в дальнейшем (в рамках компании). Это связано с тем, что тяжело «воспитать» себе заместителя. Так получается по разным причинам: задачи архитектора сложно делегировать, не всегда есть человек, желающий встать на замену и просто не хватает времени для обучения.

Слушайте подкаст на удобной платформе — SoundCloud, Apple, Google Podcasts.

Полезные ссылки

Важные статьи, видео и книги для тех, кто хочет трансформироваться в архитектора:

Источник