5 fatores de sucesso para enfrentar os problemas de integrações na automação de processos

Tendo participado de vários de projetos de automação de processos, se tem algo que podemos afirmar como sendo um denominador comum a projetos de automação em empresas das mais diferentes áreas, é dos problemas que surgem quando existe necessidade de integração do processo automatizado com outros sistemas/organizações.

O fato é que problemas relacionados a integrações invariavelmente vão ocorrer, apenas variando de acordo com o grau de complexidade do processo e das integrações em si. Por outro lado, existem sim alguns fatores e cuidados que podem evitar problemas ou facilitar a sua resolução.

Ter conhecimento destes fatores no projeto vai prepará-lo melhor para o que vem pela frente.

Vamos a eles?

1. Ter uma boa governança dos serviços/integrações/funcionalidades disponíveis

Durante a automação do processo, é comum detectar uma ou mais necessidades de integração (ex: salvar alguma informação digitada durante a execução do processo num banco de dados).

Em nossa experiência, boa parte dos problemas que ocorrem nestes casos se devem a falta de governança da organização em relação aos serviços, integrações e sistemas existentes, ou seja, não se sabe se aquela necessidade de integração do processo já se encontra disponível (ex: através de um webservice).

A consequência disso é a necessidade de se discutir do zero esta integração, fazer orçamento e incluí-la no escopo, o que leva a aumento do prazo e custo do projeto. Um fator que minimiza bastante estes problemas é se a organização já trabalha numa Arquitetura Orientada a Serviços, ou simplesmente SOA (mais informações aqui, aqui e aqui), bem como dispor de ferramentas de governança/pesquisa de serviços.

2. Prever o modelo de dados do processo adequado as necessidades de integração

Quando um processo será automatizado, deve-se previamente fazer uma análise para definir o “modelo de dados” do processo, ou seja, as informações que serão visualizadas e manipuladas ao longo da execução do processo (veja aqui para mais informações).

A definição deste modelo de dados costuma ser mais transparente quando estamos falando de informações que ficam visíveis no formulário eletrônico do processo, ou seja, as informações que os usuários vão visualizar/editar ao acessar as tarefas. Mas infelizmente não é tão óbvio quando falamos de integrações.

Por exemplo, se é necessário chamar uma integração para atualizar uma informação no ERP a partir do processo automatizado, pode se descobrir que uma das informações obrigatórias para se chamar esta integração é específica daquele sistema (ex: um determinado identificador), e esta informação não foi prevista inicialmente no modelo de dados.

Com frequência, inclusive, ocorre a situação de que para obter a informação que você precisa para chamar uma integração, é necessário chamar outra integração!

Este fator costuma gerar muitas dores de cabeça, em muitos casos não é fácil prever todas as possibilidades.

3. Ter conhecimento das funcionalidades e limitações do framework de integração do BPMS

Mesmo que inicialmente a empresa tenha adquirido uma solução de BPMS para um processo pontual ou para apenas gerenciar fluxo de trabalho sem integrações com outros sistemas, o fato é que as necessidades da organização mudam. Quando chegar o momento em que as iniciativas de automação de processos passarem a demandar mais inteligência, com integração de dados existentes em outros sistemas, é importante conhecer as funcionalidades e limitações de integração do BPMS.

Por exemplo, alguns questionamentos comuns nestes casos:

  • Posso chamar webservices através do BPMS?
  • Consigo conectar diretamente num banco de dados através do BPMS?
  • Existem adaptadores nativos que permitem conexões com sistemas conhecidos no mercado?
  • O BPMS me permite realizar transformações complexas de dados ao chamar ou obter o retorno de um webservice?
  • Existe algum formato específico de assinatura do serviço para poder ser acionado?
  • Com que tecnologias o BPMS permite fazer integração? Soap? Rest? Corba? EJB? .net? Controle de arquivos no filesystem? Outros?

