Evolução arquitetural de software para o mercado de concessão de crédito imobiliário e automóveis

Tecnologia e o mercado financeiro

Segundo Copeland e Weston [5], no mercado financeiro as pessoas e entidades podem negociar títulos financeiros, commodities, mercadorias como metais preciosos, produtos agrícolas, entre outros. Pilbeam [12] diz que mercado financeiro é qualquer operação relacionada a dinheiro. Mercado de crédito é o nome dado a parte do sistema financeiro em que ocorre o processo de concessão e tomada de crédito, sendo identificado como uma das subdivisões do mercado financeiro [6]. O mercado de crédito vem crescendo anualmente no Brasil, consequência disto, as instituições financeiras precisam de mais agilidade e eficiência em seus processos de gestão do crédito. Porém a necessidade de rigor na concessão de crédito aumenta de maneira proporcional [14]. Para o Banco Central do Brasil [1] o crédito no Brasil corresponde a quase 50% do Produto Interno Bruto (PIB).

Uma das consequências desse cenário é o rápido endividamento das famílias brasileiras devido ao uso do cheque especial e dos cartões de crédito. Entre 2009 e 2010, as operações com cheque especial avançaram 23%, e com cartão de crédito 22% [8]. Isto posto, a tecnologia se torna uma poderosa ferramenta de auxílio para instituições financeiras suportarem os novos desafios originados desse crescimento. Contudo, o mercado de crédito imobiliário e de automóveis requerem sistemas mais flexíveis as mudanças de negócios e também com menor custo de manutenibilidade e administração.

Portanto, o objetivo da modernização deverá se concentrar na redução de custos de manutenção, administração e gestão dos sistemas de informação. Isto é, as arquiteturas deverão ser criadas para suportarem constantes mudanças de requisitos funcionais e não funcionais, também permitir que partes dos sistemas sejam reutilizadas, suportem customizações sem que afete outros recursos, serem facilmente integrados, e suportarem interoperabilidade em um cenário com tecnologia heterogênea.

Avaliação da estrutura arquitetural do sistema existente

Um desafio comum no processo de evolução arquitetural de sistemas é a necessidade de modernizar a estrutura existente sem desperdiçar os atuais aspectos positivos da arquitetura atual. Arquitetura de software é o fator primário de atributos de qualidade, tais como: desempenho, manutenibilidade e segurança, que não podem ser alcançados senão com visões arquiteturais unificadas.

Para avaliação arquitetural do sistema existente foram utilizados as técnicas descritas no método Architecture Tradeoff Analysis Method (ATAM). O ATAM foi criado pelo Software Engineering Institute e é usado para avaliar arquitetura de software em relação aos atributos de qualidade. Avaliações baseadas no ATAM comumente expõem os riscos arquitetônicos que potencialmente inibem a realização dos objetivos estratégicos de negócio. De acordo com Zhu [20], o método ATAM recebe esse nome porque geralmente revela o quão bem uma arquitetura satisfaz os elementos específicos de um projeto, mas também fornece uma introspecção sobre como os objetivos de qualidade interagem uns com os outros.

O processo consiste em nove passos, e podem ser executados por fases, conforme ilustrado na Figura 1.

Figura 1. Nove passos propostos pelo método ATAM separado por quatro fases.

Analisar as possibilidades de satisfazer os requisitos de qualidade

O sistema era composto por quarenta e oito módulos em sua totalidade, os quais são utilizados em diferentes áreas, setores, departamentos e entidades. Visto que a arquitetura atual não permitia o reaproveitamento de código ou reuso de recursos, pois foi desenvolvido na década de noventa, utilizando arquitetura estrutural e linguagem de programação COBOL, isto é, influenciando negativamente para perda de sinergia entre a equipe, dificultando diretamente a manutenção e modificação do sistema.

