Uma análise do ciclo de desenvolvimento de integrações entre sistemas de informações  Heterogêneos

 

 

 

 

Artigo apresentado no XII SIMPÓSIO MULTIDISCIPLINAR DA USJT
"Conhecimento e Inovação: 100 anos do vôo do 14 Bis"

VIII Mostra de Iniciação Científica
VI Encontro de Pós-Graduação Lato Sensu
(22 a 29/09/2006)

 

 

Valmir Antonio de Almeida

Administrador de Empresas pela UMC,

Pós  Graduado em Administração de Produção pela USJT,

Pós Graduado em Master Integration System  pela USJT

e-mail: valmir_almeida@hotmail.com

 

Alexadre da Cunha (orientador)

Professor da Universidade São Judas Tadeu.


 

Uma análise do ciclo de desenvolvimento de integrações entre sistemas de informações  Heterogêneos

 

 

 

 

Artigo apresentado no XII SIMPÓSIO MULTIDISCIPLINAR DA USJT
"Conhecimento e Inovação: 100 anos do vôo do 14 Bis"

VIII Mostra de Iniciação Científica
VI Encontro de Pós-Graduação Lato Sensu
(22 a 29/09/2006)

 

 

Valmir Antonio de Almeida

Administrador de Empresas pela UMC,

Pós  Graduado em Administração de Produção pela USJT,

Pós Graduado em Master Integration System  pela USJT

e-mail: valmir_almeida@hotmail.com

 

Alexandre da Cunha (orientador)

Professor da Universidade São Judas Tadeu.

 

 

Resumo: O Artigo apresentado descreve os principais métodos de integrações de sistemas de informações Heterogêneos dentro das organizações,  com especial ênfase a técnica EAI (enterprise application integration ) e Arquitetura orientadas a Serviços (SOA). São analisados possíveis métodos de execução e controle das atividades de desenvolvimento de interfaces.

 

 

Abstract: The presented Article describes the main methods of integrations of Heterogeneous Information systems inside of the organizations, with special emphasis on EAI techniques (enterprise application integration) and Service Oriented Architecture (SOA). Possible execution methods and control of the activities of development of these interfaces are analyzed.

 

 

Palavras Chaves:  Processos Organizacionais, Integração de sistemas, controle e desenvolvimento de interfaces entre sistemas, Arquitetura orientada a Serviços, Integração de aplicativos empresariais, Enterprise Service Bus.

.

 

Key words: Organizational Processes, Integration of systems, control and development of interfaces among systems, Service-Oriented Architecture, enterprise application integration, Enterprise Service Bus

 

 


 

 

 

1)  Introdução e Justificativas.

 

Entendemos  uma organização como um sistema complexo de processos, serviços  e transações de negócios sendo que estes processos são suportados e integrados tanto através de métodos de trabalho como também pelo uso de soluções de TI (Tecnologia da Informação) conforme ilustramos na Figura 1.

 

*********************************************************

 

Figura 1

*********************************************************

 

 

 

Figura 1 – Processos suportados por aplicativos e interfaces.

 

Alguns dos métodos mais freqüentes de integração de processos encontram-se no uso de Sistemas de Bases de dados centralizados - SGDB  e o uso de softwares  de gestão integrada ERP - Enterprise Resource Planning.

O uso desta Arquitetura vem sendo considerado como fator de redução no esforço da administração das complexidades e homogeneização dos sistemas dentro das organizações.

Mas, percebemos que mesmo com os ganhos perceptíveis da integração  de processos advindos do uso de soluções  ERP,  algumas atividades ou mesmo processos inteiros   não são adequadamente atendidas pelos softwares de gestão integrada (Almeida, 1999).

Persistem ilhas de automatização ou a necessidade de soluções verticais, que  visam automatizar processos particulares dentro da organização.

Na Tabela 1, exemplificamos  alguns Casos de processos de negocio  geralmente não cobertos por recursos nativos dos  Softwares de Gestão empresarial, tratando-se uma solução chamada de “vertical”:

 

Tabela 1 – Soluções típicas de TI em função dos processos e seguimentos de indústria.

 

Processo de Negocio

Indústria/seguimento

Solução Típica de TI / Vertical

Controle de processos contínuos de fabricação

Química / Petroquímica

Sistemas de monitoramento e supervisão  de processos, (SCADA), CLP

Simulação de cortes de bobinas metálicas

Metal – Mecânica

Simuladores e otimizadores de cortes de bobinas

Vendas “home-to-home”

Geral

Automação de forças de vendas + PDA

Sistemas de Controle de ponto e registros de consumo de refeições

Recursos Humanos

Sistema de Acesso eletrônico (integradas a softwares de gestão de controle de pontos)

 

 

Podemos acrescentar  além as soluções especialistas os seguintes outros motivos da desintegração dos processos e tecnologias:

 

  • Evolução Tecnológica constante, como por exemplo, sistemas legados processados em mainframe com front-end em web.
  • Heterogeneidade de fornecimento de soluções de TI, por exemplo, Uso ferramentas  analíticas (B.I. e CRM) não fornecidas pelo fornecedor do software de gestão integrada.
  • A própria dinâmica e estrutura das organizações, e neste caso podemos ter diferentes soluções adotadas entre a matriz e suas filiais,  decorrentes de processos de aquisição / fusão de empresas.
  • Criação de novos serviços e processos dentro da organização.

 