Este conhecimento é importante para detectar eventuais restrições da ferramenta, identificar a necessidade de utilizar outras ferramentas em conjunto ao BPMS, ou no pior dos cenários até a troca do próprio BPMS. Por exemplo: se o BPMS não é capaz de fazer transformações de dados complexas ao chamar um webservice, então possivelmente será necessária outra ferramenta (ex: uma ferramenta de barramento de serviços) que fará esta transformação no lugar do BPMS, expondo para o BPMS uma versão simplificada do serviço. Neste mesmo exemplo, pode ser que esta ferramenta adicional não exista na organização, e precisa ser previsto a sua contratação e implantação, dentro do escopo do projeto de automação.

Entenda a importância de uma avaliação detalhada sobre recursos ​dos produtos ao adquirir uma plataforma ​BPMS com ​esta coleção de artigos sobre Seleção de Plataformas de BPM.

4. Equipes dos sistemas disponíveis para apoiar o projeto

Parece chover no molhado, afinal se um processo automatizado precisa se comunicar com o sistema X, então a equipe de apoio deste sistema tem que estar envolvida, certo? Bem, temos algumas histórias de iniciativas de automação de processos aprovadas em nível executivo, mas que durante o andamento do projeto as equipes dos sistemas estavam em uma das seguintes condições:

  • Não estavam sabendo do projeto – o popular “cair de paraquedas”  (sim, é comum);
  • Sabiam do projeto e que em algum momento iriam se envolver, mas não tinham nenhum contexto dos objetivos do projeto e o seu papel (tem na prática os mesmos efeitos nocivos da situação anterior);
  • Sabiam do projeto e tinham o contexto, mas não tiveram a alocação reservada para apoiar o projeto (“Eu conheço o projeto e entendo o que devo fazer, mas não sei se vou conseguir ajudá-los ainda neste mês…”).

Quando as equipes dos sistemas começam a se envolver no projeto, é comum surgirem problemas e limitações que não se tinha noção, o que pode ocasionar necessidade de se rediscutir a solução. Aqui o apoio da liderança executiva e da gestão de projetos é fundamental para minimizar os problemas, reforçando a alocação das equipes dos sistemas envolvidos, para se envolverem no projeto de automação o quanto antes, preferencialmente ainda durante as fases de análise e projeto.

5. Atenção à  etapa de testes

Se existem integrações no processo, obviamente as mesmas precisam ser bem testadas, envolvendo as equipes responsáveis pelos sistemas de origem/destino das informações.

Ocorre que na automação de processos, assim como no desenvolvimento tradicional de sistemas, pode ocorrer a tendência de dar ênfase maior apenas a “interface” do processo, que no caso do BPMS são os formulários das atividades enviadas para os usuários. Mas obviamente as integrações que são feitas automaticamente pelo processo devem ser testadas com o mesmo cuidado, verificando se estão retornando ou gravando as informações corretamente.

Isto comumente é realizado utilizando os recursos de rastreamento/auditoria presentes das próprias ferramentas de BPMS (verificando o que está recebendo ou enviando de informações), bem como acessando diretamente o sistema com o qual se tem a integração (para verificar se os dados sendo obtidos/atualizados pelo BPMS estão corretos).

Estas verificações normalmente exigem um conhecimento técnico maior (ex: visualizar payloads em XML, acessar as informações diretamente em tabelas do banco de dados do sistema em questão, etc).

 

Sem dúvida existem outros fatores envolvidos, mas acreditamos que os fatores citados acima dão um bom norte para a equipe do projeto se preparar e enfrentar os problemas que podem ocorrer nas integrações durante a automação de processos.

 

Oracle SOA Suite 12c – novidades desta nova versão

A mais nova versão lançada pelo Oracle do SOA Suite, a 12c, apresenta muitas novidades e promete melhorias em desempenho e interface. Neste artigo apresentamos uma visão geral das novidades apresentadas pela Oracle, baseada no documento disponibilizado pela empresa nomeado “What’s New in Oracle SOA Suite 12c”.

Introdução

O aumento inevitável da complexidade das integrações e novos desafios apresentados pelo mundo atual, como a integração com as aplicações na nuvem, com os dispositivos móveis e a Internet das Coisas (“Internet of Things”, IoT), foram os pilares para o desenvolvimento desta nova versão. O Oacle SOA Suite 12c foi desenvolvido com foco na simplificação das integrações destes desafios em uma única plataforma baseada em padrões de mercado.

