В работе solution архитектора или системного аналитика есть задачи на проектирование интеграции. Иногда заказчик приносит задачу с требованиями на один абзац. С чего же начать, если перед вами такие минимальные бизнес требования?
В этой статье вы узнаете
что такое модель C4 1 и 2 уровня;
о чек-листе «Проектирование интеграции решения»;
как использовать чек-лист на конкретном примере.
Представим, что ребенок — это заказчик, а мама — это IT‑специалист. Заказчик разбирается в бизнесе и знает, какой результат хочет получить. Но он не погружен в IT‑ландшафт систем банка. Задача ребенка получить строительный кран из множества деталей. Мама помогает ребенку собирать конструктор, подглядывая в инструкцию.
В IT также — архитектор, как мама, помогает заказчику, как ребенку, собирать системы в решение. И тут, в помощь архитектору или аналитику приходит навык рисования.
Я рисую диаграммы модели C4 1 уровня — System context diagram (прим. нотация схемы адаптирована под заказчиков и команды разработки). Эта диаграмма показывает взаимодействия основной системы с окружающим ее IT-ландшафтом.
Выглядит она так:
Давайте я вам расскажу как ее рисовала. Выглядит сложно, но на самом деле с чек-листом все элементарно. Я обкатала чек‑лист на десятках задач.
Чек-лист «Проектирование интеграции решения»
Рисовать буду по такой задаче:
Клиент звонит в контакт-центр (КЦ) банка, чтобы узнать информацию по счету.
Оператор КЦ заходит в приложение «Единое окно КЦ», находит необходимый счет и дает ответ на вопрос клиента.
Простой бизнес процесс, но у заказчика вопросы: а сколько будет стоить разработка, к каким командам нужно сходить?
1️⃣ Определяю сценарии использования (use case)
Use case (в переводе с англ. «вариант использования») — содержит, какие действия выполняет пользователь, и как система должна на них реагировать.
В моей задаче я выделила 2 use case:
Use case #1. Оператор контакт‑центра открывает приложение «Единое окно КЦ» и отвечает на вопрос клиента по счету.
Оператор КЦ ищет карточку клиента.
Оператор КЦ из карточки клиента находит информацию о его счетах.
Оператор КЦ находит информацию по конкретному счету.
Use case #2. Администратор приложения просматривает данные о работе системы при разборе инцидента.
2️⃣ Определяю пользователей (user)
В моей задаче участвуют два вида пользователей:
Оператор КЦ.
Администратор приложения.
Определение пользователей важно, потому что позволяет понять, какие данные могут потребоваться для выполнения use case.
Ура! Появились первые элементы на диаграмме.
3️⃣ Определяю потоки данных
Оператору КЦ нужно видеть информацию о клиенте и данные о его счетах. Администратору необходимы знания, что оператор КЦ делал в системе, чтобы проанализировать почему произошла ошибка. Также будут полезны технические логи работы приложения.
4️⃣ Определяю системы
Данные понятны, теперь занимаюсь поиском места, откуда их можно получить или куда передавать. Эта самая сложная часть задачи, так как здесь требуются знания IT-ландшафта банка, архитектурных паттернов, принятых внутри компании.
На этом шаге могут появиться несколько решений, так как сроки реализации и желание команд не всегда совпадает с потребностями заказчика.
А теперь порисуем и добавим красок нашей диаграмме — легенду.
В легенде есть три цвета:
новое — зеленое;
изменяемое — фиолетовое;
неизменяемое — красное.
Это позволит командам сразу оценивать доработки.
5️⃣ Детализирую диаграмму
А если система огромная и за ее функциональность отвечают несколько команд?
В таком случае я детализирую диаграмму, используя модель С4 2 уровня — Container diagram (прим. нотация схемы адаптирована под заказчиков и команды разработки банка). Эта диаграмма показывает детализацию внутри основной системы — модули (функционально-логические части системы).
Это помогает увеличить точность оценки и привлечь к оценке все команды.
В нашей задаче детализировать требуется приложение «Единое окно КЦ». Нам потребуется создать два новых модуля по клиентам и счетам и доработать основное приложение.
Для отрисовки использую инструмент draw.io.
Что в итоге?
Приходит ко мне заказчик с минимальными бизнес требованиями, я прохожусь по пунктам чек-листа и через пару часов у меня есть первый драфт решения и открытые вопросы к обсуждению.
Диаграмма помогает:
? Оценить стоимость доработки.
А потом идти дальше в детальную проработку внутри каждой изменяемой системы: API, БД и др. Обсуждать десятки страниц текста с заказчиком — трудоемкая задача, а вот картинку понимают лучше.
✅ Выбрать оптимальный вариант решения исходя из контекста.
Я чаще всего показываю несколько вариантов решения, чтобы команда смогла оценить и выбрать подходящее ей. Не бывает одного единственного верного решения, всё зависит от контекста, сроков, ресурсов проекта.
? Сохранить баланс.
Не грузить лишними техническими деталями заказчика и не потерять важные для команды разработки нюансы.
Довольный и радостный заказчик получает свою систему и радуется, как ребенок, которому мама помогла собрать строительный кран из 500 деталей незаметно и аккуратно, да так, что ребенок думает, что он все сделал сам. И архитектор, и команда разработки счастливо наблюдают за работой своего решения в жизни.
А какие способы помогают вам быстро спроектировать архитектуру решения?
