Я не трачу свое время на рассуждения о высоких концепциях; я трачу свое время на решение инженерных и производственных проблем".

- Илон Маск, главный инженер/конструктор SpaceX

Архитектор решения  / инжиниринг (Solution AEs) отвечают за определение и передачу общего технического и архитектурного видения в проекте для обеспечения соответствия разрабатываемой системы или решения поставленной цели.

Эти специалисты играют важную роль в рамках основной компетенции в сфере поставки корпоративных решений (ESD), обеспечивая согласованность действий многочисленных разработчиков решений в нескольких Agile Release Trains (ARTs) и поставщиков в соответствии с общим техническим направлением. Для этого они сотрудничают с Agile-командами в составе своей группы разработки и с командами в цепочке поставок для разработки решения, проверки технологических предположений, оценки альтернативных вариантов реализации и согласования окончательного результата. 

Solution AEs определяют контекст решения и взаимодействуют с менеджментом решения  для разработки видения решения, дорожной карты решения  и возможностей, необходимых для их реализации. Они также взаимодействуют с менеджментом для согласования ARTs и поставщиков в рамках цепочки решения относительно того, что и как создавать, создавая репозиторий намерений решения. Кроме того, они играют важную роль в мероприятиях, проводимых в процессе подготовки проекта решения, включая предварительное и последующее планирование,  демонстрацию систем и решений, синхронизацию проекта решения, а также семинары по проверке и адаптации (I&A) ARTs и проекта решения. 

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

Подробности 

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

• Количество, размер и сложность компонентов системы 

• Количество пользовательских и стандартных интерфейсов между компонентами 

• Широкое использование заказных киберфизических компонентов и других компонентов с длительным сроком изготовления. 

• Количество внутренних и внешних поставщиков 

• Строгость соблюдения требований и сертификации 

• Широкая организационная поддержка и поддержка цепочки поставок, необходимая для создания и развития этих систем. 

Не для каждого крупного проекта требуется целая цепочка решений.  Действительно, многие решения могут быть построены независимо с помощью одного ART, интегрируя другие коммерческие продукты и продукты с открытым исходным кодом через стандартные интерфейсы и поддерживаемые функцией системного архитектора/инжиниринга (System AE). 

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

Как показано на Рисунке 2, Solution AE выполняют основную задачу по взаимодействию с двумя другими функциями SAFe. Они работают с System AEs для разработки решения, поддерживают усилия по его определению и управлению продуктом. Конечно, даже это является чрезмерным упрощением, так как данная задача взаимодействует со многими другими в рамках процесса разработки решения.

В обязанности Solution AE входят восемь категорий, показанных на рисунке 2 и подробно описанных ниже. 

Проектирование для заказчика и заинтересованных сторон 

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

Это потребует от вас понимания заказчика, а также среды, в которой работает решение: 

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

• Понять и спроектировать контекст решения - Solution AEs рассматривают операционную среду решения, понимая и указывая физические и экологические ограничения и взаимодействие с другими системами, которые существуют в той же среде.

Обеспечение осуществимости и устойчивости 

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

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

• Партнерство с соответствующими поставщиками - Solution AEs знают, какие возможности могут предложить поставщики и как они могут внести свой вклад в общее решение. 

• Создание пайплайна непрерывной доставки (CDP) - Устойчивость требует непрерывной доставки. Solution AEs создают видение CDP решения и обеспечивают архитектуру для его поддержки, включая возможность для команд и ARTs выпускать продукцию по требованию.

Разработка и развитие технологического решения 

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

• Используют модели для описания и визуализации системы - Как ИТ, так и киберфизические системы имеют важные элементы дизайна, ограничения и решения, которые AEs должны донести до команд. Ориентированные на документы подходы к системным спецификациям не могут идти в ногу с частыми изменениями в Agile-разработке. Вместо этого AEs используют моделирование (Model-Based Systems Engineering) для определения, развития и передачи решений. Основные элементы включают: 

• Контекст - определяет область применения системы и взаимодействие с элементами внешней среды. 

• Структура - декомпозиция системы на дискретные компоненты и определение интерфейсов между ними. 

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

