Современные инструменты позволяют отделять программное обеспечение от конкретной реализации, создавая универсальные компоненты, которые могут использоваться повторно различными командами и организациями.
Основные принципы модульности
Модульность означает разделение большого объема кода на небольшие автономные части (модули), каждая из которых решает свою отдельную задачу. Эти модули обладают несколькими ключевыми свойствами:
- Автономность: каждый модуль работает независимо от других модулей, что упрощает тестирование и сопровождение.
- Интероперабельность: модули взаимодействуют друг с другом через четко определенные интерфейсы, что позволяет легко заменять одни модули другими.
- Повторное использование: готовые модули могут быть использованы в разных проектах без необходимости переписывания кода.
Такой подход особенно важен в сфере автоматизации и роботизации бизнес-процессов (Robotic Process Automation, RPA), поскольку позволяет сократить затраты на разработку новых решений и повысить эффективность существующих.
Ролевые модели и оркестрация
Современные инструменты управления корпоративными процессами часто используют концепцию оркестрации. Оркестрация подразумевает централизованное управление всеми компонентами системы, включая процессы, потоки данных и взаимодействие между ними. Здесь важную роль играет понятие «ролевой модели»:
- Каждый модуль (или бот) выполняется в рамках определенной роли, соответствующей уровню полномочий сотрудника или подразделения.
- Управление доступом осуществляется на уровне ролей, что обеспечивает защиту конфиденциальной информации и предотвращает несанкционированный доступ.
- Возможность импорта пакетов и публикации на оркестраторе позволяет централизованно управлять версиями и обновлениями, сохраняя согласованность всех компонентов системы.
Модульный подход и использование оркестрирования помогают обеспечить гибкость, масштабируемость и надежность автоматизированных систем, позволяя компаниям эффективно реагировать на внешние изменения и оптимизировать внутренние процессы.
Мнение за
Программный код во многих RPA-системах можно создавать в самом сценарии робота с помощью Low-Code редактора. В отличие от абсолютно всех существующих решений, данный программный код в RPA ROBIN не становится «захардкоженной» частью сценария робота, а сохраняется в виде отдельного защищенного пакета и может быть импортирован в другую студию как действие, либо опубликован на оркестратор.
Соответственно, такой подход позволяет управлять программным кодом отдельно от сценария самого робота – устанавливать необходимые права, ролевую модель, обеспечивать должную безопасность и технологичность его дальнейшего сопровождения и повторного использования.
В платформе Primo RPA предусмотрен полноценный SDK, который позволяет создавать собственные действия, коннекторы и обработчики вне сценария робота. Такой подход обеспечивает модульность и полное разделение бизнес-логики и кода: разработчики могут писать и тестировать решения в привычной IDE, использовать необходимые библиотеки, хранить код в корпоративных репозиториях, управлять версиями и безопасностью через CI/CD.
В отличие от low—code-реализаций, где программный код остаётся частью конкретного сценария, SDK-архитектура делает платформу открытой и расширяемой, позволяя компаниям создавать собственную экосистему компонентов, повторно использовать их в разных проектах и централизованно управлять их жизненным циклом. Это обеспечивает гибкость, безопасность и технологическую зрелость корпоративного уровня.
Мнение против
Ни в одной современной платформе код процесса не является захардкоженной частью робота. Хотя некоторые платформы позволяют предварительную компиляцию сценария в байт-код или нативный код для ускорения выполнения, поддержка управления процессом через Оркестратор, включая версионность, переиспользование, ролевую модель и т.д., является базовым требованием к современному решению RPA.
Также есть мнение, что вредные инъекции в робота достаточно быстро выявляются опытным взглядом.
И ещё один пункт: можно и плохого робота сделать, и его зашифровать, чтобы он не становился «захардкоженной» частью сценария робота. Что тогда? То есть «захардкорженность» как таковая не спасает от потенциальных проблем.