Tais fatores levam a organização a manter em sua carteira de  soluções de TI varias tecnologias e sistemas oriundos  de fornecedores diferentes, padrões abertos ou  proprietários, e isso por sua vez levam estas mesmas organizações a investirem em soluções de  integração destas Tecnologias.

 

2) Descrição do problema:

 

Como podemos entender o processo de integração entre as mais diversas soluções tecnológicas e principalmente como gerenciar tais atividades com alguma metodologia e eficiência?

Diariamente o profissional de Tecnologia da informação depara-se  com inovações técnicas aos quais necessita familiarizar-se, mas que ao mesmo tempo não possuem uma metodologia solidificada para sua aplicação.

Neste estudo temos como objetivo a analise básica dos possíveis métodos de integração entre sistemas de informação com tecnologias e fornecedores diferentes, aos quais chamamos de sistemas heterogêneos.

O nosso principal foco é o  entendimento  um   ciclo viável  de atividades de desenvolvimento de interfaces, bem como de suas entregas esperadas e  resultados finais.

Consideramos este texto oportuno para gestores e coordenadores deste tipo de projeto que pretendem entender os passos necessários para a sua execução e que  também visam o controle destas atividades com algum grau de formalização e metodologia.

Não fazem parte do escopo do problema:

 

§         Analises e comparações  técnica  das soluções e padrões tecnológicos empregados nas integrações, sendo que neste caso recomendamos alguns dos autores citados na Bibliografia, em especial Rowell, 2000; Carlson, 2001; Linthicum, 2001 e Sítios como www.integrationconsortium.org, http://www.eaiiournal.com,

§         Analise da viabilidade financeira e técnica da adoção desta tecnologia nas organizações.

§         Indicar e recomendar  de metodologias  especificas de  engenharia de software aplicadas ao assunto,  bem como de  modelagem e documentação de processos, por exemplo, UML e outras metodologias.

 


 

3) Métodos de integração de sistemas Heterogêneos:

 

Sendo detectada tanto a existência como a continuidade de soluções heterogêneas de sistemas  e tecnologias de TI dentro das organizações, geralmente são adotadas as seguintes técnicas  de integração:

 

·                            Método (i) : Integração Ponto a Ponto (File Transfer). 

 

Este método implica  no desenvolvimento de rotinas batch de troca de arquivos geralmente no formato TXT ou CSV (flat flies)  entre os sistemas de origem e destino.

Nesta técnica geralmente são considerados os seguintes aspectos:

  • A necessidade da integração e periodicidades das mesmas.
  • Os sistemas e bases de dados envolvidas na integração.
  • Os layouts,  formatos de arquivos  e  métodos de saída  dos dados  no sistema de origem.
  • Os layouts,  formatos de arquivos   e  métodos de entrada  dos dados  no sistema de destino.
  • Tratamento  exceções e erros (arquivos com Logs de exportação e importação).

 

Este método historicamente é o mais utilizado para integração entre aplicativos, pois foi a única alternativa disponível de integrações.

Segundo  Cummins (Cummins 2002, pág. 2) historicamente para os sistemas legados:  “Foram Forjados caminhos para a conexão entre sistemas entre si de modo a evitar intervenção manual e para melhorar o tempo de repostas”.

Este tipo de integração demanda um esforço técnico mediano  no desenvolvimento, conforme ilustrado na figura 2.

 

*********************************************************

 

Figura 2

*********************************************************

 

 

Figura 2 – Integração ponto a ponto entre sistemas.

 

Na Tabela 2  resumimos  algumas vantagens e riscos nesta modalidade de integração.

 

 

 

 

 

Tabela 2 – Vantagens e riscos no desenvolvimento de integração ponto a ponto entre sistemas.

 

Vantagens percebidas.

Riscos percebidos.

Método testado e consolidado

Falhas na sincronização nas transações de envio / recepção

Relativa simplicidade no desenvolvimento

Quebras de segurança (na transação e nos registros)

 

Ocorrências de atraso em função do processamento tipicamente batch.

 

Esforço adicional de inclusão de novas integrações.

 

Tendência a desatualização em função de alterações tecnológicas e nos processos de negocio.

 

 

·                            Método (ii): Integrações via Banco de Dados (Shared Database). 

 

Uma evolução natural do processo de integração, são as integrações entre aplicativos através de  sistemas de bases de dados, quer através do compartilhamento de bases de dados ou  através da tecnologia ODBC, neste caso é possível a importação, exportação ou vinculação dos dados entre diferentes bancos de dados  mediante o uso de Drivers padrões ODBC.  

 

 

*********************************************************

 

Figura 3

*********************************************************

 

 

 

Outras técnicas de integração  como CORBA e utilização de programas de interfaces padronizados como API e middleware também  propiciam integrações entre sistemas empresariais, estaremos analisando este método a partir do próximo tópico .

 

·                            Método (iii): Integrações Multipontos  via Middleware (Messaging e remote procedure invocation).

 

 

Mas como fica evidenciado, o principal foco desta modalidade concentra-se na integração de sistemas, o que muitas vezes não implica na integração e otimização de  processos de negócios.

 

Hoje o grande alvo é a integração de processos, fazendo emergir novas tendências como o uso  da arquitetura orientada a serviços – SOA (acrônimo de Service-Oriented Architecture).

Esta e outras tendências procuram levar o processo de integração entre sistema para além dos aspectos puramente computacionais.

