Системный архитектор — это специалист в области информационных и коммуникационных технологий . Системные архитекторы определяют архитектуру компьютеризированной системы (т. е. системы, состоящей из программного обеспечения и оборудования) для выполнения определенных требований . Такие определения включают: разбиение системы на компоненты, взаимодействие компонентов и интерфейсы (включая взаимодействие со средой, особенно с пользователем), а также технологии и ресурсы, которые будут использоваться при ее проектировании и внедрении.
Работа системного архитектора должна быть направлена на то, чтобы избегать проблем с реализацией и легко разрешать непредвиденные расширения/модификации на будущих этапах. Из-за обширного опыта, необходимого для этого, системный архитектор обычно является очень старшим технологом с существенными, но общими знаниями об оборудовании, программном обеспечении и подобных (пользовательских) системах. Прежде всего, системный архитектор должен быть достаточно осведомлен в области опыта пользователей. Например, архитектор системы воздушного движения должен быть более чем поверхностно знаком со всеми задачами системы воздушного движения, включая задачи всех уровней пользователей.
Должность системного архитектора подразумевает более высокий уровень проектных обязанностей, чем у системного инженера , инженера-программиста или программиста , хотя повседневные виды деятельности могут пересекаться.
Системные архитекторы взаимодействуют с несколькими заинтересованными сторонами в организации, чтобы понять различные уровни требований, домен, жизнеспособные технологии и ожидаемый процесс разработки. Их работа включает определение нескольких альтернатив проектирования и реализации, оценку таких альтернатив на основе всех выявленных ограничений (таких как стоимость, график, пространство, мощность, безопасность, удобство использования, надежность, ремонтопригодность, доступность и другие "иности" ) и выбор наиболее подходящих вариантов для дальнейшего проектирования. Результат такой работы устанавливает основные свойства системы и те, которые сложнее всего изменить в дальнейшем.
В небольших системах архитектура обычно определяется непосредственно разработчиками. Однако в более крупных системах системный архитектор должен быть назначен для описания общей системы и взаимодействия между пользователями, спонсорами и другими заинтересованными сторонами с одной стороны и инженерами с другой. Очень большие, очень сложные системы могут включать несколько архитекторов, в этом случае архитекторы работают вместе, чтобы интегрировать свои подсистемы или аспекты, и подчиняются главному архитектору, ответственному за всю систему. В целом, роль архитектора заключается в том, чтобы выступать в качестве посредника между пользователями и инженерами, согласовывая потребности и требования пользователей с тем, что инженеры определили как выполнимое в рамках заданных (инженерных) ограничений.
При проектировании систем архитекторы (и инженеры) отвечают за:
Архитектура больших систем была разработана как способ управления системами, слишком большими для того, чтобы один человек мог их представить, не говоря уже о проектировании. Системы такого размера быстро становятся нормой, поэтому архитектурные подходы и архитекторы все больше требуются для решения проблем больших и очень больших систем. В целом, все более крупные системы уменьшаются до «человеческих» пропорций с помощью подхода на основе слоев, где каждый слой состоит из ряда индивидуально понятных подслоев — каждый из которых имеет своего главного инженера и/или архитектора. Полный слой на одном уровне будет показан как функциональный «компонент» более высокого слоя (и может полностью исчезнуть на самых высоких слоях).
Архитекторы должны понимать потребности человека и разрабатывать функциональные и эстетически приятные продукты. Хороший архитектор также является главным хранителем видения конечного продукта пользователями и процесса выведения требований из этого видения и его реализации.
Архитекторы не следуют точным процедурам. Они общаются с пользователями/спонсорами в высокоинтерактивной, относительно неформальной манере — вместе они извлекают истинные требования, необходимые для спроектированной (конечной) системы. Архитектор должен постоянно поддерживать связь с конечными пользователями и (главными) системными инженерами. Поэтому архитектор должен быть близко знаком со средой и проблемой пользователей, а также с инженерной средой(ами) вероятных пространств решений.
Спецификация требований пользователя должна быть совместным продуктом пользователей и архитектора: пользователи приносят свои потребности и список пожеланий, архитектор приносит знания о том, что, скорее всего, окажется выполнимым в рамках ограничений по стоимости, времени и другим факторам. Когда потребности пользователей переведены в набор требований высокого уровня, это также лучшее время для написания первой версии приемочного теста , который затем должен быть неукоснительно обновлен в соответствии с требованиями. Таким образом, пользователи будут абсолютно ясно понимать, что они получают. Это также является защитой от непроверяемых требований, недоразумений и расползания требований.
Разработка первого уровня инженерных требований не является чисто аналитическим упражнением и должна также включать как архитектора, так и инженера. Если необходимо пойти на какие-либо компромиссы — чтобы соответствовать ограничениям — архитектор должен гарантировать, что конечный продукт и общий вид и восприятие не будут слишком сильно отличаться от намерений пользователей. Инженер должен сосредоточиться на разработке дизайна, который оптимизирует ограничения, но обеспечивает работоспособный, надежный, расширяемый и устойчивый продукт. Предоставление необходимых услуг пользователям — это истинная функция инженерной системы. Однако, поскольку системы становятся все больше и сложнее, и поскольку их акценты смещаются от простых аппаратных и программных компонентов, узкое применение традиционных принципов разработки систем оказалось недостаточным — применение более общих принципов архитектуры систем, аппаратного обеспечения и программного обеспечения к проектированию (под)систем, как представляется, необходимо. Архитектуру также можно рассматривать как упрощенную модель готового конечного продукта — ее основная функция заключается в определении частей и их взаимоотношений друг с другом, чтобы целое можно было рассматривать как последовательное, полное и правильное представление того, что имелось в виду у пользователей — особенно для интерфейса «компьютер-человек». Она также используется для обеспечения того, чтобы части подходили друг другу и соотносились желаемым образом.
Необходимо различать архитектуру мира пользователей и архитектуру инженерных систем. Первая представляет и решает проблемы и решения в мире пользователей . Она в основном отражена в компьютерно-человеческих интерфейсах (CHI) инженерной системы. Инженерная система представляет инженерные решения — то, как инженер предлагает разрабатывать и/или выбирать и комбинировать компоненты технической инфраструктуры для поддержки CHI. При отсутствии опытного архитектора существует досадная тенденция путать две архитектуры. Но — инженер мыслит в терминах аппаратного и программного обеспечения и пространства технических решений, тогда как пользователи могут мыслить в терминах решения проблемы доставки людей из точки А в точку Б за разумное время и с разумными затратами энергии или предоставления необходимой информации клиентам и персоналу. Ожидается, что системный архитектор будет сочетать знания как архитектуры мира пользователей, так и (всех потенциально полезных) архитектур инженерных систем . Первое — это совместная деятельность с пользователями; второе — это совместная деятельность с инженерами. Продукт представляет собой набор требований высокого уровня, отражающих потребности пользователей, которые могут использоваться инженерами для разработки требований к проектированию систем.
Поскольку требования меняются в ходе проекта, особенно длительного, архитектор необходим до тех пор, пока система не будет принята пользователем: архитектор гарантирует, что все изменения и интерпретации, внесенные в ходе разработки, не повлияют на точку зрения пользователей.
Архитекторы — универсалы. От них не ждут, что они будут экспертами в какой-то одной технологии, но от них ожидают знания многих технологий и способности судить об их применимости в конкретных ситуациях. Они также применяют свои знания в практических ситуациях, но оценивают затраты/выгоды различных решений с использованием разных технологий, например, аппаратное обеспечение против программного обеспечения против ручного управления, и гарантируют, что система в целом работает в соответствии с ожиданиями пользователей.
Многие коммерческие готовые или уже разработанные аппаратные и программные компоненты могут быть выбраны независимо в соответствии с ограничениями, такими как стоимость, отклик, пропускная способность и т. д. В некоторых случаях архитектор уже может собрать конечную систему (почти) без посторонней помощи. Или ему/ей все еще может понадобиться помощь инженера по аппаратному или программному обеспечению для выбора компонентов и проектирования и создания любой специальной целевой функции. Архитекторы (или инженеры) могут также заручиться помощью других специалистов — по безопасности , защите , коммуникациям , специальному оборудованию, графике , человеческому фактору , тестированию и оценке , контролю качества , надежности , ремонтопригодности , доступности , управлению интерфейсами и т. д. Эффективная команда архитекторов систем должна иметь доступ к специалистам в критических специальностях по мере необходимости.
Архитектор, планирующий здание, работает над общим проектом, убеждаясь, что он будет приятен и полезен его обитателям. В то время как одного архитектора может быть достаточно для строительства односемейного дома, может потребоваться много инженеров, кроме того, для решения подробных проблем, которые возникают при проектировании нового высотного здания. Если работа достаточно большая и сложная, части архитектуры могут быть спроектированы как независимые компоненты. То есть, если мы строим жилой комплекс, у нас может быть один архитектор для комплекса и по одному для каждого типа здания в составе архитектурной команды.
Большие системы автоматизации также требуют архитектора и большого инженерного таланта. Если спроектированная система достаточно большая и сложная, системный архитектор может доверить часть работы архитектору оборудования и/или архитектору программного обеспечения, хотя все они могут быть членами совместной архитектурной команды.
Архитектор должен перераспределить системные требования по основным компонентам или подсистемам, которые находятся в сфере компетенции одного инженера по оборудованию или программному обеспечению или инженерного менеджера и команды. Но архитектор никогда не должен рассматриваться как инженерный руководитель. (Если элемент достаточно большой и/или сложный, главный архитектор перераспределит части более специализированным архитекторам.) В идеале каждый такой компонент/подсистема является достаточно автономным объектом, чтобы его можно было протестировать как законченный компонент, отдельно от целого, используя только простой испытательный стенд для предоставления имитируемых входов и записи выходов. То есть, не обязательно знать, как работает система управления воздушным движением, чтобы спроектировать и построить подсистему управления данными для нее. Необходимо только знать ограничения, при которых подсистема, как ожидается, будет работать.
Хороший архитектор гарантирует, что система, какой бы сложной она ни была, построена на относительно простых и «чистых» концепциях для каждой (под)системы или слоя и легко понятна всем, особенно пользователям, без специальной подготовки. Архитектор будет использовать минимум эвристик, чтобы гарантировать, что каждый раздел хорошо определен и очищен от косяков , обходных путей , сокращений или запутанных деталей и исключений. По мере развития потребностей пользователей (после того, как система введена в эксплуатацию и используется) гораздо проще впоследствии развить простую концепцию, чем ту, которая нагружена исключениями, особыми случаями и большим количеством «мелкого шрифта».
Разделение архитектуры на слои важно для поддержания ее достаточно простой на каждом уровне , чтобы она оставалась понятной для одного разума. По мере того, как уровни поднимаются, целые системы на нижних уровнях становятся простыми компонентами на верхних уровнях и могут полностью исчезнуть на самых высоких уровнях.
Приемочный тест является основной обязанностью системного архитектора. Это главное средство, с помощью которого руководитель программы докажет пользователям, что система соответствует изначально запланированному варианту и что все вовлеченные архитекторы и инженеры достигли своих целей.
Архитектор здания использует эскизы, модели и чертежи. Архитектор систем автоматизации (или программного обеспечения или оборудования) должен использовать эскизы, модели и прототипы для обсуждения различных решений и результатов с пользователями, инженерами и другими архитекторами. Ранняя черновая версия руководства пользователя бесценна, особенно в сочетании с прототипом. Тем не менее, важно, чтобы был создан работоспособный, хорошо написанный набор требований или спецификация , которая будет достаточно понятна заказчику (чтобы они могли должным образом подписать его, но основные требования пользователей должны быть зафиксированы в предварительном руководстве пользователя для ясности). Но он должен использовать точный и недвусмысленный язык, чтобы у проектировщиков и других исполнителей не оставалось никаких сомнений относительно значений или намерений. В частности, все требования должны быть проверяемыми , и первоначальный проект плана тестирования должен разрабатываться одновременно с требованиями. Все заинтересованные стороны должны подписать описания приемочных испытаний или эквивалент, как единственный определяющий фактор удовлетворения требований, в начале программы.
Использование любой формы слова «архитектор» регулируется «законами о правах собственности» во многих штатах США, и для его использования человек должен иметь лицензию архитектора-строителя. [1]
В Великобритании Совет по регистрации архитекторов исключает использование термина «архитектор» (при использовании в контексте программного обеспечения и ИТ) из его ограниченного использования. [2]