Orientação a projetos: uma proposta de desenvolvimento de uma arquitetura orientada a serviços

Project orientation: a proposal to develop a service-oriented architecture

Orientação a projetos: uma proposta de desenvolvimento de uma arquitetura orientada a serviços

Project orientation: a proposal to develop a service-oriented architecture

Daniel Valente Serman

Pontifícia Universidade Católica do Rio de Janeiro, Brasil

^{Endereço para correspondência}

RESUMO

A arquitetura orientada a serviços (SOA) é ocasionalmente encarada como um desafio complexo e intransponível (Serman, 2007), sentimento motivado pela falta de atenção de praticantes e da academia sobre os meios para sua construção. O trabalho visa trazer a gestão da carteira de projetos de TI como opção para orientar o desenvolvimento de SOA. Para isso, realizou-se uma revisão da literatura sobre SOA, incluindo estudos de caso sobre sua adoção. Também foi executado um estudo de caso, no qual foram analisados os projetos de uma determinada organização, focando-se na evolução de sua arquitetura de serviços. Os resultados mostram a construção gradual de SOA no caso a partir da conclusão e sucessão dos projetos. Conclui-se com uma proposta de processo de construção de SOA e as limitações e sugestões de pesquisas futuras.

Palavras-chave: Arquitetura Orientada a Serviços (SOA), Web services, Gerência de Projetos, Gestão de Carteira de Projetos, Integração de Sistemas.

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.

1. INTRODUÇÃO

A orientação a serviços para a construção da arquitetura de sistemas de uma organização é colocada como um caminho para alcançar agilidade e flexibilidade para responder ao ambiente competitivo (Crawford et al., 2005; Kumar et al., 2007; Ciganek et al., 2005). Às vezes, são encontradas algumas posições mais extremas, como a condição de adotar essa proposta para não se cair em desvantagem competitiva (Marks & Bell, 2006).

Percebe-se, contudo, que os trabalhos sobre o tema demonstram, em geral, uma maior preocupação 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 mudança para SOA pode ser feita de forma gradual e Marks e Bell (2006) propõem modelos baseados na iteratividade para a construção de SOA. Há, porém, pouco aprofundamento sobre os métodos que podem ser utilizados. Nesse contexto, pode-se vislumbrar a utilidade da metodologia de gerência de projetos e gestão de carteira para o desenvolvimento paulatino e eficiente dos serviços, alicerçado nos projetos de implantação de sistemas de informação organizacionais.

O objetivo principal desse artigo é observar a evolução de uma arquitetura orientada a serviços através da gestão da carteira de projetos de implantação e desenvolvimento de sistemas de informação em uma organização. Um estudo de caso será executado com esse fim. Pretende-se alcançar outros objetivos, como propor um processo de construção de SOA, entender o impacto da maturidade de SOA nos projetos de sistemas de informação, identificar boas práticas e verificar a sinergia do conceito à metodologia de Gerência de Projetos.

O trabalho contribui sobre métodos para o desenvolvimento de SOA, cujo conteúdo na literatura é restrito. Sua importância para a prática também é grande, principalmente ao considerarmos que as organizações se mostram incipientes em sua utilização (Serman, 2007). A relevância do tema é salientada por Kumar et al. (2007), que cita pesquisas retratando o volume de investimento em SOA em torno de US$ 9 bilhões até 2009 e a crescente intenção das organizações em considerá-la em seus projetos.

O artigo é composto por: uma seção para fundamentação teórica de SOA e Gestão de Projetos, além de uma visão dos casos presentes na literatura sobre o desenvolvimento de SOA; a descrição do caso estudado, abordando a empresa, a situação inicial em relação a arquiteturas de sistemas e as ferramentas e métodos adotados sobre SOA; uma seção sobre a metodologia utilizada no artigo; um quarto ponto, que revela os resultados da pesquisa de campo; a quinta seção, que traz uma discussão sobre os resultados; e o sexto ponto, que contém as conclusões extraídas, limitações e sugestões para novas pesquisas.

