Вопросы на собеседовании: Корпоративный архитектор

Solutions-архитектор отвечает за проектирование оформления заказа, а enterprise-архитектор задаёт направление для всей организации.

• Solutions-архитектор определяет компоненты, API, потоки данных, схему развёртывания и NFR для этого ограниченного решения.
• Enterprise-архитектор связывает оформление заказа с бизнес-способностями и проверяет соответствие общему направлению по идентификации, платежам, данным и облаку.
• Выбор PostgreSQL для одного сервиса может остаться локальным, но появление второго мастер-источника клиентов затрагивает несколько систем и требует рассмотрения на корпоративном уровне.
• На junior-уровне я отвечал бы за артефакты решения и поднимал кросс-доменные последствия, а не заявлял полномочия на весь портфель.

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

• Я бы описал три формата ID, пути синхронизации, владельцев данных и сбой портала из-за несовпадающих записей.
• Для портала можно спроектировать адаптер за стабильным API поиска клиента, чтобы не блокировать поставку.
• Я бы не объявлял базу портала новым мастер-источником клиентов, потому что это меняет ответственность трёх существующих приложений.
• Я бы передал факты и варианты enterprise- или data-архитектору, а временный адаптер зафиксировал как риск и ADR.

Я бы сначала превратил результат в небольшую цепочку способностей и только потом выбирал приложения.

• Нужны способности идентификации клиента, конфигурации продукта, ценообразования, согласования скидки, формирования и доставки предложения.
• Я бы отметил ценообразование и согласование как слабые места, если продажи ждут таблицы и письмо руководителя, а затем подтвердил это у двух менеджеров.
• Цель в два часа становится измеримым результатом всей цепочки, а не утверждением, что каждому шагу нужна новая система.
• Только после согласования карты я бы связал способности с CRM, системой цен, генератором документов и уведомлениями.

Я бы заменил прилагательные измеримыми сценариями, которые команда может проверить.

• Производительность может означать задержку API страницы на уровне p95 менее 800 мс при 200 одновременных пользователях в пик в 9 утра.
• Доступность может означать 99,9% за календарный месяц с явно включённым или исключённым плановым обслуживанием.
• Надёжность может включать менее 1 неудачной загрузки документа на 10 000 попыток и безопасный повтор без дубликатов.
• Я бы подтвердил числа с продуктом и эксплуатацией, потому что доступность 99,99% дороже 99,9% и может не соответствовать ценности портала.

Я бы поддерживал короткую цепочку от бизнес-результата до артефактов дизайна и проверки.

• Связать цель в четыре часа с требованиями онлайн-подачи документов, автоматической проверки налоговых данных и одношагового согласования сумм до $10 000.
• Сопоставить требования со способностями подключения поставщиков, проверки соответствия и согласования.
• Связать каждую способность с контейнером портала, API валидации, сервисом workflow и системой-источником, которые её реализуют.
• Добавить критерий, например завершение 90% полных заявок за четыре часа, чтобы оспорить элемент дизайна, не поддерживающий ни одного требования.

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

• Провести интервью с оператором заказов, инженером поддержки и владельцем одного приложения, затем наблюдать один обычный и один неудачный заказ.
• Создать инвентарь четырёх систем с владельцем, назначением, жизненным циклом, данными, хостингом, критичностью и статусом поддержки.
• Нарисовать C4 context- или container-view с пользователями, приложениями, протоколами, ночным CSV и двумя синхронными API-зависимостями.
• Зафиксировать базовые факты: 1 200 заказов в день, задержка остатков в 24 часа и 3% ручных исправлений, явно отметив неизвестное.

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

• Показать складскую систему как мастер-систему для остатков, витрину как потребителя и назвать владельцев обеих сторон.
• Выбрать событие или инкрементальный API-поток, который доставляет принятые изменения за пять минут, и определить повторы и сверку.
• Включить целевые NFR, например доступность пути обновлений 99,9% и RPO 15 минут для состояния интеграции.
• Отметить переходные ограничения, например сохранение ночного файла на 30 дней для сверки перед отключением.

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

