Document07

JISTEM Revista de Gesto da Tecnologia e Sistemas de Informao Journal of Information Systems and Technology Management Vol. 7, No. 3, 2010, p. 619-638 ISSN online: 1807-1775 DOI: 10.4301/S1807-17752010000300006

_____________________________________________________________________________________

Recebido em/Manuscript first received: 05/11/2009 Aprovado em/Manuscript accepted: 13/06/2010 Endereo para correspondncia/ Address for correspondence Daniel Valente Serman, Pontifcia Universidade Catlica do Rio de Janeiro, Brasil, Rua Conde de Bonfim, 746/603 Tijuca, Rio de Janeiro, RJ, Brasil Tel: (21) 9971-1447 / (21) 3079-1447 E-mail: [email protected] ISSN online: 1807-1775 Publicado por/Published by: TECSI FEA USP 2010

ORIENTAO A PROJETOS: UMA PROPOSTA DE DESENVOLVIMENTO DE UMA ARQUITETURA ORIENTADA A SERVIOS

PROJECT ORIENTATION: A PROPOSAL TO DEVELOP A SERVICE-ORIENTED ARCHITECTURE

Daniel Valente Serman Pontifcia Universidade Catlica do Rio de Janeiro, Brasil __________________________________________________________________________________

ABSTRACT

A service-oriented architecture (SOA) is occasionally seen as a complex and undefeatable challenge (Serman, 2007). This feeling is motivated by the lack of attention from practitioners and from the academy on the means for its construction. The work aims to bring the portfolio management of IT projects as an option to guide the SOA development. A review of the literature on SOA was carried out, including case studies on the SOA adoption. A case study was also done, which analyzed some projects of a particular organization, focusing on the evolution of its services architecture. The results show a gradual development of SOA in the case studied based on projects execution and sequencing. It concludes with a proposal of a process for building SOA as well as suggestions and limitations for future research.

Keywords: Service-Oriented Architecture (SOA), Web services, Project Management, Project Portfolio Management, Systems Integration.

RESUMO

A arquitetura orientada a servios (SOA) ocasionalmente encarada como um desafio complexo e intransponvel (Serman, 2007), sentimento motivado pela falta de ateno de praticantes e da academia sobre os meios para sua construo. O trabalho visa trazer a gesto da carteira de projetos de TI como opo para orientar o desenvolvimento de SOA. Para isso, realizou-se uma reviso da literatura sobre SOA, incluindo estudos de caso sobre sua adoo. Tambm foi executado um estudo de caso, no qual foram analisados os projetos de uma determinada organizao, focando-se na evoluo de sua arquitetura de servios. Os resultados mostram a construo gradual de SOA no caso a partir da concluso e sucesso dos projetos. Conclui-se com uma proposta de processo de construo de SOA e as limitaes e sugestes de pesquisas futuras.

Palavras-chave: Arquitetura Orientada a Servios (SOA), Web services, Gerncia de Projetos, Gesto de Carteira de Projetos, Integrao de Sistemas.

.

Serman, D. V.,

R. Gest. Tecn. Sist. Inf. /JISTEM Journal of Information Systems and Technology Management, Brazil

620

1. INTRODUO

A orientao a servios para a construo da arquitetura de sistemas de uma organizao colocada como um caminho para alcanar agilidade e flexibilidade para responder ao ambiente competitivo (Crawford et al., 2005; Kumar et al., 2007; Ciganek et al., 2005). s vezes, so encontradas algumas posies mais extremas, como a condio de adotar essa proposta para no se cair em desvantagem competitiva (Marks & Bell, 2006).

Percebe-se, contudo, que os trabalhos sobre o tema demonstram, em geral, uma maior preocupao em promov-lo e em sugerir o que deve ser feito, abordando superficialmente como proceder para o desenvolvimento desse tipo de arquitetura de software.

Papazoglou e Gerogakopoulos (2003) defendem que a mudana para SOA pode ser feita de forma gradual e Marks e Bell (2006) propem modelos baseados na iteratividade para a construo de SOA. H, porm, pouco aprofundamento sobre os mtodos que podem ser utilizados. Nesse contexto, pode-se vislumbrar a utilidade da metodologia de gerncia de projetos e gesto de carteira para o desenvolvimento paulatino e eficiente dos servios, alicerado nos projetos de implantao de sistemas de informao organizacionais.

O objetivo principal desse artigo observar a evoluo de uma arquitetura orientada a servios atravs da gesto da carteira de projetos de implantao e desenvolvimento de sistemas de informao em uma organizao. Um estudo de caso ser executado com esse fim. Pretende-se alcanar outros objetivos, como propor um processo de construo de SOA, entender o impacto da maturidade de SOA nos projetos de sistemas de informao, identificar boas prticas e verificar a sinergia do conceito metodologia de Gerncia de Projetos.

O trabalho contribui sobre mtodos para o desenvolvimento de SOA, cujo contedo na literatura restrito. Sua importncia para a prtica tambm grande, principalmente ao considerarmos que as organizaes se mostram incipientes em sua utilizao (Serman, 2007). A relevncia do tema salientada por Kumar et al. (2007), que cita pesquisas retratando o volume de investimento em SOA em torno de US$ 9 bilhes at 2009 e a crescente inteno das organizaes em consider-la em seus projetos.

O artigo composto por: uma seo para fundamentao terica de SOA e Gesto de Projetos, alm de uma viso dos casos presentes na literatura sobre o desenvolvimento de SOA; a descrio do caso estudado, abordando a empresa, a situao inicial em relao a arquiteturas de sistemas e as ferramentas e mtodos adotados sobre SOA; uma seo sobre a metodologia utilizada no artigo; um quarto ponto, que revela os resultados da pesquisa de campo; a quinta seo, que traz uma discusso sobre os resultados; e o sexto ponto, que contm as concluses extradas, limitaes e sugestes para novas pesquisas.

Orientao a projetos: uma proposta de desenvolvimento de uma arquitetura orientada a servios

Vol.7, No. 3, 2010, p. 619-638

621

2.FUNDAMENTAO TERICA

2.1arquitetura Orientada A Servios