2.FUNDAMENTAÇÃO TEÓRICA

2.1arquitetura Orientada A Serviços

Sordi et al. (2006) relacionam algumas situações indesejáveis causadas por problemas de integração entre sistemas de informação como: a incapacidade de redução no tempo dos processos por limitações de integração; a possibilidade de falhas na replicação manual de dados em diferentes sistemas; lentidão na identificação de oportunidades e ameaças pela falta de uma visão integrada de diferentes sistemas; e a dificuldade na substituição de estruturas de integração obsoletas pelo seu alto nível de complexidade. Como resposta a essa situação, a orientação a serviços 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 padronização de interfaces, reutilização de código e artefatos desenvolvidos e disposição dos sistemas de informação em componentes (Mezo et al., 2008; Stal, 2002; Marks & Bell, 2006).

Há diversas semelhanças se compararmos essas promessas com o que já foi mencionado em outras propostas que passaram por TI. Reutilização de código ou de componentes já era sugerida como boa prática (Pressman, 2002) e interfaces genéricas tinham sido previamente relacionadas a brokers (Siegel, 1998). Entretanto, em conjunto com as idéias "antigas", alguns pontos podem parecer novos (nem tanto pela proposta de SOA em si, mas pelo contexto em que ela se insere):

• Padrões abertos (livres de licenciamento) para protocolos de comunicação e documentação (Curbera et al., 2004; Dietrich et al., 2007);

• Uso de um meio de comunicação universalizado como a Internet no caso dos

  web services, um dos padrões relacionados a SOA (Curbera et al., 2004; Stal, 2002).

Assim, definimos que uma arquitetura orientada a serviços como um conceito de arquitetura de software formada por componentes disponíveis através de interfaces genéricas e protocolos padronizados e preferencialmente livres de licenças (os serviços), concebidos almejando-se o menor nível de dependência possível com os sistemas de informação que os consomem e da parte técnica do desenvolvimento, estimulando a sua reutilização e aproveitamento das funcionalidades já existentes.

Krafzig et al. (2004) propõem níveis de tipos de escopo de serviços observados pelas organizações para a construção de SOA: "SOA Fundamental", com a complexidade nas aplicações e a utilização de serviços para operações básicas; "SOA em rede", com o domínio de serviços intermediários, que visam atender deficiências técnicas e funcionais das aplicações; e "SOA habilitadora de processos", com a lógica de negócio e operação concentrada nos serviços.

Dentre os benefícios prometidos na literatura, encontramos flexibilidade e agilidade (Crawford et al., 2005; Kumar et al., 2007; Ciganek et al., 2005), a mitigação de dificuldades tecnológicas oriundas da obsolescência dos sistemas legados (Mezo et al., 2008) ou de problemas de utilização de outras tecnologias de integração (Corba, Dcom, COM+) (Kumar et al., 2007) e a maior facilidade de substituição de componentes e pacotes de software (Puschmann & Alt, 2001; Serman, 2007) por causa da menor dependência dos serviços em relação aos sistemas que os suportam.

Condizendo com a proximidade maior ao negócio que alguns autores dão para suas definições de SOA (Marks & Bell, 2006; Crawford et al., 2005), esses benefícios relacionados não se restringem ao uso da tecnologia, mas abrangem também questões metodológicas, organizacionais e de negócio, como mostrado por Serman (2007) em um quadro comparativo entre modalidades de integração de dados e sistemas.

Em relação à aplicação concreta de SOA, Kumar et al. (2007) comprovam em pesquisa hipótese de que empresas que integram seus clientes em uma cadeia eletrônica de fornecimento atingem melhor desempenho nessa cadeia quando ela está fundamentada em uma arquitetura orientada a serviços.

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 serviços. Sordi et al. (2006) argumentam que a escassez e pouco aprofundamento do conhecimento sobre o assunto, principalmente na academia, pode conduzir a essa percepção.

