Revista de Gesto da Tecnologia e Sistemas de Informao Journal of Information Systems and Technology Management Vol. 3, No. 1, 2006, p.

19-34 ISSN online: 1807-1775

BENEFCIOS DA ARQUITETURA DE SOFTWARE ORIENTADA A SERVIOS PARA AS EMPRESAS: ANLISE DA EXPERINCIA DO ABN AMRO BRASIL
BENEFITS OF SOFTWARE-ORIENTED ARCHITECTURE TO CORPORATE SERVICES: AN ANALYSIS OF ABN AMRO BANK EXPERIENCE IN BRAZIL Prof. Dr. Jos Osvaldo De Sordi Universidade Catlica de Santos Profa. Dra. Bernadete de Lourdes Marinho Universidade de So Paulo Marcio Nagy ABN AMRO Bank Brasil ABSTRACT
Software architecture is a major enabler in providing effective profits 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 of its 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 channels made available to clients. KEYWORDS: Software Architecture; Integration between Information Systems; Service Orientation; Banks; Banking Services.

RESUMO
A arquitetura de software um dos principais habilitadores em proporcionar ganhos efetivos em agilidade e eficincia na manuteno e evoluo dos sistemas de informao corporativos, fator preponderante para ambientes competitivos. Os benefcios proporcionados pela adoo da arquitetura de software orientada a servios so evidenciados neste artigo por meio da anlise de um caso prtico de sua implementao na instituio financeira ABN AMRO Brasil. O caso apresenta como a instituio conseguiu resolver um dilema tradicional das instituies financeiras: a composio e integrao dos servios financeiros, entregues por meio de software nos diferentes canais de comunicao disponveis aos clientes.

_____________________________________________________________________________________
Recebido em/Manuscript first received: 19/12/2005 Aprovado em/Manuscript accepted: 30/04/2006 Endereo para correspondncia/ Address for correspondence Prof. Dr. Jos Osvaldo De Sordi Universidade Catlica de Santos - Depto Pesq. Mestrado em Gesto de Negcios Rua Dr. Carvalho de Mendona, 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 So Paulo (USP) - Depto de Administrao FEA-USP Av. Prof. Luciano Gualberto, 908 So Paulo/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 - So Paulo/SP, CEP 01310-916 Tel.: (11) 4523-1419 Fax: (11) 4523-1419 e-mail: marciog@br.abnamro.com ISSN online: 1807-1775 Publicado por/Published by: TECSI FEA USP 2006

20 Sordi, J., Marinho, B., Nagy, M. Palavras-chave: Arquitetura de Software; Integrao entre Sistemas; Orientao a Servios; Bancos; Servios Bancrios.

1 - INTRODUO Este texto descreve os resultados de uma pesquisa que teve como objeto central de estudo a arquitetura de software orientada a servios (SOA). A finalidade da pesquisa foi discutir os benefcios e a importncia da SOA s organizaes. A apresentao do tema e sua justificativa so realizadas nos dois prximos captulos. No segundo, so apresentados e conceituados os diversos termos necessrios ao entendimento da SOA, como: arquitetura de software, servio dentro do contexto da arquitetura de software, tipificao de servios e a caracterizao dos estgios de maturidade da SOA. No terceiro captulo, justifica-se a relevncia da presente pesquisa, analisando-se a importncia da SOA ao atendimento dos principais requisitos dos atuais e dinmicos ambientes de negcios. Conceituado e justificado o objeto da pesquisa, encontra-se no quarto captulo a caracterizao do trabalho: a descrio da oportunidade, dos objetivos, do mtodo empregado e do universo da pesquisa realizada. Como o mtodo de pesquisa adotado foi o estudo de caso, no quinto captulo, h a apresentao e descrio do caso analisado. Os principais conhecimentos com a pesquisa esto retratados nos dois ltimos captulos. No sexto captulo, so discutidas as lies aprendidas a partir da experincia do caso analisado e, no stimo e ltimo captulo, so apresentadas as concluses finais, debatido, de forma abrangente, o potencial de agregao de valor da SOA aos negcios. 2 CONCEITOS SOBRE A ARQUITETURA DE SOFTWARE ORIENTADA A SERVIOS Pesquisadores e praticantes da rea de administrao de sistemas de informao tm desenvolvido muitas definies para o termo arquitetura de software ao longo dos ltimos anos, o que demonstra um interesse saudvel no apenas das organizaes, mas tambm das academias. Descrevemos, a seguir, algumas dessas definies: 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 visveis e externas desses elementos, e as relaes entre eles. (BASS, CLEMENTS e KAZMAN, 2003, p. 14, traduo nossa); Arquitetura o termo que muitas pessoas tentam definir com pouca concordncia. H dois elementos comuns: um deles trata do mais alto nvel de quebra de um sistema em partes; o outro trata de uma deciso difcil de ser mudada. (FOWLER, 2002, p. 27, traduo nossa); A arquitetura de software um conjunto de declaraes, que descreve os componentes de software e atribui funcionalidades de sistema para cada um deles. Ela descreve a estrutura tcnica, limitaes e caractersticas dos
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management

Benefcios da Arquitetura de Software Orientada a Servios para as Empresas: Anlise da Experincia 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-nvel da construo de cada novo sistema. (KRAFZIG, BANKE e SLAMA, 2004, p. 56, traduo nossa). Para conceituar o objeto central do estudo, a arquitetura de software orientada a servios (SOA) faz-se necessrio desenvolver o termo servio dentro do contexto da arquitetura de software. O servio bsico o mais comumente encontrado em quantidade nas organizaes. Ele apresenta um nvel de especificidade bastante pontual e restrita. Um exemplo seriam os algoritmos para validao de nmeros ou de status, como os utilizados na validao do nmero do CPF e na averiguao da situao de crdito de uma pessoa. Um servio tambm pode ser um algoritmo mais abrangente, em termos de funcionalidades, sendo assim, denominado de servio centrado em processo. No ambiente computacional, h diversas outras variaes de servios; no Quadro 1 apresentada uma tipificao de servios desenvolvida por Krafzig, Banke e Slama (2004). Outra entidade importante na SOA o application frontend. Mesmo no sendo um servio, trata-se de um elemento ativo da SOA. ele que inicia todos os processos de negcios e recebe seus resultados. Na prtica, esta entidade caracterizada pelas diversas aplicaes que interagem com o usurio final (web applications, GUI applications, CICS applications etc) ou mesmo os programas que processam lotes de dados (sistemas batch). A anlise e compreenso do application frontend fundamental para o entendimento dos estgios de maturidade da SOA nas organizaes e que sero analisados a seguir: Quadro 1 Tipificao de servios encontrados na SOA
ATRIBUTOS DOS SERVIOS TIPOS DE SERVIOS Servio Bsico Servio simples centrado em dados ou lgica Servio Intermedirio Conectores e adaptadores tecnolgicos e servios para adio de funcionalidades De moderada a alta Servio Centrado em Processo Servio Empresarial Servio compartilhado com outras empresas ou parceiros Especfica de cada servio Especfica de cada servio Alta