• Процесс: отмечу последовательные передачи и ожидания от согласования найма до готовности сотрудника, затем сравню их с целью, где HR параллельно запускает работу команд учётных записей и административной службы.
• Данные: сравню повторный ввод имени, даты начала, локации, роли и потребностей в оборудовании с одной утверждённой записью онбординга, выявив недостающие источники, правила полей и передачи.
• Ответственность: заменю разрозненное владение очередями владельцем кейса в HR и назначенными владельцами в командах учётных записей и административной службы с внутренним сроком 1 день, RACI и путём эскалации.
• Автоматизация и переход: заменю email и ручную проверку статуса триггерами workflow, общим статусом и оповещениями о просрочке, затем проведу пилот на 20 сотрудниках и расширю запуск только когда не менее 90% завершаются за 2 дня при доле исправлений данных ниже 2%.

Я бы использовал ADM как итеративный путь от рамок работы к управляемому изменению, адаптируя артефакты к небольшой платформе.

• Preliminary и Phase A определяют метод, стейкхолдеров, охват, ограничения, Architecture Vision и разрешение продолжать.
• Phases B, C и D описывают исходную и целевую бизнес-, data-, application- и technology-архитектуру вместе с разрывами.
• Phases E и F группируют work packages, сравнивают переходные варианты и создают план реализации и миграции.
• Phases G и H контролируют поставку и последующие изменения, а Requirements Management сохраняет связь решений с требованиями на всём пути.

Preliminary задаёт порядок архитектурной работы, а Phase A согласует результат конкретной инициативы.

• Preliminary может определить облегчённый метод, нотацию моделирования, репозиторий, роли принятия решений и принципы вроде API-first интеграции.
• Phase A выявляет стейкхолдеров склада, клиентского сервиса, финансов, безопасности и продукта вместе с их интересами и вопросами.
• Architecture Vision показывает текущую проблему, целевую концепцию, ожидаемое сокращение срока с пяти дней до двух, охват и исключения.
• Statement of Architecture Work фиксирует результаты, даты, предположения, ограничения и согласование перехода к следующим фазам.

Phase B должна описать исходную и целевую бизнес-архитектуру и выявить бизнес-разрывы.

• Исходные артефакты могут показать value stream от принятия оффера до готового к работе сотрудника с семью ручными передачами и сроком пять дней.
• Карта способностей может отметить выдачу учётных записей и оборудования как слабые способности.
• Целевой процесс может назначить HR владельцем кейса и параллельно запускать работу IT и административной службы с целью завершить её до первого дня.
• Список разрывов должен назвать отсутствие владельца workflow, разные правила согласования и невидимый статус, пока не выбирая облачные продукты.

Phase C должна определить целевую архитектуру данных и приложений, необходимую для прекращения копирования.

• Представление данных называет сущности клиента, контакта и тикета, CRM как мастер-систему для данных клиента и бизнес-владельца данных.
• Представление приложений закрепляет управление клиентами за CRM, а управление обращениями за системой тикетов, не дублируя обе роли.
• Целевая интеграция предоставляет контракт поиска клиента и передаёт customer_id в тикеты вместо копирования 18 полей профиля.
• Разрывы между исходным и целевым состоянием включают дубли данных, отсутствие стабильного ID, недостающий API и очистку до переключения.

Phase D определяет технологическую архитектуру, поддерживающую приложение и его цели качества.

• Исходное состояние может состоять из одной виртуальной машины и одной базы в одной зоне, что создаёт две единые точки отказа.
• Целевое состояние может разместить stateless веб-инстансы за балансировщиком в двух AZ и использовать managed multi-AZ базу данных.
• Технологические стандарты задают поддерживаемый runtime, сегментацию сети, шифрование, мониторинг, резервное копирование и Terraform-модули.
• Список разрывов определяет ресурсы второй зоны, health checks, failover базы и тест восстановления, необходимые для цели.

