В нашей компании «распил» монолита уже прошел: у нас есть новый фронт на старом бэке, который осталось «подчистить». «Всего-то» нужно «просто» перевести фронтовую логику на другие сервисы, чтобы для пользователя переход прошёл бесшовно: как привык он работать в системе, так и должен продолжать — без видимых изменений. 

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

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

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

Моё стремление понять, с чем я имею дело и как это понять и подсветить какие-то подводные камни, риски, привело меня в некое эмоциональное состояние — замешательство. Где я ни черта не понимаю, что происходит и решаю просто попробовать начать рисовать. И здесь появляется арт-терапия.

Да, как аналитик, я понимаю, что схема это КРУТО, и есть определённые стандарты стиля. Но, чёрт возьми, когда ни черта непонятно, хочется как-то выгрузиться, разложить всё по полочкам хоть как-нибудь.

В этот момент я начинаю просто рисовать, всё что идёт: образами, схемами, которые приходят через это многомерное системное восприятие, это дает возможность уложить всё на плоскость. Рисунок за рисунком я добавляю акценты, разворачиваю с новой стороны получаемую многослойность и многоуровневость. Сложная задача требует нестандартных, креативных решений, арт-терапия — это классный способ для этого.

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

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

Итак, вся картина системы выглядит так. Но как же непросто было до неё добраться. Попробую рассказать, как я это делала.

Дисклеймер. Моя статья о том, как я распутывала клубок системы с помощью арт-терапии. Ничего особо техничного в статье не будет. Скорее это некий эксперимент акт рефлексии, заметки на полях во время «системокопания».

Распутываем клубок

№1. Сначала я попробовала нарисовать из чего же состоит система сейчас.

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

Здесь на картинке отображено из чего состоит старая система (АЛБО, Альфа-Бизнес Онлайн) и новая (НИБ, Новый Интернет-Банк), и какое у них окружение.

• В старой системе есть некое ядро (платформа), есть часть где описана логика, клиентский и админский интерфейс, публичные сервисы (которыми пользуются другие системы, чтобы получить информацию из БД АЛБО), своя БД АЛБО и отдельная БД Аудита АЛБО.

• Что касается новой — есть веб-версия и мобильная версия, развивается админ-панель. Есть некая идея, что часть системы как отдельный продукт представлен в разных каналах (проходит по всем, как-то идет переиспользование модулей).

Когда появилась система,  появилось некое её окружение, стейкхолдеры — я выдохнула… Стало яснее, видно что есть и куда можно двигаться. 

Теперь более-менее становится видно, что на что меняется, какие могут быть связи и на что стоит обратить внимание далее.

№2. Ключевые фигуры, люди.

Здесь прорисованы.

• Пользователи.

• Бизнес (заказчик).

• Развитие.

• Поддержка.

№3. Дальше я попробовала порассуждать на тему стейкхолдеров, заказчиков, потребителей — кто они, какие они, от чего зависят.

Да, у меня получилось разделение:

• пользователь — это человек с определённой ролью;

• организация — юридическое лицо;

• есть ответственный за данную бизнес-линию, в зависимости от уровня компании;

• ответственный за данный сервис в банке, функционал в системе;

• есть сопровождение (поддержка, первая, вторая линии поддержки);

• разработчики;

• и, конечно же, есть сопутствующие ответственные лица — те кто отвечает за определенные задачи, за клиентов, за конкретную систему, за финансовую безопасность ДКБ, законы, комплаенс, финмониторинг, оперблок и т.д. и т.п.

Человечки сверху — это бизнес-клиенты. Разные цвета — разные категории: корпоративные, средний бизнес и т.п. Заходят они в одну систему, хотя, по факту, у них разные задачи. Синие это пользователи, фиолетовый — бизнес-заказчик, а зеленые — своя линия поддержки. 

Плюс ещё у нас со всем этим фронтовым приложением, которое доступно для пользователей, есть совсем бэковские системы, бэк офис, здесь куча всяких штук и там нарисованы стрелочки, что они куда-то ходят иногда, иногда в АЛБО, иногда в НИБ и куда-то ещё.

№4. Кругом выделено взаимодействие публичных сервисов, с которыми нужно разобраться: нужны ли аналоги, куда выносить, есть ли такой же функционал в НИБ.

Стрелками попытка разграничить потоку — где из АЛБО нужна информация и где для АЛБО нужна информация.

№5. Кто же входит в бизнес (заказчик)? 

В заказчики входят все, кому не лень:

• клиенты;

• законодательные акты ( законы);

• системы;

• финансы;

• безопасность;

• и т.д.

№6. У пользователей могут быть компании разного уровня. С точки зрения функционала им необходим разный функционал. Как это показать?