Descrio

Encapsula a lgica do processo

Complexidade da implementao Gerenciamento de Estado Reusabilidade Freqncia da Mudana Elemento Requerido ao SOA

De baixa a moderada No

Alta

No

Sim

Alta

Baixa

Baixa

Baixa

De moderada a alta

Alta

Baixa

Sim

No

No

No

Fonte: adaptado de Krafzig, Banke e Slama (2004)

Vol. 3, No. 1, 2006, p 19-34.

22 Sordi, J., Marinho, B., Nagy, M.

Krafzig, Banke e Slama (2004) identificaram trs estgios de maturidade da SOA nas organizaes: a fundamental, a em rede e a habilitadora de processos assim descritos: SOA fundamental: o melhor ponto de partida para as organizaes que pretendem implantar a SOA. A maior parte da complexidade e da responsabilidade continua existindo ainda no application frontend, que aciona os diversos servios bsicos. Este estgio j proporciona ganhos significativos pelas facilidades de reutilizao de servios bsicos. Seus maiores benefcios so os ganhos de manuteno com as aplicaes internas de departamentos e com as aplicaes entre departamentos; SOA em rede: h o uso intensivo de servios intermedirios; estes agregam servios bsicos na forma de servios mais sofisticados. Os servios intermedirios so amplamente utilizados para atender deficincias tcnicas e funcionais dos softwares disponveis na arquitetura. Os servios intermedirios, enquanto desempenham o papel de conectores e adaptadores, oferecem muita flexibilidade para integrao entre softwares, independentemente das restries tecnolgicas. O application frontend torna-se menor e menos complexo que no SOA fundamental. Suas maiores vantagens so os ganhos de flexibilidade ao utilizar aplicaes entre unidades de negcios e entre diferentes organizaes; SOA habilitadora de processos: neste estgio, os application frontend so utilizados apenas para interao com o usurio. Toda complexidade dos processos de negcios delegada SOA, mais especificamente, aos servios centrados em processos. H uma forte separao entre as regras para gesto do processo de negcio, desempenhada pelos servios centrados em processos, e os cdigos fontes de programas necessrios para a sua execuo, disponibilizados na forma de servios bsicos para execuo dos algoritmos e na forma de application frontend para as interaes requeridas.

Os estgios de maturidade divergem, sobretudo, na distribuio de responsabilidades entre o application frontend e os servios. Quanto mais evoludo o estgio da SOA, mais e mais responsabilidades so transferidas aos servios, tornando os softwares aplicados aos negcios cada vez mais diferentes dos sistemas monolticos, predominantes h dcadas nas organizaes. Uma organizao pode vivenciar simultaneamente dois ou trs estgios de maturidade da SOA. Isto se explica devido aos diferentes escopos e necessidades de integrao, requeridos entre reas de negcios, empresas e integraes complexas de processos. Antes de concluir com os conceitos, h a necessidade de se definirem mais dois componentes fundamentais para o entendimento da arquitetura SOA: o repositrio de servios e o barramento de servios. O repositrio de servios a entidade que prov facilidades para o descobrimento dos servios disponveis na arquitetura, sobretudo daqueles fora do escopo temporal e funcional do sistema de informao, ou melhor, do processo de desenvolvimento do nosso sistema. Ele fornece informaes como: localizao virtual, provedor, taxas, limitaes tcnicas, aspectos de segurana, entre outras. O barramento de servios o meio utilizado para conexo entre todos os participantes da SOA (servios e application frontends) e engloba uma grande diversidade de produtos e conceitos. Apresentados todos os conceitos necessrios para entendimento do SOA, pode-se agora trabalhar sua definio: A arquitetura de software orientada a servios (SOA) est fundamentada nos conceitos-chave de application frontend, servio, repositrio de servio e
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management

Benefcios da Arquitetura de Software Orientada a Servios para as Empresas: Anlise da Experincia do ABN 23 AMRO Brasil