Neste caso a integração dos sistemas é realizada através  uma de infra-estrutura de comunicação do tipo de middleware, sendo que neste texto descrevemos a integração através da tecnologia  EAI /ESB ( acrônimo de  enterprise application integration e Enterprise Service Bus)  bem como de um entendimento profundo dos processos a serem integrados.

Consideramos neste estudo que  tecnologia EAI /ESB,  esta inserida dentro de uma arquitetura computacional orientada a serviço (SOA).

Resumidamente a  arquitetura SOA  visa obter o entendimento de uma corporação e seus relacionamentos internos ou externos como sendo uma coleção de serviços, estes serviços ficarão disponíveis para uso de toda a companhia e devem permitir futuras alterações seja por crescimento ou descontinuidade dos mesmos, por exemplo,  um Sistema CRM pode ser “seguimentado” em um grande número de serviços auto -contidos que executam funções de negócio específicas.

Deste modo a arquitetura SOA deve permitir que serviços sejam construídos, e principalmente integrados, com independência  dos aplicativos e plataformas computacionais disponíveis.


A arquitetura SOA apresenta as seguintes características relevantes ao processo de integração de sistemas heterogêneos:  Invocação através de interfaces, endereçamento de mensagens, interoperabilidade entre plataformas, mobilidade dos códigos processados, especialização de papeis e serviços, testabilidade, Segurança, Manutenibilidade, Reusabilidade, Paralelismo de desenvolvimento, Escalabilidade e Disponibilidade.

 

A tecnologia de EAI / ESB  insere-se na arquitetura SOA juntamente com outros padrões tecnológicos existentes tais como o uso de   XML & DTDs,  ODBC, CORBA, EJB, Java, J2EE, HTTP, HTML, DCOM & COM, SSL, API ‘s, etc.

 

Uma forma de utilização possível da tecnologia EAI, num primeiro momento, é permitir a integração de várias aplicações internas, podendo evoluir para integrações b2b (business to business) ou b2c (business to customer).

Mas seus ganhos efetivos são mais evidentes quando tais integrações possibilitam ganhos de eficiência  e otimizações dentro dos processos de negócios e serviços prestados pelas organizações,  o que pode proporcionar uma gama de diferenciais competitivos dificilmente imitados dentro da indústria onde o negocio esta inserido.

Na figura 3 apresentamos um modelo esquemático da comunicação multiponto através de Middleware, para simplificações apresentamos somente dois sistemas, mas na pratica poderão ser integrados n-sistemas.

 

 

*********************************************************

 

Figura 3

*********************************************************

Figura 3 – Dinâmica da integração multiponto entre sistemas via Middleware.

 

Segundo consultas efetuadas nos sítios apresentados na Bibliografia,  temos  quatro grandes categorias de integrações através de tecnologia EAI/ESB:

§         Database linking: Compartilhamento e duplicação de registros entre duas ou mais bases de dados.

§         Application linking: Quando duas ou mais aplicações compartilham e possibilitam interface entre  processos de negócios (conforme os exemplos da tabela I)

§         Data warehousing: Quando dados operacionais são extraídos de inúmeros bancos de origem, tratados e gravados em bases de dados especificas para analises multidimensionais (OLAP) , sendo nestes casos utilizada como uma forma de ETL (extraction Transform and Load) conforme Inmon (Inmon 2001).

§         Common virtual system: Quando todas as integrações da empresa são obtidas através da solução EAI (coletores, PDA s, ERP, OLAP - DW, Web) de modo transparente ao usuário final.

Muitos  os fornecedores da Tecnologia EAI  segundo nossa pesquisa alegam estar em conformidade com a tecnologia SOA no atendimento dos seguintes requisitos:

  • Assegurar conversões semânticas dos dados, mantendo a sua integridade, por exemplo, regras de “de-paras” transformação de registros de numérico no sistema de origem para  texto no sistema de destino.
  • Controlar os  fluxos de dados entre os aplicativos e endereçar de mensagens.
  • Facilitar alterações da arquitetura de integração entre os sistemas conforme a necessidade assim o exigir, como por exemplo, inclusão / exclusão dos aplicativos e serviços.
  • Minimizar riscos de quebras de segurança através de recursos como Criptografia e autenticação de chaves de segurança.

 

A Esquematicamente a tecnologia baseada em concentradores de mensagens (ex.: EAI) ou baseada em barramento de serviços (ESB)  é muitas vezes representada  por um núcleo  que concentra e trata as interfaces entre os sistemas organizacionais de maneira Multipontos conforme ilustrado na figura 4.


 

*********************************************************

 

Figura 4

*********************************************************

 

 

 

 

Figura 4 – Simbologia Genérica da Arquitetura de integração entre sistemas.

 

Os métodos  de integração, quer sejam através de interfaces Ponto a Ponto,  ou  Integrações Multipontos  via Middleware podem ser objetos da aplicação de técnicas de analise e especificação de software compreendendo atividades de definição de requisitos,  projeto, construção, testes, manutenção e configuração.

 

 

 

 

 

4. O Ciclo de desenvolvimento das interfaces entre sistemas heterogêneos.

 

Neste subtítulo apresentamos nossa contribuição ao problema proposto.

Em inúmeros projetos de desenvolvimento que requeriam  integrações entre sistema notamos um numero reduzido de textos voltados especificamente ao processo de gerenciamento do desenvolvimento de interfaces de sistemas.