Запросы малого, среднего и крупного бизнеса отличаются. Получается некая матрешка — чтобы покрыть все запросы, нам нужно сделать максимальную версию Интернет-Банка, а именно, покрыть корпоративный бизнес. Только тогда мы сможем всё отключить.

№7. Если на задачу посмотреть с глазами разработчиков, у нас существует 3 независимые области для разработки: мобильное приложение, новый интернет-банк и АЛБО (старый).

Но они же пересекаются, потому, что где-то единые сервисы, где-то БД одна.  

№8. Если посмотреть на задачу с точки зрения систем, то они стремятся к тому, чтобы старый интернет-банк был отключен, обособлен от интернет-банка и мобильного приложения.

№9. Если смотреть на вопрос с точки зрения саппорта, то приходится заходить в несколько информационных систем.

При этом надо быть специалистами в каждой, чтобы получить информацию для ответа на запрос пользователя. Попробовала отобразить это совмещением «сфер».

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

№10. После того как отрисовала эти схемы, я пробовала отрисовать их снова, но изобразить связи в наших системах, заглянуть с другой стороны.

№11. Здесь верхнеуровнево то, что у нас есть.

№12. Здесь хотелось показать некоторую связь клиентов (компаний) с пользователями и менеджерами, ответственными за развитие бизнес-линии.

№13. Попытка порассуждать, что можно сделать, если всё-таки оставить 2 системы, взаимные редиректы и потоки клиентов.

№14. А как быть с админкой? Что сделать для сотрудников?

№15. Когда общалась с разными командами, в голове нарисовался «граф», по которому можно понять связи продуктов внутри старой и связи с новой системами.

№16. У нас есть такая штука, что в старом Интернет-Банке местами есть редирект на новый.

Но под капотом-то ИБ старый, потому что там сервисы, какая-то логика висит. Знак вопроса — это, собственно, вопрос, должны ли эти стрелочки оставаться?

№17. Эта картинка о том, в чем разница между монолитом и микросервисом, пыталась себе зарисовать. 

№18. Эта картинка о том, что по факту у нас есть старая система (АЛБО), где есть юзерский интерфейс, админский интерфейс, базы данных, с точки зрения БД аудита и БД самого приложения. 

При этом появляются отдельные дополнительные системы, для которых нужно перенести интеграции перенести (грубо говоря, сервисов напилить). Один из вопросов — а кто ходит сюда, а куда ходим мы? Вот здесь пыталась записать системы, которые мы знаем. 

Человечки сверху — пользователи и сотрудники, которым интересно что-то знать про АЛБО: это саппорт, ОДКБ, комплаенс, финмонитеоринг, оперблок. Это люди которые ходят в админку, потребители админки.

Что в итоге и зачем?

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

Отобразите модель, и пусть вас не волнует в этот момент, что «я не художник, так неверно/непонятно». Сейчас вы художник, вы так видите.

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

Одна из важных составляющих системного анализа (аналитика) в работе со сложными многослойными системами — уметь раскладывать их на плоскость и рассматривать под разными углами. В этом помогает визуальный канал восприятия и передачи.

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

Итак:

1. Спроецируйте внутри себя процесс(задачу) как отдельно замкнутую структуру.

2. Прогоните один раз пошагово основной рабочий процесс.

3. На каждом шаге оцените возможные варианты с точки зрения всевозможных рисков, альтернатив, заинтересованных лиц, окружающей среды и влияния.

4. Ещё раз несколько раз внутри прогоните процессы, заглядывая в альтернативы.

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

6. Попробуйте пройтись снизу вверх.

7. Потом сместите вправо или влево основную ось. 

8. Далее попробуйте взглянуть в с разных сторон, не забыв заглянуть во внутрь.

9. Покрутите: слева, справа, спереди, сзади, снизу, сверху, вдали, внутри. 

Используя эту технику можно более обширно рассмотреть процесс(задачу) и найти нюансы, новые решения и варианты развития реальности.

Что же насчет миграции?

О миграции в следующей статье, потому что я сначала пыталась разобраться а откуда куда мигрировать-то? К тому же, в статье будут мои схемы и рисунки, а без контекста они бы были не понятны (как мне кажется). Прочитав эту статью, вам уже будет понятнее, что это за стрелочки и человечки.

На этом всё, спасибо за внимание, надеюсь было полезно.

cРекомендуем почитать [подборка от редактора]

• Как мы ведём требования к ПО: формализация

• Как мы ведём документацию рядом с кодом

• BPMN не в теории, а на практике

• Можно ли стать аналитиком, отучившись в онлайн-школе?

• Мой краткий чек-лист по скилам системного аналитика

• У нас была стратегия и мы её придерживались: как подружить бизнес и DevRel, сохранив ментальное здоровье

• Не принимай оффер в Data Science, пока…

Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.