«Всё пройдет». Но Low-code останется

Елена Александрова, глава отделения собственных платформ IBS, – об эффективности и целесообразности использования Low-code «конструкторов», критериях их выбора и перспективах развития (это тип движения и изменения в природе и обществе, связанный с переходом от одного качества, состояния к другому, от старого к новому).

Когда оправдан выбор перронов Low-code? Действительно ли они позволяют экономить? И в чем причина роста их популярности? Об этом, и не только, мы поговорили с Еленой Александровой, руководителем отделения собственных перронов IBS, отвечающей за развитие Low-code платформы и продуктовой линейки «Планета». Более подробно ее выступление можно будет услышать 2 декабря на конференции «LOW-CODE 2021», организуемой издательством «Отворённые системы». Особое внимание будет уделено практическим аспектам подхода Low-code, оценке эффективности и целесообразности использования соответствующих «конструкторов» для решения задач различного типа.

— Считается, что без демократизации процесса разработки цифровая трансформация компаний будет практически невозможной. Есть ли с этой точки зрения у перронов Low-code/No-code какая-то альтернатива?

Альтернатива есть всегда. Демократизация процесса разработки может достигаться, например, за счет стандартизации вкупе с использованием стилей высокого уровня типа Python. Но, конечно, философия Low-code/No-code выглядит в этом смысле наиболее перспективно.

— В каких направлениях Low-code сейчас наиболее жив? Где можно ожидать роста его популярности в обозримом будущем, а куда он не доберется?

Мы видим рост популярности подхода Low-code в первую очередь в корпоративном сегменте. Но, вероятно, это связано с тем, что IBS работает на рынке крупнейших российских компаний. Как бы там ни было, у роста популярности Low-code/No-code есть вполне объективные причины. Во-первых, почти все крупные холдинги имеют собственный большой штат квалифицированных разработчиков и уже не боятся использовать конструкторы для создания корпоративной экосистемы. Во-вторых, скорость изменений внешних и внутренних процессов любой компании давным-давно на порядок выше возможностей самой квалифицированной команды разработчиков. Ну и в-третьих, конечно, сказывается мучительный опыт внедрения готовых ИТ-продуктов, когда еще до ввода в индустриальную эксплуатацию и заказчику, и интегратору понятно, что 40% функциональности продукта просто не нужно, а то, что действительно необходимо, вендором не предусмотрено.

— Как вы считаете, вообще Low-code – это навек, или это промежуточное звено в развитии ИТ-платформ?

Как было написано на кольце царя Соломона, «всё пройдет, и это тоже пройдет». Но если измерять ход поре не веками, а хотя бы десятилетиями, стоит отметить, что концепция Low-code родилась задолго до программирования и вычислительной техники. Мы с детства пытаемся складывать мир из кубиков, LEGO, паззлов, а после строим дома, заводы и бизнесы. Сначала ребенок радуется, что из одних и тех же деталей можно построить дом и железную дорогу, а потом становится программистом и продолжает строить цифровой мир. Природное жажда человека систематизировать подход к работе, ввести стандарты, в сочетании с потребностью в творчестве делает идею «конструкторов» такой привлекательной, что она представляется безальтернативной. Вопрос только в степени сложности и целевой аудитории конкретного конструктора.

Наверное, можно сказать, что идея Low-code/No-code останется навеки, но вполне возможно, что называться она будет как-то иначе.

— Способен ли Low-code стать стандартом систем автоматизации?

Поскольку это подход, а не конкретная технология, то и о стандарте сообщать сложно. Сейчас тоже есть специалисты по программированию микроконтроллеров на Ассемблере, но большинство разработчиков все-таки пишут на Java, C++, .Net с использованием огромного числа библиотек. Я думаю, что Low-сode уже сейчас во многом стал такой же естественной частью процесса разработки, как и остальная инфраструктура.

— Какова стратегия IBS на этом базаре?

Мы развиваем собственную платформу «Планета» уже несколько лет. Ее сервисы и компоненты используются как в No-сode продуктах на базе этой перроны, так и в проектах заказной разработки. Коммерциализация платформы происходит через конкретные продукты, собранные на инструментах (технологическая оснастка, которая воздействует на предметы труда и изменяет их, предмет, орудие для производства каких-нибудь работ. . В основе конструкции и правил использования инструмента лежит) платформы, например, «Планета. Аналитика», «Планета. НСИ», «Планета. Сервер» и т. д. Это No-code инструменты корпоративного степени, созданные на Low-code платформе «Планета». Все действия пользователь этих продуктов делает в рамках конструктора, без необходимости программирования. Другой путь коммерциализации – в процессе разработки решения для конечного заказчика в качестве инфраструктуры используются технологические инструменты нашей платформы. Это позволяет существенно повысить качество и скорость реализации проектов.

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

Когда мы сообщаем об экономике цифровых платформ, в частности Low-code/No-code, ответ на вопрос об экономии ничем не отличается от ответа на аналогичный вопрос для классических ИТ-продуктов. Это итого лишь инструмент, и он может как принести измеримую и ощутимую экономию, так и нанести серьезный ущерб.

