Sistemas de Informações Heterogêneos

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

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).

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”:

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.

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.
• 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.

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.

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

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.

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.

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.

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.

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.

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:

1. Diagnostico e geração do mapa de processos de negócios.
2. Definição de regras de negocio e método de suporte dos recursos de TI ao processo.
3. Identificação dos sistemas que suportam os processos de negócios Atuais e suas interfaces.
4. Reuniões de especificação conceitual das interfaces.
5. Modelagem Técnica da interface.
6. Desenvolvimento técnico da solução.
7. Testes unitários.
8. Testes integrados.
9. Homologação.
10. Produção.
11. Manutenção.
12. 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.

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

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.

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.

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):

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 APIs.

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

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.
• 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.

Modelagem (desenho) Técnica das interfaces

Após a modelagem conceitual, executam-se:

• Especificações de APIs;
• 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.

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.

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).

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.
• Análise 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.

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.

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.

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.

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).
• 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.

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.
• 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.