Além disso, pouco se encontrou sobre problemas ou mesmo precauções com a adoção de SOA. Albrecht (2004) alerta sobre os problemas de segurança que ainda são encontrados no uso do padrão de web services, podendo trazer consequências se as empresas buscarem a comunicação externa sem cuidado.

2.2.Gerência de Projetos

Kerzner (2006) define projeto como um empreendimento com objetivo bem definido, que consome recursos e opera sob pressões de prazos, custos e qualidade. Gestão de projetos para o mesmo autor consiste no planejamento, programação e controle de uma série de tarefas integradas de forma a atingir seus objetivos com êxito para benefício dos participantes do projeto (Kerzner, 2006).

O desenvolvimento de software é um tema em que frequentemente se aplicam as técnicas de gerência de projetos. Pressman (2002) elenca alguns itens que devem fazer parte de um projeto de software, dentre os quais podem ser destacados a abstração, a modularidade e a arquitetura de software.

Esses três itens têm forte relação à proposta de SOA. O primeiro permite a correta definição do escopo dos serviços (básicos, de escopo de processo, empresarial (Krafzig et al., 2004)); o segundo conduz ao desenvolvimento de serviços adequados à reutilização; e o terceiro garante a visão geral da arquitetura para a efetivação dos benefícios almejados. Sendo assim, a orientação a serviços da arquitetura poderia trazer benefícios não só à organização como um todo, mas à execução do próprio projeto.

No que tange aos riscos dos projetos de desenvolvimento de sistemas de informação, Scott e Vessey (2002) citam quatro fontes de riscos: ambiente de negócio externo à organização; organização; sistemas de informação e projetos de sistemas corporativos. Esses autores e Summer (2000) relacionam diversos riscos que são frequentes ao desenvolvimento de sistemas de informação, como a falta de conhecimento de novas tecnologias, complexidade técnica, problemas de liderança e apoio da alta gerência, falta de alinhamento com o negócio, dentre outros.

Alcançando maior flexibilidade e agilidade com o desenvolvimento de uma arquitetura orientada a serviços, 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 organização teria maior agilidade para responder a eles.

2.3.Formação de Carteira de Projetos

As empresas podem não conseguir atender a todas as demandas que lhe são impostas no tempo desejado, já que nem sempre dispõem de recursos suficientes (Kerzner, 2006). Assim, a eficiência na formação de uma carteira de projetos é importante e deve levar em consideração os objetivos corporativos, a disponibilidade de recursos financeiros e humanos e as restrições colocadas pelo ambiente (Lin & Hsieh, 2004).

Alguns métodos para formação de carteira de projetos são propostos na literatura (Kerzner, 2006; Lin & Hsieh, 2004; Lee & Kim, 2000). Kerzner (2006) fala de quatro passos: identificação de projetos; avaliação preliminar, que engloba estudos de exequibilidade e análise de custo/benefício; seleção estratégica de projetos (buscando o alinhamento com os objetivos da empresa); e programação estratégica, que contempla análise de disponibilidade de recursos e do mercado impactado.

Lee e Kim (2000) argumentam que é importante tratar da interdependência entre os projetos, que geralmente é desconsiderada nos métodos de formação de carteira. Os autores citam três categorias sobre a interdependência: recursos (humanos), benefícios (através da sinergia entre eles) e técnicos (estipulando as relações de dependência). A reutilização dos serviços pode se enquadrar nas duas últimas categorias.

A visão de integração como uma etapa de projeto pode dar lugar a uma busca mais contínua: a informação é 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 construção de uma arquitetura de software de forma iterativa e pode ser um direcionamento eficaz para SOA, facilitando o planejamento do desenvolvimento dos serviços e sua reutilização (Mezo et al., 2008; Marks & Bell, 2006; Crawford, 2005).

2.4.Desenvolvimento de SOA nas Organizações

A literatura sobre SOA dá maior destaque para os benefícios encontrados com a adoção da proposta, requisitos tecnológicos e direcionamento técnico para a arquitetura de software. Há, entretanto, pouca atenção para aspectos metodológicos de desenvolvimento dos serviços.