Sordi et al. (2006) relacionam algumas situaes indesejveis causadas por problemas de integrao entre sistemas de informao como: a incapacidade de reduo no tempo dos processos por limitaes de integrao; a possibilidade de falhas na replicao manual de dados em diferentes sistemas; lentido na identificao de oportunidades e ameaas pela falta de uma viso integrada de diferentes sistemas; e a dificuldade na substituio de estruturas de integrao obsoletas pelo seu alto nvel de complexidade. Como resposta a essa situao, a orientao a servios da arquitetura de sistemas (SOA, Services-Oriented Architecture) apresentada pelos autores como um caminho a ser seguido.

Destacam-se nas propostas sobre SOA o foco na padronizao de interfaces, reutilizao de cdigo e artefatos desenvolvidos e disposio dos sistemas de informao em componentes (Mezo et al., 2008; Stal, 2002; Marks & Bell, 2006).

H diversas semelhanas se compararmos essas promessas com o que j foi mencionado em outras propostas que passaram por TI. Reutilizao de cdigo ou de componentes j era sugerida como boa prtica (Pressman, 2002) e interfaces genricas tinham sido previamente relacionadas a brokers (Siegel, 1998). Entretanto, em conjunto com as idias antigas, alguns pontos podem parecer novos (nem tanto pela proposta de SOA em si, mas pelo contexto em que ela se insere):

Padres abertos (livres de licenciamento) para protocolos de comunicao e documentao (Curbera et al., 2004; Dietrich et al., 2007);

Uso de um meio de comunicao universalizado como a Internet no caso dos web services, um dos padres relacionados a SOA (Curbera et al., 2004; Stal, 2002).

Assim, definimos que uma arquitetura orientada a servios como um conceito de arquitetura de software formada por componentes disponveis atravs de interfaces genricas e protocolos padronizados e preferencialmente livres de licenas (os servios), concebidos almejando-se o menor nvel de dependncia possvel com os sistemas de informao que os consomem e da parte tcnica do desenvolvimento, estimulando a sua reutilizao e aproveitamento das funcionalidades j existentes.

Krafzig et al. (2004) propem nveis de tipos de escopo de servios observados pelas organizaes para a construo de SOA: SOA Fundamental, com a complexidade nas aplicaes e a utilizao de servios para operaes bsicas; SOA em rede, com o domnio de servios intermedirios, que visam atender deficincias tcnicas e funcionais das aplicaes; e SOA habilitadora de processos, com a lgica de negcio e operao concentrada nos servios.

Dentre os benefcios prometidos na literatura, encontramos flexibilidade e agilidade (Crawford et al., 2005; Kumar et al., 2007; Ciganek et al., 2005), a mitigao de dificuldades tecnolgicas oriundas da obsolescncia dos sistemas legados (Mezo et

Serman, D. V.,


622

al., 2008) ou de problemas de utilizao de outras tecnologias de integrao (Corba, Dcom, COM+) (Kumar et al., 2007) e a maior facilidade de substituio de componentes e pacotes de software (Puschmann & Alt, 2001; Serman, 2007) por causa da menor dependncia dos servios em relao aos sistemas que os suportam.

Condizendo com a proximidade maior ao negcio que alguns autores do para suas definies de SOA (Marks & Bell, 2006; Crawford et al., 2005), esses benefcios relacionados no se restringem ao uso da tecnologia, mas abrangem tambm questes metodolgicas, organizacionais e de negcio, como mostrado por Serman (2007) em um quadro comparativo entre modalidades de integrao de dados e sistemas.

Em relao aplicao concreta de SOA, Kumar et al. (2007) comprovam em pesquisa hiptese de que empresas que integram seus clientes em uma cadeia eletrnica de fornecimento atingem melhor desempenho nessa cadeia quando ela est fundamentada em uma arquitetura orientada a servios.

Contudo, pesquisa mencionada por Serman (2007) mostra gestores de TI preocupados com supostas grandes dificuldades, geralmente ligadas a custo de se desenvolver uma arquitetura orientada a servios. Sordi et al. (2006) argumentam que a escassez e pouco aprofundamento do conhecimento sobre o assunto, principalmente na academia, pode conduzir a essa percepo.

Alm disso, pouco se encontrou sobre problemas ou mesmo precaues com a adoo de SOA. Albrecht (2004) alerta sobre os problemas de segurana que ainda so encontrados no uso do padro de web services, podendo trazer consequncias se as empresas buscarem a comunicao externa sem cuidado.

2.2.Gerncia de Projetos

Kerzner (2006) define projeto como um empreendimento com objetivo bem definido, que consome recursos e opera sob presses de prazos, custos e qualidade. Gesto de projetos para o mesmo autor consiste no planejamento, programao e controle de uma srie de tarefas integradas de forma a atingir seus objetivos com xito para benefcio dos participantes do projeto (Kerzner, 2006).

O desenvolvimento de software um tema em que frequentemente se aplicam as tcnicas de gerncia de projetos. Pressman (2002) elenca alguns itens que devem fazer parte de um projeto de software, dentre os quais podem ser destacados a abstrao, a modularidade e a arquitetura de software.

Esses trs itens tm forte relao proposta de SOA. O primeiro permite a correta definio do escopo dos servios (bsicos, de escopo de processo, empresarial (Krafzig et al., 2004)); o segundo conduz ao desenvolvimento de servios adequados reutilizao; e o terceiro garante a viso geral da arquitetura para a efetivao dos benefcios almejados. Sendo assim, a orientao a servios da arquitetura poderia trazer benefcios no s organizao como um todo, mas execuo do prprio projeto.

No que tange aos riscos dos projetos de desenvolvimento de sistemas de informao, Scott e Vessey (2002) citam quatro fontes de riscos: ambiente de negcio externo organizao; organizao; sistemas de informao e projetos de sistemas corporativos. Esses autores e Summer (2000) relacionam diversos riscos que so frequentes ao desenvolvimento de sistemas de informao, como a falta de


Vol.7, No. 3, 2010, p. 619-638

623

conhecimento de novas tecnologias, complexidade tcnica, problemas de liderana e apoio da alta gerncia, falta de alinhamento com o negcio, dentre outros.