Por observação e adaptação dos textos  disponíveis, sendo estes voltados primariamente ao processo de engenharia de software,  podemos identificar as seguintes etapas  relativas ao desenvolvimento, implantação e uso de interfaces entre sistemas:

 

(a) Diagnostico e geração do mapa de processos de negócios.

(b) Definição de regras de negocio e método de suporte dos recursos de TI ao processo.

(c) Identificação dos sistemas que suportam os processos de negócios Atuais e suas interfaces.

(d) Reuniões de especificação conceitual das interfaces.

(e) Modelagem Técnica da interface.

(f) Desenvolvimento técnico da solução.

(g) Testes unitários.

(h) Testes integrados.

(i) Homologação.

(j) Produção.

(k) Manutenção.

(l) Encerramento dos serviços.

 

Reconhecemos que na pratica, os níveis de esforço no gerenciamento formal de projetos e maturidade  no desenvolvimento de softwares variam entre as  organizações.

Nosso modelo considera tanto a existência de ações  e conhecimentos voltados ao gerenciamento de projetos e bem como a necessidade do estabelecimento de níveis de  Maturidade da organização em desenvolver suas soluções tecnológicas.

Estas etapas  podem ser aplicadas a partir do nível 2 de maturidade no desenvolvimento de Software conforme  indicado no modelo SW-CMM (vide CMMI product Team, 2002 e  Paula, 2003).

Na tabela 3  indicamos que o ciclo de desenvolvimento de interfaces pode e deve estar relacionado grau de maturidade da organização no desenvolvimento de software bem como utilizar as áreas de conhecimento em gerenciamento de projetos.

Mediante uma analise desta tabela,  podemos verificar que  as ações de  desenvolvimento de interfaces ou de qualquer software podem ser objetos de ações de gerenciamento de projetos, sendo que este gerenciamento deve ser baseado em praticas comumente aceitas.

Mas o ciclo de vida de um sistema de interface vai alem das  fases de projetos e requerem ações  gerenciamento operacional, e este gerenciamento deve ser também objeto de ações baseadas em métodos.

Neste estudo, as  etapas  que fazem parte do ciclo de desenvolvimento de interfaces encontram-se  estão além das atividades de: (1) analise de viabilidade financeira, (2) contratação aquisição e instalação da infra-estrutura computacional (servidores, redes, links etc.), (3)  e outras ações  que antecipam  o inicio efetivo do projeto, como por exemplo, seleção de equipe, treinamento, plano de comunicação  entre outros.

Nosso modelo é  apresentado como uma seqüência de etapas, mas tal apresentação  não implica que necessariamente seu desenvolvimento deva ocorrer de forma seqüencial. Segundo Maffeo (Maffeo,  1992) um software, incluindo sistemas de interfaces,  pode ser desenvolvido  mediante o processo de seguimentação  em Macro Fases, ou mediante o desenvolvimento e  liberação de protótipos de forma incremental, onde versões são liberadas para testes e uso ou ainda, com uso de assistentes automáticos.

Considerando os diversos modelos de desenvolvimento de software apresentado por este e outros autores  (Presmman, 1995) acreditamos que o ciclo apresentado deva ser adaptado conforme a metodologia de desenvolvimento adotada pela organização que estará desenvolvendo soluções de integração  entre sistemas.

 

Tabela 3 – Desenvolvimento de interfaces – Áreas chaves CMMI no nível II e áreas de conhecimento em gerenciamento de projetos (fonte: Paula, 2003 e Project Manangent Institute, 2004).

 

 

*********************************************************

 

Figura 5

*********************************************************

 

Analisaremos estas etapas e os produtos finais esperados (Deliverables)  para cada uma delas.

 

(a) Diagnostico e geração do mapa de processos de negócios

Nesta etapa, espera-se que os participantes do projeto estabeleçam e documentem os padrões de funcionamento dos processos de negócios , pois são estes processos  que efetivamente estabelecerão a real necessidade da interface entre os sistemas.

Deliverables: Estabelecimento e descrição dos processos atuais de negócios que deverão sofrer informatização e integração.

 

(b) Definição de regras de negócio e requisitos das integrações.

Nesta etapa, os  envolvidos diretamente no projeto, tanto o setor de TI como os usuários, estabelecerão os requisitos de funcionamento das interfaces. Devem ser obtidas definições dos requisitos, e nesta mesma fase podem ocorrer solicitações de alterações de processos, adequação do grau de cobertura dos aplicativos sobre os processos inclusive estudos de customização, implantação, re-implantação etc.

Deste trabalho surgirão novos padrões de operações dentro da organização e responsabilidades pela manutenção e confiabilidade dos dados. Estes novos métodos de trabalho serão  fundamentais para todo o   estudo de integração,   devendo obter aprovação da organização usuária.

Deliverables: Diagramas dos processos com o novo modelo de negocio, requisitos formais, parâmetros de testes da(s) interface(s), também nesta fase recomenda-se estabelecer os requisitos de níveis de qualidade no software a ser desenvolvido e nos níveis de atendimento dos serviços esperados para as integrações.

 

 

 

 

 

 

 

 (c) Identificação dos sistemas que suportam os processos de negócios Atuais e suas interfaces.