barramento de servio. (KRAFZIG, BANKE e SLAMA, 2004, p. 57, traduo nossa). Institutos de pesquisas conceituados na rea de tecnologia da informao indicam que a arquitetura de software orientada a servios (SOA) ter grande influncia no processo de desenvolvimento dos sistemas de informao. O Instituto Gartner, por exemplo, divulga que, at 2008, com 70% de probabilidade, teremos a SOA como prtica predominante de engenharia de software, colocando fim a mais de quarenta anos de desenvolvimento de software tradicional e suas arquiteturas de software monoltico (GARTNER, 2003). 3 IMPORTNCIA DA ARQUITETURA DE SOFTWARE PARA A GESTO DAS EMPRESAS Na mesma proporo em que os sistemas de informao tornam-se cada vez mais complexos e abrangentes, cresce em importncia e em dificuldade o trabalho de organizao e estruturao de seus componentes. Assim, algoritmos e estruturas de dados deixaram de ser o ponto mais crtico do projeto de construo de sistema de informao, em funo da diversidade de modelos aplicveis com a chegada da definio da arquitetura de software. Por ser uma das primeiras fases do ciclo de desenvolvimento de software, com forte influncia nos trabalhos posteriores de construo, integrao e modificao dos componentes do software, a arquitetura de software mostra-se capaz de proporcionar grande variao 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 corporaes deve ser: simples (para que todos seus intervenientes possam entend-la e utiliz-la); flexvel (para que possa acomodar em tempo as dinmicas alteraes requeridas pelo ambiente de negcios); geradora de reutilizao (sobretudo dos blocos de softwares); e ser capaz de desvincular funcionalidades do negcio das tecnologias utilizadas para sua execuo. A arquitetura de software uma das principais habilitadoras em termos de proporcionar ganhos efetivos em agilidade e eficincia na manuteno e evoluo dos sistemas de informao corporativos, fator preponderante para ambientes competitivos. Uma arquitetura de software inadequada gera diversos problemas tecnolgicos que refletem diretamente na gesto das organizaes. Um dos principais deles a forte integrao que se estabelece entre: programas, tabelas, filas de mensagens e demais componentes dos diversos sistemas de informao da corporao. Na abordagem tradicional de desenvolvimento de software, em que se discute superficialmente a arquitetura de software, o trabalho de integrao entre sistemas de informao realizado pontualmente como uma fase do projeto. Cada nova necessidade de integrao considerada como um problema local e nico (RUH, MAGINNIS e BROWN, 2001, p. 12). O engenheiro de software, responsvel pelo desenvolvimento do novo sistema de informao, analisa, especifica e gerencia o desenvolvimento das integraes requeridas. Estas so entregues, na maioria das vezes, na forma de adaptao nos softwares dos sistemas de informao a serem integrados, estabelecendo um forte vnculo entre estes. Esse mtodo de integrar sistemas gera uma situao indesejada que se denomina perpetuao dos sistemas de informao legados. Cada novo sistema, que referencia diretamente a um antigo sistema,
Vol. 3, No. 1, 2006, p 19-34.

24 Sordi, J., Marinho, B., Nagy, M.

torna mais custoso, trabalhoso e arriscado o processo de substituio 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 inadequao das integraes entre sistemas de informao proporcionados pela arquitetura de software tradicional, pode-se identificar diversas situaes desconfortveis gesto das organizaes, conforme indicado por Cummins (2002) e De Sordi (2005): A perda de competitividade em funo da incapacidade de reduzir o tempo dos processos pelas limitaes das integraes empregadas. Por exemplo, pelo uso de conexes assncronas que ocorrem atravs de transmisso de pacotes de dados em perodos de tempo pr-estabelecidos; Restringe a capacidade da organizao em se habilitar como fornecedor ou parceiro estratgico de redes e ambientes colaborativos que exigem das entidades participantes o domnio de modernas tecnologias de integrao; Eleva custos e aumenta o risco de exposio a erros em decorrncia do trabalho humano intensivo na redigitao de dados de uma base ou de um sistema de informao para outra base ou sistema; Lentido na organizao em identificar e tratar eventos do negcio possveis de serem percebidos pela comunicao de ocorrncias registradas em outros sistemas de informao, limitando a capacidade de inovao e pr-atividade da empresa; Dificulta a evoluo e aprimoramento dos processos de negcios em funo de se evitar a alterao das tradicionais integraes de sistemas existentes ao longo do processo, postura justificada pelos altos custos e pelos receios de se gerar novos problemas, no momento da alterao destes meios legados de integrao.

4 OPORTUNIDADE, OBJETIVO, MTODO E UNIVERSO DA PESQUISA Ao considerar: 1) a flexibilidade e demais ganhos proporcionados s organizaes pela arquitetura de software orientada a servios; 2) a falta de estudos da Academia Brasileira de Administrao sobre o tema arquitetura de software, na perspectiva do administrador de sistemas de informao; e 3) do pouco conhecimento de como as grandes corporaes brasileiras esto lidando com a SOA; identificou-se uma oportunidade de pesquisa: investigar uma experincia significativa de implementao da SOA no contexto de uma grande organizao brasileira. Da percepo da oportunidade, derivou-se o objetivo primrio da pesquisa: analisar uma experincia de implementao da SOA em uma grande corporao brasileira, com reconhecida tradio de investimentos de vanguarda na rea de tecnologia da informao. Para assim, identificar aspectos importantes de serem observados durante a introduo da SOA em uma organizao. A opo por escolher uma organizao com reconhecida tradio em investimentos em tecnologia da informao deve-se ao fato dos pesquisadores considerarem os ambientes de negcios mais familiares ou divulgados, como tambm os mais atrativos e compreensveis aos praticantes e pesquisadores da rea de administrao de sistemas de informao. Ao ponderar o universo da pesquisa, apenas uma organizao, definiu-se como objetivo secundrio: a composio de um conjunto de informaes suficientemente detalhados e significantes para que, no apenas se compreendam os conceitos bsicos da SOA, mas tambm possam servir de comparao e extrapolao da realidade do caso estudado, para o contexto de outras
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management

Benefcios da Arquitetura de Software Orientada a Servios para as Empresas: Anlise da Experincia do ABN 25 AMRO Brasil

