Blog

Revista de Gestão da Tecnologia e Sistemas de Informação Journal of Information Systems and Technology Management vol. 3, No. 1, 2006, p. 19-34 ISSN online: 1807-1775 BENEFICIOS DA ARQUITETURA DE SOFTWARE ORIENTADA A SERVIÇOS PARA AS EMPRESAS: ANÁLISE DA EXPERIÊNCIA DO ABN AMRO BRASI BENEFITS OF SOFWVARE-ORIENTED ARCHITECTURE TO CORPORATE SERVICES: AN ANALYSIS OF ABN AMRO BANK EXPERIENCE IN BRAZIL Prof. Dr. José Osvaldo De Sordi Universidade Católic Profa. Dra.

Bernadet Universidade de São Marcio Nagy ABN AMRO Bank ara ABSTRACT 2 ul p Software architecture is a major enabler in providing effective rofits related to agility and efficiency in corporate information systems maintenance and evolution: a key factor in competitive environments. The benefits resulting from the adoption of software- oriented architecture (SOA) are demonstrated in this article through the analysis of a practical case ofits implementation in the financial institution: ABN AMRO, in Brazil.

The case describes how the institution solved a traditional dilemma faced by financial institutions: the composition and Integration of financial services delivered through software to different communications hannels made available to clients. proporcionados pela adoção da arquitetura de software orientada a serdiços são evidenciados neste artigo por meio da análise de um caso prático de sua implementação na instituiçao financeira ABN AMRO Brasil.

O caso apresenta como a instituição conseguiu resolver um dilema tradicional das Instituições financeiras: a composição e integração dos serviços financeiros, entregues por meio de software nos diferentes canais de comunicação disponíveis aos clientes. Recebido em/Manuscript first received: 1 9/12/2005 Aprovado em/ Manuscript accepted: 30/04/2006 Endereço para correspondência/ Address for correspondence Prof. Dr. José Osvaldo De Sordi Universidade Católica de Santos – Depto pesq- Mestrado em Gestão de Negócios Rua Dr.

Carvalho de Mendonça, 144 – Santos/SP, CEP 11070-906 Tel. : (13) 3226-0504 Fax: (13) 3226-0500 e-mail: de. sordi@terra. com. br Profa. Dra. Bernadete de Lourdes Marinho Universidade de São Paulo (USP) – Depto de Administração FEA-USP AV. prof. Luciano Gualberto, 908 – sao pau10/SP, CEP 05508-900 Fone e Fax: (11) 3815-6189 e-mail: marinhoy@usp. br Marcio Nagy ABN AMRO Bank Brasil Departamento de Arquitetura e Infra-estrutura Corporativa AV. paulista, 1374 – sao pau10/SP, CEP 01310-916 Tel. : (11) 4523-1419 Fax: (11) 4523-1419 e-mail: marciog@br. bnamro. com publicado porpublished by: TECSI FEA USP – 2006 20 Sordi, J. , Marinho, B. , Nagy, M. Palavras-chave: Arquitetura de Software; Integração entre Sistemas; Orientação a Se 2 32 resultados de uma pesquisa que teve como objeto central de estudo a arquitetura de software orientada a serviços (SOA). A finalidade da pesquisa foi discutir os benefícios e a importância da SOA às organizações. A apresentação do tema e sua justificativa são realizadas nos dois próximos capítulos.

No segundo, são apresentados e conceituados os diversos termos necessários ao entendimento da SOA como: arquitetura de software, serviço dentro do contexto da arquitetura de software, tipificação de serviços e a caracterização dos estágios de maturidade da SOA. No terceiro capítulo, justifica-se a relevância da presente pesquisa, analisando-se a importância da SOA ao atendimento dos principais requisitos dos atuais e dinâmicos ambientes de negócios.