• Системные распределения - распределяют ресурсы системы (например, пропускную способность, мощность, вес, пространство) между компонентами. 

• Коммуникации - определяют и передают общие модели взаимодействия между компонентами системы. 

Эти элементы представляют собой часть общей совокупности знаний по системной инженерии. Для получения более подробной информации см. Свод знаний по системной инженерии INCOSE (SE Bok) [1] и многочисленные архитектурные платформы, определенные инженерным сообществом (TOGAF, DoDAF и SysML). 

• Применение цифровой инженерии к киберфизическим системам - По мере развития технологии моделирования цифровая инженерия предоставляет все больше возможностей для ускорения и снижения затрат на обучение посредством анализа и моделирования в виртуальном мире. Эти виртуальные модели, также называемые "цифровыми двойниками", подтверждаются на основе информации, собранной из физической и операционной среды, как показано в контурах обратной связи на рисунке 3. Для создания этой цифровой инженерной среды Solution AEs работают в различных функциональных областях и организационных границах. Они обеспечивают, чтобы системы в производственной и операционной среде предоставляли необходимые данные для развития виртуальных моделей.

• Совместное определение системы - Хорошие технические спецификации требуют глубоких знаний, которыми обладают команды, поставщики, операторы, другие архитекторы, производители и многие другие источники. Вместо того чтобы принимать решения в одиночку, AEs могут проводить совместные семинары по спецификации и проектированию (Рисунок 4). Эти мероприятия объединяют все заинтересованные стороны вокруг конкретной темы, чтобы быстро и эффективно достичь общего понимания и принять решение.

• Декомпозиция решения - Solution AEs осуществляют декомпозицию решения на компоненты, которые снижают когнитивную нагрузку команд и ARTs [2]. Кроме того, при декомпозиции используются существующие решения от внутренних и внешних поставщиков, что ускоряет разработку и снижает затраты. 

• Управление интерфейсами между компонентами - Solution AEs управляют интерфейсами для облегчения независимых итераций проектирования. Интерфейсы применяются как к программному (обычно API), так и к аппаратному обеспечению. Дополнительную информацию об интерфейсах аппаратного обеспечения см. в разделе "Проектирование с учетом изменений" в статье SAFe о разработке аппаратного обеспечения. 

• Определите контекст решения - Solution AEs определяют условия эксплуатации решения, ограничения которых могут включать: 

• Поддерживаемые технологии, интерфейсы и API 

• Требования к упаковке и развертыванию 

• Физические соединения (например, питание, связь) 

• Распределение ресурсов (например, размер, вес, емкость, пропускная способность, тепловой режим и т.д.). 

Как и другие спецификации, контекст решения развивается на основе обучения.

• Обеспечить гибкость реализации - В то время как некоторые требования известны заранее, многие могут меняться по мере появления новых знаний и дальнейшего обсуждения. Чтобы поддержать это, AEs могут использовать диапазоны (например, время зарядки автомобиля в пределах 20-30 минут) в спецификациях системы, которые уточняются и затем фиксируются на основе знаний, полученных по мере того, как команды исследуют альтернативные проекты. Требования также могут быть выражены на "языке намерений", а не на "должностных инструкциях", которые часто ограничивают реализацию. Например, утверждение "Автомобиль должен поддерживать стандарты зарядки SAE J1772 и CHAdeMO" может быть выражено как "Автомобиль может быть заряжен с использованием электрических стандартов во всех выбранных странах" для передачи смысла. 

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

• Управление рисками - Крупным инновационным системам присуща технологическая неопределенность, которую Solution AEs помогают устранить путем управления рисками. Например, они обеспечивают наличие в бэклогах подготовки решений работ по снижению рисков, в ходе которых изучаются альтернативные варианты и проверяются предположения. И они поддерживают команды, которые выполняют эту работу. 

• Участие в организации команды и ART - Solution AEs привносят архитектурные знания при определении потоков ценности и ARTs для создания организационных структур, которые способствуют созданию желаемой архитектуры будущего состояния (закон Конвея [3]).

Управление нефункциональными требованиями и их соблюдением  