Alcanando maior flexibilidade e agilidade com o desenvolvimento de uma arquitetura orientada a servios, conforme prometido por alguns autores (Crawford et al., 2005; Kumar et al., 2007; Ciganek et al., 2005), esses riscos criados poderiam ser mitigados, pois a organizao teria maior agilidade para responder a eles.

2.3.Formao de Carteira de Projetos

As empresas podem no conseguir atender a todas as demandas que lhe so impostas no tempo desejado, j que nem sempre dispem de recursos suficientes (Kerzner, 2006). Assim, a eficincia na formao de uma carteira de projetos importante e deve levar em considerao os objetivos corporativos, a disponibilidade de recursos financeiros e humanos e as restries colocadas pelo ambiente (Lin & Hsieh, 2004).

Alguns mtodos para formao de carteira de projetos so propostos na literatura (Kerzner, 2006; Lin & Hsieh, 2004; Lee & Kim, 2000). Kerzner (2006) fala de quatro passos: identificao de projetos; avaliao preliminar, que engloba estudos de exequibilidade e anlise de custo/benefcio; seleo estratgica de projetos (buscando o alinhamento com os objetivos da empresa); e programao estratgica, que contempla anlise de disponibilidade de recursos e do mercado impactado.

Lee e Kim (2000) argumentam que importante tratar da interdependncia entre os projetos, que geralmente desconsiderada nos mtodos de formao de carteira. Os autores citam trs categorias sobre a interdependncia: recursos (humanos), benefcios (atravs da sinergia entre eles) e tcnicos (estipulando as relaes de dependncia). A reutilizao dos servios pode se enquadrar nas duas ltimas categorias.

A viso de integrao como uma etapa de projeto pode dar lugar a uma busca mais contnua: a informao integrada em torno de algum assunto, avalia-se o resultado e identifica-se outro ponto para uma nova rodada (Bernstein & Haas, 2008). Segundo esse direcionamento, uma carteira de projetos permite a construo de uma arquitetura de software de forma iterativa e pode ser um direcionamento eficaz para SOA, facilitando o planejamento do desenvolvimento dos servios e sua reutilizao (Mezo et al., 2008; Marks & Bell, 2006; Crawford, 2005).

2.4.Desenvolvimento de SOA nas Organizaes

A literatura sobre SOA d maior destaque para os benefcios encontrados com a adoo da proposta, requisitos tecnolgicos e direcionamento tcnico para a arquitetura de software. H, entretanto, pouca ateno para aspectos metodolgicos de desenvolvimento dos servios.

Poucos artigos abordam metodologias ou tcnicas para a construo de SOA. Buscamos estudos de caso sobre o assunto, mas, na maior parte dos casos, encontramos a apresentao do que foi construdo, mas pouco ou nenhum detalhe sobre como o resultado foi atingido.

Serman, D. V.,


624

Dentre os exemplos encontrados de aplicao de SOA, encontrou-se a utilizao de modelos de servios padronizados para determinadas reas de negcio, como a fabricao de calados segundo o conceito de customizao em massa (Dietrich et al., 2007) e a poltica de definio de preo para leiles reversos (Bernhardt & Hinz, 2005). Bernhardt e Hinz (2005) trazem a ideia de um parceiro externo que funciona como provedor de servios que passariam a integrar a arquitetura da organizao cliente.

O trabalho de Sordi et al. (2006) foi uma das excees, apresentando a proposta de nveis de maturidade de Krafzig et al. (2004) como caminho para desenvolvimento de SOA. A proposta consistiria na construo de servios dos nveis bsicos at os mais complexos, que envolveriam outras organizaes. Entretanto, no h aprofundamento sobre como a construo de SOA foi executada; acredita-se que o desenvolvimento ocorreu de uma nica s vez, em um grande projeto.

Em contrapartida, Marks e Bell (2006) propem um modelo iterativo de negcios para SOA. Os autores argumentam que SOA no se baseia em um modelo de desenvolvimento restrito a um nico evento, como um big bang. Eles relacionam seis caminhos possveis de identificao de servios que devem ser usados em conjunto de forma repetitiva: anlise de processos de negcio, anlise das entidades de dados principais (ex: pedidos, faturas, etc), oportunidades atravs de projetos j orados, conhecimento sobre o domnio do negcio e servios e aplicaes pr-existentes. No citado, contudo, nenhum exemplo.

3. DESCRIO DO CASO ESTUDADO

A empresa estudada pertence ao ramo de Petrleo e Gs e possui mais de cinco mil funcionrios. Dentre eles, em torno de cento e sessenta integram a Gerncia de Informtica.

O incio do movimento de construo de uma arquitetura orientada a servios nessa empresa comeou com a aquisio de uma ferramenta de integrao de aplicaes (EAI Enterprise Application Integration).

O objetivo com essa ferramenta era integrar o parque de sistemas, caracterizado pela heterogeneidade de plataformas, linguagens de programao e protocolos de comunicao. Com a centralizao da comunicao entre os sistemas e sua rastreabilidade se pretendia resolver problemas de uma implantao de ERP mal sucedida, que no reduziu o legado e s aumentou o nvel de complexidade.

A ferramenta prometia compatibilidade com diversos padres de protocolos de comunicao e plataformas, como web services, acesso a bancos de dados de produtos de mercado, HTTP, FTP, Java, dentre outros.

Foi iniciado um projeto piloto para introduo de SOA a partir da ferramenta, composto por trs projetos que estariam ligados a necessidades de integrao de informao da empresa. O objetivo primrio consistia em entender o funcionamento da ferramenta adquirida e, por conseguinte, decifrar o mecanismo de interao com as aplicaes da organizao.

A percepo inicial da equipe de TI era de que a ferramenta era mgica pela forma como foi apresentada pelo fornecedor. Foi necessrio, ento, contratar uma


Vol.7, No. 3, 2010, p. 619-638

625

consultoria especializada para treinar a equipe na ferramenta.

Em seguida, com um maior domnio dessa equipe e algum apoio da fornecedora da ferramenta de EAI, novos projetos da carteira da rea de TI foram contemplados na iniciativa. Requisitos de negcio ligados fragmentao da informao por diversos sistemas e possibilidade de reutilizao de servios foram critrios para seleo dos projetos.