Conceituado e justificado o objeto da pesquisa, encontra-se no quarto cap[tulo a caracterização do trabalho: a descrição da oportunidade, dos bjetivos, do método empregado e do universo da pesquisa realizada. Como o método de pesquisa adotado foi o estudo de caso, no quinto capitulo, há a apresentação e descrição do caso analisado. Os principais conhecimentos com a pesquisa estão retratados nos dois últimos capítulos.

No sexto capítulo, são discutidas as lições aprendidas a partir da experiência do caso analisado e, no sétimo e último capítulo, são apresentadas as conclusões finais, debatido, de forma abrangente, o potencial de agregação de valor da SOA aos negoclos. 2- CONCEITOS SOBRE AAR UITETURA DE SOFMARE ORI ENTADA A 32 software” ao longo dos últimos anos, o que demonstra um interesse saudável não apenas das organizações, mas também das academias.

Descrevemos, a seguir, algumas dessas definições: “A arquitetura de software de um programa ou de um sistema computacional é a estrutura ou as estruturas do sistema, que compreende elementos de software, as propriedades visíveis e externas desses elementos, e as relações entre eles. ” (BASS, CLEMENTS e KAZMAN, 2003, p. 14, tradução nossa); “Arquitetura é o termo que muitas pessoas tentam definir com pouca concordância. Há dois elementos comuns: um deles trata do mais alto nível de quebra de um sistema em partes; o outro trata de uma decisão dificil de ser mudada. ” (FOWLER, 2002, p. 7, tradução nossa); “A arquitetura de software é um conjunto de declarações, que descreve os componentes de software e atribui funcionalidades de sistema para cada um deles. Ela descreve a estrutura técnica, limitações e características dos Revista de Gestão da Tecnologia e Sistemas de Informação/ Benefícios da Arquitetura de Software Orientada a Serviços para as Empresas: Análise da Experiência do ABN 21 AMRO Brasil componentes, bem como as interfaces entre eles. A arquitetura é o esqueleto do sistema e, por isso, torna-se o plano de mais alto-nível da construção de cada A, 2004, p. 6, traducao novo sistema. ” (KRAFZIG, 4 32 comumente encontrado em quantidade nas organizações. Ele apresenta um nível de especificidade bastante pontual e restrita. Um exemplo seriam os algoritmos para validação de números ou de status, como os utilizados na validação do número do CPF e na averiguação da situação de crédito de uma pessoa. Um serviço também pode ser um algoritmo mais abrangente, em ermos de funcionalidades, sendo assim, denominado de “serviço centrado em processo”.

No ambiente computacional, há diversas outras variações de serviços; no Quadro 1 é apresentada uma tipificação de serviços desenvolvida por Krafzig, Banke e Slama (2004). Outra entidade importante na SOA é o application frontend. Mesmo não sendo um serviço, trata-se de um elemento ativo da SOA É ele que inicia todos os processos de negócios e recebe seus resultados. Na prática, esta entidade é caracterizada pelas diversas aplicações que interagem com o usuário final (web applications, GUI applications, CICS applications etc) ou mesmo os programas que processam lotes de dados (sistemas batch).

A análise e compreensão do application frontend é fundamental para o entendimento dos estágios de maturidade da SOA nas organizações e que serão analisados a seguir: Quadro 1 – Tipificação de serviços encontrados na SOA ATRIBUTOS DOS SERVIÇOS Descrição TIPOS DE SERVIÇOS Serviço De baixa a moderada De moderada a alta Alta Especifica de cada serviço Gerenciamento de Estado Não Nao Sim Específica de cada “Reusabilidade” Baixa Frequência da Mudança 6 OF32 frontend orna-se menor e menos complexo que no SOA fundamental.

Suas maiores vantagens são os ganhos de flexibilidade ao utilizar aplicações entre unidades de negócios e entre diferentes organizações; SOA habilitadora de processos: neste estágio, os application frontend são utilizados apenas para interação com o usuário. Toda complexidade dos processos de negócios é delegada à SOA mais especificamente, aos serviços centrados em processos.

Há uma forte separação entre as regras para gestão do processo de negócio, desempenhada pelos serviços centrados em processos, e os códigos fontes de programas necessários ara a sua execução, disponibilizados na forma de serviços básicos para execução dos algoritmos e na forma de application frontend para as interações requeridas.

Os estágios de maturidade divergem, sobretudo, na distribuição de responsabilidades entre o application frontend e os serviços. Quanto mais evoluído o estágio da SOA, mais e mais responsabilidades são transferidas aos serviços, tornando os softwares aplicados aos negócios cada vez mais diferentes dos sistemas monolíticos, predominantes há décadas nas organizações. uma organização pode vivenciar simultaneamente dois ou três stágios de maturidade da SOA.

Isto se explica de ntes escopos e provê facilidades para o descobrimento dos serviços disponíveis na arquitetura, sobretudo daqueles fora do escopo temporal e funcional do sistema de informação, ou melhor, do processo de desenvolvimento do nosso sistema. Ele fornece informações como: localização virtual, provedor, taxas, limitações técnicas, aspectos de segurança, entre outras. O barramento de serviços é o meio utilizado para conexão entre todos os participantes da SOA (serviços e application frontends) e engloba uma grande diversidade de produtos e conceitos.

Apresentados todos os conceitos necessários para entendimento do SOA, pode-se agora trabalhar sua definição: “A arquitetura de software orientada a serviços (SOA) está fundamentada nos conceitos-chave de application frontend, serviço, repositório de serviço e as Empresas: Análise da Experiência do ABN 23 barramento de serviço. ” (KRAFZIG, BANKE e SLAMA, 2004, p. 57, tradução nossa).

Institutos de pesquisas conceituados na área de tecnologia da informação indicam que a arquitetura de software orientada a serviços (SOA) terá grande influência no processo de desenvolvimento dos sistemas de informação. O Instituto Gartner, por exemplo, div 8 32 ARQUITETURA DE SOFTWARE PARA A GESTAO DAS EMPRESAS Na mesma proporção em que os sistemas de informação tornam- se cada vez mais complexos e abrangentes, cresce em importância e em dificuldade o trabalho de organização e estruturação de seus componentes.

Assim, algoritmos e estruturas de dados deixaram de ser o ponto mais critico do projeto de construção de sistema de informação, em função da diversidade de modelos aplicáveis com a chegada da definição da arquitetura de software. Por ser uma das primeiras fases do ciclo de desenvolvimento de oftware, com forte influência nos trabalhos posteriores de construção, integração e modificação dos componentes do software, a arquitetura de software mostra-se capaz de proporcionar grande variação no retorno do investimento, realizado em software, considerando-se: qualidade, prazos e custos. BASS, CLEMENTS e KAZMAN, 2003, p. 12). A arquitetura de software das corporações deve ser: simples (para que todos seus intervenientes possam entendê-la e utilizá-la); flexível (para que possa acomodar em tempo as dinâmicas alterações requeridas pelo ambiente de negócios); eradora de reutilização (sobretudo dos blocos de softwares); e ser capaz de desvincular funcionalidades do negócio das tecnologias utilizadas para sua execução.

A arquitetura de software é uma das principais habilitadoras em termos de proporcionar ganhos efetivos em agilidade e eficiência na manutenção e evolução dos sistemas de informação cor orativos fator preponderante para ambientes competitivos. Um dos principais deles é a forte integração que se estabelece entre: programas, tabelas, filas de mensagens e demais componentes dos diversos sistemas de informação da corporação.

Na abordagem tradicional de desenvolvimento de software, em que se discute superficialmente a arquitetura de software, o trabalho de integração entre sistemas de informação é realizado pontualmente como uma fase do projeto. Cada nova necessidade de integração é considerada como um problema local e único (RUH, MAGINNIS e BROWN, 2001, p. 12).

O engenheiro de software, responsável pelo desenvolvimento do novo sistema de informação, analisa, especifica e gerencia o desenvolvimento das integrações requeridas. Estas são entregues, na maioria das vezes, na forma de adaptação nos softwares dos sistemas e informação a serem integrados, estabelecendo um forte vínculo entre estes. Esse método de integrar sistemas gera uma situação indesejada que se denomina “perpetuação dos sistemas de informação legados”.

Cada novo sistema, que referencia diretamente a um antigo sistema, vol. 3, No. 1, 2006, p 19-34. 24 sordi,J. , Marinho, 3. , Nagy, M. torna mais custoso, trabalhoso e arriscado o processo de substituição deste sistema legado, devido ao impacto em todos os demais sistemas, inclusive nos mais recentes (BUTLER. 1999, p. 19). Considerando-se apenas a falta ou inadequação das integrações entre sistemas de 0 DF 32