Nas últimas semanas, publicamos no nosso blog a tradução de artigos excelentes orbitando sobre a mesma disputa: SAPUI5 versus Fiori. Escolhemos divulgar a opinião destes três experts, mas existem vários outros textos abordando o assunto. Menos, entretanto, do que seria necessário para esgotar o tema.

Quero aproveitar o gancho dos artigos para colocar a minha visão a respeito da escolha entre SAPUI5 e SAP Fiori Elements.

Iniciando pelo especialista Tobias Hofmann, que afirma categoricamente que o SAPUI5 vai desaparecer: você pode ler o original em inglês ou tradução em nosso blog: Sua Próxima Habilidade Obsoleta: Desenvolvimento UI5.

Recomendo fortemente a leitura, mas quero desenvolver um raciocínio especificamente sobre esses trechos: “Ter que aprender algo novo não é ruim e, pelo menos fora do universo SAP, é comum. Essa renovação constante é prova de que há inovação. Tecnologias antigas são assimiladas ou substituídas. Raramente ficam completamente obsoletas de uma vez. A mudança leva tempo e normalmente as ideias, ou pressupostos básicos, do que será substituído, continuam.”

O Tobias levanta o ponto central da questão: o que verdadeiramente interessa para a empresa não é a tecnologia; é o próprio negócio. E, para manter a operação funcionando, o desenvolvedor ABAP é alguém imprescindível.

Ele é o cara do seu processo dentro do sistema SAP. Digamos que ele está trabalhando em uma empresa de varejo, na indústria de moda, há 15 anos. Ele é um profissional que sabe tudo do negócio, conhece muito bem o processo.

Você simplesmente não pode perdê-lo.

Para substituir o ABAP pelo SAPUI5,  ele teria que aprender algo totalmente novo, não apenas dominar um método de trabalho diferente, mas empreender uma mudança completa de paradigmas. No mesmo tabuleiro, temos que o cliente, tanto o interno quanto o externo, têm uma demanda gigante pela UX proporcionada pelo Fiori. E, complicando a jogada, a SAP avisando que a mudança será inevitável e acontecerá muito em breve.

Pois bem, olhando para esse profissional que detém um conhecimento inestimável. Será que ele quer mudar? Isso interessa a uma pessoa que tem uma posição já consolidada no mercado, com muitos anos de carreira? O quanto isso custaria para a empresa?

Quem está acostumado a desenvolver ABAP não migra com facilidade para a linguagem de front-end, para o mundo do SAPUI5. O know how que esse profissional acumulou, entretanto, é valioso. Aqui nos deparamos com um paradoxo: quanto mais experiente o profissional, menos quer aprender tudo do zero.

Eu me coloco tranquilamente no lugar desse profissional. Após anos de prática em desenvolvimento ABAP e experiência na empresa, ao invés de me ver valorizado por todo o conhecimento que eu adquiri e por tudo o que eu entrego, eu me vejo colocado frente a uma necessidade de reaprender tudo.

Eu me sentiria pouco recompensado, e justamente em um momento que eu posso, talvez, pensar em parar, em me aposentar. Ou procurar outra oportunidade, como se diz no mercado. Ou, claro, investir em uma reinvenção na carreira, pela qual certamente eu esperaria ver meu salário bastante aumentado.

Assim, chegamos ao artigo de Tomas Buryanek , que escreve do ponto de vista de um desenvolvedor SAP ABAP “clássico”. Dessa posição, ele aponta como problema principal da mudança a curva de aprendizado muito íngreme. 

As diferenças da linguagem são imensas: o output do ABAP era sempre ABAP, hoje a estabilidade do ABAP foi substituída por algo que demanda conhecimentos de HTML, JavaScript, CSS, é preciso conectar fontes que antes eram explícitas com banco de dados.

A visão que o artigo traz é de que o UI5 não funciona porque o eclipse não é mais suportado, tem diretrizes de movimento, toda uma dificuldade. Algo que noto a cada vez que vou a uma empresa e converso com o pessoal que tem mais tempo de estrada: as pessoas não querem mudar toda a sua bagagem de conhecimento. Tem uma questão psicológica de desqualificar tudo o que o profissional já aprendeu.

Então, temos de um lado o recém-chegado, o técnico que acabou de sair da faculdade, ainda não conquistou essa vivência e não vai ter quem o ensine e, do outro, o profissional consolidado que tem dificuldade para ensinar graças a uma natural barreira geracional, fora o principal: não têm o desejo de migrar.

Eu acho muito curioso que nos eventos internacionais, quem está falando de tecnologia sempre é um cara 50+ da SAP, e aqui no Brasil são sempre os mais jovens. 

Conversando com estes dois artigos, temos a tabela apresentada em SAPUI5 vs Fiori Elementes (FE) do Showkath Naseem, também traduzido em nosso blog, ilustra à perfeição alguns pontos levantados pelo Tobias. Reproduzo a tabela aqui:

 Programação SAPUI5 (Código) vs SAP Fiori Elements (FE)

SAPUI5 Programming (Code)	SAP Fiori Elements (FE)
Modelo de programação flexível	Modelo de programação “semi” flexível
Os desenvolvedores de aplicativos têm que escrever muito código UI5, então o custo de desenvolvimento e manutenção do projeto será mais alto	O código SAPUI5 será gerado automaticamente com base em anotações de visão CDS e metadados usando o framework FE
É necessário escrever código SAPUI5, codificar em JavaScript	Codificação SAPUI5 automática
Escreva código personalizado (UI5, HTML, JQuery, etc.) para construir controles, modelos, código jQuery/Ajax para invocar APIs REST, serviços OData	Programação declarativa
Requer consideração tanto das diretrizes técnicas SAPUI5 quanto das diretrizes de design SAP Fiori para entregar o aplicativo	Automatiza muitas tarefas tediosas, minimiza o código padrão, gera UI e invocação de serviço automaticamente, fornece recursos prontos para uso
Possível desvio das diretrizes Fiori, fornece flexibilidade para personalização, mas perde as vantagens do Fiori	SAP Fiori elements cumpre todas as diretrizes UX e Fiori prontas para uso. Não quebra os padrões SAP Fiori, diretrizes UX
Necessário escrever código adicional para barra de ferramentas ou alterar comportamento em uma tabela responsiva	Por padrão, responsividade e adaptabilidade (executa em vários dispositivos) conforme FE segue estritamente as diretrizes Fiori3
Retrabalho para migrar para a nova versão	Compatibilidade direta com novas versões (diretrizes da nova versão Fiori), sem esforço adicional necessário
Esforço de codificação será maior e o custo de desenvolvimento também	Reduz drasticamente o tempo de codificação e o esforço de desenvolvimento
Quando o código é extenso, o custo de manutenção também será maior	Custo de manutenção muito reduzido
Possível refatoração de código e renovação para otimizações de desempenho	Melhor desempenho possível desde o início
Código personalizado + maior esforço de desenvolvimento	Suporta adaptação de UI, planos de piso, relatórios de lista e página de objeto

Customização

SAPUI5 Programming (Code)	SAP Fiori Elements (FE)
Customização possível	Customização – em andamento pela SAP. Exemplo: Lista dinâmica de opções dependendo de outro campo dinâmico
Podemos navegar do aplicativo SAP Fiori Elements para um aplicativo SAPUI5 personalizado. Implementar páginas personalizadas. Na página de objeto: seções personalizadas são suportadas	Verifique a documentação detalhada
Aberto para implementar qualquer solicitação de recurso sofisticado	Lógica complexa nem sempre é possível com Fiori elements atualmente
Integração de bibliotecas de terceiros/opensource possível	Não suportado no momento

Agora, voltando ao artigo do Tobias, ele olharia essa tabela de atributos do SAPUI5, o lado esquerdo, que vai desaparecer. O lado direito, o Fiori Elements, é o que vai funcionar e o motivo, segundo ele explicita no artigo, é que vai dar para usar sem precisar aprender a parte de linguagem de programação front-end.

Aqui temos a solução do problema muito bem colocado pelo Tobias, e escolhi o artigo dele para contar exatamente a posição da Tachyonix nessa questão: o Fiori Elements não está avançado para funcionar. Ele ainda não está pronto. 

Mas a Tachyonix está.

Somos a coluna do meio entre as funcionalidades indispensáveis do SAPUI5 e a facilidade e entrega em termos de User Experience do Fiori Elements. Nós fazemos o lado direito da tabela funcionar.

A Tachyonix consegue aplicar o app Fiori, sem ter que ensinar o desenvolvedor ABAP do zero. Resolve todos os problemas colocados nessa equação.

Com a solução Tachyonix, dá para utilizar todo o fluxo normal do negócio, retail, varejo etc. sem ter que tirar o desenvolvedor ABAP do lugar correto dele, que é fazendo o negócio funcionar.

Em resumo, para incorporar o Fiori Elements há uma barreira de aprendizagem que afasta os profissionais mais experientes. O Fiori  tem uma performance muito rápida e já está ligado ao seu negócio, a camada de apresentação é que não está. A tecnologia é que tem que casar os dois mundos, não o seu funcionário mais experiente e talentoso.

A SAP não está conseguindo pular essa etapa. A solução é abstrair a tecnologia, que é justamente o que a Tachyonix oferece: faz a tecnologia funcionar para a empresa e deixa o desenvolvedor, o profissional valioso, continuar trabalhando. 

“Essa é a oferta irresistível da Tachyonix: muda o front-end e mantém o modelo de dados.”

Apenas uma mudança terá que ser implementada: a aplicação de SAP GUI, o console que você tinha que instalar no seu computador, agora será um aplicativo web. O know-how de quem conhece a sua empresa continua valendo e a operação se mantém inalterada. 

Hoje, em 2024, isso é valioso. Em 2027, será puro ouro. Falarei mais disso em breve.