Em paralelo, foram concebidas algumas diretrizes e tcnicas para a construo da arquitetura orientada a servios. Manuais e treinamentos foram elaborados para que os conceitos e mtodos fossem disseminados e assimilados por toda a equipe de Informtica da organizao.

4.METODOLOGIA

O mtodo empregado na pesquisa foi o de estudo de caso nico incorporado (Yin, 2003). Fundamenta-se a escolha do estudo de um caso pela sua natureza reveladora (Yin, 2003), pois no foi encontrado na reviso da literatura nenhum relato sobre experincias com a orientao do desenvolvimento de SOA com base em projetos de implantao de sistemas de informao.

O critrio de acessibilidade proposto por Vergara (1998) corrobora a escolha, j que a empresa analisada foi a nica identificada em que se aplica essa viso para a implementao de SOA.

O estudo nico porque trata apenas de uma empresa, mas incorporado porque se pretende promover a anlise no nvel dos projetos, tratando-os como subunidades do caso. Com isso, a evoluo de SOA ser apreciada atravs da viso das caractersticas particulares de cada projeto, sem abandonar a unidade de estudo, que a empresa.

O universo da pesquisa consistiu em projetos de desenvolvimento ou implantao de sistemas de informao da organizao, para os quais se aplicou a viso de servios para a arquitetura e se utilizou a ferramenta de EAI. Foram selecionados projetos em que a inteno de usar a proposta foi parte do planejamento do projeto ou surgiu durante sua execuo.

A amostra foi formada por oito projetos. Decidiu-se incluir tambm um projeto de construo de um arcabouo terico e metodolgico para o desenvolvimento de uma arquitetura orientada a servios corporativa. Esse projeto ser tratado parte, j que no houve desenvolvimento de software.

Para a coleta de dados foi entrevistado um dos membros de cada projeto da amostra, podendo ser seu gerente, lder tcnico ou analista responsvel pela integrao. O conhecimento sobre conceitos de SOA e da ferramenta utilizados embasaram a escolha do profissional do projeto a ser entrevistado. O teste do roteiro da entrevista foi realizado com dois projetos da amostra e julgou-se no haver necessidade de alteraes.

No primeiro contato com o entrevistado, foram apresentados os objetivos da pesquisa, como os resultados das entrevistas seriam apresentados e foi dada a garantia de confidencialidade. Em seguida, foi submetido um questionrio com perguntas

Serman, D. V.,


626

abertas. Para os profissionais localizados no mesmo stio do pesquisador, as entrevistas foram presenciais; caso contrrio, o questionrio foi submetido via e-mail e houve rplica e trplica, tambm por e-mail.

Para a pergunta sobre as motivaes que levaram adoo de SOA nos projetos, foram considerados os fatores citados por Mezo et al. (2008), que interferem na deciso sobre sistemas de informao. As motivaes mencionadas para os projetos foram enquadradas em categorias, conforme feito por Serman (2007): tecnolgicas, organizacionais e de negcio.

Nas entrevistas, foram questionados os requisitos, benefcios e problemas encontrados com o desenvolvimento dos servios e com sua insero na arquitetura da organizao. Foi solicitado aos entrevistados que levassem em considerao a mesma categorizao usada para as motivaes (tecnolgicas, organizacionais e de negcio).

O resultado das entrevistas foi compilado por projeto. Frequentemente, os entrevistados saam do escopo original das perguntas, o que esperado quando muitas dessas respostas so motivadas por reaes de defesa ou promoo do trabalho realizado (Serman, 2007). Nesses casos, as respostas foram reorganizadas e arroladas aos itens do questionrio mais adequados.

5.RESULTADOS

Dentre os oito projetos que compunham inicialmente a amostra, dois foram retirados ao longo da pesquisa: um deles foi cancelado no incio de sua execuo e o segundo foi considerado irrelevante pelo seu lder tcnico.

Os dois primeiros projetos da amostra correspondem ao piloto de utilizao da ferramenta de EAI na organizao. Os quatro seguintes correspondem a projetos de desenvolvimento de sistemas ou implantao de pacotes de software de mercado em que se adotou a proposta de SOA. A Tabela 1 exibe algumas informaes do projeto apresentadas em ordem cronolgica.

A consultoria contratada para utilizao da ferramenta de EAI participou dos trs primeiros projetos (M, P e G). Os entrevistados desses casos apontaram problemas de falta de conhecimento e postura da consultoria, passando uma percepo de que a evoluo de SOA s pode seguir com sua sada e envolvimento direto e total da equipe de TI da organizao.


Vol.7, No. 3, 2010, p. 619-638

627

Projeto Assunto Impacto para o negcio

Tamanho equipe TI

M Canal eletrnico para colocao automtica de pedidos de clientes

Restrito a um percentual muito baixo dos clientes

Dois analistas de sistemas

P Integrao dos processos de controle de crdito de clientes

Processos crticos para o negcio, atingindo todos os clientes

Quatro analistas de sistemas

G Integrao dos processos de gesto de equipamentos

Muito importante para uma gesto eficiente dos equipamentos

Sete analistas de sistemas

S Gesto de compra de insumos importantes para o negcio

Automatizao da criao de pedidos de compra e contratos

Trs analistas de sistemas

N Nota fiscal eletrnica Todo o faturamento

teria notas fiscais eletrnicas

Vinte analistas de sistemas

C

Integrao de processos de atendimento e gesto do relacionamento com cliente

Substituio do pacote de gesto de relacionamento com cliente

Quinze analistas de sistemas

Tabela 1: Informaes sobre projetos contemplados no estudo de caso.

Os relatos indicaram que o sucesso no piloto permitiu que a viso de SOA fosse estendida a outros projetos importantes da carteira da rea de TI. A Tabela 2 mostra as motivaes indicadas pelos entrevistados para a adoo da proposta de SOA com base na lista de fatores citados por Mezo et al. (2008).

Os entrevistados foram questionados sobre requisitos que precisaram atender para que SOA fosse adotada, alm dos benefcios e problemas obtidos para o projeto e para a organizao. Esses pontos esto apresentados na Erro! A origem da referncia no foi encontrada..

Por outro lado, a Tabela 4 mostra as contribuies dos projetos para a arquitetura segundo os entrevistados, alm da viso de reutilizao de servios. Nela, se indica o potencial de reuso dos servios construdos no projeto e o consumo de outros previamente desenvolvidos.

