Кто такой архитектор? Системный или функциональный? Статья 1

Используем AWS Lambda: что такое событийно-управляемая архитектура – Часть 1

Оригинал статьи: ссылка (James Beswick, Principal Developer Advocate)

В серии “Используем AWS Lambda” я затрону несколько тем, важных для разработчиков, архитекторов и системных администраторов, которые работают с приложениями, использующими AWS Lambda. Эта серия из трёх статей познакомит вас с событийно-управляемой архитектурой, и покажет, как она связана с бессерверными приложениями.

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

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

Требования и ограничения

Наша цель — спроектировать архитектуру программного обеспечения (ПО) систематическим, предсказуемым и экономически эффективным способом. Для этого нужно определить требования к продукту.

Как правило, техническое задание (ТЗ) на разработку продукта содержит требования, но не всегда они указаны в достаточном объеме. По этой причине в числе ключевых задач IT-архитектора – сбор и анализ требований, создание дизайна архитектуры и описание решения, его проверка, а также контроль и надзор во время разработки ПО.

Рассмотрим, что входит в список требований:

1. Цель проектирования

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

2. Атрибуты качества, нефункциональные требования

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

Пример: система должна работать 24х7, допускается простой не более 30 минут в месяц.

3. Функциональные требования

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

Пример: возможность выгружать данные из файла и рассылать отчеты по email.

4. Системные требования

Возникают постепенно в процессе детализации и реализуются итеративно.

Пример: авторизация, ведение журнала действий, кэширование.

5. Ограничения

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

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

Согласно методологии ADD, сбор требований – это первый этап работы. Его назначение:

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

Далее рассмотрим остальные этапы проектирования.

Soft-skills ИТ-архитектора.

Коммуникабельность.

Именно высокий уровень коммуникабельности, умение общаться с заказчиками, аналитиками, разработчиками позволят убедить, презентовать и обосновать свою точку зрения. Умение вести дискуссию поможет прийти к разумному компромиссу.

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

Клиентоориентированность.

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

Управленческие навыки.

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

Нацеленность на результат.

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

Эмоциональный интеллект.

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

Критичность.

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

Широкий кругозор и способность к самообразованию.

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

Требования к кандидатам на старте и навыки системного архитектора

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

Архитектору информационных систем необходимо знание любого верхнеуровневого языка программирования: Python, Ruby, C#, C++, Java, Kotlin и др. Желательно знание основных принципов работы с HTML, CSS, Java Script, базами данных, типами и структурами данных, а также с сетевым стеком TCP/IP вплоть до прикладного уровня. Ему потребуется наличие опыта проверки производительности систем на основе их спецификаций, а также опыт работы с облачными средами и навыки разработки ПО для корпоративных облаков. Еще понадобится опыт разработки интуитивно понятных учебных пособий и шаблонов в помощь новым руководителям проектов, а также наработанная база поставщиков оборудования, независимых ИТ-лабораторий и сервисных центров по тестированию новых технологий. Не стоит забывать про управленческие навыки и навыки координации работы отделов.

Ниже представлен список наиболее важных требований к кандидатам на должность системного архитектора, основанный на запросах работодателей с Glassdoor.com – крупнейшего американского сайта по поиску работы.

Источник: Glassdoor.com

Задачи и обязанности

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

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

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

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

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

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

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

«Без знания предметной области ты остаешься на уровне сеньора. Чем больше ты понимаешь язык бизнеса, тем ты ценнее».

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

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

«Умение выбрать оптимальное решение вместо лучшего — вот основная задача архитектора».

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

«Я занимаюсь не столько реализацией конкретных фич игры, сколько придумыванием того, как они должны быть реализованы вообще и каким будет их взаимодействие друг с другом. Например, при разработке игры от меня требуется выбрать технологии реализации клиента и сервера, выбрать способ коммуникации между ними, определиться, какие операции следует реализовать на клиенте, а какие — на сервере, и как все это будет храниться в базе. В мои обязанности входит работа над движком игры — как реализовать это всё, чтобы оно было легко переносимо и работало как можно быстрее. Допустим, наша новая игра дает всего лишь на первом iPad. Во всем виноват рендер, который должен отсортировать и нарисовать множество объектов. Моя задача: придумать более производительный алгоритм и реализовать его. Задача программистов: прикрутить его к конкретным проектам».

Типичный рабочий день архитетора предпологает:
— участие в групповом планировании, митингах, совещаниях с заказчиком;
— консультирование команды по текущим вопросам;
— проектирование и написание технической документации;
— изучение новых технологий;
— работа с кодом проекта, прототипирование, оптимизация, рефакторинг.

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

Заработная плата

Данная позиция — довольно редко встречается даже среди специалистов узкой сферы интернет-технологий. Исходя из этого, оплата труда начинается от 70 000 р. в регионах, а крупных городах, таких как Екатеринбург, Санкт-Петербург, Москва, стартует от 130 000 р.

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

• Образование должно быть только высшим (ИТ или технического направления).
• Знание современных методологий, программ, архитектуры ПО — обязательно.
• Широкий кругозор и начитанность в сфере технологий, а также умение применять отдельные элементы к своей системе — необходимый навык.
• Английский — как минимум Intermediate level, что позволяет читать документацию и инструкции к оборудованию на языке оригинала.
• Опыт работы по специальности — от трех лет.

Стоит отметить, что даже для специалиста без опыта работы заработные платы в Москве — от 80 000 р.

Программисту, имеющему немного опыта на платформе 1С 8.3, бывает сложно разобраться: ПередЗаписью, ПриЗаписи, ПослеЗаписи, на сервере, на клиенте, в модуле формы, в модуле объекта. Эта шпаргалка была создана в процессе обучения и реального опыта с целью разложить всё по полочкам, чтобы было четкое понимание в каком случае какой обработчик нужно использовать и в какой последовательности они запускаются при записи и проведении документов. Данная статья будет полезна в большей степени начинающим разработчикам. Но и опытным позволит освежить информацию, упорядочить её.

25.07.2019 106179 AlbinaAAA 47