4 Metode – en narrativ tilnærming
4.5 Intervjuene
Para validação do modelo apresentado neste estudo, foi selecionada uma aplicação crítica, construída em uma instituição financeira Brasileira, com fundamentação em arquiteturas SOA. Um dos pontos mais importantes que foram avaliados por esta instituição foi a possibilidade de compartilhamento de serviços corporativos e eliminação de processos redundantes.
O objetivo desta aplicação é prover as funcionalidades necessárias para abertura de contas correntes. O processo negocial já existe e está bastante maduro, porém, pelo fato de envolver diversos sistemas do legado, o processo se torna longo e demorado, causando impacto no atendimento às demandas de um mercado altamente competitivo.
O processo de desenvolvimento tradicional, até então utilizado por esta instituição, não estava provendo a velocidade e flexibilidade necessárias para atendimento ao negócio, que exige o desenvolvimento de aplicações em prazos cada dia mais curtos. Devido à criticidade, ao alto nível de complexidade e disponibilidade apresentados pelos processos de negócio, torna-se fundamental a adoção de uma plataforma de desenvolvimento que atenda a estas necessidades. Neste sentido, a adoção de uma arquitetura SOA torna-se importante devido às suas características relativas a flexibilidade, escalabilidade e interoperabilidade.
O processo de desenvolvimento foi iniciado a partir do mapeamento dos processos de negócio visando identificar rotinas e procedimentos utilizados pela área gestora. Após a análise dos fluxos e definição da orquestração dos processos de negócio, foi iniciado um levantamento para identificação de ativos de software no legado. Naquele momento o sistema de abertura de contas se encontrava em produção e com alto grau de maturidade e confiabilidade. Foram, então, identificados os componentes e construídos os serviços de negócio. A aplicação hoje se encontra em produção para todas as agências em todo o território nacional suportando um alto volume transacional diário.
Devido às características de flexibilidade e velocidade ao atendimento das demandas negociais apresentadas por uma arquitetura orientada a serviços, a área de inovação tecnológica decidiu implementar uma infra-estrutura de desenvolvimento e execução de aplicações por meio de um Barramento Corporativo de Serviços, ou Enterprise Service Bus – ESB.
Uma arquitetura orientada a serviços implementada por meio de um ESB, apresenta as características demandadas pela nova diretiva organizacional de simplificação arquitetural, mudando o foco do desenvolvimento onde o atendimento era feito para áreas específicas, para um desenvolvimento que visa construir aplicações que manipulam o negócio, tendo como meta o compartilhamento de serviços corporativos e eliminação de processos redundantes.
Atendendo à criticidade do negócio tratado por instituições do mercado financeiro, este trabalho vem fornecer uma ferramenta para gestão da qualidade de software apresentando um método para avaliação da disponibilidade de serviços críticos da organização.
A disponibilidade de serviços apresenta um fator crítico ao negócio, a gestão da qualidade de cada serviço individualmente, reflete diretamente na qualidade dos serviços oferecidos pela organização. O método apresentado neste trabalho oferece suporte a verificação da qualidade no nível atômico de serviços, porém, com capacidade de atendimento as regras de composição de serviços de negócio, permitindo uma análise de disponibilidade negocial.
A aplicação de abertura de contas, fundamentada na implementação de um Barramento Corporativo de Serviços, foi construída com forte re-utilização de ativos localizados nos sistemas legados. A implantação desta aplicação representa uma forte mudança de processos de negócio, porém, apresenta baixa demanda no desenvolvimento de novas funcionalidades. Este cenário apresenta uma situação bastante favorável à aplicação de uma arquitetura orientada a serviços (SOA), com capacidade de integração das abordagens Top-Down e
Bottom-Up.
A abordagem bottom-up (ERL, 2008), parte da descoberta de ativos de software no legado. Com base no mapeamento de fluxos de trabalho, identificação e orquestração de novos serviços proveniente de uma abordagem top-down (ERL, 2008), chegamos ao melhor cenário de implementação de uma arquitetura orientada a serviços, que prevê a combinação
de ambas as abordagens, ou seja, suprimos os processos de negócio mapeados a partir da análise top-down (ERL, 2008) com serviços provenientes de um repositório de serviços corporativos, construído a partir da análise bottom-up (ERL, 2008). Desta forma temos uma arquitetura com capacidade de desenvolvimento de novas soluções com a qualidade e no prazo exigidos pelas áreas de negócio.
8.2 – Visão Estratégica de Implementação de um Barramento Corporativo
A implementação de um Barramento Corporativo de Serviços está alinhada ao plano estratégico da organização, que visa a adoção de tecnologias abertas para interoperabilidade de sistemas, flexibilização arquitetural e agilidade no atendimento ao negócio. A figura 25 mostra uma visão de implementação tecnológica da organização, onde a implementação de uma arquitetura SOA, se apresenta como elemento chave na execução da estratégia corporativa.Figura 25 - Visão de implementação tecnológica (CIAB, 2007)
Após um estudo detalhado de ativos existentes no legado, bem como, uma análise das novas funcionalidades demandadas pelo negócio, foi possível a construção de um Diagrama de Fluxo de Dados - DFD, apresentado na figura 26, contendo as funcionalidades da nova aplicação:
8.3 – Visão de Requisitos Funcionais – Diagrama de Contexto
Barram en to Corporativo de Serviços
Agência
D evolve R esposta de Serviços
Sistem a de C artões de C rédito R ecebe Solicitação de Serviços
C ontas C orrentes B anco 24 horas C ontas Eletrônicas Sistem a de Anáise de R isco C liente Sistem a de C rédito Avaliação de Risco p/ CDC P ro p a g a C o n ta A b e rt a A valiação de Risco p/ Cartão de Crédito Sistem a de Análse de R isco de C rédito R e s e rv a N ú m e ro d e C o n ta R estrições do C liente
dados cadastrais de clientes
C o n s u lt a C lie n te dados restrições cliente C adastro de C lientes C adastro de C lientes C adastro de
C lientes C adastro deC lientes
In c lu s ã o C lie n te A lt e ra ç ã o C lie n te V a lid a ç ã o , H o m o lo g a ç ã o e E x p o rt a ç ã o R estrição C adastral dados de contas dados de avaliações Recebe Avaliação de Risco de C rédito
e Cartão M últiplo dados de
crédito dados de cartão de crédito dados de C onta dados de C onta dados de C onta
Figura 26 - Diagrama de Fluxo de Dados do Barramento Corporativo de Serviços
De acordo com o mapeamento de processos de negócio, e orientados pelos requisitos funcionais da aplicação, foram descritos os principais cenários de execução por meio de uma visão de casos de uso. Na figura 27 apresentamos o Modelo de Requisitos composto pelos casos de uso envolvidos no processo de abertura de contas:
8.4 – Visão de Requisitos Funcionais a partir dos Casos de Uso
Figura 27 - Modelo de Requisitos do Barramento Corporativo de Serviços
Foram estabelecidos alguns requisitos arquiteturais para funcionamento da aplicação: • Todos os serviços executados por meio do Barramento Corporativo de
Serviços devem ser selecionados por uma camada primária das requisições chamada Diretório de Serviços (DS – Directory Services).
• As requisições devem ser encaminhadas a partir de uma aplicação cliente localizada em cada uma das agências, responsável pela captação dos dados. A partir deste ponto, o Diretório de Serviços deverá ser sensibilizado para executar o serviço solicitado a partir da aplicação de captação.
• Ao receber a requisição, o diretório de serviços consulta a existência do serviço solicitado, utilizando o protocolo padrão UDDI – Universal
Description, Discovery and Integration (ERL, 2008). Em seguida o serviço é selecionado e executado.
8.5 – Visão de Integração com o Legado de Aplicações
Para atendimento das demandas da aplicação no prazo solicitado, foi necessária a identificação de serviços no legado candidatos ao reuso. Primeiramente foram identificados os sistemas nos quais estavam localizadas estas funcionalidades, e em seguida feita uma análise de alternativas de interoperabilidade destes serviços ao Barramento Corporativo. Na figura 28 são apresentados os sistemas identificados como hospedeiros (legados) destas funcionalidades.
Figura 28 - Identificação dos sistemas legados com serviços a serem reutilizados
Para conectividade com os sistemas legados, foram utilizadas tecnologias já existentes e de amplo domínio no mercado, tais como: Websphere MQ Server, CICS e Web Services. O fluxo de execução bem como a coreografia e orquestração de serviços foram implementados na camada de infra-estrutura do ESB.
Tendo em vista a grande diversidade de consumidores destes serviços, foi necessário a externalização dos mesmos em mais de um padrão de utilização:
• Serviços externalizados por meio de Filas MQ para os sistemas implementados utilizando esta tecnologia;
• Serviços externalizados por meio de transações CICS visando atendimento as aplicações existentes no legado;
• Serviços externalizados utilizando o padrão XML com implementação de Web Services, visando melhor atendimento à plataforma distribuída e aplicações Web.
A figura 29 apresenta uma visão simplificada de como estes padrões foram implementados na aplicação:
8.6 – Domínio de Serviços Corporativos
O quadro 12 demonstra os serviços de negócio, ou serviços compostos, identificados visando atendimento às demandas apresentadas pelo domínio de negócio:
Serviços UCs Sistêmicos Funcionalidades Legado
Restrição Cliente
UC: Verificar Adimplência. UC: Consulta Restrições cadastrais.
UC: Valida CPF
Realiza uma consulta
parametrizada de restrições do cliente no sistema. Sistema Receita Federal Consulta
Cliente UC: Consulta Cliente Consulta os dados do cliente a partir do seu CPF.
Cadastro de Clientes Reserva
Número de
Conta UC: Gerar Número de C/C
Reserva um número de Conta Corrente para posterior abertura
Sistema de Conta Corrente
Replicar Conta
Corrente UC: Replicar CC
Replica os dados da nova Conta Corrente para que os mesmos possam estar disponíveis imediatamente em todos os canais. Operações adicionais de cliente são contratadas após abertura de contas. Conta Eletrônica Sistema de Conta Corrente Banco 24 Horas Manutenção do Cliente
UC: Mantém cadastro usuário UC: Atualização de dados do Cliente
Mantém as informações
atualizadas no cadastro unificado de clientes
Cadastro de Clientes
Quadro 13 - Domínio de Serviços Críticos do Barramento Corporativo – Abertura de Contas
Para análise de disponibilidade neste estudo utilizamos o serviço Abertura de
Conta tendo em vista sua criticidade para realização do processo de abertura de conta.
8.7 – Matriz de Análise de Impacto de Falhas – CFIA
No caso específico do Serviço Abertura de Contas, todos os serviços atômicos listados no Quadro 13, são considerados críticos para finalização da funcionalidade negocial. Desta forma todos são considerados Pontos Únicos de Falha (SPOF), no Quadro 14, está demonstrada a Matriz CFIA para o serviço Abertura de Contas.
Item de
Configuração Restrição Cliente Consulta Cliente
Reserva Número da Conta
Replicar
Conta Manutenção do Cliente
Abertura de Contas X X X X X
Crédito Pessoal X X X
Cartão Múltiplo X X X
Quadro 14 - Matriz de análise de impacto de falhas de componentes – CFIA (ITIL, 2003)
8.8 – Análise da Disponibilidade do Serviço de Negócio
8.8.1 – Análise com base no Índice de DisponibilidadeA análise dos Logs da aplicação foi feita com base nos critérios de criticidade da aplicação para a organização. Foi escolhido o horário entre 10:00hrs e 15:00hrs do dia 03/11/2008, período considerado com alta carga de processamento, portanto, crítico para disponibilidade do serviço de abertura de contas.
De acordo com a norma ISO/IEC 9126-2 (2002), temos a disponibilidade definida por:
Onde:
D – Índice de disponibilidade do serviço To – Tempo total de Operação
Após a análise dos Logs apresentados no Anexo: Log de execução da Aplicação temos:
Abertura de Contas To Tr D
Restrição Cliente 300 17m00s 94,64%
Consulta Cliente 300 35m35s 89,46%
Reserva Número de Conta 300 45m43s 86,85%
Replicar Conta Corrente 300 8m06s 97,38%
Manutenção do Cliente 300 15m27s 95,16%
Quadro 15 - Dados de disponibilidade de serviços atômicos - Barramento
DRestriçaoCliente = 94,64% DConsultaCliente = 89,46% DReservaNumeroConta = 86,85% DReplicarContaCorrente = 97,38% DManutencaoCliente = 95,16%
Melhor caso de Disponibilidade:
DAbertura de Contas = 300 / (300 + 45,43) = 0,8685 ou 86,85%
Pior caso de Disponibilidade:
DAbertura de Contas = 300 / (300 + 121,11) = 0,7124 ou 71,24%
Probabilidade da Disponibilidade:
PDAbertura de Contas = 0.6813 ou 68,13%
Neste caso, temos o serviço Replicar Conta Corrente como sendo o serviço de maior disponibilidade entre os serviços atômicos, porém, a disponibilidade do Serviço Abertura de
que apresenta o menor dos índices de disponibilidade, pois apresenta o maior tempo de reparo. A diminuição do tempo de reparo do serviço Reserva Número de Conta é um dos elementos que representam maior impacto na melhoria da disponibilidade do serviço de negócio.
Cabe ressaltar outro benefício da análise inter-relacionada entre os índices de disponibilidade dos serviços atômicos e o índice de disponibilidade do serviço de negócio, que é a percepção, por meio da análise tanto do pior caso de disponibilidade quanto da probabilidade da disponibilidade, que há uma diferença significativa entre os valores dos serviços atômicos e de negócio, mesmo que alguns serviços atômicos apresentem altos índices de disponibilidade. Podemos identificar claramente o impacto individual de cada serviço no resultado da disponibilidade do serviço de negócio, facilitando ao gestor de TI no direcionamento de esforços e foco no trabalho de desenvolvimento e manutenção para melhoria da qualidade do serviço, e por conseqüência dos resultados de negócio.
8.8.2 – Análise com base no Intervalo Médio entre Falhas - MTBF
A análise dos Logs da aplicação foi feita com base nos critérios de criticidade da aplicação para a Organização. Foi escolhido o horário entre 10:00hrs e 15:00hrs do dia 03/11/2008, período considerado com alta carga de processamento, portanto, crítico para disponibilidade do serviço de abertura de contas.
De acordo com a norma ISO/IEC 9126-2 (2002), temos o MTBF definido por:
Onde:
MTBF – Tempo médio entre falhas
HF – Horário da falha do serviço (momento de falha)
HIE – Horário de início da execução do serviço (inicio da execução, ou momento de reinicio após a falha)
Após a análise dos Log apresentados no Anexo: Log de execução da Aplicação Barramento Corporativo de Serviços, temos:
Abertura de Contas ( HF – HIE) NF MTBF
Restrição Cliente 4h43m00s 15 18m52s
Consulta Cliente 4h24m25s 10 26m27s
Reserva Número de Conta 4h14m17s 9 28m15s
Replicar Conta Corrente 4h51m54s 15 19m28s
Manutenção do Cliente 4h44m3s 11 25m52s
Quadro 16 - Dados de MTBF serviços atômicos - Barramento
MTBFRestriçaoCliente = 18min 52seg MTBFConsultaCliente = 26min 27seg MTBFReservaNumeroConta = 28min 15seg MTBFReplicarContaCorrente = 19min 28seg MTBFManutencaoCliente = 25min 52seg
Como exemplo de análise, neste caso, percebemos que o serviço Restrição Cliente,
apesar de apresentar um dos mais altos índices de disponibilidade, apresenta baixo MTBF, como demonstrado no Quadro 15 e, MTTR como descrito no Quadro 16. Por meio de uma análise combinada entre as métricas de confiabilidade, percebemos que este serviço apresenta um elevado número de falhas e um dos menores tempos de recuperação do serviço, ou seja, o usuário sofre sucessivas interrupções de curto espaço de tempo. Na área de negócio na qual está inserida esta aplicação, temos atendimento ao público, portanto, este pode ser um fator de impacto significativo na qualidade do serviço prestado.
8.8.3 – Análise com base no Tempo Médio de Recuperação de Serviço - MTTR A análise dos Logs da aplicação foi feita com base nos critérios de criticidade da aplicação para a Organização. Foi escolhido o horário entre 10:00hrs e 15:00hrs do dia 03/11/2008, período considerado com alta carga de processamento, portanto, crítico para disponibilidade do serviço de abertura de contas.
De acordo com a norma ISO/IEC 9126-2 (2002), temos o MTTR definido por:
Onde:
MTTR – Tempo médio de recuperação de falhas TR – Tempo de reparo do serviço (momento de falha) NF – Quantidade total de falhas
Após a análise dos Logs temos:
Abertura de Contas ( TR ) NF MTTR
Restrição Cliente 17m00s 15 1m08s
Consulta Cliente 35m35s 10 3m33s
Reserva Número de Conta 45m43s 9 5m05s
Replicar Conta Corrente 8m06s 15 32s
Manutenção do Cliente 15m27s 11 1m24s
MTTRRestriçaoCliente = 1min 08seg MTTRConsultaCliente = 3min 33seg MTTRReservaNumeroConta = 5min 05seg MTTRReplicarContaCorrente = 32seg MTTRManutencaoCliente = 1min 24seg
Na análise do quadro de tempo médio de recuperação de falhas - MTTR, percebemos que o serviço Replicar Conta Corrente apresenta alta capacidade de recuperação, porém, este fator, isoladamente, não garante bom índice de disponibilidade para o serviço de negócio. Sua disponibilidade passa a ser influenciada pelo tempo de reparo apresentado pelo serviço Reserva Numero de Conta, que apesar de apresentar o maior intervalo entre falhas, foi o de menor capacidade de recuperação automática, impactando diretamente na sua disponibilidade e, na disponibilidade do serviço de negócio.
A análise comparativa dos índices de confiabilidade, mostra claramente, que, não basta termos apenas um dos fatores favoráveis, como neste caso temos um bom MTBF, precisamos levar em consideração fatores como índice de disponibilidade do serviço e sua capacidade de recuperação.
8.8.4 – Cálculo da Disponibilidade em Função do MTBF e MTTR
Com base nos resultados obtidos a partir do cálculo de MTBF e MTTR, de acordo com o fórum de alta disponibilidade SAF (SAF, 2008 ; HAF, 2001 ; HOLLAND, 2002 apud TARKOMA, 2003) o índice de disponibilidade de um serviço pode ser calculado a partir do MTBF e MTTR. Como o sistema usado em nosso estudo de caso não possui redundância, segundo estudos do fórum de alta disponibilidade – SAF (2008), podemos calcular a disponibilidade por meio da expressão (SAF, 2008 ; HAF, 2001):
temos:
Abertura de Contas MTBF MTTR Disponibilidade
Restrição Cliente 18m52s 1m08s 94,33%
Consulta Cliente 26m27s 3m33s 88,14%
Reserva Número de Conta 28m15s 5m05s 84,76%
Replicar Conta Corrente 19m28s 32s 97,30%
Manutenção do Cliente 25m52s 1m24s 94,85%
Quadro 18 – Índice de Disponibilidade segundo os fatores MTBF e MTTR
Podemos perceber que os índices de disponibilidade podem ser calculados em vários cenários de informação:
1. Com base nos tempos de operação e tempos de reparo dos serviços atômicos. Neste cenário de informação utilizamos os cálculos apresentados pela norma ISO/IEC 9126-2;
2. Com base nos índices MTBF – Intervalo entre falhas e MTTR - Tempo médio de reparo. Com estes dados utilizamos os cálculos fundamentados pelo Fórum de alta disponibilidade SAF (SAF, 2008 ; HAF, 2001); 3. Utilizando cálculo de probabilidade da disponibilidade fundamentados na
teoria dos eventos independentes (SOONG, 2004). Com estes dados podemos calcular o índice de disponibilidade prevista para serviços de negócio ainda não implementados, ou seja, atendendo novas regras de composição de serviços, com base nos serviços disponíveis em nosso repositório;
Todos os cenários apresentam índices de disponibilidade muito próximos, portanto, de acordo com os dados que dispomos, podemos selecionar a forma mais adequada para o cálculo da disponibilidade de serviços.