Foram citados alguns padres de mercado para desenvolvimento de software e protocolos de comunicao, como web services (Ferris e Farrel, 2003) e Java, mas alguns relatos citaram a necessidade de contornar e entender questes especficas de pacotes de software adquiridos e at do ERP.

Todos os entrevistados mencionaram a boa percepo dos usurios envolvidos nos

Serman, D. V.,


628

projetos com a adoo de SOA. Um dos entrevistados explicou que as prticas adotadas pelas equipes motivaram uma maior aproximao da parte funcional com a tcnica, assim como da gerncia de TI equipe do projeto.

Projeto Tecnolgico Organizacional / Metodolgico

Negcios

M

Tecnologias ligadas Internet Forte impacto da infra-estrutura tecnolgica no negcio Sistemas legados Troca de informao pelos sistemas de forma eficiente Configurao da soluo em servios

Processos fragmentados em mltiplos sistemas de informao

Necessidade de escalabilidade e flexibilidade Coordenao de distintos canais de produtos Transaes em tempo real Mltiplos clientes Integrao entre os prprios sistemas e os dos clientes Ambiente dinmico

P Troca de informaes pelos sistemas de forma eficiente

Processos fragmentados em diferentes sistemas de informao

Transaes em tempo real

G

Sistemas legados Troca de informao pelos sistemas de forma eficiente

Processos fragmentados em diferentes sistemas de informao

Transaes em tempo real

S

Troca de informaes pelos sistemas de forma eficiente Configurao da soluo em servios


Necessidade de escalabilidade e flexibilidade Transaes em tempo real

N

Tecnologias ligadas Internet Forte impacto da infra-estrutura tecnolgica no negcio Sistemas legados Troca de informaes pelos sistemas de forma eficiente Configurao da soluo em servios

Baixa capacidade de adaptao a novas tecnologias e resistncia a mudanas

Necessidade de escalabilidade e flexibilidade Transaes em tempo real Integrao entre os prprios sistemas e os dos clientes Integrao entre os prprios sistemas e os dos fornecedores Ambiente Dinmico

C

Tecnologias ligadas Internet Forte impacto da infra-estrutura tecnolgica no negcio Sistemas legados Troca de informao pelos sistemas de forma eficiente Configurao da soluo em servios


Desenvolvimento frequente de novos produtos e servios Necessidade de escalabilidade e flexibilidade Transaes em tempo real

Tabela 2: Motivaes em cada projeto para a adoo da proposta de SOA com base em aspectos tecnolgico, organizacional/metodolgico e de negcios.


Vol.7, No. 3, 2010, p. 619-638

629

Benefcios com SOA Problemas com SOA Pro-jeto Requisitos Para projeto Para

organizao Para projeto Para

org.

M

Conhecimento sobre ferramenta de EAI Incutir viso de processos na equipe

Gesto do projeto em frentes independentes

Disseminar SOA para nveis no tcnicos Servios reutilizados sem apoio da equipe inicial

Necessidade de coordenao de mais equipes e consultorias

P

Conhecimento sobre formas de comunicao com sistemas envolvidos

Soluo mais simples e de mais fcil manuteno para atender negcio

Necessidade de consultoria da ferramenta de EAI Reconstruo de servios

G

Conhecimento sobre formas de comunicao com pacote implantado Incutir viso de processos na equipe

Facilidade de identificao de problemas de integrao Maior controle das consultorias contratadas Maior confiana dos usurios envolvidos

Maior eficincia dos processos de negcio pela integrao mais eficaz

S

Conhecimento sobre formas de comunicao com ERP

Facilidade de identificao de problemas de integrao

Menores custos com criao de servios com alto potencial de reuso

N

Soluo nica para empresas do grupo Controle das mudanas em definies fiscais

Maior eficincia em vrios processos ligados emisso e recepo de documentos fiscais

C

Isolamento do resultado do desenvolvimento do legado e do pacote adquirido Maior eficincia na integrao dos sistemas

Maior flexibilidade nos processos da gesto do relacionamento com cliente

Resistncia da equipe tcnica ao conceito de servios

Tabela 3: Requisitos nos projetos para o desenvolvimento dos servios e benefcios e problemas para projeto e a organizao por adotar SOA

Serman, D. V.,


630

Projeto Contribuies do projeto

para SOA da organizao Reutilizou servios?

Construo de servios

reutilizados?

M

Definio de papis e disseminao de metodologias para toda a equipe de TI da organizao Maior conhecimento sobre ferramenta de EAI

No Sim (com alto nvel de reuso)

P

Maior confiana na ferramenta de EAI e no seu papel central na arquitetura Definio de protocolo de comunicao para consumo de servios pelo ERP

No No

G

Consolidao do conhecimento e operao da ferramenta de EAI Definio de protocolo de comunicao de sistemas baseados em bancos de dados

No No

S Definio de protocolo de comunicao para consumo de servios do ERP No Sim (com alto nvel

de reuso)

N

Definio de estrutura com nvel integral de disponibilidade de sistemas Consolidao do uso da ferramenta de EAI e da proposta de SOA

No Sim (com mdio nvel de reuso)

C Construo de vrios servios com bom potencial de reuso Sim Sim (com alto nvel

de reuso) Tabela 4: Impactos do projeto para a construo de SOA da organizao.

O projeto para construo do arcabouo terico e metodolgico para governana de SOA visou, segundo o entrevistado, criar padres de nomenclatura e design, definir processos e responsabilidades para a equipe tcnica, dentre outros tpicos. Esse arcabouo deveria ser, por definio da gerncia de TI, centrado na ferramenta de EAI.

Relatou-se que a importncia dessa iniciativa era a falta de maturidade conceitual da ferramenta de EAI, a incompetncia de seu fornecedor em conceber normas concretas de governana e documentao e a ausncia de um bom parceiro naquele momento para prestao de servios sobre a ferramenta.

Para a preparao da equipe de TI foram ministrados cursos sobre a ferramenta e foram criados alguns mecanismos para facilitar o trabalho da equipe de infraestrutura em sua administrao. Definiu-se um processo de identificao e criao de servios e foram liberados documentos para solicitao de servios e de descrio dos protocolos de comunicao dos sistemas e plataformas utilizados pela empresa.