Управление требованиями - это сотрудничество между Solution AE и менеджментом решения. Solution AE выполняют следующие обязанности в рамках этого сотрудничества: 

• Определение нефункциональных требований (NFRs) - Solution AE главным образом отвечают за понимание и управление NFRs, которые ограничивают проектирование и реализацию системы. Они документируют их в концепции решения и определяют средства для их устранения. 

• Решение проблем соответствия - Solution AEs работают с командами и ARTs для создания и поддержания объективных доказательств, которые демонстрируют, что решение отвечает всем соответствующим функциональным и нефункциональным требованиям и что процессы разработки соответствуют всем нормативным, отраслевым и другим применимым стандартам.

Определите и расставьте приоритеты в отношении вспомогательных факторов 

Solution AEs сотрудничают с менеджментом решения для определения и установления приоритетов новых работ по исследованию и сокращению технического долга. Они осуществляют это таким образом: 

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

• Введение вспомогательных средств через Kanban решение - Solution AEs ведут работу по обеспечению технической поддержки через Kanban-решение. Они представляют вспомогательные элементы во время расстановки приоритетов и помогают командам и ARTs в их реализации.

Обеспечьте непрерывную доставку 

Практика Lean-Agile требует непрерывной доставки для быстрой обратной связи и корректировки, независимо от масштаба или объема решения. Для достижения этих целей Solution AEs: 

• Создают архитектуру решения для непрерывной доставки - Solution AEs обеспечивают архитектуру системы, содействующую практике непрерывной доставки для ARTs и команд. 

• Содействуют разработке CDP - Solution AEs сотрудничают с Agile-командами и системными командами для определения и создания CDP окружения для различных технологий компонентов решения. 

• Убедитесь, что в бэклогах есть CDP - Solution AEs помогают расставить приоритеты и донести до менеджмента решения, продакт-менеджмента и других заинтересованных сторон ценность инструментов CDP во время подготовки решений и определения приоритетов в бэклоге ART.

Поддержание архитектурной платформы

Архитектурная платформа поддерживает непрерывный поток значений, обеспечивая техническую основу, которая позволяет командам и ARTs быстро и надежно создавать новые функциональные возможности. Чтобы построить такую платформу, Solution AEs: 

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

• Управление архитектурной платформой - Solution AEs сотрудничают с System AEs и командами для определения и создания архитектурной платформы. Они гарантируют, что факторы поддержки определены и расставлены по приоритетам в соответствующей цепочке решений и ART бэклогах .

Управление поставщиками 

Чтобы ускорить доставку и снизить затраты, крупные производители систем часто полагаются на поставщиков, обладающих уникальными возможностями. В SAFe ключевые поставщики ведут себя как ARTs и работают в качестве еще одного потока создания ценности в цепи поставок. Solution AEs имеют следующие обязанности в отношениях с поставщиками: 

• Отслеживание технологий по всему спектру поставщиков - Solution AEs постоянно отслеживают технологические инновации по широкому спектру поставщиков и оценивают их ценность для бизнес-потребностей. 

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

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

Изучите больше

[1] INCOSE Guide to the Systems Engineering Body of Knowledge (Руководство к своду знаний по системной инженерии) (SEBoK) версия 2.2. Май 2020. https://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK) 

[2] Skelton, Mathew, и Manuel Pais. Team Topologies (Топологии команд). IT Revolution Press, 2019. 

[3] Conway’s Law (Закон Конвея). https://en.wikipedia.org/wiki/Conway%27s_law 

[4] Inside Elon Musk’s plan to build one Starship a week (Внутри плана Илона Маска по строительству одного звездолета в неделю ). ARS Technica, 2020. https://arstechnica.com/science/2020/03/inside-elon-musks-plan-to-build-one-starship-a-week-and-settle-mars

Материал подготовлен в рамках курса «Системный аналитик. Advanced».

Всех желающих приглашаем на открытый урок «Трассировка бизнес-целей на пользовательские истории». На занятии разберем принципы Impact Mapping, построим карту, которая позволит разложить бизнес-цели на пользовательские истории и разложим истории на карту пользовательских историй. >> РЕГИСТРАЦИЯ