Integração com a nuvem

O recentemente lançado Oracle Cloud Adapters simplifica a integração das aplicações na nuvem com a infraestrutura já existente, oferecendo, além de conectividade baseada em padrões, bases para auditorias, conformidade, segurança e governança.

Eles permitem que o desenvolvedor não precise desenvolver lógicas específicas para gerenciar as conexões, focando na lógica de negócio. Para a criação dos adapters, são oferecidos assistentes com opções e configurações.

Em resumo, a maioria das nuances da integração com as aplicações na nuvem, tais como gerenciamento de sessão, tratamento de arquivos WSDL complexos e segurança são tratadas pelo próprio adapter, reduzindo a possibilidade de erros, o ciclo de desenvolvimento e o custo de manutenção.

Também foi disponibilizado o Cloud Adapter SDK, onde é possível criar o seu próprio adapter utilizando a mesma ferramenta usada pela Oracle. Ela oferece um conjunto de APIs, tanto para situações em tempo de projeto quanto em tempo de execução.

Dispositivos móveis

Atualmente os usuários exigem a possibilidade de utilizar seus smartphones e tablets para acessar os dados corporativos e aplicativos de negócio, onde e quando quiserem. Para ajudar nesta mudança de paradigma, o Representational State Transfer (REST) e o JavaScript Object Notation (JSON) surgiram como padrões dominantes para expor serviços e APIs para dispositivos móveis.

O Oracle SOA Suite 12c incluiu o REST bindind no JDeveloper para simplificar a exposição das implementações tradicionais do SOA Suite para dispositivos móveis. Ele está disponível para os composites SOA e para os serviços do Service Bus, permitindo expor interfaces e invocar serviços REST externamente.

Internet das Coisas (IoT)

Os dispositivos e aparelhos estão se tornando cada vez mais conectados, e a internet das coisas está se fazendo muito presente. Neste cenário, o Middleware atua como uma ponte entre os dispositivos e as aplicações corporativas.

Processamento de eventos é parte integrante desse tipo de plataforma, pois grande quantidade de dados são enviados dos dispositivos e é essencial distinguir que dados são importantes e quais não são.

O Oracle Event Processing (OEP) vem com a promessa de análise em tempo real e dados em alta velocidade, se tornando uma solução para construir aplicações IoT para filtrar, correlacionar e processar os eventos. Nesta nova versão, a Oracle integrou mais fortemente a plataforma OEP com o Oracle Service Bus (OSB) e com o Oracle SOA Suite Event Delivery Network (EDN).

Managed File Transfer

O Oracle Managed File Transfer (Oracle MFT) é um produto novo desta versão, que permite trocas de arquivo seguras, gerenciamento entre departamentos internos e parceiros externos e facilidade de uso, especialmente por pessoal não técnico. As suas capacidades de relatório permitem obter um status da transferência do arquivo e o seu reenvio, se necessário.

B2B

O Oracle B2B 12c foi integrado mais fortemente com o Oracle SOA Suite e Oracle Managed File Transfer. Os usuários do B2B podem enviar e receber mensagens no Oracle B2B utilizando o Managed File Transfer, além da possibilidade da transmissão de documentos grandes. Para melhoria de gerenciamento e monitoramento, o B2B foi integrado com o SOA Error Hospital, comentado posteriormente. Para simplificar a experiência dos usuários que utilizam Web Services no B2B, foi adicionado o suporte ao Local Policy Attachment para configuração de segurança de Web Services.