Estando claramente definidos os processos de negócios e requisitos funcionais,  cabe ao setor de tecnologia da informação, com o apoio dos usuários finais, devem-se estabelecer quais os sistemas atuam (ou atuarão) nos processos de negocio.

Esta etapa tem como objetivo fundamental o  desenvolvimento de um inventario das interfaces  que executarão os intercâmbios de dados entre os sistemas envolvidos na solução.

 

Deliverables:  Inventario dos sistemas participantes na solução e inventario  das  Interfaces detectadas entre os mesmos  e grau de complexidade percebida na integração entre os sistemas.  

Com estes inventários são possíveis estabelecer estimativas de esforços, tempos, custos e recursos de especificação e desenvolvimento das mesmas, em função do grau de complexidade preliminarmente percebida,  bem como estimativas de trafego  entre sistemas.

 

Os itens (a), (b) e (c) podem ser agrupados como fazendo parte do conjunto de  tarefas de analise e   entendimento dos processos e devem fazer parte do catalogo de serviços, conforme recomendado para a arquitetura SOA.

 Técnicas como que vão desde a elaboração de fluxograma de atividades até o desenvolvimento de modelagem  de processos como BPM (Business Process Management) podem servir de suporte metodológico.

Citando Cummins (Cummins, 2002, pág. 56):

“Esses processos podem determinar a ordem em que ocorrem as atividades, a participação dos usuários e as ações que devem ser tomadas para resolver exceções”.

 

 

(d) Reuniões de especificação conceitual das interfaces

Após Estabelecimento formal  quanto aos processos e sistemas a serem integrados entendemos que estamos aptos a dar inicio os trabalhos de especificações de Interfaces.

Nossa proposta é que nesta etapa possam participar os fornecedores dos sistemas com domínio da sua solução,  analistas de negócios, Administradores de base de dados  e analistas programadores voltados diretamente ao processo de desenvolvimento de API s.

Nesta etapa deve-se manter forte controle dos documentos e versões produzidas, e para obtenção deste controle e produtividade no processo, sendo recomendado o uso de ferramentas e métodos automatizados de documentação e workflow de documentos.

Espera-se nestas reuniões a analise e detalhamento dos seguintes pontos conforme a tabela 4

Nesta tabela  apresentamos alguns atributos que julgamos úteis no processo de desenvolvimento de interfaces entre sistemas computacionais.

Reconhecemos que  a UML  (Unified Modeling Language)  pode servir como apoio metodológico na elaboração de documentos que descrevam a seqüência de eventos de atores que utilizam  um ou mais sistema completar um processo. Através da elaboração de “Casos de Uso” (user case) e pode-se estabelecer uma padronização de especificação de atributos, operações e  restrições do modelo que esta sendo especificado.

Em especial o desenvolvimento de Casos de Uso é o documento que  deve “descrever os cenários pretendidos para um sistema, com  o objetivo de atender  as necessidades do usuário” segundo Silva (Silva 2001).

Deliverables: Especificação formal dos requisitos funcionais esperados para as interfaces, e no quando utilizado os padrões UML, a elaboração de “usos de caso” para as integrações.

 

 

 

 

Tabela 4 – Atributos a serem especificados no processo de interfaces

 

I

- Nome dos processos e eventos de envolvidos

II

- Sistemas / aplicações que necessitam ter intercambio de dados

III

- Informações de origem(ns) e destino(s) dos dados que vão transitar na integração.

IV

-  Justificativa formal e aceita da necessidade da integração

V

- Forma da integração (automática ou manual).

VI

- Periodicidade das integrações (batch, on-line, etc.).

VII

- Necessidades de desenvolvimento de APIs e UPC’s

VIII

-Erros possíveis e formas de tratamentos.

IX

- Formas de postagem e roteamento de mensagens de Erro.

X

- Regras de transformação de dados ( Por exemplo: o código do fornecedor no sistema A é Char(12)    e no sistema B  é int(7), visando não haver divergências, deve-se assumir o menor campo ou aplicar uma regra  de transformação que transforme  os 12 caracteres em 7  dígitos numéricos).

XI

- Atributos dos dados / campos a serem tratados (utilizando o jargão do desenvolvimento orientado a objetos: Classes,  Objetos, atributos e métodos dos objetos).

XII

- Campos  e registros obrigatórios.

XIII

- Níveis de segurança esperado para a integração (criptografia, chaves de acesso etc.).

XIV

- Procedimentos  a serem executados pelos usuários  para as transações envolvidas (conferências,  intervenções quando detectado erros ou  mensagens de exceção).

XV

- Outros pontos relevantes na analise (Ex.: Regras de consistências entre o conteúdo de saída no sistema A e o conteúdo de entrada no Sistema B).

Pontos de atenção:

  • Quaisquer alterações  nos processos ou nas funcionalidades dos sistemas podem alterar as especificações definidas nesta fase, daí a importância  de escopos bem definidos, consolidados.
  • Deve-se esperar também, que destas reuniões, serão identificadas algumas demandas de padronização, por exemplo, definir que o código de produtos  deve ter sempre 7 posições sem espaços ou pontos em todos os sistemas da empresa.  Inmon (Inmon 1997, págs. 34-35) exemplifica este tópico em um processo de integração entre sistemas legados e um sistema Datawarehouse nos seguintes termos:  “Caso os dados de uma aplicação estejam codificados  como X/Y, eles serão convertidos à medida que forem transferidos  para o Warehouse. As considerações  sobre consistência são validas para todas as questões  de projeto de aplicações, como as convenções  de atribuição de nomes, estruturas de chaves, unidades de medidas de atributos e características físicas dos dados.”
  • Com base nas analise será possível a identificação de predecessões de desenvolvimento e a viabilidades de execução de desenvolvimento em paralelo. Na figura 5  exemplificados as possibilidades de distribuição de atividades.

 