organizaes ou de outros segmentos de negcios, colaborando, assim, para um processo de melhor compreenso da SOA no contexto das corporaes brasileiras. Para atender os objetivos propostos, optou-se por desenvolver uma pesquisa predominantemente qualitativa, utilizando o mtodo descritivo e exploratrio, baseado em um estudo de caso. O mtodo de estudo de caso particularmente adequado para gerao e construo de teorias, sobretudo, em reas de estudos em que haja poucos dados e teorias (YIN, 1994). Neste aspecto, o estudo de caso se aplica de forma muito oportuno ao estudo da SOA no contexto das organizaes brasileiras, uma vez que pouco se conhece sobre seus fundamentos e seus benefcios proporcionados gesto das empresas que a adotam. Para definio da organizao a se pesquisar por intermdio do mtodo de estudo de caso considerou-se: a) haver alguma experincia significativa com SOA em andamento na organizao; b) atuar em um segmento de mercado em que houvesse conhecimento da academia quanto ao comportamento de investimentos com relao aos recursos de tecnologia da informao; e, finalmente, c) ter viabilidade organizacional para realizao da pesquisa, ou seja, disponibilidade e interesse da organizao em participar da pesquisa. A empresa pesquisada Da aplicao dos critrios para definio do caso a ser pesquisado, chegou-se ao segmento bancrio, mais especificamente, instituio financeira ABN AMRO Brasil. A instituio ABN AMRO est presente no Brasil desde 1917, quando iniciou suas operaes como Banco Holands da Amrica do Sul, com escritrios nas cidades de Santos e Rio de Janeiro. Em 1998, o ABN AMRO Brasil adquiriu o Banco Real, uma das maiores instituies financeiras do Brasil, na poca. Em 2004, o ABN AMRO Brasil apresentou um lucro lquido de R$ 1.237.000.000 e encerrou este mesmo ano com: 9.200.000 clientes, 1.890 agncias e postos de atendimentos bancrios, 8.179 mquinas de auto-atendimento e 28.571 funcionrios (BANCO REAL, 2005). Os trabalhos de pesquisa junto ao ABN AMRO Brasil consistiram em diversas entrevistas e reunies presenciais e no-presenciais com os profissionais da rea de Arquitetura e Infra-estrutura Corporativa da instituio. Esta rea no s a responsvel pela definio de padres da SOA, como tambm pela construo e evoluo do barramento de servios, a serem discutidos na prxima seo. Houve intensa pesquisa documental, tanto de relatrios tcnicos como de documentos de negcios, tanto do perodo de estruturao e concepo da idia, do business plan utilizado para convencimento da organizao, at as diretrizes atuais para operao e evoluo da SOA. 5 INTRODUO DA SOA NO ABN AMRO BRASIL Com o objetivo de atender a diversidade de preferncias e necessidades de seu grande contingente de clientes, o ABN AMRO Brasil foi, ao longo dos ltimos anos, disponibilizando seus servios financeiros por intermdio de diversos canais de comunicao. So ainda pioneiros nos sistemas de informao na rede de caixas das agncias bancrias para uma diversidade de outros canais: pontos de auto-atendimento (quiosques) em locais de convenincia aos usurios, pginas na Internet (Internet banking), correio eletrnico (e-mail
Vol. 3, No. 1, 2006, p 19-34.

26 Sordi, J., Marinho, B., Nagy, M.

banking), telefone (call center), mensagem de texto via celular (WAP) e gerentes que se deslocam at a localidade do cliente (gerente volante). Nem todos os canais disponibilizam todos os tipos de servios, como tambm h diferentes agrupamentos destes num mesmo canal, em funo do tipo de cliente que os utilizam, por exemplo, se pessoa fsica ou jurdica. Os servios financeiros oferecidos apresentam um histrico de forte envolvimento do uso de softwares. Os servios mais utilizados foram os primeiros a receberem investimentos em termos de desenvolvimento de sistemas de informao para sua operao e gerenciamento. Assim, os servios financeiros mais usados hoje so os que empregam os sistemas de informao mais amplamente testados, revisados e tambm de maior longevidade. H sistema em operao cujo desenvolvimento inicial data do incio da dcada de 70. Cabe ressaltar que a arquitetura destes sistemas composta por um grande e complexo application frontend, que coordena chamadas s diversas funes, todas empacotadas dentro do prprio application frontend, constituindo um grande bloco de cdigo fonte (sistema monoltico). Devido aos requisitos de alto volume de transao, segurana e desempenho computacional, j demandados trs dcadas atrs, fizeram com que os principais servios financeiros tivessem seus sistemas de informao desenvolvidos na plataforma computacional de grande porte (mainframe). As tecnologias empregadas para construo dos sistemas de informao foram: linguagem de programao COBOL e PL1, ambiente transacional CICS e armazenamento de dados em DB2 e ADABAS. Ao longo dos anos, foram sendo desenvolvidos e aprimorados diversos sistemas de informao que passaram a implementar todos os servios financeiros do banco, entre estes, destacam-se os seguintes sistemas: conta-corrente, poupana, investimentos, pagamentos e emprstimos. O amplo uso dos principais servios financeiros nos diversos canais de comunicao fez com que os sistemas de informao utilizados em suas operaes tivessem de estar disponveis e operantes junto aos diferentes canais de interao com os clientes do banco. Os diferentes canais de comunicao foram sendo disponibilizados aos clientes gradativamente ao longo do tempo. medida em que cada novo canal de comunicao era disponibilizado, repetiam-se os esforos de integrao dos diversos sistemas de informao, que implementavam cada um dos principais servios financeiros, com o software de interatividade especfico do novo canal de interao que vinha sendo disponibilizado. Por exemplo, ao desenvolver a soluo de software do Internet banking, em 1999, construram, alm das pginas para interao de usurios via web (application frontend), diversos recursos de software necessrios para integrar a soluo com cada um dos diversos sistemas de informao que executam cada um dos servios oferecidos no Internet banking. Esta repetio de esforos para integrar mltiplos sistemas de informao a mltiplos canais foi um dos motivadores para implementao da SOA no ABN AMRO Brasil. Neste primeiro momento, prevaleceu a necessidade de compartilhar recursos sistemas de informao - com baixo acoplamento e de fcil reutilizao destes, perante os diversos canais. Assim, desenvolveu-se um projeto inicial para construo de uma SOA fundamental, em que os sistemas de informao foram compreendidos como servios bsicos e os softwares desenvolvidos para cada canal como sendo os application frontend.

Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management

Benefcios da Arquitetura de Software Orientada a Servios para as Empresas: Anlise da Experincia do ABN 27 AMRO Brasil