Melhoramentos para produtividade

  • Instalação rápida: o processo foi simplificado, e para ambientes de desenvolvimento oferece uma base onde todos os componentes do SOA Suite são instalados, além do JDeveloper com o servidor WebLogic integrado e todas extensões .
  • Interface unificada de desenvolvimento: foi dado um passo para integrar os componentes do Oracle SOA Suite, Oracle Service Bus (OSB) e o Oracle Event Processing (OEP). Foram criadas interfaces e editores no JDeveloper para o desenvolvimento de projetos do OSB e OEP integrados e compartilhando recursos já presentes anteriormente.
  • Templates: novos recursos que ampliam a possibilidade de compartilhamento e reuso de serviços e componentes, permitindo a customização de modelos de projetos, de componentes, de grupos de atividades em um processo BPEL e pipeline do OSB.
  • Subprocessos BPEL: promovem o reuso e compartilhamento de fragmentos da lógica de negócio, que podem ser inline (dentro de um processo BPEL) ou standalone (externo).
  • Melhoramentos no depurador: foi incluído no JDeveloper um depurador visual, como um depurador java, que permite definir pontos de parada nos composites SOA, processos BPEL e pipeline do OSB.
  • Melhoramentos nos testes: o SOA Suite test framework foi aprimorado, onde as entradas e saídas podem ser geradas automaticamente ou carregadas de um arquivo, mensagens podem ser verificadas, serviços externos e falhas podem ser emuladas e os testes podem ser rodados diretamente do JDeveloper, mostrando relatórios detalhados de cada rodada de testes.
  • Novos adapters: novos adapters de aplicação e tecnologia estão disponíveis nesta nova versão. Eles são o Oracle Adapter for SAP R/3, Oracle Adapter for JD Edwards World, Coherence Adapter, Oracle Adapter for MSMQ, Oracle Adapter for LDAP e o melhorado UMS Adapter.
  • Novas funcionalidades nos adapters: foi ampliado o suporte ao SOA Suite, Service Bus e projetos BPM, ativação e desativação agendada, integração com o depurador, monitoramento e diagnóstico no Enterprise Manager Fusion Middleware Control (EM).
  • Tradução e transformação de dados: foi estendida a habilidade de tradução do native XSD (nXSD) para os processos BPEL, Service Bus e Mediador. Inclui também um novo editor para XQuery, fornecendo uma visão bidirecional para a construção de módulos e bibliotecas XQuery 1.0. Houve também aprimoramentos no XSLT Mapper, permitindo o uso do Design View para lógicas maiores e mais complexas, a introdução de duas novas visões (Map View e XSLT View), entre outros melhoramentos.

 Melhoramentos de gerenciamento

  • Gerenciamento dos projetos OSB: todas as operações e tarefas de gerenciamento do OSB foram movidas para o Enterprise Manager Fusion Middleware Control, porém as configurações dos serviços continuam disponíveis no Service Bus Console juntamente com o JDeveloper.
  • Melhoramentos no Enterprise Fusion Middleware Controlforam implementadas mudanças para melhorar a responsividade e simplificar a administração e o tratamento de problemas diários. Entre as mudanças estão o redesenho do dashboard SOA principal, o melhoramento das pesquisas, a prevenção ao carregamento inicial de dados excessivos e o melhoramento no rastreamento das instâncias (incluindo Service Bus, B2B e Managed File Transfer). Também foi criado o Error Hospital para agregar as instâncias que geraram falhas, baseado em vários critérios, permitindo assim realizar ações corretivas coletivamente.
  • Alertas de notificação de falhas: alertas de falha podem ser enviados aos administradores automaticamente, ou por agendamento, por vários canais de comunicação como e-mail e SMS.
  • Melhoramentos para desempenho: esta nova versão utiliza os gerenciadores de trabalho do servidor WebLogic. Isto simplifica a configuração e permite ao SOA efetivamente utilizar os recursos disponíveis. Esta versão também fornece perfis de banco de dados pré-ajustados para automaticamente habilitar características de desempenho apropriadas, baseadas no tamanho esperado dos dados.
  • Enterprise Scheduler Service: novo componente que permite agendar a execução de componentes SOA ou serviços. Também pode ser utilizado para ativar ou desativar adapters que estão realizando pooling em horários específicos.
  • Integração contínua: esta versão fornece um plugin Maven que permite os times de desenvolvimento criar, construir, empacotar e realizar deploy de projetos SOA. Através do Maven, um servidor de integração contínua pode ser utilizado para gerenciar os projetos SOA.

 Melhoramentos adicionais

  • Criptografia de informações pessoais: devido ao Enterprise Manager Fusion Middleware Control expor as mensagens aos administradores, foi adicionada a possibilidade de realizar a criptografia de campos específicos da mensagem.
  • Fault Policy Editor no BPEL: nesta versão as politicas de falhas podem ser configuradas utilizando a interface visual Fault Policy Editor.
  • SOA Design-Time Meta Data Services Repository: foi criado um repositório MDS baseado em arquivos para ser usado em tempo de desenvolvimento. Ele é automaticamente configurado quando a aplicação SOA é criada.
  • Aceleração da inicialização: novos perfis modulares permitem iniciar a plataforma SOA em subconjuntos de funcionalidades, reduzindo o tempo médio de inicialização da plataforma. Outra novidade quanto a isso é a possibilidade de realizar o carregamento dos composites apenas quando utilizados.
  • Re-sequencer no Service Bus: este recurso permite que o Service Bus ordene as mensagens baseado em uma informação sequencial ou cronológica.

 