*********************************************************

 

Figura 6

*********************************************************

 

 

 

Figura 5 – Exemplo de distribuição de atividades de desenvolvimento de Interfaces.

 

  • Nesta etapa recomenda-se um refinamento do modelo de trafego (em Kb/ numero de transações), níveis de serviço  aceitável  para a integração, por exemplo: disponibilidade de 99,88% etc.

 

 

(e) Modelagem (desenho) Técnica das interfaces

 

Após a modelagem conceitual, executam-se:

  • Especificações de API s,
  • Especificação técnica das Customizações necessárias,
  • Especificações  de ajustes nos dicionários de dados e tabelas  do SGDB para suportar a integração.

Trata-se do refinamento técnico do que será desenvolvido, visando aumentar a confiabilidade dos trabalhos indicados na fase e reduzir retrabalhos futuros.

Deliverables: Especificação formal dos requisitos das integrações  a serem desenvolvidas. Espera-se também que este material seja previamente discutido entre os fornecedores e enviado para desenvolvimento interno ou externo, antes de iniciar-se a próxima etapa.

 

(f) Desenvolvimento (construção) técnico das integrações e codificação

De posse das especificações conceituais das funcionalidades e detalhamentos técnicos, e após analises em conjunto com os fornecedores, iniciam-se  duas ações visando o desenvolvimento técnico da integração:

  • Codificação  da solução,  utilizando-se as tecnologias de desenvolvimento dos arquivos de importação e programas de exportação e importação destes registros,  e no caso de uso do Middleware EAI/ESB, dos seus componentes tecnológicos (XML,  J2EE, Corba, APIs etc.).
  • Ajustes da arquitetura técnica (Concentrador de Mensagens, Servidores e Links, diretórios e direitos) para suportar as transações e testes das próximas fases em função do refinamento obtido na etapa (e).

Deliverables: (1) Infra-estrutura computacional disponibilizada. (2) Desenvolvimento técnico (programação e parametrização) das interfaces e do ambiente de integração.

 

(g) Testes unitários

Após o desenvolvimento técnico iniciam-se os trabalhos de testes unitários de geração dos registros pelo(s) sistema(s) de origem, uso de API s,  envio e recepção no caso da interface Ponto a ponto e  na Hipótese de uso da tecnologia EAI/ESB: Entrada no Concentrador de Mensagens, transformação,  aplicação de regras de conversão e posterior envio da mensagem para o(s) Sistema(s) de Destino(s), conforme os requisitos estabelecidos nas fases anteriores.

Nestes testes unitários começa-se a monitorar os níveis segurança,  desempenho e disponibilidade dos serviços.

Produtos finais esperados:  Testes das APIs, e das  transformações executadas no Concentrador de Mensagens, analise da confiabilidade e segurança nas transações  e obtenção inicial de métricas de performance, ajustes e tunning da infra-estrutura  e base de dados envolvidas. Inicio dos testes e avaliação dos atendimentos dos requisitos   estabelecidos no típico (b).

 

(h) Testes integrados

Nos testes integrados espera-se a verificação de como as integrações desenvolvidas estão operando dentro dos níveis crescentes de complexidades e volumes de transações especificados, são considerando pelo menos os seguintes aspectos:

  • Volume de dados / Numero de registros – transações envolvidas visando a execução de testes de stress.
  • Saída dos dados / registros do aplicativo de origem no aplicativo destino (com a passagem pelo no Concentrador de Mensagens s no caso da tecnologia EAI/ESB)
  • Análise do funcionamento, aderência  e adequação das regras de Transformação.
  • Detecção de erros e tratamento  de erros
  • Postagem de mensagens de erros e exceções.
  • Envio dos registros  para o aplicativo de destino.
  • Analise do nível de segurança
  • Estabilidade das tecnologias e padrões envolvidos no desenvolvimento como XML, DTD’s etc.
  • Desempenho medido nos recursos envolvidos na integração como rede, SGDB,  Middleware.
  • Desempenho da solução nos sistemas que participam na integração e neste caso deve-se analisar  tempos de processamento e esperas, gargalos de saída e entrada, etc.

Deliverables:  Integração testada, medições  e avaliação do desempenho da solução   e conforme os parâmetros definidos no tópico (b),  revisões e ajustes finais, liberação da solução para homologação final.  

 

 

(i) Homologação

Após os testes integrados toda a solução deve ser testada também pelos usuários finais, visando homologação.

Muitas etapas dos processos de integração, quer  seja pelo método ponto a ponto ou via EAI/ESB,  são  transparentes aos usuários finais, mas,  não podemos esquecer que todo e qualquer sistema informatizado tem por objetivo atender a requisitos e a serviços  esperados pelos usuários e a s.

Para isso, recomendamos uma simulação integrada do processo, de modo a obter um parecer final dos usuários quanto ao atendimento dos requisitos.

 

Deliverables: Homologação do processo e entrada em produção conforme planejamento para o projeto.