Poucos artigos abordam metodologias ou técnicas para a construção de SOA. Buscamos estudos de caso sobre o assunto, mas, na maior parte dos casos, encontramos a apresentação do que foi construído, mas pouco ou nenhum detalhe sobre como o resultado foi atingido.

Dentre os exemplos encontrados de aplicação de SOA, encontrou-se a utilização de modelos de serviços padronizados para determinadas áreas de negócio, como a fabricação de calçados segundo o conceito de "customização em massa" (Dietrich et al., 2007) e a política de definição de preço para leilões reversos (Bernhardt & Hinz, 2005). Bernhardt e Hinz (2005) trazem a ideia de um parceiro externo que funciona como provedor de serviços que passariam a integrar a arquitetura da organização cliente.

O trabalho de Sordi et al. (2006) foi uma das exceções, apresentando a proposta de níveis de maturidade de Krafzig et al. (2004) como caminho para desenvolvimento de SOA. A proposta consistiria na construção de serviços dos níveis básicos até os mais complexos, que envolveriam outras organizações. Entretanto, não há aprofundamento sobre como a construção 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) propõem um "modelo iterativo de negócios para SOA". Os autores argumentam que SOA não se baseia em um modelo de desenvolvimento restrito a um único evento, como um "big bang". Eles relacionam seis caminhos possíveis de identificação de serviços que devem ser usados em conjunto de forma repetitiva: análise de processos de negócio, análise das entidades de dados principais (ex: pedidos, faturas, etc), oportunidades através de projetos já orçados, conhecimento sobre o domínio do negócio e serviços e aplicações pré-existentes. Não é citado, contudo, nenhum exemplo.

3. DESCRIÇÃO DO CASO ESTUDADO

A empresa estudada pertence ao ramo de Petróleo e Gás e possui mais de cinco mil funcionários. Dentre eles, em torno de cento e sessenta integram a Gerência de Informática.

O início do movimento de construção de uma arquitetura orientada a serviços nessa empresa começou com a aquisição de uma ferramenta de integração de aplicações (EAI - Enterprise Application Integration).

O objetivo com essa ferramenta era integrar o parque de sistemas, caracterizado pela heterogeneidade de plataformas, linguagens de programação e protocolos de comunicação. Com a centralização da comunicação entre os sistemas e sua rastreabilidade se pretendia resolver problemas de uma implantação de ERP mal sucedida, que não reduziu o legado e só aumentou o nível de complexidade.

A ferramenta prometia compatibilidade com diversos padrões de protocolos de comunicação 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 introdução de SOA a partir da ferramenta, composto por três projetos que estariam ligados a necessidades de integração de informação da empresa. O objetivo primário consistia em entender o funcionamento da ferramenta adquirida e, por conseguinte, decifrar o mecanismo de interação com as aplicações da organização.

A percepção inicial da equipe de TI era de que a ferramenta era "mágica" pela forma como foi apresentada pelo fornecedor. Foi necessário, então, contratar uma consultoria especializada para treinar a equipe na ferramenta.

Em seguida, com um maior domínio 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 negócio ligados à fragmentação da informação por diversos sistemas e possibilidade de reutilização de serviços foram critérios para seleção dos projetos.

Em paralelo, foram concebidas algumas diretrizes e técnicas para a construção da arquitetura orientada a serviços. Manuais e treinamentos foram elaborados para que os conceitos e métodos fossem disseminados e assimilados por toda a equipe de Informática da organização.

4.METODOLOGIA

O método 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 não foi encontrado na revisão da literatura nenhum relato sobre experiências com a orientação do desenvolvimento de SOA com base em projetos de implantação de sistemas de informação.

O critério de acessibilidade proposto por Vergara (1998) corrobora a escolha, já que a empresa analisada foi a única identificada em que se aplica essa visão para a implementação de SOA.