Outras sugestes foram levantadas: criao de uma rea ou grupo formal dedicado arquitetura de sistemas de informao da empresa; criao de portal de documentao dos servios e integrao do mtodo de desenvolvimento de servios ao processo de desenvolvimento utilizado pela empresa.

O entrevistado mencionou que vrios objetivos do projeto no foram atingidos. Um dos motivos apresentados foi o descolamento do mentor e executor do projeto com as prticas e necessidades apontadas pelos projetos de desenvolvimento de software em que a proposta de SOA estava sendo adotada.


Vol.7, No. 3, 2010, p. 619-638

631

DISCUSSO

As entrevistas trouxeram um contedo relevante sobre o desenvolvimento de servios a partir dos projetos que compuseram a amostra e a contribuio que a viso orientada a servios e direcionada pelos projetos trouxe para a organizao.

Sobre as motivaes que conduziram adoo de SOA para o projeto, destacaram-se nos relatos:

Aspectos tcnicos: troca de informao pelos sistemas de forma eficiente, configurao das solues na forma de servios, forte impacto da infra-estrutura tecnolgica no negcio;

Aspectos metodolgicos/organizacionais: processos fragmentados em diferentes sistemas de informao;

Aspectos de negcio: transaes em tempo real, necessidade de escalabilidade e flexibilidade e de integrao entre os prprios sistemas e os de clientes e fornecedores.

A Tabela 3 mostra que houve um maior impacto de requisitos para a adoo de SOA, principalmente tcnicos, nos primeiros projetos. Mencionou-se principalmente a necessidade de conhecimento da ferramenta de EAI, que era considerada o centro da arquitetura, e dos protocolos de comunicao com os sistemas implantados ou j existentes.

Muitos desses sistemas e plataformas no eram compatveis com padres de mercado, exigindo que a equipe tcnica buscasse apoio dos fornecedores para implementar a comunicao entre a ferramenta de EAI e esses sistemas. A nica referncia a esse ponto na literatura utilizada feita por Serman (2007).

Os depoimentos se mostraram geralmente positivos sobre SOA. Foram relatados poucos problemas com sua adoo e eles geralmente estavam diretamente relacionados aos requisitos citados. Essa ausncia de problemas tambm foi observada na pesquisa de Serman (2007) sobre integrao de sistemas e dados e podem ter a mesma causa: parcialidade pela defesa ou promoo do trabalho que o entrevistado desempenhou no projeto.

Dentre os benefcios mais citados para o projeto, encontramos um maior controle e independncia entre as equipes tcnicas envolvidas e uma integrao mais eficiente dos sistemas de informao. Para a organizao, citaram-se a padronizao de protocolos de conexo com sistemas e plataformas da empresa, maior flexibilidade e eficincia dos processos de negcio e o amadurecimento das tcnicas de desenvolvimento da equipe tcnica.

Os fatores motivadores para a adoo de SOA e os benefcios sugeridos lembram promessas encontradas na literatura, principalmente quanto flexibilidade e agilidade para atender clientes e fornecedores e isolamento de lgica de negcios (ELFWING et al, 2002; FERRIS e FARREL, 2003; MARKS e BELL, 2006; SORDI et al., 2006; CRAWFORD et al., 2005).

Percebeu-se nos relatos a concomitncia da construo de SOA com uma necessidade latente de corrigir de forma eficiente a fragmentao da informao pelos

Serman, D. V.,


632

sistemas. A Tabela 4 indica o desenvolvimento de servios nos projetos P e G sem potencial de reuso, enquanto a Tabela 3 mostra a meno a benefcios em torno de uma integrao mais eficiente.

Essa foi uma razo apontada para a centralizao da arquitetura na ferramenta de EAI. Segundo o entrevistado do projeto M, isso foi inicialmente um problema, pois se buscava unicamente efetuar as integraes na ferramenta sem considerar a viso de servios. Tal fato, conforme relato do prprio entrevistado, foi contornado com o apoio da equipe tcnica da organizao.

A Tabela 1 mostrou o foco inicial em projetos com menor impacto e escopo para a construo da estrutura de servios. Mesmo assim, foram relacionadas vrias contribuies dos primeiros projetos para SOA, como o desenvolvimento de servios com alto potencial de reuso e o conhecimento sobre os protocolos de comunicao dos principais sistemas e plataformas existentes na organizao.

Esse direcionamento indica um caminho diferente a um projeto central e de grande escopo para a construo de SOA em mbito corporativo (SORDI et al., 2006). Um planejamento da montagem da arquitetura baseada em projetos com menor impacto pode reduzir a percepo de risco para os gestores, que podem ver SOA como algo inalcanvel (SERMAN, 2007).

Assim, a construo dos servios no obedeceu a graus de evoluo como os propostos por Krafzig et al. (2004). Prevalece o desenvolvimento gradual da arquitetura, tomando como referncia o potencial de reutilizao e o amadurecimento tcnico.

Mesmo partindo de projetos menores, os efeitos foram considerados muito proveitosos. O entrevistado do projeto M indicou que os servios criados foram reutilizados em outros projetos e solicitaes sem necessidade do seu apoio ou de customizaes. Isso demonstra a importncia de se adotar um mtodo para a formao da carteira de projetos, como proposto por Kerzner (2006).

Mencionou-se a influncia de parceiros e agentes externos nos projetos que compuseram a amostra. Houve a criao ou reutilizao de servios com a pretenso de atender solicitaes de clientes e fornecedores e tambm para acatar obrigaes colocadas pelo Estado, como no caso da Nota Fiscal Eletrnica.

O entrevistado do projeto C indicou que essa prontido para atender os agentes externos trouxe agilidade e vantagem competitiva, reiterando o resultado encontrado por Kumar et al. (2007) de que SOA exerce influncia positiva sobre cadeias eletrnicas de fornecimento.

CONCLUSO

O trabalho mostra relevncia ao abordar uma forma gradual de desenvolvimento de uma arquitetura orientada a servios. A discusso levantada no se resume ao nvel tcnico ou s costumeiras promessas, ajudando metologicamente organizaes que temem adotar essa proposta por ach-la complexa e difcil de ser implementada ou por no contar com recursos com as competncias necessrias, conforme revelado por pesquisa (SERMAN, 2007).