Os tópicos (g), (h) e (i)  enquadram-se dentro dos processos de teste de software.

Um sistema de interfaces deve ser passível de testes, ou segundo IEEE (IEEE, 2004)   possuir “Testability.

Nesta mesma referencia descreve-se  o termo “Software Testability”  sendo a característica do Software de possibilitar testes e atender  a determinados critérios previamente estabelecidos, como também  possibilitar  a coleta de medições estatísticas dos resultados obtidos (tradução livre).

Conforme Paula (Paula, 2003), requer-se o desenvolvimento de “Planos de testes”,  que visam demonstrar qual teste deve ser executado;  e “Especificações de testes”, que  descreve em detalhes cada tipo de teste que será realizado.

Tanto os testes Unitários como os integrados devem considerar os requisitos obtidos nas fases anteriores.

 

(j) Produção

É a Liberação controlada e monitorada de todo o desenvolvimento para uso da organização.

No caso da Tecnologia EAI/ESB, a fase de produção representa que o framework de  Concentração  de Mensagens passa  a ser uma parte  indissociável da arquitetura tecnológica da empresa.

Devem ser dada continuidade ao processo de monitoração dos indicadores de desempenho dos componentes da solução como bancos de dados,  controle do trafego da rede, e controle do numero de transações, desempenho do Concentrador de Mensagens etc.

Nesta etapa,  toda a configuração da solução empregada como Software, Hardware, links  devem possuir:

  • Documentação especifica,
  • Controle de versões e atualizações,
  • Verificações e auditorias periódicas
  • Controle e planejamento de mudanças planejadas conforme  o tópico (k) manutenção.

Entendemos que não basta colocar a integração “no ar”, mas, continuar no processo de monitoramento e administração do ambiente.

Deliverables: Controle da capacidade da arquitetura, planejamento de manutenções e paradas, indicação de níveis de confiabilidade, analise da disponibilidade da arquitetura, controle e administração da configuração.

 

(k) Manutenção.

Visa dar continuidade a operação da integração  e principalmente oferecer a flexibilidade de crescimento de novos serviços

A Tecnologia EAI/ESB, visa proporcionar uma maior flexibilidade no processo de manutenção se comparado com uma manutenção de interfaces Ponto a ponto.

Estas Manutenções devem ser previamente  planejadas,  testadas em um ambiente a parte e estabelecidas, pois podem implicar em paradas de alguns processos críticos para a cadeia de valor da empresa ou dano para a própria imagem da organização.

Neste estudo agrupamos as manutenções da infra-estrutura de interface dentro de 3 Classes:

 

Classe I - Manutenção dos componentes tecnológicos (paralisação temporária dos serviços):

Mudanças nos padrões tecnológicos, upgrades nos servidores, alterações na infra-estrutura ajustes na capacidade de trafego, ou paralisações na infra-estrutura tais como sinistros, queda prolongada de energia, ataques de vírus e hackers,  etc.  demandam eventuais paradas no ambiente.

Também alterações em qualquer um dos componentes do processo,   sejam nos sistemas de  origem, sistemas de  destino, regras de negocio, alterações na tecnologia de integração podem exigir  freqüentes projetos  de adaptações.

 

Classe II - Manutenção nos aplicativos (upgrades e trocas de versões)

Eventuais manutenções no dicionário de dados que quaisquer uns dos sistemas envolvidos na integração requerem também manutenções planejadas.

Neste caso, antes da execução de uma atualização da versão do aplicativo, recomenda-se que a empresa execute uma re-analise da interface  e nos atributos  descritos na tabela 3 deste texto.

Como medida de segurança os DBA s devem manter um controle estrito de mudanças nos atributos dos campos e manter contatos com a equipe de EAI/ESB para monitorar e auxiliar nas revisões da interface.

 

Classe III – Substituição/  entrada de novos serviços

Na Introdução de novos sistemas a serem integrados via Middleware,  ou alterações no processo  de negocio, ira requerer  manutenções  adaptativas dos serviços que podem alterar todas as regras de roteamento previamente estabelecidas.

Em especial para este caso, recomendamos que sejam seguidos novamente os passos mencionados neste estudo.

 

Deliverables:  Controle de falhas e manutenções corretivas,  Registro e analise de manutenções pro ativas  e adaptativas,  elaboração e implantação de planos de continuidade e evolução dos serviços, cronogramas de manutenção, desenvolvimento e execução de planos de manutenção.

O processo de manutenção visa manter a solução operacional durante o seu ciclo de vida.

Estas Deveriam ter suas atividades  registradas,  eventuais alterações no software ou outros artefatos relacionados ao processo de integração de sistemas deveriam passar por um novo ciclo de testes e capacitação dos envolvidos na operação e Manutenção de toda a infra-estrutura.

 

(l) Encerramento dos serviços.

Entendemos que em uma organização podem ocorrer pelos menos três tipos de encerramento / descontinuidade dos serviços.

  • Descontinuidade de fornecimento e suporte de  um ou mais sistemas integrados via middleware ou interface ponto a ponto.
  • Descontinuidade do fornecimento e suporte do Middleware (EAI/ESB) ou,
  • Descontinuidade total das operações da empresa ou da malha operacional.

Para os dois primeiros casos recomenda-se o desenvolvimento de acordos de níveis de fornecimento com clausulas de alertas  antecipados de  encerramento das atividades num horizonte de tempo que permita a substituição do(s) sistema(s)  ou do próprio  Concentrador de Mensagens de integração, conforme recomendado para as manutenções Classe I indicadas no tópico (K).