O estudo é único porque trata apenas de uma empresa, mas é incorporado porque se pretende promover a análise no nível dos projetos, tratando-os como subunidades do caso. Com isso, a evolução de SOA será apreciada através da visão das características particulares de cada projeto, sem abandonar a unidade de estudo, que é a empresa.

O universo da pesquisa consistiu em projetos de desenvolvimento ou implantação de sistemas de informação da organização, para os quais se aplicou a visão de serviços para a arquitetura e se utilizou a ferramenta de EAI. Foram selecionados projetos em que a intenção de usar a proposta foi parte do planejamento do projeto ou surgiu durante sua execução.

A amostra foi formada por oito projetos. Decidiu-se incluir também um projeto de construção de um arcabouço teórico e metodológico para o desenvolvimento de uma arquitetura orientada a serviços corporativa. Esse projeto será tratado à parte, já que não houve desenvolvimento de software.

Para a coleta de dados foi entrevistado um dos membros de cada projeto da amostra, podendo ser seu gerente, líder técnico ou analista responsável pela integração. 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 não haver necessidade de alterações.

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 questionário com perguntas abertas. Para os profissionais localizados no mesmo sítio do pesquisador, as entrevistas foram presenciais; caso contrário, o questionário foi submetido via e-mail e houve réplica e tréplica, também por e-mail.

Para a pergunta sobre as motivações que levaram à adoção de SOA nos projetos, foram considerados os fatores citados por Mezo et al. (2008), que interferem na decisão sobre sistemas de informação. As motivações mencionadas para os projetos foram enquadradas em categorias, conforme feito por Serman (2007): tecnológicas, organizacionais e de negócio.

Nas entrevistas, foram questionados os requisitos, benefícios e problemas encontrados com o desenvolvimento dos serviços e com sua inserção na arquitetura da organização. Foi solicitado aos entrevistados que levassem em consideração a mesma categorização usada para as motivações (tecnológicas, organizacionais e de negócio).

O resultado das entrevistas foi compilado por projeto. Frequentemente, os entrevistados saíam do escopo original das perguntas, o que é esperado quando muitas dessas respostas são motivadas por reações de defesa ou promoção do trabalho realizado (Serman, 2007). Nesses casos, as respostas foram reorganizadas e arroladas aos itens do questionário 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 início de sua execução e o segundo foi considerado irrelevante pelo seu líder técnico.

Os dois primeiros projetos da amostra correspondem ao piloto de utilização da ferramenta de EAI na organização. Os quatro seguintes correspondem a projetos de desenvolvimento de sistemas ou implantação de pacotes de software de mercado em que se adotou a proposta de SOA. A Tabela 1 exibe algumas informações do projeto apresentadas em ordem cronológica.

A consultoria contratada para utilização da ferramenta de EAI participou dos três primeiros projetos (M, P e G). Os entrevistados desses casos apontaram problemas de falta de conhecimento e postura da consultoria, passando uma percepção de que a evolução de SOA só pode seguir com sua saída e envolvimento direto e total da equipe de TI da organização.

Os relatos indicaram que o sucesso no piloto permitiu que a visão de SOA fosse estendida a outros projetos importantes da carteira da área de TI. A Tabela 2 mostra as motivações indicadas pelos entrevistados para a adoção 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, além dos benefícios e problemas obtidos para o projeto e para a organização. Esses pontos estão apresentados na Erro! A origem da referência não foi encontrada..

Por outro lado, a Tabela 4 mostra as contribuições dos projetos para a arquitetura segundo os entrevistados, além da visão de reutilização de serviços. Nela, se indica o potencial de reuso dos serviços construídos no projeto e o consumo de outros previamente desenvolvidos.

Foram citados alguns padrões de mercado para desenvolvimento de software e protocolos de comunicação, como web services (Ferris e Farrel, 2003) e Java, mas alguns relatos citaram a necessidade de contornar e entender questões específicas de pacotes de software adquiridos e até do ERP.

Todos os entrevistados mencionaram a boa percepção dos usuários envolvidos nos projetos com a adoção de SOA. Um dos entrevistados explicou que as práticas adotadas pelas equipes motivaram uma maior aproximação da parte funcional com a técnica, assim como da gerência de TI à equipe do projeto.