A utilizao de carteiras de projetos para orientar a construo de SOA pode


Vol.7, No. 3, 2010, p. 619-638

633

reforar o alinhamento dos objetivos de TI em relao aos da organizao, ajudando a comunicar essa iniciativa de forma clara e trazendo respaldo para a manuteno dos esforos despendidos.

A pesquisa demonstrou que no regra que sejam necessrios projetos vultosos para alcanar resultados com SOA. Os projetos iniciais do caso estudado tinham escopo e impacto reduzidos, mas neles foram criados servios com alto potencial de reutilizao. Os projetos seguintes aproveitaram os servios e benefcios (ex: definio protocolos de comunicao com determinado sistema ou plataforma) gerados pelos predecessores e permitiram a criao de novos servios ou benefcios.

Figura 1: viso da evoluo de SOA pela sua construo gradual orientada a projetos

A Figura 1 exibe uma viso da evoluo de SOA no caso estudado. O eixo horizontal mostra trs fases para SOA referentes ao nvel de amadurecimento da organizao na adoo da proposta. Essa categorizao diferente da proposta por Krafzig et al. (2004), que se refere ao tipo e escopo dos servios construdos. O eixo vertical se refere ao foco da anlise, usando as categorias propostas por Serman (2007) para o contexto impactado.

Todos os pontos citados na Figura 1 foram extrados das entrevistas. No aspecto tcnico, verificou-se a necessidade inicial de descrever os protocolos de comunicao

Inicial

NEGCIO

Desconhecimento sobre SOA

Utilizao de servios mais comuns s operaes

Ampliao do escopo de utilizao dos servios

METODOLOGIA

Criao de servios com alto potencial de reuso em projetos de escopo e impacto reduzido

Reutilizao de servios em mais e maiores projetos

Reuso de servios sem necessidade de interveno de equipe que os criaram

TCNICO

Descrio e definio de protocolos de comunicao com sistemas/plataformas

Divulgao de SOA por toda equipe de TI

Definio de padres de protocolos de comunicao para desenvolvimento e seleo de pacotes

SOA Experimental

SOA Amadurecendo

SOA Plena

Serman, D. V.,


634

dos sistemas e plataformas (Projetos M, P, G e S), entendendo como integr-los com a ferramenta de EAI. Com o sucesso dos primeiros projetos, divulgou-se a proposta de SOA para toda a gerncia de TI (Projeto M) e definiram-se padres de protocolos de comunicao para aquisio de pacotes de software (Projeto G) e desenvolvimento de novos sistemas (Projeto M).

Pelo lado metodolgico, o desenvolvimento da arquitetura progrediu mais intensamente quando os servios com alto potencial de reuso foram desenvolvidos. Para esse caso, aproveitaram-se projetos com menor importncia e impacto para a organizao (Projeto M e S). Com os bons resultados obtidos, a proposta de SOA foi estendida a mais e maiores projetos (Projeto C), atingindo um ponto em que os servios eram reutilizados sem o conhecimento da equipe que os desenvolveu.

A estrutura inicial para SOA pode ser construda atravs de projetos de pequeno impacto. Desenvolvem-se servios de alto potencial de reuso, mas com escopo de utilizao reduzido para permitir o amadurecimento gradual da equipe e estrutura tcnica.

A partir dessa base, a organizao pode continuar de forma iterativa, acompanhando os ciclos de abertura e execuo dos seus projetos. A arquitetura e a equipe vo amadurecendo at que premissas da proposta de SOA, principalmente em relao ao reuso dos servios, sejam seguidas de forma mais automtica. A

Figura 2 exibe uma proposta de construo de SOA. A estrutura inicial para SOA se baseia em trs componentes: o plano de interfaces, com a descrio de como se comunicar com os principais sistemas e plataformas da organizao; a carteira inicial de projetos, dos quais sairo os primeiros servios; e um modelo de governana para SOA, com a definio de papis e procedimentos relacionados. Com esses componentes prontos, a organizao pode iniciar as iteraes para a evoluo de SOA com base nos seus ciclos de projeto.

As etapas que compem a iterao de evoluo de SOA so compatveis com os quatro passos propostos por Kerzner (2006) para a formao de uma carteira de projetos. Descontando a divulgao dos servios, as demais etapas contemplam a identificao de projetos, anlise de relao custo/benefcio (servios com maior potencial de reuso), seleo dos projetos e anlise dos impactos (futuras aplicaes dos servios criados).


Vol.7, No. 3, 2010, p. 619-638

635

Descrio protocolos

comunicao identificados

Descrio protocolos

comunicao identificados

Identificao sistemas e

plataformas principais

Identificao sistemas e

plataformas principais

Identificao de servios com

alto potencial de reuso ou crticos

Identificao de servios com

alto potencial de reuso ou crticos

Identificao de projetos para

desenvolvimento de servios

Identificao de projetos para

desenvolvimento de servios

Identificao de servios

candidatospara criao

Identificao de servios

candidatospara criao

Definio de modelo de

governana SOA para organizao

Definio de modelo de

governana SOA para organizao

Divulgao de modelo de

governana SOA

Divulgao de modelo de

governana SOA

PLANO DE INTERFACES

CARTEIRA INICIAL

GOVERNANASOA

Identificao de reuso de

servios

Identificao de reuso de

servios

Definio e criao de

projetos para servios

Definio e criao de

projetos para servios

Divulgao de servios criados

Divulgao de servios criados

EVOLUO ITERATIVA

ESTRUTURA SOA INICIAL

Figura 2: processo de construo de SOA orientada a projetos

A utilizao de uma ferramenta de EAI como cerne da arquitetura de servios uma caracterstica interessante do estudo. Ela auxiliou e tambm trouxe problemas durante a construo dos servios. A imaturidade da ferramenta, como apontado pelo entrevistado do Projeto M, imps mais um ponto de ateno equipe envolvida; contudo, foi muito til na soluo de problemas de fragmentao da informao, um dos motivadores para adoo de SOA. Entende-se que a proposta de construo de SOA orientada a projetos independa do emprego desse tipo de ferramenta.

