Проектирование интеграции. Чек-лист — как подготовить архитектурное решение

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

В работе solution архитектора или системного аналитика есть задачи на проектирование интеграции. Иногда заказчик приносит задачу с требованиями на один абзац. С чего же начать, если перед вами такие минимальные бизнес требования?

В этой статье вы узнаете
  • что такое модель C4 1 и 2 уровня;

  • о чек-листе «Проектирование интеграции решения»;

  • как использовать чек-лист на конкретном примере.

Представим, что ребенок — это заказчик, а мама — это IT‑специалист.  Заказчик разбирается в бизнесе и знает, какой результат хочет получить. Но он не погружен в IT‑ландшафт систем банка. Задача ребенка получить строительный кран из множества деталей. Мама помогает ребенку собирать конструктор, подглядывая в инструкцию. 

В IT также — архитектор, как мама, помогает заказчику, как ребенку, собирать системы в решение. И тут, в помощь архитектору или аналитику приходит навык рисования.

Я рисую диаграммы модели C4 1 уровня — System context diagram  (прим. нотация схемы адаптирована под заказчиков и команды разработки). Эта диаграмма показывает взаимодействия основной системы с окружающим ее IT-ландшафтом. 

Выглядит она так:

Рисунок 1. Диаграмма модели C4 1 уровня
Рисунок 1. Диаграмма модели C4 1 уровня

Давайте я вам расскажу как ее рисовала. Выглядит сложно, но на самом деле с чек-листом все элементарно. Я обкатала чек‑лист на десятках задач.

Чек-лист «Проектирование интеграции решения»

Рисовать будет по такой задаче:

  • Клиент звонит в контакт-центр (КЦ) банка, чтобы узнать информацию по счету.

  • Оператор КЦ заходит в приложение «Единое окно КЦ», находит необходимый счет и дает ответ на вопрос клиента.

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

1️⃣ Определяю сценарии использования (use case)

Use case (в переводе с англ. «вариант использования») — содержит, какие действия выполняет пользователь, и как система должна на них реагировать.

В моей задаче я выделила 2 use case:

Use case #1. Оператор контакт‑центра открывает приложение «Единое окно КЦ» и отвечает на вопрос клиента по счету.

  1. Оператор КЦ ищет карточку клиента.

  2. Оператор КЦ из карточки клиента находит информацию о его счетах.

  3. Оператор КЦ находит информацию по конкретному счету.

Use case #2. Администратор приложения просматривает данные о работе системы при разборе инцидента.

2️⃣ Определяю пользователей (user)

В моей задаче участвуют два вида пользователей:

  1. Оператор КЦ.

  2. Администратор приложения.

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

Ура! Появились первые элементы на диаграмме.

Рисунок 2. Пользователи. Диаграмма модели C4 1 уровня
Рисунок 2. Пользователи. Диаграмма модели C4 1 уровня

3️⃣ Определяю потоки данных

Оператору КЦ нужно видеть информацию о клиенте и данные о его счетах. Администратору необходимы знания, что оператор КЦ делал в системе, чтобы проанализировать почему произошла ошибка. Также будут полезны технические логи работы приложения.

Рисунок 3. Потоки данных. Диаграмма модели C4 1 уровня
Рисунок 3. Потоки данных. Диаграмма модели C4 1 уровня

4️⃣ Определяю системы

Данные понятны, теперь занимаюсь поиском места, откуда их можно получить или куда передавать. Эта самая сложная часть задачи, так как здесь требуются знания IT-ландшафта банка, архитектурных паттернов, принятых внутри компании. 

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

А теперь порисуем и добавим красок нашей диаграмме — легенду.

В легенде есть три цвета:

  • новое — зеленое;

  • изменяемое — фиолетовое;

  • неизменяемое — красное. 

Это позволит командам сразу оценивать доработки.

Рисунок 4. Диаграмма модели C4 1 уровня
Рисунок 4. Диаграмма модели C4 1 уровня

5️⃣ Детализирую диаграмму

А если система огромная и за ее функциональность отвечают несколько команд? 

В таком случае я детализирую диаграмму, используя модель С4 2 уровня — Container diagram (прим. нотация схемы адаптирована под заказчиков и команды разработки банка). Эта диаграмма показывает детализацию внутри основной системы — модули (функционально-логические части системы).

Это помогает увеличить точность оценки и привлечь к оценке все команды.

В  нашей задаче детализировать требуется приложение «Единое окно КЦ». Нам потребуется создать два новых модуля по клиентам и счетам и доработать основное приложение.

Рисунок 5. Диаграмма модели C4 2 уровня
Рисунок 5. Диаграмма модели C4 2 уровня

Для отрисовки использую инструмент draw.io.

Что в итоге?

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

Диаграмма помогает:

Источник: https://habr.com/ru/companies/alfa/articles/770184/


Интересные статьи

Интересные статьи

«Не понимаю нашего будущего» — если вы слышите такое внутри вашей компании, то, возможно, вам просто необходима стратегическая сессия.По крайней мере такое решение я, как scrum master и Agile coach оп...
Всем привет! С 15 октября по 14 ноября 2021 года в России проходит Всероссийская перепись населения, цифровым партнером которой выступает Ростелеком. Главным нововведением для жителей России станет во...
Как подготовить митап для команды или любой внешней аудитории?Со своими студентами, занимающимися на курсе TeamLead, я часто обсуждаю митапы как инструмент сплочения, мот...
Наша история начинается с твита Томаша Лакомы, в котором он предлагает представить, что такой вопрос встретился вам на собеседовании. Мне кажется, что реакция на такой вопрос на со...
Excel — это чрезвычайно распространённый инструмент для анализа данных. С ним легко научиться работать, есть он практически на каждом компьютере, а тот, кто его освоил, может с его помощью решать...