Desta forma, o atributo custo de manutenção e modificação, logo, se tornaram um dos principais influenciadores a modernização. Isto posto, uma arquitetura distribuída, parecia ser uma excelente alternativa, assim, iniciamos uma análise no conceito chamado plataforma multicanal web. Uma plataforma multicanais web tem por objetivo agrupar os canais web através de um único ecossistema de aplicações fornecendo processos integrados como:

• e-commerce: conceito aplicável a qualquer tipo de negócio ou transação comercial que implique a transferência de informação via Internet;
• e-marketing: técnicas de marketing que desenvolvidas por uma organização através da Internet, redes móveis ou outros canais interativos, com objetivo de comunicar, vender e promover produtos e serviços [10];
• e-service: conceito aplicado a prestação de serviços através da Internet em tempo real [11].

Atualmente, as corporações procuram diferenciar-se dos concorrentes proporcionando aos seus clientes uma experiência de compra multicanal mais eficiente, rápida e fácil. Ao mesmo tempo, podem reduzir custos e a complexidade da TI, enriquecendo as compras dos usuários e melhorando a gestão de relacionamento com parceiros [13].

Por outro lado, a plataforma multicanal se diferencia pela integração entre vários componentes de diferentes características, por consequência, requer uma arquitetura que suporte integração de tecnologias heterogêneas.

Sendo assim, um padrão arquitetural de sistemas que favorece a integração e fomenta o reuso parecia ser uma boa opção, com tal característica, optamos em avaliar o padrão de Arquitetura Orientada a Serviços (SOA) [2].

Segundo Brown [3], neste tipo de arquitetura, os sistemas deixam de ser monolíticos, ou seja, não buscam resolver todas as necessidades de negócio em um só componente. Passam a fazer parte de um ecossistema formado pela integração de diferentes fontes para formar uma solução completa. Desta forma, SOA transforma recursos de TI em serviços de software descentralizados que podem se comunicar entre si aumentando a flexibilidade dos aplicativos de negócio [7]. No âmbito empresarial, a agregação de serviços é útil para interligar soluções legadas e processos dentro da companhia.

De acordo com Reenshaug [10], os princípios de SOA são embasados em características como:

• reuso;
• compartilhamento de contrato (padrão de comunicação);
• baixo acoplamento (dependência);
• fazer abstração de sua lógica interna (distribuição de responsabilidades);
• processo orquestrado (troca de mensagens);
• autonomia de recursos (independência);
• não devem manter estado, preferencialmente;
• ser visível (governança).

Já que SOA determinava a arquitetura de solução, isto é, como as camadas do sistema deveriam se comunicar e relacionar, precisávamos então escolher a arquitetura de aplicações (front-end), logo, visando facilitar a implementação de SOA, recomendamos a adoção do padrão arquitetural Model-View-Controller (MVC). O padrão MVC oferece uma estrutura altamente testável, o padrão arquitetural MVC é ideal para um projeto orientado a testes.

Visão geral do negócio

O sistema de concessão de crédito é utilizado por diversos usuários, na linguagem de negócio esses usuários são chamados de Canais. Os canais são classificados como parceiros internos e externos, os externos são: Concessionárias, Seguradoras e Parceiros Comerciais, enquanto os internos são: Agências de negócio, Autoatendimento e Suporte. O sistema é composto por inúmeros módulos, tais como: carteiras, formalização, proposta, adesão, crédito, impostos, cobrança, alienação, pagamento, faturamento, gestão, reserva, dentre outros que totalizam 48 módulos. O principal propósito do sistema é vender carta de crédito de imóveis e automóveis e gerenciar os grupos por concessão.

Visão da atual arquitetura

A atual estrutura arquitetônica contém duas camadas que consistem em aplicação e base de dados. A aplicação foi desenvolvida utilizando a linguagem de programação Java e através de conectores Information Management System (IMS) acessa a base de dados DB2. A aplicação é hospedada em um ambiente Linux, enquanto a base de dados é suportada por um Mainframe. A Figura 2 ilustra a arquitetura lógica do sistema.

Figura 2. Ilustração da arquitetura lógica do atual sistema.