No terceiro caso, a também a empresa deve elaborar um plano de phase-out das integrações  de modo sincronizado com o encerramento das atividades.

Deliverables:  Contratos de níveis de serviço e fornecimento, Plano de encerramento e descontinuidade dos serviços e processos.

 

5. Conclusões.

As possibilidades de soluções  envolvendo integração entre sistemas Heterogêneos  são infinitas e possibilitam  a introdução de melhorias tanto  tecnológicas e principalmente nos métodos de gerenciamento do processo de desenvolvimento visando como não poderia deixar de ser, a  obtenção de maiores ganhos de eficiência e controle.

Neste texto procuramos reforçar o fato de que além do domínio técnico deve existir um domínio no  gerenciamento do processo  e quanto maior o grau de maturidade da empresa no desenvolvimento de  softwares, maior a necessidade de formalização destas atividades.

E, por se  tratarem métodos e técnicas  emergentes, esta analise pretendida de forma alguma é exaustiva.

 

Bibliografia

 

ALMEIDA, Valmir Antonio de. Administrando Customizações em Softwares ERP.  Developers Cio Magazine, Agosto 1999.

 

CARLSON, Carlson. Modeling XML applications Whit UML, Practical e-business applications. USA, Addison Wesley, 2001.

 

CMMI PRODUCT TEAM. Capability Maturity Model Integration (CMMIsm), Versão 1.1. CMMI for Systems Engineering and Software Engineering (CMMI-SE/SW, V1.1). Staged Representation, CMU/SEI-2002-TR-002. ESC-TR-2002-002.

 

CUMMINS,  Fred A. Enterprise Integration. USA John Wiley & Sons, inc 2002 (Tradução:  Integração de Sistemas EAI  - Enterprise application Integration:  Arquiteturas para integração de sistemas e aplicações corporativas, Rio de Janeiro, Editora Campus,  2002).

 

IEEE (The institute of Electrical and Electronics Engineers)  (Editor), Guide to the Software Engineering Body of Knowledge, 2004. obtido via  http://www.swebok.org/  acessada em  Outubro 2005.

 

INMON.  Willian H. Como construir o Data Warehouse. Rio de Janeiro, Editora Campus,  1997.

 

INMON.  Willian H.  et all. Datawarehousing, Como transformar informações em oportunidades de negócios. São Paulo, Editora Berkeley, 2001.

 

LINTHICUM, David S. Enterprise Application Integration, USA, Addison-Wesley Information Technology Series, 2001.

 

MAFFEO, Bruno. Engenharia de Software e Especificação de Sistemas. Rio de Janeiro, Editora Campus, 1992.

 

PAULA FILHO, Wilson de Pádua. Engenharia de Software – Fundamentos, métodos e Padrões. 2ª Edição,  Rio de Janeiro, LTC, 2003.

 

PRESSMAN, Roger.  Engenharia de Software. 3ª Ed. São Paulo, Makron Books do Brasil, 1995.

 

PROJECT MANAGEMENT INSITUTE (Editor), Um Guia do Conjunto de conhecimentos em Gerenciamento de Projetos  - (Guia PMBOK 3ª Edição), 2004.

 

ROWELL, Michael. Undestanding EAI. USA, SAMS 2000.

 

SILVA, Douglas Marcos da. Guia de Consulta Rápida UML. São Paulo, Novatec Editora,  2001.

 

Sítios na internet com informações  relacionadas ao assunto (1º e 2º  semestres de 2005):

http://www.eaiiournal.com

http://eai.ittoolbox.com/

http://www.bitpipe.com/data/web/bp/eai

www.integrationconsortium.org

http://www.neogrid.com.br/

http://www.bea.com/

http://www.vitria.com/

http://www.sei.cmu.edu

http://www.swebok. Org/

 

Sítios na internet com informações  relacionadas ao assunto (1º  semestre de 2006):

www1.webmethods.com/PDF/The_Business_Case_for_SOA.pdf

http://javaboutique.internet.com/tutorials/serv_orient/

http://dev2dev.bea.com/pub/a/2005/12/soa-roadmap.html


 

Termos Técnicos utilizados no texto:

 

API:                    Aplication Program Interface

BI:                       Business Intelligence

BPM:                  business process management

COM:                 Component Object Model

CORBA:            Common Object Request Broker Architecture

COTS:                Commercial- OFF-The-Shelf)

CRM:                 Customer Relationship Management

DCOM:              Distributed COM

DTDs  :               Document Type Definitions

DW:                    Data Warehouse

EAI:                    Enterprise application integration

EJB:                    Enterprise JavaBeans

ESB:                   Enterprise Service Bus

ERP:                   Enterprise Resource Planning

HTML:               Hipertext Mark-up Language

HTTP:                Hipertext Transport protocol

OLAP:                On-line Analytical process

ODBC:               Open Database Connectivity

PDA:                   Personal digital assistants (PDAs ou Handhelds), ou Assistente Pessoal Digital

SGDB:                Sistema gerenciador de Bancos de dados

SOA:                   Service-oriented architecture

SSL:                    Secure Socket Layer

UML:                  Unified Modeling Language

Web:                   Word Wide Web

XML:                 eXtensible Mark-up Language