O projeto para construção do arcabouço teórico e metodológico para governança de SOA visou, segundo o entrevistado, criar padrões de nomenclatura e design, definir processos e responsabilidades para a equipe técnica, dentre outros tópicos. Esse arcabouço deveria ser, por definição da gerência de TI, centrado na ferramenta de EAI.

Relatou-se que a importância dessa iniciativa era a falta de maturidade conceitual da ferramenta de EAI, a incompetência de seu fornecedor em conceber normas concretas de governança e documentação e a ausência de um bom parceiro naquele momento para prestação de serviços sobre a ferramenta.

Para a preparação 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 administração. Definiu-se um processo de identificação e criação de serviços e foram liberados documentos para solicitação de serviços e de descrição dos protocolos de comunicação dos sistemas e plataformas utilizados pela empresa.

Outras sugestões foram levantadas: criação de uma área ou grupo formal dedicado à arquitetura de sistemas de informação da empresa; criação de portal de documentação dos serviços e integração do método de desenvolvimento de serviços ao processo de desenvolvimento utilizado pela empresa.

O entrevistado mencionou que vários objetivos do projeto não foram atingidos. Um dos motivos apresentados foi o "descolamento" do mentor e executor do projeto com as práticas e necessidades apontadas pelos projetos de desenvolvimento de software em que a proposta de SOA estava sendo adotada.

DISCUSSÃO

As entrevistas trouxeram um conteúdo relevante sobre o desenvolvimento de serviços a partir dos projetos que compuseram a amostra e a contribuição que a visão orientada a serviços e direcionada pelos projetos trouxe para a organização.

Sobre as motivações que conduziram à adoção de SOA para o projeto, destacaram-se nos relatos:

• Aspectos técnicos: troca de informação pelos sistemas de forma eficiente, configuração das soluções na forma de serviços, forte impacto da infra-estrutura tecnológica no negócio;

• Aspectos metodológicos/organizacionais: processos fragmentados em diferentes sistemas de informação;

• Aspectos de negócio: transações em tempo real, necessidade de escalabilidade e flexibilidade e de integração entre os próprios sistemas e os de clientes e fornecedores.

A Tabela 3 mostra que houve um maior impacto de requisitos para a adoção de SOA, principalmente técnicos, 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 comunicação com os sistemas implantados ou já existentes.

Muitos desses sistemas e plataformas não eram compatíveis com padrões de mercado, exigindo que a equipe técnica buscasse apoio dos fornecedores para implementar a comunicação entre a ferramenta de EAI e esses sistemas. A única referência a esse ponto na literatura utilizada é feita por Serman (2007).

Os depoimentos se mostraram geralmente positivos sobre SOA. Foram relatados poucos problemas com sua adoção e eles geralmente estavam diretamente relacionados aos requisitos citados. Essa ausência de problemas também foi observada na pesquisa de Serman (2007) sobre integração de sistemas e dados e podem ter a mesma causa: parcialidade pela defesa ou promoção do trabalho que o entrevistado desempenhou no projeto.

Dentre os benefícios mais citados para o projeto, encontramos um maior controle e independência entre as equipes técnicas envolvidas e uma integração mais eficiente dos sistemas de informação. Para a organização, citaram-se a padronização de protocolos de conexão com sistemas e plataformas da empresa, maior flexibilidade e eficiência dos processos de negócio e o amadurecimento das técnicas de desenvolvimento da equipe técnica.