A atual arquitetura é considerada de baixa complexidade e a divisão de responsabilidades em apenas duas camadas favorece no quesito desempenho. Outro ponto relevante é o baixo custo com licenças de software e infraestrutura. Entretanto, essa estrutura não apresenta só vantagens quando comparada com os interesses de negócio. O modelo lógico contém alto nível de acoplamento entre os componentes, por consequência é sensível a mudanças de requisitos de negócio, dado que qualquer alteração exigirá recompilação completa do sistema, portanto, a execução de teste de regressão e um novo ciclo de implantação se fazem necessárias, tornando com isso, o procedimento caro e demorado.

Para isso, elencamos as principais vantagens e desvantagens do modelo.

Vantagens:

• Desempenho;
• Baixa complexidade;
• Baixo custo de infraestrutura;
• Baixo custo de licença de software;
• Sistema maduro.

Desvantagens:

• Alto acoplamento (dependência);
• Sensível a mudanças de negócio (modificabilidade);
• Baixa nível de segurança;
• Não é escalável;
• Não suporta arquitetura de alta disponibilidade;
• Alto custo de manutenabilidade.

Inicio da avaliação arquitetural

No início do processo de análise, o líder de avaliação iniciou o processo apresentando o método de trabalho a todos os membros da equipe e também interessados no projeto. Isto é, todas as atividades que foram executadas durante o processo foram descritas e também explicadas em detalhes para cada integrante, desde as práticas de avaliação até qual deveria ser o formato de saída para geração dos resultados de cada análise.

Em seguida, deu início ao processo de identificação e entendimento dos interesses de negócio (Business Drivers). Nesta etapa foram feitas várias reuniões com os interessados pelo projeto e também com os usuários operacionais do sistema, na finalidade de coletar o máximo de informação possível para definição dos atributos de qualidade. O principal foco neste momento era identificar as principais funcionalidades, restrições técnicas e também os atributos balizadores de qualidade do negócio. Ao final, os dados coletados foram:

Principais funcionalidades:

• Adesão;
• Crédito ;
• Faturamento;
• Pagamento;
• Gestão.

Restrições técnicas:

• O sistema deverá ser construído totalmente em linguagem de alto nível - C#;
• Não será permitido o uso de tecnologias Open Source (por determinação do cliente).

Atributos balizadores de qualidade:

• Arquitetura deverá permitir integrações de tecnologias heterogêneas;
• Reduzir o custo para modificabilidade;
• Reduzir o custo de manutenibilidade;
• Baixar o nível de dependência entre os módulos.

Apresentação do projeto arquitetural

A evolução da arquitetura do sistema baseia-se no conceito de Plataformas Multicanais. Deste modo, serão criados barramentos que dividirão responsabilidades. A Figura 3 ilustra as camadas da estrutura lógica do sistema. A plataforma multicanais é representada pela primeira camada, ou seja, usuários através de um navegador web poderão utilizar o sistema.

A terceira camada é composta pelas aplicações web. O sistema deverá seguir a filosofia de SOA e os módulos serão construídos com o padrão arquitetural MVC, facilitando a execução de casos de testes de integração e unitários. Para migração de plataforma, todos os módulos serão reconstruídos na plataforma .NET e linguagem de programação C#, todos os binários gerados deverão ser suportados/hospedados no sistema operacional Microsoft Windows Server. A infraestrutura consistirá em dois racks com quatro systems físicas, o qual um é contingência, portanto, os racks deverão ser montados em diferentes lugares físicos.

Para troca de mensagens entre os diferentes módulos, foram adotadas tecnologias de enfileiramento de mensagens (MQ), devido a complexidade de alguns cenários, foram utilizados Microsoft MQ (MSMQ) e IBM Websphere MQ, também ferramentas de Enterprise Service Bus (ESB), sendo IBM Websphere Message Broker. O sistema de gerenciamento de base de dados (SGBD) deverá ser suportado pela plataforma Microsoft Windows Server. Neste sentido, uma quarta camada é criada e será chamada de Camada de Integração MultiCanal.