Novidades no site da iProcess!

A iProcess gera, diariamente, inovação e melhores resultados a seus clientes e parceiros.

E também inova e se renova!

Convidamos você a visitar nosso novo site e conhecer alguns dos motivos que tornaram a iProcess uma referência em consultoria de BPM e SOA no Brasil!

Algumas das novidades:

  • Novos serviços nas áreas de BPM, SOA e Desenvolvimento de Software
  • Nova seção Portal de Conhecimento, uma área dedicada ao compartilhamento de apresentações, vídeos, artigos, relatórios e links para conhecimento nas áreas de BPM e SOA
  • Certificações recentemente conquistadas
  • Novos cursos da nossa unidade de treinamentos, a iProcess Education
  • Últimas notícias

E muito mais!

Acesse agora: www.iprocess.com.br

Particularidades na execução de projetos com integrações – Parte Final

Nos dois primeiros posts (disponíveis em 1 e 2), tratamos particularidades da gestão/execução e práticas metodológicas para bons resultados em projetos envolvendo integrações.

Para fechar esta série de artigos, hoje descreveremos alguns riscos importantes e fatores críticos de sucesso (FCS) nestes projetos, para que recebam a devida atenção e, se necessário, tratamento.

Em resumo, grande parte dos riscos e FCS se referem à comunicação e à integração das equipes do projeto, dado que muitas das informações e necessidades de trabalhos desta natureza envolvem algum tipo de compartilhamento.

Desta forma, listamos abaixo alguns itens que consideramos relevantes:

  • O primeiro ponto quem sabe até não seja o mais importante, mas certamente é um dos mais frequentes. Durante testes do sistema, quando ocorrem problemas, costumamos dizer: “até que se prove o contrário, a ‘culpa’ é da integração”. E pode-se dizer que até é um fato lógico. Quando uma das equipes realiza algum teste e não vê o resultado esperado acontecendo na outra “ponta”, naturalmente a primeira desconfiança é de algum defeito ou inconsistência na integração, que justamente faz a “ligação” entre os dois sistemas. Porém, esquece-se que a integração não é uma peça de software isolada, e sim um pequeno sistema formado pela origem, destino e o meio, que é a integração em si. E em qualquer um destes componentes pode ocorrer erro. Assim, é importante tanto alinhar as expectativas das equipes (inclusive para evitar desgastes) quanto definir um processo de teste e avaliação de problemas tecnicamente adequado para o cenário do projeto e dos sistemas envolvidos.
  • Boa parte das etapas de desenvolvimento e testes será realizado de maneira simbiótica por todas as equipes envolvidas (equipe do sistema que será integrado, de integrações e dos legados). Desta forma, uma prática bastante importante é a apresentação destas equipes, visando sua aproximação e integração. Com isto, espera-se que todos se conheçam, saibam os papéis de cada um e a quais responsabilidades respondem, quais os conhecimentos de cada integrante quando precisarem de apoio, etc. Além disso, a própria integração pessoal da equipe auxilia na pró-atividade e facilidade da comunicação.
  • Apesar da metodologia de desenvolvimento normalmente contemplar e se adequar a boa parte do escopo, como as integrações são o meio e dependem da forma como as “pontas” são desenvolvidas e entregues, é fundamental avaliar as eventuais modificações necessárias na metodologia, bem como apresentá-las às equipes. As responsabilidades também devem ficar muito claras. Além disso, é mandatório registrar estas mudanças em algum local, para consulta. Esta preocupação é essencialmente importante pois é muito comum (para não dizer que acontece sempre) que se confundam sobre o que cada equipe deve fazer e até onde sua autonomia vai. Isto pode gerar conflitos e desgastes desnecessários, perda de produtividade ou até problemas mais graves, que se refletem apenas quando o projeto já está em um estágio mais avançado.
  • É comum em um projeto com integrações existirem documentações compartilhadas, nas quais uma equipe preenche parte do documento, e outra(s) o completa(m). Assim, é importante esclarecer com todos quais tópicos cada um é responsável e definir uma política de armazenamento e versionamento adequadas.
  • A comunicação entre as equipes durante a análise e os testes é outro fator crítico. É fundamental definir um fluxo adequado e claro de comunicação entre os integrantes das equipes, de acordo com as responsabilidades no projeto. E, claro, esta definição depende de uma avaliação criteriosa dos estilos e da disposição física das equipes, do ambiente de trabalho e dos recursos de comunicação disponíveis.
  • Por fim, um ponto bastante simples, mas que pode facilitar muito a identificação de problemas. À medida que integrações forem codificadas e estejam razoavelmente estáveis, podem ser disponibilizadas para uso pelas demais equipes. Claro, dependendo do planejamento do projeto e da metodologia utilizada, elas nem serão acionadas antes dos testes integrados. Mas, caso as equipes das “pontas” já estejam prontas para realizar testes com o uso das integrações, isto pode antecipar alertas relevantes sobre inconsistências e defeitos.

Com este artigo, fechamos esta série dedicada especialmente a dicas, boas práticas e cuidados com projetos envolvendo integrações, que possuem particularidades que os tornam especialmente desafiadores.

Fiquem à vontade para opinar e sugerir outras práticas interessantes.

Esperamos que tenham gostado!

Nos falamos em futuros artigos. Até lá!

Particularidades na execução de projetos com integrações – Parte 2

No primeiro post (disponível aqui), iniciamos uma avaliação de particularidades da gestão e execução de projetos envolvendo integrações, com foco nas dependências técnicas e gerenciais.

Hoje, a ideia é “conversarmos” sobre algumas práticas metodológicas importantes para minimizar riscos e conduzir o trabalho de maneira organizada.

Apesar de podermos citar um grande número de práticas, algumas são especialmente relevantes para o sucesso deste tipo de projeto, a saber:

  • Definição de uma arquitetura do projeto. O básico do básico, mas por vezes esquecido. É fundamental definir uma arquitetura de comunicação, tecnologias a serem utilizadas e padrões de implementação no projeto, especialmente para as integrações. Outro ponto muitas vezes negligenciado – não adianta ter, tem que comunicar. Se for necessário, imprima a arquitetura e cole no monitor dos integrantes da equipe. Cada um precisa ter a arquitetura na cabeça, sem exceções. Criar uma página tipo wiki também pode ser simples e eficiente.
  • Implementação de mocks na etapa inicial de desenvolvimento ou arquitetura. Como citado no primeiro post, a definição e construção de mocks é uma prática que facilita a formalização da comunicação entre os componentes do sistema (principalmente quando estes estão divididos entre vários fornecedores) e auxilia o paralelismo de atividades. Uma outra avaliação é bastante importante – o comportamento interno do mock. Se por um lado um artefato que simplesmente devolve “vazio” é fácil e rápido de implementar, por outro ele não auxilia os testes unitários, por exemplo. Se implementarmos algumas regras, os testes unitários podem ser mais efetivos, mas é um trabalho que posteriormente será descartado. Assim, é fundamental avaliar qual a complexidade e conteúdo dos mocks a ser desenvolvido para cada caso e requisitos do projeto.
  • Testes unitários com componentes já desenvolvidos. Conforme o segundo item, a validação das regras de negócio das integrações não depende apenas das interfaces (assinaturas, contratos, etc) dos componentes chamados por estas, e sim principalmente de sua implementação interna. Desta forma, assim que possível é importante a substituição dos mocks pelos componentes definitivos, o que já ajuda, e muito, na avaliação de eventuais problemas de integração dos dados e até de análise. Porém, um alerta. Caso os componentes ainda estejam em uma fase incipiente de desenvolvimento, podem conter bugs que mais prejudicarão do que ajudarão durante a implementação das integrações. Assim, é necessário avaliar a qualidade dos componentes das “pontas” quando estes forem usados.
    • Revisão periódica de serviços ou componentes que vão ficando prontos. Item relacionado ao tópico anterior. Defina um meio de acompanhar e comunicar quais componentes das “pontas” da integração (serviços que serão chamados, por exemplo) estão prontos e disponíveis para uso no decorrer do projeto. É bastante comum esquecermos disto por vários dias e perdermos a oportunidade de aproveitar os ganhos do tópico acima.
  • Teste de arquitetura com “integração piloto”. Uma prática que resolve várias dores de cabeça e antecipa problemas do desenvolvimento é validar a arquitetura definida para o desenvolvimento das integrações com a implementação de uma “integração piloto”. Aproveite este momento para questionar e validar as diretrizes arquiteturais para o restante do projeto. Claro, nem sempre isto é simples, visto que muitos projetos incluem integrações com “n” formas de implementação e utilização de recursos. Mas, na medida do possível, é uma prática muito vantajosa.
  • Mapa de dependências entre componentes. Prática simples e muito útil. Organize um mapa com todos os componentes do projeto e quem depende de quem. Não use textos – faça o mapa de forma gráfica. Aí temos uma vasta gama de ferramentas que podem ser usadas – aplicativos de mind mapping, de desenho, de modelagem, etc. E use a criatividade. Pinte componentes de cada tecnologia com uma cor diferente, separe-os por equipe responsável, por desenvolvedor, e assim por diante.
  • Repositório único de contratos. É realmente muito importante definir um repositório que armazene a versão oficial de contratos de serviços e demais componentes que são dependência para outros no projeto. Assim, todas as equipes sabem onde consultar a versão a ser utilizada, evitando ruídos de comunicação. Claro, se alguma alteração é feita, deve ser comunicada a todos – e isto deve estar contemplado no Plano de Comunicação do projeto. Este repositório deve estar sempre atualizado.
  • Organizar a análise e desenvolvimento das integrações por assunto. É bastante comum em projetos envolvendo integrações que estas estejam separadas por assuntos de negócio tratados pelo sistema. Por exemplo: ao desenvolver integrações de um ERP com sistemas legados, organizar os profissionais que vão analisar e implementar as integrações por cada módulo do ERP. Nem sempre isto é possível – alguns processos são transversais e passam por vários módulos – mas claramente auxilia o entendimento das integrações pelo conhecimento de negócio que cada profissional adquire. Claro, isto incide em alguns riscos bastante relevantes. Se um profissional, seja analista ou desenvolvedor, sai da equipe, um grande conhecimento pode ir com ele. Uma forma de contornar isto é envolver o líder técnico e um analista líder em pontos-chave da análise e desenvolvimento de todas as integrações, a fim de que possa responder pelo conhecimento destas.
  • Definição de cenários de testes entre as equipes. Um ponto chave do projeto, difícil de gerenciar e que frequentemente enfrenta grandes problemas, é o teste integrado do sistema, principalmente quando existem diferentes equipes envolvidas. Uma sugestão muito interessante é a reunião dos responsáveis das equipes para elaboração de cenários de teste integrados. Veja, a ideia não é detalhar cada cenário neste momento, e sim definir quais são os cenários a serem executados para validar a integração dos sistemas de ponta a ponta. Após, cada equipe detalha seus cenários individualmente, que são validados ao final, novamente entre todos.

