Translate

terça-feira, 3 de dezembro de 2013

Autoatendimento para o canal ATM: Overview sobre o Front-End

        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: