Привет, я расскажу про наш путь создания low-code платформы-конструктора для разработки сложных Back office систем. Сложными, в данном контексте, называются продукты с базами данных на 500 таблиц и больше, тысячами web-экранов для пользователей, большим кол-вом логики в бизнес процессах, постоянным потоком новых требований и оказанием поддержки сотням клиентов. Платформой-конструктором я называю именно полноценный инструмент для создания новых (!) продуктов с нуля, а не готовый продукт с небольшими возможностями по кастомизации. Я опишу подробно историю создания нашего решения, какие подводные камни мы встретили на своем пути, и какие подходы для нас сработали лучше всего. Статья может оказаться особенно полезной для среды Финтех. 

Часть первая. Предыстория и постановка задачи

Начало

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

Кроме участия в разработке главного продукта компании, я занимался разработкой и внедрением систем как для внутреннего использования, так и различных продуктов для клиентов. Много времени также было посвящено разработке web-клиента, конструктора для моделирования веб экранов и API к системе. Данный опыт позволил мне сформулировать требования к полноценному low-code инструменту для разработки backoffice систем, а так же создать его в будущем. В начале, главной мотивацией послужила постоянная необходимость быстро собирать MVP (Minimum Viable Product) для клиентов, как внутренних, так и внешних. Как обычно, на рынке нет идеального решения под твои задачи, и возникает острое желание максимально быстро собрать MVP самостоятельно, на знакомых тебе технологиях. Задача достаточно банальна - развернуть базу данных, написать где-то логику взаимодействия и создать экраны для просмотра и редактирования данных. Здесь у каждой финтех компании свои наработки. Одни пишут все почти с нуля, другие создают конструкторы, упрощающие процесс. Так получилось, что почти все наши самописные инструменты (которые мы использовали для создания главного продукта компании) оказались идеально применимы для новых MVP и новых продуктов. 

Процесс разработки тогда выглядел так: описываешь структуру базы данных, генерируешь по кнопке скрипты, в специальном редакторе создаешь экраны, линки на другие экраны, таблицы, формы. Пишешь код на PL/SQL под Oracle, создаешь кнопки на экранах, по которым хранимые процедуры в вызываются в базе. Кажется все просто, а потом начинается развитие продукта,  усложнение логики, постоянные сборки, выпуск новых версий и обновление продукта у существующих клиентов. 

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

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

Дело даже не в выборе инструмента (конструктора или платформы) на котором нужно написать продукт под конкретное ТЗ заказчика, а потом сесть на самолет и улететь к морю. Проблема в организации ПРОИЗВОДСТВА сложных продуктов, регулярного выпуска новых версий и установок у сотни клиентов. Об этом все забывают когда говорят, что на рынке уже полно инструментов, чтобы базу создать, API, экраны и прочее. Казалось бы, берешь их - и все готово, однако организация производства IT продуктов - это еще вопрос организации процессов разработки, тестирования, поддержки, кастомизации и прочего, а разрозненные инструменты решают только свои конкретные задачи. Кажется, что тут нет связи - процессы сами по себе, а инструменты сами по себе, однако я столкнулся с рядом обстоятельств, которые сильно влияют на организацию всех процессов и, соответственно, на выбор инструментов. 

Организация производства продуктов

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

1) “Бизнесовые” разработчики

Разработчики - все инженеры, но все они разные инженеры. Речь не про скилы, а про более глобальное разделение - чем ближе к бизнесу, тем меньше могут запрограммировать, хотя и понимают, что нужно. Наоборот, великие системные разработчики - интроверты, и не хотят погружаться в бизнес среду, а могут и вообще напугать заказчика затуманенным взглядом и мыслями об абстракциях. Обычно это решается толстым слоем прокладок из менеджеров: продуктовых, teamlead-ов и прочих. Вокруг этого еще много IT-практик выросло - как и что делать. Плюс к этому еще митинги, созвоны, ретроспективы. Компания больше 30 человек может работой обеспечить себя сама. Мне никогда не нравился неконтролируемо растущий штат переводчиков с одного языка на другой. Большинство компаний к этому приходит, но я предлагаю держаться до последнего. Я хочу чтобы люди, которые ближе к бизнесу, которые могут понять и сформулировать задачу, при желании и небольшом опыте в разработке смогли самостоятельно создавать новые продукты и развивать старые. Это критически важно, чтобы быстро адаптироваться под новые требования и управлять продуктом. 

