Вводная
Уже прошло несколько десятилетий под эгидой развития IT технологий, но мы по-прежнему повсеместно сталкиваемся с косяками в IT системах, например: в продуктовом магазине на кассе не смогли пробить товар; в отделении почты не удалось отправить посылку; в интернет-магазине не работает форма онлайн-оплаты; в пиццерии не удается оформить онлайн-заказ и т. д.
К огромному счастью, эпоха таких проблем потихоньку близится к своему закату, и огромную роль в этом играет именно технология роботизации RPA, которую стало возможно рассматривать как основу всей IT инфраструктуры компании, с того момента, когда появилась pyOpenRPA.
Задумываетесь об этом?
-
IT задачу делают очень долго/дорого/косячно.
-
По итогу реализации не получаете ожидаемый бизнес-эффект.
-
Содержите огромный штат IT персонала.
Слышите такие фразы от коллег?
-
Давайте примем решение после получения дополнительной информации.
-
Я буду разрабатывать строго по тому, что было написано в ТЗ.
-
Я не тестировщик.
-
Я не аналитик.
Если что-то из вышеперечисленного для Вас оказалось знакомым, то Вам точно будет интересно почитать эту статью, и как можно превратить IT в настоящую конфетку.
Моя цель — это подсветить, как мне кажется, одну из существенных проблем современных IT, и поделиться вариантами решения этих проблем. Если у вас таких обозначенных проблем не наблюдается — то буду рад увидеть в комментариях, секрет успешности именно вашего IT. Продолжим…
Мы привыкли думать, что с помощью автоматизации у нас возникнут золотые горы, от которых все (или почти все) проблемы будут решены. На практике получается, что в большинстве случаев автоматизация приводит к еще большим расходам, чем без неё.
Почему так происходит? Рассмотрим на нескольких реальных примерах, которые происходили вокруг меня в разное время.
История первая
Прихожу я к корпоративному архитектору, чтобы согласовать очередного робота. Бизнес-заказчик просит реализовать алгоритм, который взаимодействует с 3-мя информационными системами. Этот робот позволит сократить время отклика в несколько раз, что хорошо отразится на репутации компании. И для решения этой задачи прошу его одобрить «доступ на чтение» в БД этих систем к требуемым таблицам.
Архитектор спрашивает меня: «Почему заказчик приходит к команде роботов, а не к командам соответствующих информационных систем для реализации так называемой классической автоматизации?» Я ему отвечаю: «Они пытались занести эту задачу на классическую автоматизацию, но в силу большого количества задействованных разработчиков (от каждой системы минимум по 1-му разработчику) данная задача получается трудоемкой для такого эффекта, и не ставится в приоритет — до неё дело не дошло.» На это архитектор мне говорит, что никакого подключения к БД у робота быть не должно, да и вообще роботы — это «промышленный костыль». Роботов вообще быть не должно в IT архитектуре. А если они и есть, то это должна быть временная история. На старте разработки роботы обязательно надо установить дату отключения этого робота, занести задачу на реализацию в целевой архитектуре.
Конечно, команда роботов может сделать все через UI (наша сильная сторона роботов в том-то и заключается, что мы можем исполнить любой каприз). Но мы с Вами знаем продолжение пословицы: «за Ваши деньги». Так и здесь: Реализация через UI потребует увеличенного ресурса разработки в 1.5 — 2.5 раза (для создания максимальной отказоустойчивости), и быстродействие робота упадет на порядки (так как обращение к БД в разы быстрее, чем обращение к UI). Стоит ли оно того? Архитекторы довольны, бизнес-заказчик получит робота позже, и менее производительного.
Не могу не сказать про такой комментарий от архитекторов, что роботам нельзя иметь доступ на чтение в БД, потому что «роботы положат БД своими запросами». Но, извините, при таком подходе надо тогда всем запретить доступ в БД (ну, чтобы точно не положить её), но будет ли в таком случае от неё толк? 🙂 Ну а профессиональные навыки разработчиков никто не отменял — если программисты сильные, то программа будет качественной. Если слабые — понятно… Этот закон применим к любой области/ к любым подразделениям. Вообще к любым. Вряд ли тогда будет корректно запрещать Роботам доступ к БД, потому что они Роботы.
История вторая
В одной компании была разработана концепция Микросервисной IT архитектуры. Рассчитывалось, что эта концепция избавит компанию от многочисленных проблем, связанных с работоспособностью бизнес-процессов. Привлекли специально обученных людей: архитекторов, проектировщиков, разработчиков, девопсеров — задумку стали притворять в жизнь. Подошел обозначенный срок запуска, а чуда не произошло. Да и не просто не произошло, да еще и запустить всю эту концепцию не удалось. Стали вкладывать в это дело еще больше денег и времени, чтобы добиться цели — добились, через еще полгода и с диким количеством новых дефектов уже от Микросервисной истории. Да и запустить смогли только саму архитектуру, а бизнес-процессы остались работать на старых системах, как и работали. Ну а дальше началась другая история про многочисленные переписывания всего и вся на Микросервисы — долго, дорого и ….
К тому моменту у меня уже была реализована целая IT архитектура на базе технологии роботизации RPA, которая была построена в разы быстрее и потребовала гораздо меньше вычислительных ресурсов. Как следствие, данная архитектура оказалась еще и дешевле (существенно). Тут я прихожу и говорю: «Вот уже есть рабочая архитектура как бизнесу надо — берите пожалуйста и распространяйте.» Дальше в ход пошла политика, потому что, как оказалось, нельзя просто так взять и поменять вектор развития — нужно отвечать за ранее выбранный тренд (особенно, если в этом были задействованы большие деньги). Далее подробности оставим за кадром.
В итоге компания по-прежнему осталась в состоянии смешанной IT архитектуры, в которой появился еще и Микросервисный кусочек.
История третья
Как-то мне довелось участвовать в проекте, где требовалось выполнить очень интересную задачу, чтобы достичь поставленной бизнес-цели. Ко мне приходил заказчик и каждый раз рассказывал о том, что мы должны достичь эту цель как можно скорее, мы должны приложить все-все-все усилия. В ответ я пытаюсь погрузить его в технические детали, чтобы коллективным разумом найти наиболее оптимальные решения на те вопросы, которые индивидуально определить не удается. Заказчик по-прежнему не пытается услышать меня и продолжает рассказывать про то, как нам важно достичь поставленной цели как можно скорее.
Мы часто не пытаемся понять другую сторону: Бизнес-заказчик не пытается понять проблематику программиста, а программист не пытается понять проблематику бизнес-заказчика. Все это еще осложняется тем, что в компаниях натравливается дикая бюрократия (для обеспечения контроля), которая еще больше начинает тормозить прогресс. Ну а дальше естественный отбор — выживет сильнейший.
Рекомендую попробовать реализовать хотя бы один проект с максимальной вовлеченностью в проблемы другой стороны. Возможно, вам не все понравится в этом, но бизнес-эффект с точки зрения конечной цели будет гораздо лучше.
Микросервисы или RPA? Простое объяснение
Микросервисы — это система обособленных процессов. Какую роль играет приставка «микро», почему не «сервисы»? А дело в том, что сервис-ориентированная архитектура (SOA) уже давным-давно была придумана, а Микросервисы — это одна из производных (маркетинг, реинкарнация). Хорошие статьи по этому поводу уже были написаны ранее — рекомендую почитать (1) эту или (2) эту.
SOA в свое время не стала панацеей. Стоит ли рассчитывать, что ее «микро» сервисная реинкарнация исправит это положение?
RPA — это технология адаптации к уже существующей (неэффективной, неоптимальной) IT архитектуре. Идеология RPA гласит, что не надо ломать то, что хорошо работает — надо улучшить то, что работает плохо.
И ведь действительно, почему мы должны вычищать мегатонны исходных кодов из-за того, что кто-то искусственно назвал все эти IT системы «legacy». Если они до сих пор выполняют свою функцию? Возникли проблемы с тем, что Вы не можете внести туда изменения в функциональность? Так робот RPA поможет это исправить, и без переделывания всего остального!
Что бы Вы выбрали: сломать всё и делать «с нуля» или улучшить то, что уже функционирует? Так вот когда Вы говорите: «хочу Микросервисы», то Вы выбираете далеко не улучшение того, что у вас уже работает.
Микросервисы или RPA? Сложное объяснение
Рассмотрим внедрение новой бизнес-функции в существующие бизнес-процессы. Внедрение попробуем провести с помощью технологических подходов (1) Микросервисов и (2) роботизации RPA.
Кейс
В нашей небольшой бургерной компании возникла необходимость по внедрению дополнительного алгоритма расчета индивидуальных скидок на основании оставшихся ингридиентов. Например, осталось много говяжьих котлет в ресторане #n, система делает рассылку находящимся рядом посетителям об уникальном предложении.
Дано
В бургерной компании реализована смешанная IT архитектура, состоящая из разных систем, которые писались и внедрялись в разные периоды времени. Данная архитектура успешно выполняла свою функцию, но с течением времени некоторые новые требования реализовать уже не удавалось в связи с устареванием некоторых технологических решений.
В бургерной компании используется несколько фронт систем (касса, терминал, мобильное приложение), подключенных к бэк системам (система входящих заказов, система учета остатков)
Далее поиграем в IT архитекторов и попробуем решить поставленную задачу двумя методами: через (1) Микросервисы и (2) через роботизацию RPA. Обращаю внимание на то, что данные схемы не являются абсолютно полными — в них содержится ключевая часть разработки, которую можно рассмотреть в сравнении при реализации разными методами: увидеть плюсы и минусы. Малозначимые компоненты оставлю за скобками.
Решение через Микросервисы
Преследуя подход Микросервисов мы будем вынуждены отказаться от старых добрых IT систем (признав их как legacy, если они не реализованы по принципам SOA. А они, скорее всего, по этим принципам не реализованы 🙂 ). Отказавшись от старых IT систем потребуется восполнить все необходимые бизнес-функции в новой IT архитектуре, а значит потребуется провести масштабную разработку многочисленных Микросервисов. Перед тем как начать их разрабатывать, потребуется провести настройку всей необходимой инфраструктуры, потому что для Микросервисов, скорее всего, потребуется значительное количество вычислительных мощностей. Еще нужно будет закупить все необходимые лицензии, если в чем-то будет использоваться не open source решение.
После того как утраченная бизнес-функциональность будет восполнена, только после этого мы сможем перейти к разработке нового сервиса, ради которого затевалось все это изменение.
Ниже схематично представлены изменения от исходной схемы IT архитектуры до целевой в случае использования данного метода. Схема очень условная, некоторые модули специально не отрисованы, чтобы не отвлекать внимание от сути происходящего 🙂
Решение через RPA
В случае использования метода роботизации (RPA как основа IT архитектуры) мы сталкиваемся с удивительными вещами. В процессе анализа существующей смешанной IT архитектуры, вдруг, выясняется, что, оказывается, можно реализовать требуемую бизнес-функцию с использованием уже существующего зоопарка систем. Почему именно с роботизацией? А потому что именно с её помощью мы можем взаимодействовать, даже, с такими системами, с которыми никто не готов взаимодействовать. Технология RPA является тем самым ключевым связующим звеном, которое может вдохнуть второе ((третье) четвертое и т.д.) дыхание в Ваши бизнес-процессы, и дать им возможность приносить пользу еще долгое время.
Применительно к поставленной задаче, с помощью RPA можно разработать специального робота, который в режиме реального времени будет извлекать через UI необходимую информацию об остатках, после чего учитывать ее при расчете в системе заказа, внося соответствующие изменения через API.
RPA как основа IT автоматизации
С момента появления темы RPA стали появляться программные продукты соответствующего класса. год 2020 был ознаменован рекордным количеством платных платформ роботизации RPA (более 50). 2021 год открылся в новом качестве, а именно: на рынок резко вышли несколько open source платформ роботизации RPA, что повлияло на качественное развитие рынка технологий IT. Но именно open source платформа pyOpenRPA предоставила возможность, не просто создавать бесплатных роботов, но и внедрять данную технологию RPA в другие крупные IT проекты, что и дало возможность впервые рассматривать роботизацию RPA как основу IT архитектуры компании.
Подробнее об open source pyOpenRPA можно почитать в этой статье.
Заключение (выводы)
Хочу сказать пару слов о некоторых трендах. Уважаемые коллеги заказчики. Не верьте в то, что говорят. Доверяй, но проверяй. Один из трендов современности — это глобально переделывать существующий зоопарк систем в микроскопичную архитектуру. Скорее всего, у вас не будет того, про что вам так сладко рассказывают. Я в качестве стажера, консультанта, эксперта увидел десятки IT архитектур компаний разных сегментов и разного объёма бизнеса. Знаете, что пытается сделать практически каждый технический директор? Избавиться от архитектуры прошлого директора. А знаете, что происходит потом? Порождённое количество проблем порождает новую конфликтную ситуацию, из-за которой снова происходит смена директора — и вышеописанный процесс начинается сначала.
Самое большое заблуждение, которое я уяснил для себя после увиденного — это отказ от того, что уже работает и функционирует. Да, скорее всего оно работает не идеально. Но работает же. Так почему же не попытаться улучшить то, что есть?
PS> Немного занудства 🙂
Этот мир пытается выжать «эффект» из каждой капли. Но никто не задумывается о том, а что же будет потом, когда эти капли закончатся?
PSS>
Буду рад любой поддержке, если тема для Вас актуальна.
Буду рад прочитать конструктивные комментарии по этой теме.