A distribuição arquitetural em diferentes camadas lógicas (software) e física (hardware) está alinhada a um dos atributos registrado na árvore de utilidades, sendo ele o item modificabilidade, está divisão proporcionou mais flexibilidade para evolução do sistema, permitindo crescimento vertical e horizontal. O sistema não contém nenhuma integração com sistemas legados, contudo, a estrutura arquitetural proposta permite a integração com qualquer tecnologia, ferramentas ou sistemas.

Figura 3. Visão geral da arquitetura lógica do sistema de concessão de crédito.

Identificação das decisões arquiteturais

Nesta etapa do trabalho, o objetivo era identificar os principais fatores que influenciaram na decisão arquitetural, desta maneira, foram efetuadas revisões e analises em todos os componentes e tecnologias envolvidas na solução arquitetural. A adoção da plataforma Microsoft foi altamente influenciada devido à restrição do uso de plataformas Open Source determinada pelo cliente. Além disto, a filosofia SOA ajudou na criação de um sistema menos acoplado, enquanto o MVC auxiliou na criação de módulos altamente testáveis. A inclusão de ferramentas e tecnologias de comunicação através de barramentos (middleware) está relacionado a solicitação de uma estrutura passível a integração entre tecnologias heterogêneas, o que pode ser visto na figura 5, na qual ilustra a nova arquitetura da aplicação.

Criação da árvore de atributos de qualidade

Neste momento a equipe de avaliação trabalhou com os tomadores de decisão do projeto na finalidade de identificar, priorizar e refinar os mais importantes objetivos de atributos de qualidade. A construção dessa árvore de utilidade é essencial, pois guiará o restante do processo. A Figura 4 apresenta os atributos registrados na árvore de utilidades.

Figura 4. Árvore de atributos de qualidade.

Análise das decisões arquiteturais

A Figura 5 ilustra uma visão geral da arquitetura do sistema. Em resumo, a estrutura consiste em três partes, camada de apresentação, construída na padrão arquitetural MVC. A camada de interoperabilidade, criada para atender o atributo de qualidade integração e facilitar a mudanças de requisitos. Em terceiro, a camada de comunicação, criada para suportar as exigências de qualidade dos quesitos modificabilidade e manutenabilidade.

Figura 5. Visão geral da arquitetura do sistema.

Análise das decisões arquiteturais da camada de apresentação

A camada de apresentação foi construída no padrão MVC. O sistema inicia-se com um componente de autenticação único que consume um serviço através da camada de comunicação para execução do reconhecimento do usuário. Caso a requisição retorne com a autenticação efetuada com êxito, o componente efetua uma nova requisição para o recurso de rotas, o qual direcionará o usuário para uma página inicial do sistema com o menu de opções customizado conforme privilégios do usuário. As páginas de visualização são fortemente tipadas por classes chamadas de modelo, esses objetos contém as regras de negócio e também acesso aos serviços de persistência e recuperação de dados. Além disto, existem as classes de controle que contém as instruções comportamentais das páginas de visualização.

O modelo implementa o recurso de ligação (binding) com o padrão de projeto observer, conforme pode ser visto na figura 6. Este padrão facilita a atualização dos dados na camada de visualização, notificando o objeto view sempre que o modelo sofre qualquer alteração estado.

Figura 6. Arquitetura da aplicação baseada no padrão MVC.

Este padrão arquitetural na camada de aplicação permite a separação dos objetos que compõem a estrutura do sistema, por exemplo: modelo de negócio, controle de comportamentos e visualizações. Deste modo, é possível aplicar casos de testes mais específicos e por consequência mais eficientes.

Análise das decisões arquiteturais da camada de integração

A Figura 7 ilustra uma visão da camada de integração entre a aplicação e os serviços. Este componente consiste em objetos que contém conhecimento da estrutura de dados e conectividade com a camada de comunicação. A principal função deste componente é a interpretação da estrutura de dados que permite interoperabilidade na troca de mensagens entre as transações, com isso, o sistema pode ser migrado por partes/fases, dado que a camada de integração se responsabiliza pela comunicação entre os serviço e artefatos de armazenamento de dados. Esta camada foi implementada em função do atributo de qualidade "modificabilidade", por acrescentar flexibilidade ao sistema e aceitação na mudança de requisitos funcionais e não funcionais.

Figura 7. Arquitetura de integração entre aplicação e serviço.

Análise das decisões arquiteturais da camada de comunicação

A terceira e última parte da arquitetura do sistema é a camada de comunicação. A Figura 8 ilustra os objetos que compõem a comunicação entre a camada de integração e os serviços.

De forma sucinta, o primeiro objeto contém drivers e conexão (conectores) e através de um provedor de acesso o conector sincroniza com o serviço de comunicação, que executa uma chamada ao serviço de operação. O serviço de operação é o componente que contém as regras de negócio e acesso a base de dados. Esses serviços foram cuidadosamente analisados e separados em várias partes de um determinado processo de negócio, isto é, buscando atingir a granularidade ideal para alcançar os benefícios de reutilização e governança dos componentes (meet-in-the-middle).

Esta camada auxilia no atendimento ao atributo de qualidade "manutenibilidade". Considerando que a manutenção dos serviços serão feitas separadamente, eliminando a necessidade de execução de testes de regressão em todo o sistema, e também facilitando a publicação das alterações.

Figura 8. Arquitetura de comunicação

Brainstorm e priorização dos cenários

Nesta etapa foram mapeados todas as decisões do projeto para cada cenário de alta prioridade na árvore de utilidade. Várias questões foram associadas a cada decisão do projeto arquitetural relacionada com os atributos de qualidade em seus respectivos cenários. Também foi criada uma lista de considerações feitas pelos arquitetos para cada questionamento. Em vista disso, foram registrados todos os riscos, não-riscos, pontos de sensibilidade e tradeoffs identificados. A Tabela 1 apresenta os participantes desta etapa.

Participantes

Tabela 1. Membros do comitê de brainstorm.

Foram criados cenários para cada atributo de alta prioridade da árvore de utilidades. A Tabela 2 apresenta o cenário para o atributo "modificabilidade". A Tabela 3 apresenta um cenários para o item "integração", enquanto a Tabela 4 implementa um cenário para o atributo "manutenibilidade".

Tabela 2. Cenário para atributo de modificabilidade.

Tabela 3. Cenário para atributo de integração.

Tabela 4. Cenário para atributo de manutenibilidade.

Resultados obtidos

Através deste estudo de caso pode-se avaliar que a evolução da arquitetura do software para o mercado de concessão de crédito imobiliário e automóveis, utilizando SOA, dividiu sistemas complexos em partes menores e com finalidades específicas. Isto possibilitou a alocação de equipamentos em espaços físicos distintos, além de permitir a divisão de responsabilidades entre as equipes de desenvolvimento.

Também atingiu os objetivos almejados pela companhia: na reutilização de recursos e funcionalidades já implementadas em outros processos da empresa; facilidade de manutenção em regras de negócio organizadas em componentes com baixa granularidade; desenvolvimento de novas funcionalidades que possam acompanhar a flexibilidade e dinamismo do mercado; além de suportar o crescimento horizontal da aplicação (arquitetura escalável).

O projeto teve duração de quase dois anos, durante esse período, a equipe enfrentou inúmeros problemas técnicos e funcionais (entendimento do negócio), oriundos de um processo doloroso de modernização de software, contudo, essa abordagem resultou o menor esforço na integração de sistemas com diferentes empresas, pois segue um padrão de comunicação conhecido e já consolidado no mercado. Outro padrão que permitiu a equipe de desenvolvimento tornar-se mais efetiva em tarefas de manutenção foi o MVC nas aplicações de front-end.

Conclusão

