Olá senhores
leitores. Após um longo período de ausência, estou de volta com mais um artigo
interessante sobre autoatendimento em terminais do tipo ATM. Vou falar um pouco
sobre a arquitetura das soluções de autoatendimento, e com isso quero apresentar
aos leitores, o que está envolvido nesse tipo de aplicação, quais são os
principais elementos arquitetônicos da solução como um todo, e também
localmente, quando se ajusta a lente para olhar mais próximo a composição da
aplicação que controla os terminais. O objetivo deste artigo, como sempre, é
mostrar para o jovem uma visão mais geral a cerca dessa indústria, e o que ela
pode oferecer de desafios e recompensas. Agora vamos ao que interessa!
Uma solução
completa de autoatendimento envolve dezenas de software dispostos em três
pontos da arquitetura da solução: Front-End, Middleware e Back-End. Esses
termos são utilizados largamente na engenharia de software para designar o
propósito do software em questão, e na arquitetura de uma solução de
autoatendimento, Front-End designa o software cujo propósito é oferecer algum
tipo de interface (não necessariamente gráfica) para algum tipo de usuário
(cliente, operador, gestor e etc). Por meio dessa interface, são oferecidos
serviços que serão processados no Back-End. Esse termo designa, portanto, o
software que executa normalmente em ambientes de servidores (pequenos, médios
ou grande porte), mas que têm funções relativas ao processamento e efetivação
das transações que compõem cada um daqueles serviços. Em uma solução de
autoatendimento, essas são transações bancárias, típicas de produtos como depósito
e conta corrente, os quais são exemplos de produtos bancários encontrados em sistemas
que compõem o Back-End. Já o termo Middleware, normalmente está associado a
qualquer tipo de serviço localizado entre as duas outras camadas citadas. A
monitoração remota do terminal ATM, o serviço de parametrização desse terminal
e também o serviço de atualização remota, normalmente estão localizados nessa
camada.
Considerando a
indústria das instituições bancárias, e sua estrutura de TI, fisicamente, o
Back-End é representado, em muitos casos, por um computador de grande porte
denominado Mainframe. Esse
computador hospeda a maioria do software e demais elementos que compõem o
Back-End na arquitetura. Esse software é responsável, por exemplo, por
autorizar boa parte das transações, além de conter os principais programas
responsáveis pelos produtos mais básicos de uma instituição financeira, como a
conta-corrente e etc. O conjunto mais básico desses produtos bancários é
designado como Core Banking,
e todas as instituições bancárias possui uma solução dessa natureza, seja feita
dentro da própria instituição, seja adquirida pronta no mercado. Não importa quantos
canais de atendimento essas instituições possuam, por exemplo, ATM, atendimento
telefônico, internet banking e etc. Todos eles terão, em algum ponto, que se
submeter ao Mainframe, usando uma ou mais transações servidas por ele,
acessando portanto, componentes do Back-End.
O Middleware é
ponto da arquitetura onde normalmente se localizam sistemas de gestão dos
canais. O gestor de cada produto da instituição, normalmente irá precisar de
relatórios estáticos, e também configurar parâmetros de operação das
transações. Bom, é aqui que começa a confusão. Veja, qualquer instituição tem
diversos canais de atendimento como citei anteriormente. Imagine se essa
instituição tiver que desenvolver no Back-End uma transação de saldo para
Internet Banking, outra versão da transação de saldo para o canal ATM, e por
fim, um para o canal de atendimento telefônico. Isso seria um caos, certo?
Seria não, é! O fato é que muitos bancos encontram-se exatamente nessa
situação, pois sua solução de autoatendimento não foi projetada para operar
diversos canais ao mesmo tempo. É até fácil de entender, alguns canais só foram
considerados bem recentemente, com o advento de alguma nova tecnologia. Por
exemplo, smartphone é uma realidade agora, todo mundo tem um, mas não era assim
há cinco anos. Revisar toda a arquitetura sai caro e, principalmente, pode
resultar em muitos problemas para os clientes até estabilizar. Por isso, ocorre
que muitas instituições acabam por manter estruturas com essas fragilidades
arquitetônicas. Outras instituições que tiveram a chance de revisar sua
arquitetura procuraram concentrar no middleware soluções de convergência entre
os diversos canais. Componentes localizados no middleware intermediam as
transações entre os diversos canais e o Mainframe. Assim, uma única versão, e
um único formato de transação ficam disponíveis no Host, e o Middleware é o
responsável por tornar essa transação acessível aos diversos canais, no formato
que eles esperam. Isso é conhecido como solução multicanal.
O Front-End é
a nossa praia. Esse ponto da arquitetura é onde se encontra a interface com o
cliente em cada um dos canais. Assim, no canal ATM o Front-End é a aplicação de
autoatendimento no terminal ATM, incluindo todas as demais aplicações
utilitárias e de serviço que compõe os componentes desse ponto da arquitetura.
Em um canal de atendimento telefônico, seria o sistema baseado em URA. Óbvio
que o Front-End de cada um dos canais de atendimento tem suas complexidades, e
eu vou detalhar aqui um pouquinho da complexidade envolvida no canal ATM. A
aplicação de autoatendimento para o canal ATM é um dos principais componentes
do Front-End na arquitetura de qualquer solução de autoatendimento quando
falamos de automação bancária. A complexidade envolvida nessa aplicação pode
ser observada na imagem a seguir.
A primeira
questão que se tem que observar é que a aplicação precisará controlar os periféricos
do terminal de autoatendimento. O ATM na imagem pode ser um terminal caixa
eletrônico ou um terminal eletrônico do tipo kiosk. Eles são normalmente
encontrados em bancos, shopping centers, aeroportos ou até mesmo em lojas de
conveniência. O conjunto de periféricos encontrados nesses terminais depende do
modelo do terminal. Por exemplo, um ATM do tipo Full Fuction, normalmente possui módulo depositário, dispensador de
cédulas, leitora de cartões, impressora térmica, placa de leds e sensores,
painel do operador e pinpad. Já um terminal do tipo kiosk é encontrado
normalmente na seguinte configuração: impressora térmica, pinpad e leitora de
cartões. Claro que com o advento de novas tecnologias de hardware, diversos
novos periféricos vem sendo adicionados a esses terminais: leitoras de
smartcard, leitores biométricos, câmeras videofotográficas (normalmente uma
WebCam) e etc. Veja que a configuração do terminal determina o escopo de
atuação da aplicação. Para cada um dos periféricos contidos nessa configuração,
será necessário um software controlador. Esse software é denominado como Device Driver. Na
automação bancária é mais comum encontrar esses drivers escritos em C/C++, e
operando em User Mode. No
entanto, há uma separação de responsabilidade aqui. O Device Driver tem que
conhecer detalhes relativos à comunicação serial ou paralela, e ainda conhecer
o protocolo de operação do dispositivo. Esse tipo de preocupação está muito
longe do negócio, que é oferecer serviços bancários. E, além disso, por
questões de segurança, o protocolo de operação de dispositivos como o
dispensador de cédulas é mantido sob segredo por muitos fornecedores. Por isso,
normalmente essa camada de software é responsabilidade do fabricante do ATM.
Como cada
dispositivo possui uma infinidade de opções de modelos e fornecedores, uma
forma de separar essa complexidade da aplicação é por meio de uma camada middleware.
Para o autoatendimento em terminais ATM, especialmente para bancos, é muito
comum o uso de Service Providers CEN/XFS e Device Services J/XFS, nessa camada
middleware. Eu falei um pouco sobre essa camada no artigo Guia
para Automação Bancária para iniciantes. Eu também abordei,
superficialmente, sobre o desenvolvimento de Service Providers no artigo Desenvolvendo
Drivers XFS – Overview. O objetivo dessa camada de software é tentar livrar
a aplicação da complexidade que há nessa diversidade que eu citei no paragrafo
anterior. CEN/XFS e J/XFS são padrões largamente usados na indústria da
automação bancária, e seu objetivo primário é abstrair essa complexidade
(embora nem sempre haja sucesso). No entanto, muitas instituições bancárias aqui
no Brasil não usam esses padrões. Instituições como o Banco do Brasil,
Santander e outros, preferiram projetar sua própria camada Middleware. Nesse
caso, essas instituições definem uma especificação, e repassam-na para qualquer
fornecedor de ATM que pretenda vender seus equipamentos para ela. Também é
comum encontrar instituições que usam um padrão aberto como o CEN/XFS e o
J/XFS, e o alteram de acordo com suas necessidades, criando assim extensões
para esses padrões. É o caso de instituições como o Itaú, Tecban e outros. Como
eu já falei bastante sobre essa camada em artigos anteriores, para este artigo
eu vou me concentrar na camada seguinte que é onde se localiza a aplicação.
A aplicação de
autoatendimento para terminais ATM ou kiosk pode ser baseada em diversas
tecnologias, e projetada com base em diversas estratégias arquitetônicas. Três
dessas estratégias são bastante comuns: Fat Client, Thin Client e Hibrido. A
estratégia Fat Client é a mais comum e está presente na grande maioria das
soluções de autoatendimento das instituições bancárias no Brasil. Nessa
estratégia, o software de autoatendimento está hospedado inteiramente no
terminal de autoatendimento, fazendo forte uso dos recursos de armazenamento e
processamento do terminal. Ou seja, uma solução Fat Client exige mais do
hardware (a unidade de microprocessamento – computador) do terminal. Essa
estratégia é a mais comum, pois as instituições sempre investiram pesado em
seus terminais ATM. A maioria dessas instituições compram, todos os anos, novos
ATMs para substituir parte de seu parque, já obsoleto. Ou seja, há um
investimento contínuo em hardware, e por isso mesmo, as instituições em geral,
preferem preservar esse investimento, e optam por soluções Fat Client. Já a estratégia
Thin Client exige mais hardware em servidores e não nos terminais. Esse tipo de
solução, na maioria das vezes, é projetado com base em alguma tecnologia Web,
com fluxos transacionais, telas e imagens e a maioria dos recursos utilizadas
na aplicação ficam hospedados em um servidor na rede. Assim, não há necessidade
de muito poder de processamento e armazenamento nos terminais. Esse tipo de
estratégia é bastante comum para o autoatendimento de domínios como o de venda
de ingressos para cinema e shows, usando os terminais do tipo kiosk. Nesse
caso, as unidades de processamento dos terminais normalmente contam com um mini
computador (Ex. Raspberry
Pi), com baixa capacidade de processamento e armazenamento de dados. Já a
solução hibrida procura usar as duas estratégias. Normalmente aqueles serviços
mais importantes (Ex.: saque, saldo e deposito e etc) da instituição tem seus
recursos mantidos no terminal, e os serviços usados com menos frequência (Ex.:
serviço de recarga de celular, publicidade e etc), ou com menos importância
para o negócio, ou ainda que sofram alterações com mais frequência, tem seus
recursos mantidos no servidor. A estratégia a ser escolhida realmente depende
do tipo de negócio, dos recursos de hardware que o cliente já dispõe, e também
de questões organizacionais.
Não importa
qual a arquitetura da aplicação de autoatendimento. Seja ela qual for o
software resultante terá, basicamente, os mesmos módulos mostrados na figura a
seguir. Essa é a visão em camadas de uma aplicação de autoatendimento
conceitual. São mostrados os componentes típicos de um sistema de
autoatendimento para ATM, e como eles se relacionam entre si e sistemas
externos encontrados nesses ambientes. Esse tipo de sistema têm, em geral, três
tipos de usuários: Cliente, Operador e Gestor. A seguir faço uma descrição
básica de cada um desses componentes.
Interface do
Cliente é o componente responsável pela camada de apresentação do software para
o cliente. Tipicamente, essa camada é construída com base em Java Swing ou seus
equivalentes no caso de outras linguagens. No entanto, é comum também encontrar
essa camada em construções Flash e HTML5 e, por vezes, uma combinação de todas
elas. A tendência atual no meio do autoatendimento é utilizar interfaces cada
vez mais interativas, semelhantes àquelas encontradas nos celulares smartphones.
Essa tendência têm sido possível em razão da utilização de telas sensíveis ao
toque, que simulam o mouse. Assim, o cliente não utiliza mais as teclas
laterais para operar a aplicação. Ele toca diretamente em componentes gráficos
na tela do terminal, aumentando a interação, e melhorando a experiência do
usuário cliente com a aplicação de autoatendimento. Em edições recentes da
CIAB, outras tecnologias foram apresentadas, ainda em forma de conceito, para
melhorar ainda mais essa experiência do cliente. Uma dessas tecnologias utiliza
sensores do tipo kinect que
leem os movimentos do cliente, e permitem que a aplicação seja controlada sem a
necessidade de tocar na tela do terminal.
Serviços para
Cliente é o componente responsável por derivar todos os serviços que estarão
disponíveis para o usuário cliente do software. São serviços típicos, o Saque e
Depósito em dinheiro ou cheque, bem como extrato de movimentação bancária,
transferências de recursos, pagamento de contas entre outros. Para falar de
tendências, eu não poderia deixar de citar os movimentos convergentes que têm
ocorrido na indústria do autoatendimento bancário. Por meio da convergência
entre canais, um novo conjunto de serviços tem sido colocado à disposição do
cliente. Os clientes podem iniciar transações de saque no canal Internet
Banking e concluí-las nos terminais ATM. Em outras soluções o cliente também
pode configurar uma operação de saque no smartphone e transferir esses dados
via NFC para o terminal, que dispensará o dinheiro em seguida.
Publicidade é
o modulo responsável por receber campanhas e vincular propagandas junto à
interface do cliente. Essas campanhas, em geral, são construídas e
parametrizadas em sistemas especialistas para os quais esse componente pode ter
interface. Aqui a tendência é a utilização de sistemas especialistas cada vez
mais inteligentes, que fazem recomendações cada vez mais assertivas para o
cliente. O objetivo final de qualquer propaganda, é a venda de um produto. Os
sistemas de publicidade são alimentados por informações oriundas de diversos
canais da instituição, e quanto mais informação ele puder reunir a respeito do
cliente, melhores podem ser suas recomendações e, portanto, as chances de
realização de uma venda. Por outro lado, tenho visto soluções de
autoatendimento que simplesmente negligenciam esse aspecto do negócio. Já vi
aplicação recomendando empréstimo para cliente cujo saldo bancário mostra que
ele não precisa disso, e também aplicações mostrando simples mensagem de aguarde,
quando poderia estar vinculando uma mensagem publicitária. Acho que aqui, o
autoatendimento bancário tem muito ainda por utilizar do conhecimento
construído por outros domínios, como o de vendas pela Web, os quais utilizam
poderosos sistemas
de recomendação.
Monitor é o
componente que monitora aspectos como estados dos dispositivos, disponibilidades
de serviços e notifica essas informações para sistemas especialistas responsáveis
pela monitoração remota dos terminais. Esse módulo é o responsável, por
exemplo, por coletar informações que irão definir qual a disponibilidade do
terminal em um determinado período. As instituições bancárias mantém contratos
de SLA com equipes de manutenção (que as vezes pertencem aos próprios
fabricantes dos terminais), e nesse contratos há um número mágico que indica
qual é a disponibilidade mínima do terminal durante um período (normalmente um
mês). Algumas instituições determinam multas para as equipes ou fabricantes,
quando a disponibilidade de seus terminais fica abaixo do que está estipulado
nesses contratos. Por isso, esse módulo tem um papel bastante importante na
aplicação de autoatendimento.
Periféricos é
o componente por meio do qual se tem acesso ao hardware periférico do
equipamento. Esse componente é responsável por oferecer uma forma padronizada
de acesso a esses periféricos, mesmo diante da diversidade de fabricantes,
modelos e infraestrutura disponível no hardware. Bom, isso é o desejável, mas o
que se vê muitas vezes em algumas soluções no mercado é uma fraca separação da
camada de acesso ao hardware e o restante do negócio da aplicação. Se toda vez
que um novo serviço for introduzido na aplicação, o programador tiver que se
preocupar em incluir código condicional para cada um dos modelos de terminal,
fabricantes e etc, então a manutenção da solução será um caos. Então, o melhor
é que haja uma separação clara dos módulos de acesso ao hardware, e que eles
abstraiam a complexidade que possa haver nesse hardware, como modelo e
fabricante de equipamentos e dispositivos.
Gestor é o
componente que controla e gere a operação dos demais componentes da aplicação.
Esse componente é responsável por decidir, por exemplo, se a aplicação está em
operação ou fora de operação por manutenção, e também por processar comandos
remotos enviados por sistemas especialistas de gestão de terminais.
Autorizador é
o módulo responsável por estruturar a comunicação com um sistema externo que
autoriza as transações. Em geral, todos os serviços disponíveis para o Cliente
e o Operador só podem ser acessados mediante processos de autorização, os quais
podem ocorrer em diversas etapas. A cada etapa, dados são trocados entre o
sistema autorizador e a aplicação de autoatendimento, e uma das
responsabilidades do componente em questão é representar esses dados de maneira
conveniente para acesso pelos os demais componentes do software.
Serviço para
Operador é o componente responsável por derivar todos os serviços que estarão
disponíveis para o usuário Operador. São serviços típicos, abastecimento de
numerário, configuração do número do terminal ATM, e outros.
Interface do
Operador é o componente responsável pela camada de apresentação do software
para o operador. Em geral, essa interface é mantida por hardware periférico
específico, denominado Painel do Operador. No entanto, em alguns modelos de ATM
essa interface é apresentada no mesmo hardware periférico utilizado para a
interface do usuário Cliente (ex.: monitor). Quer dizer, em equipamentos
dotados de painel do operador, um dispositivo especializado contendo um teclado
e um display, é o responsável por prover a interface necessária para o operador
operar o terminal a partir da de sua parte traseira. Esse tipo de configuração
é típico em ambiente de agencia bancária, onde os terminais ficam posicionados
por traz de um drywall, com apenas sua parte frontal sendo exposta aos
clientes. Nessa configuração, o operador trabalha na parte de traz do drywall,
separado do contato com o cliente, mantendo a segurança da operação e o
conforto dos clientes também. Já quando os terminais estão em ambientes de
shoppings ou lojas de conveniência, é comum que o terminal fique encostado em
uma parede, impedindo sua operação traseira. Nesse tipo de configuração, não há
um painel adicional e o operador deverá realizar suas operações por meio da
mesma tela e teclado operados pelo cliente.
É isso. Até mais.
Nenhum comentário:
Postar um comentário