5.1 - Construo da SOA fundamental Uma premissa importante adotada pelo ABN AMRO Brasil, em 1999, poca em que se planejou e construiu a SOA fundamental, quando os sistemas crticos do banco continuariam operando no ambiente computacional de grande porte (mainframe), com ambiente transacional CICS e que, portanto, o barramento de servios tambm deveria, por essa razo, ser disponibilizado no ambiente computacional de grande porte. O ABN AMRO Brasil optou por construir seu prprio barramento de servios, o qual recebeu o nome de JAS/MCI, acrnimos de Java Application Server e Multi Channel Interface. Na poca, analisou-se a opo de compra de barramento de servios na forma de solues prontas, pacotes de software, ferramentas denominadas de middleware ou EAI (Enterprise Application Integration) pela indstria de software. No entanto, as solues analisadas foram identificadas como sendo muito orientadas plataforma baixa, em especial aos sistemas operacionais Windows e UNIX, com muito direcionamento para aplicaes no ambiente Internet, o que no era o foco do ABN AMRO Brasil, cujo desafio era integrar um conjunto de sistemas de informao totalmente residente na plataforma alta (mainframe). O MCI foi construdo com o uso da linguagem de programao COBOL e o sistema de controle de transaes CICS, enquanto que o JAS foi desenvolvido, inicialmente, em C++ e, posteriormente, desenvolvido na linguagem de programao JAVA, seguindo o padro J2EE. O MCI o barramento de servios, principal meio de acesso a todos os servios bsicos (sistemas de informao) residentes no mainframe, enquanto que o JAS conecta os diversos application frontend, construdos em plataforma baixa e disponibilizados via ambiente Internet. A proposta desse conjunto de softwares, muito bem-sucedida, foi de reutilizar e compartilhar os sistemas de informao do banco em diferentes canais, permitindo, inclusive aos usurios finais, us-los via os modernos e prticos recursos do ambiente Internet. A viso geral da estrutura JAS/MCI est descrita na Figura 1.
CANAIS DISPONVEIS (application frontends) MIDDLEWARE JAS/MCI (barramento de servios) SISTEMAS DE INFORMAO (servios bsicos)

Auto Atendimento Caixa de Agncia Call Center e-mail Banking Gerente Volante
REDE PBLICA

REDE PRIVADA

Conta Corrente

J A S

M C I

Poupana

Investimentos

Pagamentos

Internet Banking WAP

Emprstimos

outras plataformas computacionais

plataforma computacional de grande porte (mainframe)

Figura 1 Barramento de servios JAS/MCI conectando diversos sistemas de informao, na forma de servios bsicos, a diversos canais de comunicao.

Vol. 3, No. 1, 2006, p 19-34.

28 Sordi, J., Marinho, B., Nagy, M.

O barramento de servios JAS/MCI entrou em operao em 2000. A tecnologia de integrao anterior era bastante simplificada, uma vez que todos os sistemas de informao que implementavam os servios bancrios e, dois dos trs softwares de canais existentes at ento caixa e auto atendimento estavam hospedados na mesma plataforma computacional e utilizavam o mesmo protocolo de comunicao: SNA LU2, o que proporcionava muitas facilidades como, por exemplo, terminais emularem o ambiente mainframe. O terceiro canal disponvel na poca, o call center, j acedia aos diversos servios por intermdio de componentes de integrao. O fato que definiu a necessidade da construo de um barramento de servios, que pudesse interligar de forma eficaz todos os servios bancrios a todos os atuais e futuros canais disponveis aos clientes, surgiu da necessidade da introduo de mais um novo canal de comunicao com clientes: o canal Internet, denominado de Internet Banking. Este exigia a comunicao bi-direcional entre a baixa plataforma, onde operavam os clientes por intermdio de seus computadores pessoais, conectados Internet, e o ambiente mainframe, em que residiam os sistemas de informao, que implementavam os servios bancrios. Desde ento, o barramento de servios JAS/MCI tem evoludo constantemente, fundamentado nos princpios da reutilizao, defendidos pela orientao a servios. Atendendo ao propsito de apresentar os estgios evolutivos do ABN AMRO Brasil com relao adoo da SOA, apresenta-se na seo seguinte, um exemplo de reutilizao de servios bsicos por outros servios, compondo um servio intermedirio. importante lembrar que a presena dos servios intermedirios caracteriza o segundo estgio de maturidade da SOA, denominado de SOA em rede. 5.2 - Evoluo para SOA em rede Para ilustrar a agregao entre servios bsicos compondo servios mais sofisticados, rotulados de servios intermedirios, caracterstica tpica do segundo estgio de maturidade da SOA, denominada SOA em rede, apresentar-se- nessa seo a descrio da lgica operacional exigida para uma transao de negcio do ABN AMRO Brasil. E, na seqncia, a descrio de como os servios bsicos disponveis na SOA se compem para operacionalizar tal transao. A transao de negcio a ser analisada a transferncia de valor entre contas que caracteriza um dos servios disponveis na SOA. A transao, como um todo, pode ser subdividida em dois sub-processos: autorizar a transao e efetivar transferncia. A seguir so descritas as atividades realizadas nestes dois sub-processos: Sub-processo autorizar transao: 1 atividade verificar saldo da conta-corrente a ser debitada, ou seja, da conta-corrente, origem do recurso financeiro a ser transferido; 2 atividade verificar status da conta-corrente a ser debitada, se h algum bloqueio de movimentao de valores assinalado naquela conta-corrente, por exemplo, conta bloqueada judicialmente, conta paralisada por mais de 180 dias, entre outras situaes que possam bloquear a movimentao de valores de uma conta-corrente; 3 atividade verificar os limites de transferncias, h um limite mximo para o total a ser transferido no dia, como tambm h limites especficos para cada um dos tipos de canais utilizados por questo de segurana. Assim, h um
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management

Benefcios da Arquitetura de Software Orientada a Servios para as Empresas: Anlise da Experincia do ABN 29 AMRO Brasil

limite especfico para o Internet banking, outro para transferncias via call center e um terceiro para transferncias realizadas junto ao caixa da agncia. Sub-processo efetivar transferncia: 1 atividade gravar em um arquivo os dados necessrios para execuo da transferncia autorizada; este arquivo no final do dia ser o insumo (input) para um sistema que processa lotes de dados (sistema batch); 2 atividade realizar transferncia, ou seja, executar o sistema batch que transmite s demais instituies financeiras os dados sobre transferncias solicitadas pelos correntistas do ABN AMRO Brasil. Os servios da SOA utilizados para operacionalizao do sub-processo autorizar transao esto descritos na Figura 2. Note que h um servio bsico para cada uma das trs atividades descritas textualmente para o sub-processo; o servio bsico gerador de cdigo transao especifico para o acompanhamento e segurana da transao, essencial para futuras auditorias que se faam necessrias.
applications frontend
Caixa de Caixa de Agncia Agncia (CICS) (CICS) Call center Call center (CICS) (CICS) Gerente Gerente volante volante (HTML) (HTML) Internet Internet banking banking (HTML) (HTML)