No próximo post, que encerra esta série, trataremos de riscos e pontos de atenção em projetos com integrações, visando auxiliar principalmente seu planejamento e gestão. Até lá!

Desafios intangíveis da implantação SOA – compartilhando experiências

Apesar da Arquitetura Orientada a Serviços não ser novidade, com inúmeros livros, artigos e materiais publicados sobre o tema, verificamos no decorrer da experiência em projetos que existe ainda uma grande discrepância na compreensão do conceito que existe por trás dessa sigla. Com frequência vemos “SOA” sendo usado para descrever uma camada com serviços de integração, muitas vezes ponto a ponto, desconsiderando totalmente a riqueza de critérios relacionados ao conceito.

Essa distância entre proposição e aplicação não é exclusividade de SOA. No desenvolvimento ágil de software, por exemplo, muitos projetistas e empresas afirmam usar SCRUM, enquanto possuem somente um grande backlog de tarefas e um quadro kamban com a lista de TO DO, DOING, DONE. Muitas vezes utilizam-se desse artifício para justificar uma documentação precária. Mas isso é um outro assunto. :)

Em projetos de integração, quando é necessária uma camada – obviamente – de integração, comumente usa-se o termo camada SOA para defini-la. Mas sem um alinhamento arquitetural apropriado, esta camada acaba se restringindo simplesmente a um aplicativo cuja função é fazer com que dois ou mais sistemas possam trocar informações entre si. Isso por si só não caracteriza SOA e não gera nenhum benefício e nem ganho tangível para a organização. Esta distorção do conceito pode causar uma grande antipatia por parte de clientes e usuários. Assim, em algumas situações, chega-se ao ponto que, basta ouvir falar em ‘SOA’, que a rejeição é certa!