2) Главная линейка + кастомизации

Если продукт для рынка, а не “запил” под конкретного клиента с одной инсталляцией, придется подумать о кастомизации. Она может произойти: для конкретного клиента перед поставкой, у клиента в момент внедрения или самим клиентом в процессе эксплуатации. Головная боль, конечно, это сведение новых версий продукта с кастомизированными. Нужны механизмы для максимальной автоматизации и “разделения“ ответственности. Чаще всего это касается дополнительных полей, изменений в экранах, поведения функционала. Бывает и что-то более серьезное - создание дополнительных модулей к существующим. Без продуманного подхода к кастомизации IT-компания скатывается в поддержку индивидуальной ветки кода под каждого клиента, что практически сводит к нулю развитие главной линейки продукта. Это очень важный момент, который критически влияет на управление продуктом. 

3) Прозрачность

Для быстрого решения проблем критично время, которое проходит от обращения клиента до попадания задачи на конкретного разработчика. При этом (при сложных конфигурациях продукта у клиентов) часто невозможно быстро воспроизвести проблему локально. Конечно, есть логи, но если у вас много настроек и бизнес логики, конкретный stack trace может не помочь. Нужно привлекать разработчиков, но сперва нужно разобраться хотя бы примерно где ошибка, особенно с учетом многочисленных кастомизаций, которые были произведены для этого клиента, а также его текущей установленной версии. Здесь нужна “прозрачность” решения, декларативное представление продукта и кастомизаций. Если продукт хоть как-то (а чем больше тем лучше) представляется в текстовом виде, удобном для простого сравнения его версий, кастомизаций, структуры экранов, то это на порядки упрощает первую диагностику. В противном случае, если это blackbox из которого “торчат провода”, вы потеряете много ценного времени уже на первом этапе. Автоматические тесты могут не спасти, поскольку кол-во возможных конфигураций (особенно в финтех) обычно сильно превышает возможности базового покрытия решения тестами. 

4) Управление структурой базы данных

Структуру базы данных полезно иметь в декларативном текстовом виде. Это важно для управления версиями, организации автоматического обновления, разделения на модули, кастомизации и, опять же, для повышения прозрачности решения. Кроме того, при описании бизнес логики на каком-либо языке программирования, очень полезно работать с базой через объектное API, которое тоже обычно создается на основании того же описания структуры базы данных. В дополнение к “чистой” структуре базы данных (таблицы, представления, поля, индексы) удобно добавлять дополнительную информацию о доменах полей, но об этом подробно расскажу на примере нашей реализации. В целом, выгодно вообще изолировать базу данных от всех “хранимых процедур” и сделать ее только системой для хранения и быстрого поиска информации, а все остальное вытащить наружу в аппликационный сервер. При таком подходе можно делать линейное масштабирование решения, наращивая аппликационные сервера для тяжелых вычислений. Как следствие, код “бизнес логики” не знает где и как мы храним данные, что позволяет переходить от одной базы данных к другой, а также рассматривать как реляционные, так и не реляционные базы данных. В нашем случае получился “гибридный подход”, поскольку одним из критичных параметров для нас было “время простоя” во время upgrade-а.

5) Модульность и микросервисы