servios intermedirios
Conector transfer. Conector transfer. valores p/ canais valores p/ canais Mainframe (MCI) Mainframe (MCI) Conector transfer. Conector transfer. valores p/ canais valores p/ canais Internet (JAS) Internet (JAS)

Autorizador de Autorizador de transao transao transfer. (MCI) transfer. (MCI)

servios bsicos
Gerador de Gerador de cdigo cdigo transao transao Verificador de Verificador de saldo conta saldo conta corrente corrente Verificador de Verificador de status da status da conta corrente conta corrente Autorizador de Autorizador de limites para limites para transferncia transferncia

Consultar Consultar limites limites permitidos permitidos

Obter valores Obter valores j transferidos j transferidos no dia no dia

Figura 2 Servios acionados para execuo da transao de negcio transferncia de valor entre contas

Para que se possa ter uma anlise estruturada e fundamentada dos ganhos aferidos ao ABN AMRO Brasil pelo alcance do segundo estgio de maturidade da SOA - SOA em rede - necessrio resgatar alguns dos princpios da qualidade de software. Das percepes inicias de Pressman (2004) sobre qualidade de software, aos atuais pesquisadores, como Ghezzi, Jazayeri, Mandrioli (2002), possvel derivar alguns importantes fundamentos da engenharia de software: decomposio do software, permitindo lidar com toda complexidade;
Vol. 3, No. 1, 2006, p 19-34.

30 Sordi, J., Marinho, B., Nagy, M.

generalizao, para reutilizao e reduo de custos; flexibilizao, para permitir mudanas e a evoluo do software; formalismo, til para reduo de inconsistncias; e abstrao, para se considerar o que importante, descartando detalhes. No caso do ABN AMRO Brasil, atingir o estgio de maturidade SOA em rede proporcionou o alcance de alguns benefcios inerentes ao software de qualidade, conforme depoimentos, observaes e constataes realizadas durante a pesquisa. Seguem descries de alguns dos fatos que corroboram com essa afirmao: Os servios bsicos apresentam um nvel de generalizao bastante apropriado, proporcionando aos desenvolvedores de sistemas de informao fcil compreenso da funo e finalidade de cada um deles, o que resulta em ampla reutilizao desses. Como exemplo, podemos citar o servio bsico verificador de saldo de conta-corrente utilizado por todos os servios que gerem dbito em conta-corrente, como: transferncias, DOCs, aplicaes, pagamentos, entre outros. Este servio apresenta mais de 100 milhes de acessos durante o ms. O servio intermedirio autorizador de transao o mesmo utilizado pelas transaes de: transferncia de valor entre contas, pagamentos de contas, aplicaes, resgates, ou seja, todos os servios que geram movimentao financeira nas contas dos clientes. O servio bsico gerador de cdigo transao tambm utilizado pelos diversos sistemas de informao do banco que geram transaes; A flexibilizao quanto manuteno e evoluo do sistema est assegurada por vrias razes, seja por ter compartimentos bem definidos (boa decomposio), que facilitam a pesquisa e a alterao somente dos objetos pertinentes, seja por isolar tais compartimentos entre si, ou seja, no gerar impedncia entre eles. No caso da transferncia de valor entre contas, ilustrada pela Figura 2, os servios intermedirios conector transferncias para canais Internet e conector transferncias para canais Mainframe retratam bem essa caracterstica. Caso a organizao substitua o servio autorizador de transao, ou seja, troque o software que o implementa, tal mudana no seria percebida pelos quatro applications frontend que os acionam. Os nicos objetos a serem alterados seriam os dois conectores representados como servios intermedirios. 6 - LIES APRENDIDAS COM A EXPERINCIA DA SOA NO ABN AMRO BRASIL O histrico de aplicao dos recursos de tecnologia da informao na entrega de um conjunto de servios bancrios por meio de diferentes canais de comunicao um desafio tpico das instituies financeiras, independentemente de continente ou de aspectos culturais, conforme pode se observar no texto de Homann, Rill e Wimmer (2004, p. 34, traduo nossa): O segmento bancrio tem sido tradicionalmente um negcio altamente integrado, onde as instituies financeiras distribuem exclusivamente produtos desenvolvidos por si mesmas, atravs de canais proprietrios, com todo suporte e operacionalizao das transaes de negcios realizadas dentro dos seus limites. Os autores apontam que, nos ltimos anos, ocorreu uma profunda alterao na forma das instituies financeiras de arquitetar seus novos sistemas de informao, salientando a predileo dessas pela SOA. Indicam como principal razo a desagregao de suas cadeias de valor (desverticalizao) ocorrida pelo foco em suas atividades fins, pela terceirizao das demais atividades e pela criao de vrias unidades funcionais autnomas, que acabam por envolver diferentes softwares operando em diferentes plataformas computacionais.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management

Benefcios da Arquitetura de Software Orientada a Servios para as Empresas: Anlise da Experincia do ABN 31 AMRO Brasil