Phase E формирует жизнеспособные переходные варианты, а Phase F превращает выбранный вариант в последовательный план миграции.

• Phase E группирует работу в контракт API, изменение источника, изменение потребителя, мониторинг и отключение файла.
• Она может сравнить прямое переключение с 30 днями параллельной работы API и файла по стоимости, риску и бизнес-ценности.
• Phase F выстраивает зависимости, назначает владельцев и даты и ставит contract testing до переключения потребителя.
• План миграции содержит вехи вроде 95% паритета API к шестой неделе, критерии отката и отключение файла после двух чистых сверок.

Phase G проверяет соответствие реализации, Phase H управляет последующими изменениями архитектуры, а Requirements Management сохраняет трассируемость в обеих.

• В Phase G проверить развёрнутый API по утверждённому контракту, security-контролям, цели latency 500 мс и записанным ADR.
• Существенное отклонение, например незашифрованный резервный файл, зафиксировать с владельцем, сроком исправления и принятым риском, а не молча менять цель.
• В Phase H оценить новый прогноз партнёрского объёма и решить, достаточно ли малого обновления архитектуры или нужен новый цикл ADM.
• Requirements Management связывает прогноз и изменения NFR с затронутыми дизайнами, work packages, тестами и согласованиями.

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

• Business-слой может показать актора Customer, процесс Handle Return и бизнес-сервис Return Management.
• Application-слой может показать компоненты Returns Portal и Order Service и application service Return Eligibility.
• Technology-слой может показать узлы Kubernetes, system software PostgreSQL и технологический сервис сообщений.
• Связи между слоями позволяют проследить клиентский сервис возвратов до приложений и runtime, от которых он зависит.

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

• Использовать serving от application service Return Eligibility к бизнес-процессу Handle Return, потому что сервис поддерживает это поведение.
• Использовать realization от application function Return Eligibility к application service, потому что поведение реализует внешний сервис.
• Использовать access от поведения приложения к data object Order с отметкой read-only, если эта деталь нужна представлению.
• Использовать assignment от компонента Returns Application к этой функции, чтобы показать, какая активная структура выполняет поведение.

Я бы создал два сфокусированных представления из одной модели, потому что стейкхолдеров волнуют разные вопросы.

• Product-view показывает клиентских акторов, value stream возвратов, бизнес-сервисы, ключевые способности и поддерживающие приложения.
• Platform-view показывает компоненты приложений, технологические сервисы, узлы, сети и deployment-зависимости в двух AZ.
• Оба представления сохраняют общие идентификаторы элементов, поэтому Returns Portal означает один компонент в обоих.
• Я бы убрал низкоуровневую инфраструктуру из product-view и детали бизнес-мотивации из platform-view, чтобы обсуждение оставалось понятным.

Я бы провёл измеримую цель через бизнес-поведение к поддержке приложениями и технологиями.

• Связать цель в десять минут и её требование с бизнес-процессом Refund Approval и бизнес-сервисом Refund Management.
• Показать Customer Service Agent, назначенного на процесс, и необходимую бизнесу способность Refund Approval.
• Показать application service Refund Workflow, обслуживающий бизнес-процесс, application function, реализующую этот сервис, и компонент Refund Workflow, назначенный на функцию.
• Показать доступ функции к данным Refund Case и проследить компонент через его artifact и deployment node, сохранив видимость операционной зависимости.

Я выбираю самый низкий уровень, необходимый для вопроса review, и не показываю все уровни по умолчанию.

• Context-диаграмма нужна для согласования границы системы, пользователей и внешних систем с бизнесом и безопасностью.
• Container-диаграмма нужна для обсуждения развёртываемых или исполняемых единиц, хранилищ, протоколов и владельцев с командой поставки.
• Component-диаграмма нужна только когда внутренние обязанности одного контейнера неясны или рискованны.
• Для 30-минутного kickoff я бы начал с context и одного container-view, а затем при необходимости добавил component-view сложного интеграционного сервиса.