A avaliação aplicada seguindo o método ATAM ajudou a expor os riscos arquitetônicos que potencialmente inibiriam a realização dos objetivos estratégicos de negócio. Além disso, o resultado revelou o quão a arquitetura poderá satisfazer os objetivos peculiares de um projeto, mas também forneceu uma introspecção sobre como os objetivos de qualidade interagem uns com os outros.

Sobre os autores

Flávio Mariotti é mestre em Engenharia da Computação com ênfase em Engenharia de Software pelo IPT/USP. Pós-Graduado pelo Instituto Brasileiro de Tecnologia Avançada IBTA em Engenharia de Software baseado em SOA. Bacharel em Sistemas de Informação pela UNIUBE e Técnico em Processamento de Dados pelo UniFeb. Brazil Architecture Manager na CSC - Computer Sciences Corporation, Professor Universitário para cursos de pós-graduação na FIAP, Articulista, Palestrante e Consultor especializado em desenvolvimento de software orientado em arquiteturas OO, SOA, GIS, Mobile, Cloud Computing.

Paulo André é bacharel em Análise de Sistemas e Mestrando em Engenharia da Computação. Tem trabalhado com metodologia ágil, arquitetura corporativa, sistema distribuídos de alta performance e escaláveis horizontalmente, fazendo também a gestão de times. Hoje é CTO da Dress / Go.

Referências

1. BROWN, A. W.; JOHNSTON, S. K.; LARSON, G.; PALISTRANT, J. SOA Development Using the IBM Rational Software Development Platform. IBM Press, 2005, 36p.

2. BURCECK, S. Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC). 1992, Disponível em: <http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html>. Acessado em: 22 nov. 2013.

3. COPELAND, T.; WESTON, J. Financial Theory and Corporate Policy. Addison-Wesley 3 edição. 1988, 946p.

4. ELTON E. J.; GRUBER E. J.; BROWN S. J.; GOETZMANN W. N. (2013) Modern Portfolio Theory and Investment Analysis, John Wiley / Sons, New York, 2006. Wiley, 7rd edição, 752p.

5. ERIC, M. A.; MICHAEL, B. (2006). Service Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology. 384p.

6. ERL, T. (2009) SOA Principles of Service Design. Prentice Hall. 1 edição.

7. KENNETH, L.; TRAVER. C. G. E-Commerce 2012: business, technology and society. Prentice Hall, 2011.

8. NUNES, J. C.; CAVIQUE, L. Plano de Marketing: estratégia em ação. Dom Quixote, 2004.

9. PILBEAM, K. Finance and Financial Markets. Palgrave Macmillan 3 edição. 2010, 444p.

10. REENSHAUG, T. (1979) MVC <http://heim.ifi.uio.no/~trygver/themes/mvc/ mvc-index.html>. Acessado em: 01/12/2013.

11. SAP (2012) Enrich Customer Experience with Multichannel Commerce on a Single Platform. CMP19223.

12. TUROLLA, F. A.; GABRIELLI, M. F.; GONDIM, I. J; Crédito e financiamento à infraestrutura no Brasil. Revista Tecnologia de Crédito, Setembro, 2013, página 39-48. Número 85. Serasa Experian. Disponível em: <http://www.serasaexperian.com.br/revista-tecnologia-de-credito/pdf/Revista_Tecnologia_de_Credito_85_WEB.pdf>. Acessado em: 11 dez. 2013.

13. ZHU, H. Software Design Methodology. Great Britian: Elsevier Butterworth-Heinemann, 2005, 368p.

14. TUROLLA, F. A.; GABRIELLI, M. F.; GONDIM, I. J; Crédito e financiamento à infraestrutura no Brasil. Revista Tecnologia de Crédito, Setembro, 2013, página 39-48. Número 85. Serasa Experian. Disponível em: <http://www.serasaexperian.com.br/revista-tecnologia-de-credito/pdf/Revista_Tecnologia_de_Credito_85_WEB.pdf>. Acessado em: 11 dez. 2013.