Os fatores motivadores para a adoção de SOA e os benefícios sugeridos lembram "promessas" encontradas na literatura, principalmente quanto à flexibilidade e à agilidade para atender clientes e fornecedores e isolamento de lógica de negócios (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 concomitância da construção de SOA com uma necessidade latente de corrigir de forma eficiente a fragmentação da informação pelos sistemas. A Tabela 4 indica o desenvolvimento de serviços nos projetos P e G sem potencial de reuso, enquanto a Tabela 3 mostra a menção a benefícios em torno de uma integração mais eficiente.

Essa foi uma razão apontada para a centralização da arquitetura na ferramenta de EAI. Segundo o entrevistado do projeto M, isso foi inicialmente um problema, pois se buscava unicamente efetuar as integrações na ferramenta sem considerar a visão de serviços. Tal fato, conforme relato do próprio entrevistado, foi contornado com o apoio da equipe técnica da organização.

A Tabela 1 mostrou o foco inicial em projetos com menor impacto e escopo para a construção da estrutura de serviços. Mesmo assim, foram relacionadas várias contribuições dos primeiros projetos para SOA, como o desenvolvimento de serviços com alto potencial de reuso e o conhecimento sobre os protocolos de comunicação dos principais sistemas e plataformas existentes na organização.

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

Assim, a construção dos serviços não obedeceu a graus de evolução como os propostos por Krafzig et al. (2004). Prevalece o desenvolvimento gradual da arquitetura, tomando como referência o potencial de reutilização e o amadurecimento técnico.

Mesmo partindo de projetos menores, os efeitos foram considerados muito proveitosos. O entrevistado do projeto M indicou que os serviços criados foram reutilizados em outros projetos e solicitações sem necessidade do seu apoio ou de customizações. Isso demonstra a importância de se adotar um método para a formação da carteira de projetos, como proposto por Kerzner (2006).

Mencionou-se a influência de parceiros e agentes externos nos projetos que compuseram a amostra. Houve a criação ou reutilização de serviços com a pretensão de atender solicitações de clientes e fornecedores e também para acatar obrigações colocadas pelo Estado, como no caso da Nota Fiscal Eletrônica.

O entrevistado do projeto C indicou que essa "prontidão" para atender os agentes externos trouxe agilidade e vantagem competitiva, reiterando o resultado encontrado por Kumar et al. (2007) de que SOA exerce influência positiva sobre cadeias eletrônicas de fornecimento.

CONCLUSÃO

O trabalho mostra relevância ao abordar uma forma gradual de desenvolvimento de uma arquitetura orientada a serviços. A discussão levantada não se resume ao nível técnico ou às costumeiras promessas, ajudando metologicamente organizações que temem adotar essa proposta por achá-la complexa e difícil de ser implementada ou por não contar com recursos com as competências necessárias, conforme revelado por pesquisa (SERMAN, 2007).

A utilização de carteiras de projetos para orientar a construção de SOA pode reforçar o alinhamento dos objetivos de TI em relação aos da organização, ajudando a comunicar essa iniciativa de forma clara e trazendo respaldo para a manutenção dos esforços despendidos.

A pesquisa demonstrou que não é regra que sejam necessários projetos vultosos para alcançar resultados com SOA. Os projetos iniciais do caso estudado tinham escopo e impacto reduzidos, mas neles foram criados serviços com alto potencial de reutilização. Os projetos seguintes aproveitaram os serviços e benefícios (ex: definição protocolos de comunicação com determinado sistema ou plataforma) gerados pelos predecessores e permitiram a criação de novos serviços ou benefícios.

A Figura 1 exibe uma visão da evolução de SOA no caso estudado. O eixo horizontal mostra três fases para SOA referentes ao nível de amadurecimento da organização na adoção da proposta. Essa categorização é diferente da proposta por Krafzig et al. (2004), que se refere ao tipo e escopo dos serviços construídos. O eixo vertical se refere ao foco da análise, usando as categorias propostas por Serman (2007) para o contexto impactado.

Todos os pontos citados na Figura 1 foram extraídos das entrevistas. No aspecto técnico, verificou-se a necessidade inicial de descrever os protocolos de comunicação 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 gerência de TI (Projeto M) e definiram-se padrões de protocolos de comunicação para aquisição de pacotes de software (Projeto G) e desenvolvimento de novos sistemas (Projeto M).

Pelo lado metodológico, o desenvolvimento da arquitetura progrediu mais intensamente quando os serviços com alto potencial de reuso foram desenvolvidos. Para esse caso, aproveitaram-se projetos com menor importância e impacto para a organização (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 serviços eram reutilizados sem o conhecimento da equipe que os desenvolveu.

A estrutura inicial para SOA pode ser construída através de projetos de pequeno impacto. Desenvolvem-se serviços de alto potencial de reuso, mas com escopo de utilização reduzido para permitir o amadurecimento gradual da equipe e estrutura técnica.

A partir dessa base, a organização pode continuar de forma iterativa, acompanhando os ciclos de abertura e execução dos seus projetos. A arquitetura e a equipe vão amadurecendo até que premissas da proposta de SOA, principalmente em relação ao reuso dos serviços, sejam seguidas de forma mais automática.

A Figura 2 exibe uma proposta de construção de SOA. A estrutura inicial para SOA se baseia em três componentes: o plano de interfaces, com a descrição de como se comunicar com os principais sistemas e plataformas da organização; a carteira inicial de projetos, dos quais sairão os primeiros serviços; e um modelo de governança para SOA, com a definição de papéis e procedimentos relacionados. Com esses componentes prontos, a organização pode iniciar as iterações para a evolução de SOA com base nos seus ciclos de projeto.

As etapas que compõem a iteração de evolução de SOA são compatíveis com os quatro passos propostos por Kerzner (2006) para a formação de uma carteira de projetos. Descontando a divulgação dos serviços, as demais etapas contemplam a identificação de projetos, análise de relação custo/benefício (serviços com maior potencial de reuso), seleção dos projetos e análise dos impactos (futuras aplicações dos serviços criados).

A utilização de uma ferramenta de EAI como cerne da arquitetura de serviços é uma característica interessante do estudo. Ela auxiliou e também trouxe problemas durante a construção dos serviços. A imaturidade da ferramenta, como apontado pelo entrevistado do Projeto M, impôs mais um ponto de atenção à equipe envolvida; contudo, foi muito útil na solução de problemas de fragmentação da informação, um dos motivadores para adoção de SOA. Entende-se que a proposta de construção de SOA orientada a projetos independa do emprego desse tipo de ferramenta.

LIMITAÇÕES

A observação da proposta de construção de SOA orientada a projetos se resumiu a apenas um caso. Isso se torna ainda mais crítico pelo número muito reduzido de estudos de caso sobre o processo de desenvolvimento de SOA.

Ao mesmo tempo em que torna maior a contribuição do trabalho, isso dificulta a avaliação dos seus resultados. A execução de outros estudos de caso sobre esse assunto pode reforçar as inspirações aqui mencionadas e trazer outras novas, facilitando a análise de erros e acertos na proposta sugerida.

A utilização no caso estudado de uma ferramenta de EAI como cerne da arquitetura construída também pode ser observada em mais detalhes. Além disso, um aprofundamento sobre governança de TI pode ser útil para uma visão mais consistente do modelo de governança de SOA e da condução da carteira de projetos.

Recebido em: 05/11/2009

Aprovado em: 13/06/2010

• 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 (CEC'05), 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
• Kerzner, H. (2006) Gestão de projetos: as melhores práticas. 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)Características de las empresas que utilizan Arquitectura Orientada a Servicios y de su contexto de operación. 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) Estratégias de TI para a integração eletrônica da informação: um estudo sobre o estado da arte e da prática. 2007. 119 p. Dissertação (Mestrado em Administração)-Pontifícia Universidade Católica 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) Benefícios da Arquitetura de Software Orientada a Serviços para as empresas: análise da experiência 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
• 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 relatórios de pesquisa em administração São Paulo: Atlas,
• Yin, R. K. (2003) Case study Research, Design and Methods. Thousands Oaks, C.A: Sage Publications

Datas de Publicação

• Publicação nesta coleção
  21 Fev 2011
• Data do Fascículo
  2010

Histórico

• Aceito
  13 Jun 2010
• Recebido
  05 Nov 2009