Para ter flexibilidade para conexo dos softwares de terceiros aos seus processos de negcios, a maioria das instituies bancrias adotou a SOA como meio de substituio das tradicionais tecnologias para integrao entre sistemas de informao, ou seja, introduziram a SOA fundamental (BLUMBERG, apud BIELSKI, 2005, p. 62). As instituies bancrias com maior experincia na utilizao da SOA a compreendem e a utilizam de forma mais ampla e estratgica; entre elas destaca- se o ABN AMRO: bancos como Wells Fargo, Citigroup, Bank of America, Washington Mutual, e ABN AMRO deram saltos tecnolgicos maiores, adotando a SOA como um sistema mais amplo, como uma estratgia de operao bem-organizada. (BLUMBERG, apud BIELSKI, 2005, p. 62). Os contedos das pesquisas de BIELSKI (2005), HOMANN, RILL e WIMMER (2004) evidenciam a vanguarda da arquitetura de software corporativo do ABN AMRO Brasil, considerando que, desde o ano de 2000, a instituio j integrava seus servios bancrios aos diferentes canais de acesso disponveis aos seus clientes por meio de um barramento de servios. A anlise da experincia do ABN AMRO Brasil com a construo e operao do JAS/MCI caracteriza vrios aspectos importantes de serem observados pelos gestores dos recursos de tecnologia da informao que desejam implementar a arquitetura de software orientada a servios (SOA). Alguns desses aspectos so descritos a seguir. Observou-se que a implementao da SOA no ABN AMRO Real seguiu os estgios evolutivos definidos por Krafzig, Banke e Slama (2004). Inicialmente, introduziu-se a SOA fundamental, com intuito de resolver problemas de integrao entre sistemas de informao. Posteriormente, evolui para SOA em Rede, obtendo ganhos de flexibilidade na construo de softwares, por intermdio da reutilizao de componentes j disponveis. Esta ao resultou, inclusive, em applications frontends menores em tamanho e complexidade, por ter parte do seu software original transformando-se em servios disponveis a todos os demais sistemas de informao. A introduo da SOA, seguindo essa ordem, interessante por gerar resultados rapidamente (resoluo de problemas relativos integrao entre sistemas de informao), dando maior respaldo e tranqilidade equipe de implementao para evoluir aos estgios seguintes da SOA (SOA em Rede e SOA Habilitadora de Processos). Estgios que requerem mais tempo para resultar em ganhos perceptveis aos negcios. Assim, temos como lio aprendida: a SOA fundamental um estgio que deve ser percorrido por aqueles que se iniciam na SOA, no s por mostrar resultados em um curto espao de tempo e dar respaldo iniciativa como um todo, mas tambm por ser um bom estgio para aprendizagem e vivncia nos principais fundamentos da arquitetura SOA. Outro aspecto importante a se destacar que a introduo da arquitetura de software orientada a servios no implica na obrigatoriedade de se comprar um software que implemente o barramento de servios, ou seja, na aquisio de um middleware ou EAI. A organizao pode construir seu prprio barramento de servios, como fez o ABN AMRO Brasil. Entre as vantagens dessa abordagem esto: (a) a reduo de custo total da soluo, em funo da no compra da ferramenta (licenas de uso) e dos custos inerentes ao treinamento e consultoria para implementao da mesma; (b) maior compreenso da organizao quanto s funcionalidades e caractersticas requeridas a um barramento de servios, uma vez que ela ir desenvolv-la; (c) melhor adequao da ferramenta ao ambiente
Vol. 3, No. 1, 2006, p 19-34.

32 Sordi, J., Marinho, B., Nagy, M.

computacional da organizao, uma vez que ser construdo sob-medida s necessidades da empresa. Quanto menor a diversidade tecnolgica dos sistemas de informao a serem integrados e das plataformas tecnolgicas onde estes esto sendo processados, mais atrativa se torna a opo pela construo de um barramento de servios prprio. No caso do ABN AMRO Brasil, a maior parte dos sistemas de informao foi desenvolvida internamente, utilizando-se de um conjunto de tecnologias padronizadas pela rea de Arquitetura e Infra-estrutura Corporativa: COBOL, PL1, CICS, DB2 e ADABAS. Alm disso, a grande maioria destes sistemas era processada na plataforma mainframe, excetuandose apenas alguns applications frontends, que residiam em outras plataformas. Estas lies aprendidas com a experincia do ABN AMRO Brasil constituem aspectos relevantes de serem observados pelas instituies que pretendam iniciar-se na SOA, o que remete ao objetivo primrio da pesquisa, descrito no captulo quatro, plenamente atingido pela presente pesquisa. A forte demanda por integrao entre sistemas de informao no ambiente bancrio, caracterizada por um conjunto de servios entregues em diferentes canais, constitui um contexto apropriado para discusso da introduo e evoluo da SOA nas organizaes. Primeiro, por tratar-se de um cenrio compreensvel ao pblico leitor que, em sua grande maioria, utiliza-se cotidianamente de tais recursos. Segundo, apresenta uma demanda de integrao muito bem definida. Terceiro, trata-se de um segmento com um nvel de maturidade tecnolgica, em termos de arquitetura de software, acima da mdia dos demais segmentos. Desta forma, o caso analisado - de introduo e evoluo da SOA no ABN AMRO Brasil aplicvel comparao e extrapolao da realidade estudada para o contexto de outras organizaes ou de outros segmentos de negcios, colaborando, assim, para um processo de melhor compreenso da SOA, no contexto das corporaes brasileiras. Vale relembrar que este era o objetivo secundrio da presente pesquisa e que tambm foi plenamente atingido. 7 CONCLUSES FINAIS Para que se possa concluir esse texto com um entendimento abrangente sobre o potencial da SOA em termos de agregao de valor aos negcios, entendendo-a como recurso estratgico ao aumento da competitividade das organizaes, descreve-se uma polmica recente, ocorrida nos meios acadmicos e organizacionais, sobre a importncia estratgica da tecnologia da informao (TI) aos negcios. A discusso foi motivada pela publicao do artigo de Nicholas Carr (2003): IT doesnt matter. Neste artigo, o autor define os recursos de TI como commodity, ou seja, recurso no estratgico em funo destes estarem disponveis a todas as organizaes. Muitos questionaram essa posio, Keen, por exemplo, refutou-a afirmando: Quando todas as empresas tm, essencialmente, acesso aos mesmos recursos de tecnologia da informao, a diferena competitiva e os benefcios econmicos que as empresas possam ganhar reside no gerenciamento da TI e no nas diferenas tecnolgicas (KEEN, apud DEVARAJ e KOHLI, 2002, p. 20, traduo nossa). Analisando a posio de Carr e de seus detratores, nota-se que no h discordncia na essncia das idias. H de se considerar e ressaltar a definio utilizada por Carr para TI, declarada em uma pequena nota de rodap, apresentada na ltima pgina do seu polmico artigo:
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management