Я не поддерживаю безумную моду на микросервисы всегда и везде, но нельзя не признать, что сегодня наличие микросервисов является чуть ли не критерием качества продукта. Если у тебя не микросервисы - ты сразу неправ, а чем больше микросервисов, тем лучше и надежней продукт. В любом случае, каждый делает как хочет, но есть важная причина “распила” по микросервисам или модулям. И это не “надежность”, которая, с моей точки зрения, не от подхода зависит, а скорее от опыта в разработке. По-настоящему краеугольным камнем является возможность разделения функционала для независимого версионирования и независимой поставки клиенту “по частям”. Причина, прежде всего, это “стресс” клиента при полной переустановке всего решения целиком, особенно если там база данных с 1000-ми таблиц.  У себя внутри-то вы разберетесь, а вот остановка прода - это больно, страшно, и нужно все перетестировать целиком. Поэтому “модульность” (для некоторых это “микросервисность”) это очень важно.  Кроме того, так удобно организовывать лицензии, просто поставляя или не поставляя часть функционала. 

6) Конструктор веб экранов

Я делю веб экраны на 2 типа.

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

Второй тип экранов - это экраны для сотрудников, которым нужно смотреть на большое кол-во данных. По сути это рабочие места (дашборды), с кучей данных, кнопок и функционала, который еще и постоянно меняется и дополняется. Экранов первого типа - обычно 10-ки, а второго типа 1000-и. Сюда же, ко второму типу, относятся все экраны с настройками и просмотром сырых данных для администрирования. Экраны второго типа обычно очень стандартизованы и строятся по определенным правилам из ограниченного набора компонентов. Поскольку таких экранов много, а функционал постоянно развивается, нужен конструктор экранов, который избавил бы разработчиков от верстки и позволил быстро набрасывать компоненты и создавать экраны. Также немаловажно, чтобы редактор умел сериализовывать экран в какой-либо структурированный формат (типа json/xml/yaml) для последующего текстового сравнения различных версий одного и того же экрана, а также для массовых текстовых замен, что тоже иногда очень нужно. Наличие редактора экранов является сильным конкурентным преимуществом и позволяет кастомизировать функционал на стороне клиента.

7) Быстрый старт и low-code разработка

Данный пункт отчасти вытекает из предыдущих, но важно просуммировать и сделать акцент. Для эффективной разработки важна максимальная автоматизация технических аспектов и простота, стройность подхода. Сложности хватит при описании бизнес логики и построении архитектуры базы, но из этой сложности нужно убрать всю техническую рутину. По-настоящему “страшны” миксы “техники” и “логики” где все вперемешку, и требуются уникальные универсальные люди. Это критически повышает зависимость от разработчиков и усложняет развитие, масштабирование, поддержку, тестирование, да вообще все процессы, касающееся жизненного цикла продукта. Нужно обеспечить максимально быстрый вход для новых сотрудников и сделать так, чтобы ни у кого не более голова о том, как собирать решение, работать с базой, создавать API, конструировать экраны, кастомизировать, устанавливать у клиентов и так далее. Иначе говоря, предоставить возможность сосредоточиться на решении бизнес задачи, создании продукта и не потеряться в технических деталях. При этом никто не говорит, что любой человек с улицы сможет вам собрать продукт. Нужно абстрактное мышление, чтобы выделить из требований клиента “бизнес объекты”, придумать как лучше хранить их в базе данных, какие индексы создать, придумать как построить экраны: что пользователь должен увидеть сразу, что по линкам в дополнительных формах и многое другое. Конечно, нужен опыт, но опыт скорее аналитический, архитектурный. Важна независимость от Back и Front разработчиков, от DevOps. Нужно чтобы “бизнес”-разработчики смогли самостоятельно собирать и поддерживать продукты. Конечно, потом это обрастет и красивыми нестандартными экранами (экраны первого типа), и DevOps подключится и для интеграций еще кто-то из бородатых программистов, но важно, чтобы ядро с основным функционалом было понятно и “просто” устроено. 

8) Быстрый MVP и минимальный TTM (Time To Market)