Serman, D. V.,


636

LIMITAES

A observao da proposta de construo de SOA orientada a projetos se resumiu a apenas um caso. Isso se torna ainda mais crtico pelo nmero muito reduzido de estudos de caso sobre o processo de desenvolvimento de SOA.

Ao mesmo tempo em que torna maior a contribuio do trabalho, isso dificulta a avaliao dos seus resultados. A execuo de outros estudos de caso sobre esse assunto pode reforar as inspiraes aqui mencionadas e trazer outras novas, facilitando a anlise de erros e acertos na proposta sugerida.

A utilizao no caso estudado de uma ferramenta de EAI como cerne da arquitetura construda tambm pode ser observada em mais detalhes. Alm disso, um aprofundamento sobre governana de TI pode ser til para uma viso mais consistente do modelo de governana de SOA e da conduo da carteira de projetos.

REFERNCIAS

Albrecht, C. C. (2004) How clean is the future of SOAP? Communications of the ACM, v. 47, n. 2, p. 66-68,

Bernhardt, M.; Hinz, O. (2005) Creating Value with Interactive Pricing Mechanisms a Web Service-Oriented Architecture. Proceedings of the Seventh IEEE International Conference on E-Commerce Technology (CEC05), p. 339-346.

Bernstein, P. A.; Haas, L. M. (2008) Information Integration in the Enterprise. Communications of the ACM, v. 51, n. 9, p. 72-79

Ciganek, A. P..; Haines, M. N.; Haseman, W. (2005) Challenges of Adopting Web Services: Experiences from the Financial Industry. In: Proceedings of the 38th Hawaii International Conference on System Sciences, p. 1-10

Curbera, F.; Khalaf, R.; Mukhi, N.; Tai, S.; Weerawarana, S. (2003)The Next Step in Web Services. Communications of the ACM, v. 46, n. 10, p. 29-34

Crawford, C. H.; Bate, G. P.; Cherbakov, L.; Holley, K.; Tsocanos, (2005) C. Toward an on demand service-oriented architecture. IBM Systems Journal, v. 44, n. 1, p. 81-107

Dietrich, A. J.; Kirn, S.; Sugumaran, V. (2007) A Service-Oriented Architecture for Mass Customization: A Shoe Industry Case Study. IEEE Transactions on Engineering Management, v. 54, n. 1, p. 190-204,

Elfwing, R.; Paulsson, U.; Lundberg, L. (2002) Performance of SOAP in Web Service Environment Compared to CORBA. In: Proceedings of the Ninth Asia-Pacific Software Engineering Conference, p. 1-10

Ferris, C.; Farrel, J. (2003) What are Web Services? Communications of the ACM, v. 46, n. 6, p. 31


Vol.7, No. 3, 2010, p. 619-638

637

Kerzner, H. (2006) Gesto de projetos: as melhores prticas. 2 ed. Porto Alegre: Bookman

Kumar, S.; Dakshinamoorthy, V.; Krishnan, M. S. (2007) Does SOA Improve the Supply Chain? An Empirical Analysis of the Impact of SOA Adoption on Electronic Supply Chain Performance. Proceedings of the 40th Hawaii International Conference on System Sciences, p. 1-10

Krafzig, D.; Banke, K.; Slama, D. (2004) Enterprise SOA: Service-Oriented Architecture Best Practices. Indianapolis: Prentice Hall

Lee, J.; Siau, K.; Hong, S. (2003) Enterprise Integration with ERP and EAI. Communications of the ACM, v. 46, n. 2, p. 54-60

Lee, J. W. ; KIM, S. H. (2000) Using analytic network process and goal programming for interdependent information system project selection. Computers & Operations Research, v. 27, p. 367-382

Lin, C.; Hsieh, P. J. (2004) A fuzzy decision support system for strategic portfolio management. Decision Support Systems, v. 38, p. 383-398

Marks, E. A.; Bell, M. (2006) Service-oriented architecture: a planning and implementation guide for business and technology. New Jersey: John Wiley e Sons, Inc,

Mezo, B. M.; Chaparro, T. S.; Heras, A. D. (2008)Caractersticas de las empresas que utilizan Arquitectura Orientada a Servicios y de su contexto de operacin. Journal of Information Systems and Technology Management, v. 5, n. 2, p. 269-304

Papazoglou, M. P.; Georgakopoulos, D. (2003) Service-Oriented Computing. Communications of the ACM, v. 46, n. 10, p. 25-28

Pressman, R. S. (2002) Engenharia de software. 5 ed. Rio de Janeiro: McGraw-Hill

Puschmann, T.; ALT, R. (2001) Enterprise Application Integration - The Case of the Robert Bosch Group. In: Proceedings of the 34th Hawaii International Conference on System Sciences, p. 1-10

Scott, J. E.; Vessey, I. (2002) Managing Risks in Enterprise Systems Implementation. Communications of the ACM, v. 45, n. 4, p. 74-81

Serman, D. V. (2007) Estratgias de TI para a integrao eletrnica da informao: um estudo sobre o estado da arte e da prtica. 2007. 119 p. Dissertao (Mestrado em Administrao)Pontifcia Universidade Catlica do Rio de Janeiro, Rio de Janeiro

Siegel, J. (1998) Omg Overview - CORBA and the OMA in Enterprise Computing. Communications of the ACM. v. 41, n. 10, p. 37-43

Sordi, J., Marinho, B., NAGY, M. (2006) Benefcios da Arquitetura de Software Orientada a Servios para as empresas: anlise da experincia do ABN AMRO Brasil. Journal of Information Systems and Technology Management, v. 3, n. 1, p. 19-34

Stal, M. (20062) Web Services: Beyond Component-Based Computing. Communications of the ACM, v. 45, n. 10, p. 71-78

Serman, D. V.,


638

Summer, M. (2000) Risk Factors in Enterprise Wide Information Management Systems Projects. Proceedings of the 2000 ACM SIGCPR conference on Computer personnel research, p. 180-187,

Vergara, S. C. (1998) Projetos e relatrios de pesquisa em administrao. So Paulo: Atlas,

Yin, R. K. (2003) Case study Research, Design and Methods. Thousands Oaks, C.A: Sage Publications

Documents

Document07