Com o tempo começamos a observar que esse é, talvez, um dos maiores limitadores para que a arquitetura orientada a serviços ganhe espaço hoje nas organizações. Sem conhecer com um pouco mais de profundidade o conceito é praticamente impossível que haja aceite da utilização desse tipo de arquitetura por parte do financiador do projetos. É difícil justificar SOA do ponto de vista tempo, custo e escopo. Pensar em criar serviços que serão reutilizáveis e outros artifícios como governança nem sempre são reconhecidos quando falamos de um cenário de TI que, atualmente, trabalha sempre com curtos prazos e projetos que já começam atrasados.

Se você também se depara com essas situações no seu dia-a-dia, queremos saber o que você faz para lidar com elas. De qualquer maneira, aproveitamos pra compartilhar algumas lições aprendidas nossas:

  1. Procure compreender o conceito de SOA. Aqui no nosso blog temos alguns artigos sobre o tema (veja esse, por exemplo). Se preferir um livro, sugerimos a literatura de Thomas Erl, especialmente dois: “SOA: Concepts, Tecnology and Design” e “SOA: Principles of Service Design“.
  2. Deixe claro o que é e o que não é SOA. Quando o seu cliente chamar a camada de integração (por exemplo, ponto a ponto) de “SOA”, esclareça que isso não é uma arquitetura orientada a serviços. Se precisar justificar, lembre-se que:
  • SOA não é
  • uma tecnologia
  • uma metodologia
  • algo que se compra e que se instala
  • um webservice
  • SOA é:
  • uma filosofia arquitetural
  • baseada no conceito do uso de serviços atômicos, independentes e com baixo acoplamento

Falando de SOA, precisamos falar também de serviços. Segundo Erl, existem oito requisitos que definem uma boa implementação de serviços para que a implantação de SOA seja satisfatória. São eles:

  • Contrato de Serviço Padronizado: serviços dentro do mesmo inventário de serviços estão em conformidade com os mesmos padrões de design de contrato.
  • Serviço com Fraco Acoplamento: os contratos de serviços exigem e impõem baixo acoplamento e estão dissociados de seu ambiente e escopo.
  • Abstração de Serviço: contratos de serviços contém apenas informações essenciais. Informações sobre os serviços são limitas ao que é publicado em contratos de serviços.
  • Reutilização de Serviço: serviços contém e expressam uma lógica agnóstica e podem ser posicionados como recursos corporativos reutilizáveis.
  • Autonomia de Serviço: serviços exercem um alto nível de controle sobre o ambiente de execução.
  • Serviço statelessness: serviços minimizam o consumo de recursos, adiando a gestão da informação do estado, quando necessário.
  • Descoberta de serviço: serviços são complementados com meta dados comunicativos, onde cada um deles pode ser efetivo.
  • Modularidade de Serviço: serviços são participantes efetivos em composições (composites), independentemente do tamanho e da complexidade da composição.

Estas são algumas informações que podem ser úteis para você que também acredita nos valores de SOA.

E nós aguardamos suas experiências. :)