Одним из критериев успеха “конструктора” для меня является время до MVP. Не секрет, что не все проекты одинаково успешны, и вопрос: “сколько пройдет времени до первого показа клиенту?” очень важен. Более того, часто заказчик вообще не “вписывается” в проект, пока не увидит хоть что-то похожее на решение его задачи. Конечно, у всех разработчиков есть “какая-то тактика”: показать другие продукты, сказать: “вот так же, только лучше”, нарисовать картинок с анимацией, загипнотизировать харизмой (мы и не такое делали), тут кто как умеет, для старта может и “прокатит”, но потом будет тяжело. Проблема обычно не в IT компании, а в клиенте, который не может поставить ТЗ без чего-то уже работающего. В теории все понимают, что нужно все хорошо расписать, все продумать, но на практике всегда не так. На эту тему миллиарды теорий, как все сделать правильно, но всегда сроки, конкурсы, всегда все заняты, и времени никогда нет. Более того, действительно трудно все продумать до мелочей, если не представляешь как оно будет выглядеть. Поэтому, ТЗ будет всегда уточняться в процессе работы, и это предмет торговли при подписании актов приемки, даже если они неформальные. Можно жить в своем мире и считать, что этого нет (а для некоторых и нет, если их закрывают люди, которые разгребают эти проблемы), но я считаю, что эту “пьянку” важнее суметь возглавить. Если вы постоянно во время всего процесса разработки показываете опережающие прототипы новых этапов, то и у клиента будет время подсобраться и решить как правильно, и у вас будет время просуммировать изменения в ТЗ и направить продукт в нужное русло. Для работы в таком режиме у вас должен быть инструмент, который позволяет быстро изменять/дополнять структуру базы и создавать экраны, которые на 80% будут похожи на финальные. Это предоставит клиенту возможность придумать, что же именно он хочет. Можно фотографировать это в виде требований, рисовать маркером изменения и вместе обсуждать как удобней для работы. Данная “управляемость” продуктом позволит осуществить максимально быстрый выход на рынок и существенно сократит время доработки напильником на последнем этапе.

9) Установка (развертывание) решений

Разделю на две части: 

Первая часть - Этап разработки продукта. Здесь критична быстрота сборки и установки новой версии для проверки. Сколько времени проходит от изменений в структуре базы (в файлах с описанием структуры) до сборки версии и начала программирования логики, а также до установки новой версии на стенд. Если для работы нужно постоянно запускать кучу генераторов кода, других утилит, что-то куда-то перекладывающих и конфигурирующих по пути, то это будет сильно мешать разработчикам. Для “бизнес”-разработчиков это может оказаться убийственно сложно. По сути, нужно две кнопки: первая - применить изменения в структуре для начала кодирования бизнес логики, вторая - установить на стенд для проверки и моделирования экранов. Это должно быть действительно быстро, потому что эти действия будут производится миллионы раз.

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

10) Общая философия

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

Постановка задачи

Я очень люблю выражение "чтобы забить гол нужно бить по воротам", поэтому соберу краткое резюме того, что я хочу получить в итоге. 

Главная задача: предложить Low-Code инструмент для создания продуктов в среде Финтех, Страховании, систем различного учета, различных Back office решений, систем интеграций и прочих. 

Цели инструмента: создание и развитие новых продуктов, построение производства "семейства" продуктов, на базе одного фундамента. К примеру вы компания, которая как "SAP" или "1С" собирается выпускать много продуктов на одной платформе и предлагать их кастомизацию другим участникам рынка.

Требования к "сложности" продуктов: сотни, тысячи таблиц в базе данных и пользовательских веб-экранов, много логики в бизнес процессах, а также тысячи пользователей.

Особенности разработки: Быстрое прототипирование (MVP), выпуск версий и выход на рынок (TTM). Концентрация на разработке бизнес-логики, полностью автоматизированная техническая рутина. Простая замена и подключение новых разработчиков. Прозрачность функционала для контроля качества, внедрения и поддержки. Модульность. Независимость от базы данных. Масштабирование на уровне сервера приложений.

Продолжение следует...

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

Директор по развитию ООО "Дольмен", telegram: @fintechbrother 

Олег Асламов

Директор по развитию ООО "Дольмен", telegram: @fintechbrother