Can bots and the ODA happily co-exist?
As CSPs transform to API-first architectures for IT and operations automation, they are also adopting integration technologies based on bot platforms, like robotic process automation (RPA) and intelligent process automation (IPA), to solve tactical integration and task automation challenges. Can these two very different approaches to automation – one very well defined and based on long term planning, the other focused on more immediate, incremental aims – find a way to co-exist?
17 Sep 2021
Can bots and the ODA happily co-exist?
As CSPs transform to API-first architectures for IT and operations automation, they are also adopting integration technologies based on bot platforms, like robotic process automation (RPA) and intelligent process automation (IPA), to solve tactical integration and task automation challenges. As a result, these two very different approaches to automation – one very well defined and based on long term planning, the other focused on more immediate, incremental aims – must co-exist.
Operations architects, however, often voice concerns regarding the use of bots in the context of a well-defined, API-centric integration architecture like the TM Forum Open Digital Architecture (ODA). Their concerns range from change management issues to possible IT policy violations. “In some cases the bots are not really ‘kosher’ and only short term,” explains Harpreet Singh, Sr. Digital Products Strategy Manager, TELUS. For example, he says, “if the bot is screen-scraping we have policies which stop screen-scraping.”
Other typical push back from operations experts to bots include:
The reality on the ground, however, is that bots are being used increasingly to deliver value fast through rapid integration and automation, particularly on a tactical or evolutionary basis. As a result, CSPs will need to account for the incursion of bot technologies as part of their automation plans.
“The most correct approach is a combination of both strategies,” says Flavio Reis, CTO, Lojas Renner S.A. and former CIO for cloud and cybersecurity with a tier 1 global CSP. Reis argues that a CSP must have an API-first strategy to “drive all new projects, technology selection, and legacy modernization.” But, because not all functions will be API-enabled on day one, Reis says, bots can play a key role in implementing alternative integrations, such as via user interface, command line interface, or interacting with file stores.
George Glass, CTO, TM Forum, advises caution as bots and APIs are rolled out in parallel. “I think there’s a time they can co-exist, but it has to be managed very carefully” Glass says. He offers several suggestions to CSPs that are faced with managing these two worlds and bringing them together.
Introduce RPA carefully and in a controlled manner. “ODA and RPA will not live in separate worlds,” Glass explains, “but you’re doing per-solution design, per system design, and bots are gluing that together,” Glass says.
Treat bots as systems and applications. “Bots have to become part of your systems inventory, just like your pricing engines and portals, and you have to put the same kind of rigor around them as you would around any BSS component,” he says.
Bots may become legacy extensions. A bot in a contact center might hit a legacy BSS system 500 times a day to free an agent from a repetitive task. As a result, that bot-based automation becomes an extension of the legacy platform and must be governed to deal with any change in the process or retirement of the legacy BSS.
Glass also encourages CSPs relying on bot-based integration approaches to determine whether the problem at hand is better solved with an architecture-based approach. A systems or API upgrade can be a better option “than sticking a robot on top because your system is missing something,” Glass explains.
This integration debate continues to develop. It raises important questions for CSPs about the role of new technologies in process automation and integration.
For a deeper look as this debate and the automation questions that arise from it, download our new report: Process automation: an evolutionary approach to digital transformation
Architects object
Operations architects, however, often voice concerns regarding the use of bots in the context of a well-defined, API-centric integration architecture like the TM Forum Open Digital Architecture (ODA). Their concerns range from change management issues to possible IT policy violations. “In some cases the bots are not really ‘kosher’ and only short term,” explains Harpreet Singh, Sr. Digital Products Strategy Manager, TELUS. For example, he says, “if the bot is screen-scraping we have policies which stop screen-scraping.”
Other typical push back from operations experts to bots include:
- Tasks are more complex than assumed,
- integrations may be brittle and change resistant,
- may build a new legacy integration layer on top of retiring legacy systems,
- may only add automate flawed processes and carry them forward.
Need to work together
The reality on the ground, however, is that bots are being used increasingly to deliver value fast through rapid integration and automation, particularly on a tactical or evolutionary basis. As a result, CSPs will need to account for the incursion of bot technologies as part of their automation plans.
“The most correct approach is a combination of both strategies,” says Flavio Reis, CTO, Lojas Renner S.A. and former CIO for cloud and cybersecurity with a tier 1 global CSP. Reis argues that a CSP must have an API-first strategy to “drive all new projects, technology selection, and legacy modernization.” But, because not all functions will be API-enabled on day one, Reis says, bots can play a key role in implementing alternative integrations, such as via user interface, command line interface, or interacting with file stores.
Glass advises caution
George Glass, CTO, TM Forum, advises caution as bots and APIs are rolled out in parallel. “I think there’s a time they can co-exist, but it has to be managed very carefully” Glass says. He offers several suggestions to CSPs that are faced with managing these two worlds and bringing them together.
Introduce RPA carefully and in a controlled manner. “ODA and RPA will not live in separate worlds,” Glass explains, “but you’re doing per-solution design, per system design, and bots are gluing that together,” Glass says.
Treat bots as systems and applications. “Bots have to become part of your systems inventory, just like your pricing engines and portals, and you have to put the same kind of rigor around them as you would around any BSS component,” he says.
Govern bots with strong change management
“If RPA integrations are built on top of applications without system designers knowing, then when changes happen in the application, the bots may well stop working,” Glass says.
Bots may become legacy extensions. A bot in a contact center might hit a legacy BSS system 500 times a day to free an agent from a repetitive task. As a result, that bot-based automation becomes an extension of the legacy platform and must be governed to deal with any change in the process or retirement of the legacy BSS.
Glass also encourages CSPs relying on bot-based integration approaches to determine whether the problem at hand is better solved with an architecture-based approach. A systems or API upgrade can be a better option “than sticking a robot on top because your system is missing something,” Glass explains.
This integration debate continues to develop. It raises important questions for CSPs about the role of new technologies in process automation and integration.
For a deeper look as this debate and the automation questions that arise from it, download our new report: Process automation: an evolutionary approach to digital transformation