Пока юные, зеленые и жизнерадостные новички предвкушают полет через тернии к звездам, хмурые CTO и CEO давно познали истину: не всякая хорошая идея реализуема, ибо мир чуточку сложнее. В этой статье мы поговорим про проблемы решений уровня enterprise и с чем их едят.
Чтобы сразу отсечь очевидное, мы не будем рассматривать откровенную фантазию: AI-бот-трейдер с маржинальностью в 100% в месяц, миллиард долларов кэшфлоу через 3 месяца запуска продукта и универсальное центрирование div'ов на JS.
Мы разберем весьма прикладные и распространенные ситуации, в которых мы к тому же разбираемся.
Начнем с двух наиболее болезненных причинах, о которые разбиваются мечты многих PM'ов и заказчиков (хоть внутренних, хоть внешних).
Ресурсы
Денег, времени и людей всегда меньше, чем идей, задач и планов. Особенно тяжко приходится тем командам, которые плотно работают с Legacy-системами (наша вторая причина проблем).
Некоторые, даже казалось бы элементарные вещи, тупо невозможно реализовать как по причине физического отсутствия механизмов, так и по причине высокого риска задеть своими изменениями другие системы и сервисы.
Как-то мы столкнулись с тем, что в одной из команд клиента было невозможно получить данные из сервиса, так как последняя версия документации была десятилетней давности. На решение проблемы понадобилось почти 6 месяцев.
Один из способов снизить влияние фактора ресурсов - оптимизация всего и вся, но у этого всегда есть потолок. Количество часов в сутках одинаковое, а оптимизация требует существенных временных затрат.
Второй вариант – это агрессивный найм. Но как была на рынке труда нехватка в 500 тыс. айтишников, так и осталась. К сожалению или счастью, эта проблема не решается увеличением окладов, ведь проблема не только (и не столько) в количестве, но и ВНЕЗАПНО в качестве.
Третий вариант – найти аутсорс-команду. Это дает возможность в моменте набрать команду и компетенции, однако стоимость за специалиста будет в лучшем случае х1,5.
Legacy
Этим пугают джунов, это проклинают все тимлиды.
От легаси весьма непросто избавиться, а еще сложнее двигаться наравне с конкурентами. Особенно в наше время, когда все чаще появляются молодые компании, которым повезло выстраивать свою архитектуру по более современным принципам.
Особенно остро этот момент обстоит с крупным и, в чуть меньшей степени, средним бизнесом. Например, если ты банк, а у тебя древнющая АБСка (Автоматизированная Банковская Система), то скорее всего на нее подвязано просто тошнотворно большое количество сервисов, так как АБС – центральный элемент любого банка.
А значит, если что-то неаккуратно поменять, то можно все и добросовестно уронить.
Переписать легаси - люто дорого и рискованно.
Есть ли решение?
Ах если бы была такая возможность плавно перейти от легаси к современной и мощной системе, чтобы фича за фичей как пирожки готовились.
Способы есть. Для начала, требуется волевое решение и запас терпения. И помним главное: «Стратегические просчеты тактическими приемами не компенсировать». Иными словами, работать нужно не с последствиями, а с причиной.
Способ раз
Натурально разделить всю легаси на «маленькие кубики» и обновлять по кусочкам. Из хорошего - это относительно безопасный способ с точки зрения целостности системы и влияния на процессы.
По итогу мы получим либо модульный монолит, либо модную и молодежную микросервисную архитектуру.
Из плохого - это очень долго. Натурально может занять несколько лет напряженной и слаженной работы команды. При этом достаточно сложно спрогнозировать, сколько времени займет переход. А значит, это еще и достаточно дорого.
Способ два
Пилить рядышком новую систему. Тоже вполне себе неплохой способ. Из хорошего - абсолютно безопасно по отношению к существующим бизнес-процессам. Но в то же время это и один из главных минусов.
Подобный подход требует точного понимания, как будет выглядеть и функционировать система в конечной версии. А значит, только после окончания всех работ мы сможем протестировать эту систему в боевом режиме.
Это достаточно рискованно в условиях постоянно меняющегося рынка. Может так получиться, что через год-два мир поменяется в очередной раз, а мы получим на выходе непонятно что.
Здесь основной минус в рисках. Неизвестно насколько точно система попадет под потребности, плюс, неизвестно как пройдет процесс замены одной системы на другую.
Способ три - Создаем мидл слой
Что же такое мидл-слой? А это эдакий клей между новым и старым.
Задумка следующая:
- Взять наиболее необходимые готовые компоненты, которые работают в одной связке. Например, MDM, BPM-движок, ECM, IDM, ERP и т.д.
- Добавить некое «окно взаимодействия» (API Gateway), которое позволит старой и новой системе общаться.
- Настроить взаимодействие между системами.
- В новой системе добавляете все фичи, которые так желали, а взаимодействие происходит через API.
- Вуаля. Вы прекрасны, вы обладаете плюсами нового движка, но и не переписываете core-часть.
Как обычно, есть нюансы.
Во-первых, достаточно сложно найти готовые взаимосвязанные компоненты, которые умеют работать как часы.
Во-вторых, как правило все эти компоненты продаются по-отдельности, а значит колонка «Итого» в сумме может посоперничать с бюджетом Молдавии.
В-третьих, готовые решения часто тяжело кастомизируются, а значит, придется много времени и сил потратить на переобучение всей команды: от разработчиков до операционистов.
Что придумала наша команда
Мы достаточно плотно работали с компаниями, в которых проблема перехода в новую реальность стояла достаточно остро. На базе этого опыта мы разработали собственную платформу, которая как раз и нацелена на то, чтобы переход с Legacy осуществлялся максимально комфортно и быстро. Разрабатывали изначально для себя, чтобы быстрее выполнять собственные задачи, но мы быстро поняли, что подобный продукт интересен и другим участникам рынка.
Мы поняли, что самое важное сегодня – уметь быстро и предсказуемо разрабатывать новые сервисы, а значит, нужна платформа, которая позволит упростить жизнь разработчикам.
Мы поставили перед собой задачу создать платформу, с помощью которой команды смогут в конвейерном режиме создавать продукты как для внутренних пользователей, так и для внешних.
Мы назвали ее PoDT - Platform of Digital Transformation (Платформа Цифровой Трансформации).
С чего все начиналось: API Gateway
Первое, с чего мы начали, это тот самый «клей», который позволяет объединить старое и новое.
С помощью API Gateway мы научились связывать как модули нашей платформы, так и внутренние и внешние сервисы компании-клиента. На самом деле, именно с этого модуля и начался наш путь к созданию нашей платформы, так как часто у наших клиентов стояла задача как раз объединить Legacy и новые сервисы.
Эволюция платформы
У больших компаний много данных, которые необходимо правильно «складировать», правильно заполнять и регулярно использовать. Часто встречаются дубли в справочниках, неправильное заполнение полей и атрибутов, битые файлы. Поэтому весьма плавно и логично мы разработали свою MDM (систему по управлению мастер-данными) и ECM (система по управлению документами).
Внедрение только этих модулей в ряде кейсов позволяло сэкономить десятки миллионов рублей в год за счет централизации, дедупликации и нормализации данных. Частный кейс: если раньше составление отчетов по поставщикам могло занять несколько месяцев, то с новым модулем это время сократилось до нескольких недель.
Единая точка входа
Большая компания обретает конкурентное преимущество за счет постоянной оптимизации процессов. Например, внутренние данные компании и доступ к ним – весьма чувствительная тема. Поэтому доступ к каждому сервису обычно под паролем. Так как сервисов может быть достаточно много, то весьма неудобно и затратно постоянно вводить пару логин-пароль. Поэтому опять же весьма естественным образом появилась наша IDMка (система по управлению пользователями и правами доступа).
Модуль позволяет полностью настроить все права и доступы вплоть до отдельных атрибутов справочников системы, ну и разумеется – появляется функция единой точки входа (SSO), а значит, пользователю достаточно ввести пароль к своему ПК или ноутбуку, и он автоматически залогинится во всех необходимых сервисах.
Редактор бизнес-процессов (BPM движок)
Ну и конечно, никакая цифровая трансформация невозможна без инструментов автоматизации бизнес процессов.
Построенный на базе Camunda модуль позволяет выстроить все процессы на визуальном уровне и внедрить все стандарты в производство. Можно задать любую логику взаимодействия и последовательности: как простые ручные задачи, так и сложные иерархичные задачи с вложенными алгоритмами.
Вишенка на торте - единый интерфейс
Еще одна приятная особенность платформы в том, что внутренним пользователям не нужно переключаться между компонентами системы, ведь доступ ко всем модулям проводится через единый интерфейс.
Ускоряйте Time-2-Value и Time-2-Market в своей компании
И это все? Разумеется нет. Возможности платформы намного шире. Мы не даем закрытую экосистему, в которой нельзя ничего менять. Задумка платформы в том, чтобы дать максимальную гибкость командам разработки, избавив их от наиболее рутинных и дорогих разработок, таких как MDM, ECM, BPM – и сконцентрировались на самом важном. А самое важное – это быстро и предсказуемо разрабатывать сервисы, которые приносят дополнительную ценность для компании и ее клиентов.