На мой взгляд, No-code экономически выгоден в проектах, связанных с скоро изменяющимися, но типовыми процессами в крупных и средних компаниях. Например, в каждой организации есть свой процесс мониторинга и анализа данных, собственный набор источников этих данных, а ключевые показатели эффективности могут быстро меняться в зависимости от ситуации на рынке, нормативной базы и даже экологических предпочтений конкретного региона. Платформенный подход в этом случае точно позволит компании сэкономить не только за счет актуальной аналитики, но и на этапе эксплуатации системы. На практике почти в каждой компании кушать BI-продукты «на полке», поскольку задачи, которые ставились перед ними на момент покупки и внедрения, давно потеряли актуальность. В этом случае гибкость Low-code/No-code приносит вполне очевидную выгоду.

— На что необходимо обращать внимание при выборе конкретного инструмента? Какими могут быть стоп-факторы?

Это интересный и непростой вопрос. Классический подход к выбору ИТ-продуктов предполагает долгий список вопросов, на которые должен себе ответить покупатель. Основная часть вопросов касается функциональности продукта, его эксплуатационных характеристик, лицензионной политики и технической поддержки. Мне представляется, что в случае продуктов Low-code/No-code подход к выбору должен быть другим.

При выборе платформы, с которой организации придется жить ближайшие годы, я бы прежде всего обращала внимание на финансовую устойчивость, спектр компетенций и опыт вендора. Развитие собственной платформы – положительный инвестиционный проект, это дорого. Надо быть уверенным хотя бы на два-три года вперед, что развитие платформы не придется сворачивать, как бы ни развивались события на базаре. То есть наличие выделенного финансирования, команды развития платформы, подразделения R&D, детализированной дорожной карты работ и видения на годы вперед являются значительным позитивным сигналом для заказчика.

Второй важный блок вопросов связан с тем, что при выборе (предпочтение одних вариантов множеству других) инструмента никто не может заранее сказать, как изменятся бизнес-задачи заказчика, какие компетенции и в какой районы потребуются, например, через год или два. При выборе классического ИТ-продукта мы по сути выбираем инструмент решения сегодняшних задач и часто забываем, что сам этот инструмент был создан годы назад, а спроектирован еще ранее. Конечно, он не может учитывать все те изменения, которые уже произошли. Для Low-code/No-code этот вопрос решается гораздо легче благодаря максимальной гибкости инструментария. Но грядущие задачи по-прежнему находятся в зоне неопределенности. Справится ли платформа с будущими вызовами? Есть ли у ее вендора достаточно компетенций в смежных с разработкой районах? Может ли вендор выступить в роли ИТ-партнера заказчика, принимая на себя ответственность за качество и эффективность работы сервисов?

— В чем особенности аналитического Low-code, каким является ваша «Планета» (по сравнению, например, с ВРМ, RPA и другими инструментами)? Какие это накладывает требования на неё?

«Планета» подлинно начала свое развитие в статусе платформы, отталкиваясь от BI-инструментария. Так сложилось исторически – надо же с чего-то начать, и в нашем случае это очутился BI. Думаю, что мы совсем не уникальны в этом смысле. Все платформы Low-code/No-code начинали с решения задач какого-то одного типа и потом расширяли функциональность, исподволь стирая границы между RPA, CRM, BI, BPM. В результате получается довольно интересная картина.

Для аналитических задач характерны высокие требования к возможностям платформы по визуализации и интеграции этих. Даже решая задачи в рамках бизнес-аналитики, заказчики, тем не менее, ожидают увидеть возможности BI, BPM, MDM и веб-дизайна в рамках одной платформы (может означать: Железнодорожная платформа: Платформа — возвышенная площадка, помост для посадки пассажиров в вагоны, для нагрузки и выгрузки товаров).

— Вы позиционируете свою перрон в том числе для госсектора. Но подход Low-code – это в чистом виде компромисс. Насколько такой компромисс возможен в госсекторе?

Мы действительно много трудимся с государственными структурами. В последнее время и без того серьезные требования к качеству и функциональности решений возросли. Компромисс в этой части вряд ли вероятен.

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

— По озвученной на одной из наших конференций статистике, из трех разработчиков Low-code лишь один является «натуральным» бизнес-пользователем, а двое фактически «айтишники» – то есть без ИТ-бэкграунда пока обойтись проблематично. Что необходимо делать, чтобы ситуация изменилась?

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

На практике я вижу два встречных процесса: экономисты и менеджеры становятся «техногиками», а многие «техногики» обучаются думать в терминах бизнес-логики. У нас в команде разработчиков есть экономисты, менеджеры и даже психологи по первому образованию! А если «хорошенько потереть» немало менеджеров, то обнаружится бывший разработчик. Если эта тенденция продолжится, то особой проблемы с кадрами для индустрии Low-code/No-code быть не должно.

Тем не немного, мы, как и все на ИТ-рынке, сталкиваемся с проблемой кадрового дефицита и решаем ее с помощью программ обучения. У нас постоянно запускаются серьезные стажерские программы для молодых специалистов, кушать корпоративный университет и программы обучения для руководителей. Мне очень нравится в этом смысле подход IBS к развитию специалистов: поощряется любое развитие, не лишь в той области, где сотрудник работает, – было бы желание развиваться и природное любопытство.

Источник