Benefcios da Arquitetura de Software Orientada a Servios para as Empresas: Anlise da Experincia do ABN 33 AMRO Brasil

Tecnologia da informao um termo confuso. Nesse artigo, ele utilizado em seu senso comum, denotando as tecnologias utilizadas para processar, armazenar e transportar informaes no formato digital. (CARR, 2003, p.49, traduo nossa). Como o prprio Carr aponta, a definio do termo TI bastante confusa e pode ser entendida de muitas formas, conforme a experincia de cada leitor. Muitos dos reacionrios no devem ter lido a discreta nota de rodap do artigo de Carr ou, se a leram, no a interpretaram conforme o autor. Muitos autores j vinham trabalhando com a mesma idia de Carr, o simples fato das organizaes investirem na compra de tecnologias de processamento (CPUs embarcadas em computadores servidores ou clientes), meios de armazenamento (unidades de discos, fitotecas robotizadas) e meios para o transporte de informaes (rede de dados, servios de transporte como o EDI) no resolve mais os grandes desafios destas, muito menos apresenta potencial para ser considerada um recurso estratgico. O entendimento de Keen, que o valor estratgico da TI est na forma de gerenciar os seus diversos componentes, o mesmo de outros autores. Meehan (2002), por exemplo, entende que a misso principal das reas de TI das grandes corporaes deslocou-se da entrega de novos sistemas de informao para integrao dos diversos sistemas de informao j existentes. Muitos destes novos sistemas foram introduzidos ao longo dos ltimos anos, parte deles motivados pelo temor ao bug do milnio. O fato que nunca se presenciou tanta quantidade e diversidade de sistemas de informao nas organizaes. Uma anlise detalhada dos autores que discutem o futuro da TI nas organizaes aponta para duas linhas bastante distintas, porm coerentes: (a) os investimentos realizados na compra de recursos de TI ao longo dos ltimos anos, sobretudo sistemas de informao, geram, sob a perspectiva de negcios, resultados cada vez mais pontuais e de menor importncia, sendo essa uma abordagem a ser desconsiderada pelas organizaes; (b) h muito mais a fazer do que simplesmente comprar e disponibilizar recursos de TI organizao; h um grande e difcil trabalho de harmonizar todos esses recursos, de forma que eles sejam capazes de acompanhar a evoluo e o dinamismo das organizaes. Resumindo, a abordagem tradicional para gesto da TI no mais capaz de produzir vantagens estratgicas organizao. A vantagem estratgica, fortemente fundamentada em recursos de TI, ainda pode ser alcanada, desde que se adote uma outra abordagem para sua gesto. Neste aspecto, a discusso da arquitetura de software, em especial da SOA, bastante apropriada. Ela direciona a ateno gerencial, historicamente dedicada construo de software, para a harmonizao, para arquitetura de cada sistema de informao, considerandose o todo. O entendimento dos conceitos, dos componentes e da importncia da arquitetura de software aos negcios fundamental aos administradores de sistemas de informao, tanto para que eles tenham o conhecimento necessrio, quanto para se motivarem na adoo de uma nova abordagem para gesto dos recursos de TI. Neste contexto, a pesquisa sobre a implementao da SOA no ABN AMRO Brasil prodigiosa na discusso e apresentao de conhecimentos capazes de provocar nos administradores de sistemas de informao e nos pesquisadores da rea de administrao de sistemas de informao o insight necessrio para se considerar uma nova abordagem para gesto dos recursos de TI.

Vol. 3, No. 1, 2006, p 19-34.

34 Sordi, J., Marinho, B., Nagy, M.

REFERNCIAS BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. 2. ed. Software Architecture in Practice. Addision-Wesley, 2003. BANCO REAL. Quem somos. Banco Real Portal <http://www.bancoreal.com.br>. Acesso em: 4 out. 2005. Brasil. Disponvel em:

BIELSKI, Lauren. Breakout systems and applications give bankers new options. American Bankers Association: ABA Banking Journal, New York; v. 97, n. 6, p. 61-65, jun. 2005. BUTLER Group. Application integration management guide. Butler Group, 1999. Disponvel em: < http://www.researchandmarkets.com/reports/>. Acessado em: jan. 2001. CARR, Nicholas G. IT doesnt matter. Harvard Business Review, Boston, v.81, n.5, p.4149, May 2003. CUMMINS, Fred A. Enterprise integration: an architecture for enterprise application and systems integration. Nova York: John Wiley & Sons, 2002. DE SORDI, Jos O. Gesto por processos: uma abordagem da moderna administrao. So Paulo: Saraiva, 2005. DEVARAJ, Sarv; KOHLI, Rajiv. The IT payoff: measuring the business value of information technology investments. New Jersey: Prentice Hall, 2002. FOWLER, Martin. Patterns of Enterprise Architecture. Addision-Wesley, 2002. GARTNER. Service-Oriented Architecture: Mainstream Straight Ahead. Gartner, apr. 2003. Disponvel em: <http://www.gartner.com/pages/story.php.id.3586.s.8.jsp>. Acessado em: nov. 2005. GHEZZI, Carlo; JAZAYERI, Mehdi; MANDRIOLI, Dino. Fundamentals of Software Engineering. 2. ed. Indianapolis: Prentice Hall, sep. 2002. HOMANN, Ulrich; RILL, Michael; WIMMER, Andreas. Flexible Value Structuers in Banking, Association for Computing Machinery: Communications of the ACM, New York; v. 47, n. 5, p. 34-36, mai. 2004. KRAFZIG, Dirk; BANKE, Karl; SLAMA, Dirk. Enterprise SOA: Service-Oriented Architecture Best Practices. Indianapolis: Prentice Hall, 2004 MEEHAN, Michael. IT Managers Make EAI Projects a Top Priority. ComputerWorld, fev. 2002. PRESSMAN, Roger S. Software Engineering: a practitioners approach. 6. ed. New York: McGraw-Hill, 2004. RUH, A.William; MAGINNIS, Francis X. BROWN, William J. Enterprise application integration. Nova York: John Wiley & Sons, 2001. YIN, Robert K. Case study research: design and methods. 2. ed. California: Sage Publications Inc., 1994.

Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management