O downsizing desenvolveu-se durante a década de 80, com o rápido desenvolvimento na tecnologia de microcomputadores, muitas empresas migraram os seus sistemas e o ambiente de execução, que eram geralmente baseados em computadores de grande porte para esta plataforma. Observe abaixo algumas das condições que contribuíram para esta migração.

Para as empresas quanto mais baixas for o nível hierárquico em que as decisões são tomadas melhores serão os seus resultados, para isso é essencial a diminuição da pirâmide da empresa, esta redução facilita a comunicação. A chave para o sucesso de idéias como esta é a criação de sistemas que sejam pequenos em termos de tamanho e não de potência, flexíveis e distribuíveis. O downsizing dos sistemas de informação tem sido associado ao conceito de eliminação dos excessos de burocracia da infra-estrutura nas empresas.

Alguns objetivos buscados com implantação de um processo de downsizing são: Custos menores; Maior rapidez em responsividade e tomadas de decisões; Menos distorções nas comunicações; Delegação de poder a pessoas de maior produtividade.

A reengenharia é dada como saída para restaurar grandes problemas existentes na estrutura atual dentro da empresa, mas mudar radicalmente, sem a análise de reengenharia, eqüivale mudar apenas por transformar e não avançar, ou seja, tem pouca chance de sucesso de implementação do downsizing em sistemas de informações sem que haja legítimas justificativas. Quando aparecer alguns sinais indicativos na sua empresa é hora de se fazer reengenharia. Alguns sinais são apresentados como: Ampla insatisfação com os sistemas de informação; Redução em posição competitiva; Comunicações deficientes entre divisões ou departamentos; Procedimentos que se tornaram insuficientes; Concorrência; O surgimento de esforços de reengenharia em departamentos; Programas intensivos dirigidos para a qualidade e que não tenham conexão com a tecnologia de informação e a incapacidade de aproveitar oportunidades surgidas.

À medida que os planejadores estratégicos deram início ao reexame dos procedimentos estabelecidos e das infra-estruturas de suas empresas, eles foram prestando muita atenção no modo pelo qual suas empresas estavam utilizando seus sistemas de informações. Mais ou menos na mesma ocasião, um novo elemento aparecia no palco empresarial: O computador pessoal, a introdução de máquinas poderosas e de preço acessível, que colocavam a tecnologia diretamente nas mãos do usuário individual, mudou totalmente o enfoque que as pessoas davam ao processamento de dados. O computador, contudo, não era a resposta a todas as necessidades da computação. Por muitas razões que incluíam gastos com mecanismos de impressão, tais como impressoras, e a inconveniência e ineficiência de se compartilhar arquivos por meio magnéticos as redes locais vieram a se tornar mais e mais populares ao longo da década de 90. O acrescentamento técnico não é competente de transformar o mundo. Mais do que apenas o avanço tecnológico, é necessário que se tire o maior proveito possível da tecnologia do conhecimento.

O downsizing surgiu devido aos problemas existentes dentro da organização com relação a sua tecnologia de informação, onde as empresas em busca de soluções estavam mudando os conceitos. Alguns dos problemas são fáceis de serem identificados outros nem tanto, vamos tentar compreender esses fatos. As empresas julgam que um grande leque dos problemas está relacionado com o processamento de dados centralizados. Julgam que este tipo de processamento possui deficiências, algumas das deficiências apontadas são: Falta de estimativa das necessidades da empresa; Uma responsividade deficiente às solicitações de usuários; Práticas de transferências internas de pagamentos que promovem incentivos a determinados grupos de usuários finais no sentido de que venham a desenvolver seus próprios sistemas.

Os gastos com a tecnologia de informação têm se tornado itens significativos de despesas que não apresentam um retorno aparente sobre tais investimentos. Esse fato tem dado um importante impulso à tendência ao downsizing. Acredita-se que quanto mais próximo do usuário final estiver o desenvolvimento de aplicações maior a probabilidade de sucesso de tais aplicações. Ao mesmo tempo, aumenta a possibilidade de se exercer um controle gerencial mais direto. A função de processamento de dados centralizada ainda tem um significado, mas seu papel está sofrendo profundas alterações como resultadas do processo de downsizing.

Ao considerar a implementação do downsizing, divida suas aplicações nestas quatro categorias: Aplicações que deverão passar pelo downsizing; Aplicações que são candidatas naturais ao downsizing, mas que originalmente foram desenvolvidas em mainframe; Partes de aplicações que deveriam passar pelo downsizing; Aplicações que ficam mais bem implementadas em mainframe por meio de um grupo de processamento centralizado.

Boas pretendentes ao downsizing são as aplicações que envolvem entrada de dados e editoramento, análises estatísticas e matemáticas e aplicações altamente interativas, tais como Computer Aided Design. É melhor evitar aquelas aplicações que sejam críticas, com elevadas exigências de segurança, as que envolvem grandes volumes de atualização de bancos de dados e aquelas aplicações complexas que transportam as fronteiras da organização. Downsizing não significa necessariamente que uma determinada aplicação deva ser integralmente removida do mainframe. Existe uma tendência denominada rightsizing, a qual envolve o downsizing apenas de partes de aplicações por meio de uma seleção de plataformas certas ou apropriadas para cada parte. Isto poderia significar a remoção de entrada de dados e funções de editoramento para plataforma do downsizing, ao mesmo tempo em que o mainframe continua a processar as modificações nos bancos de dados.

Existe também uma categoria de aplicações que foram originalmente desenvolvidas em mainframe, mas que são mais adequadas a uma plataforma do downsizing. Pode não haver justificativa econômica para a migração de tais aplicações para fora do mainframe. Muitas empresas têm preferido ser muito seletivas ao executar o downsizing desses tipos de aplicações.

Aspectos Positivos e Negativos: Em resumo, não espere que o downsizing vá presumir todos os males atribuídos a sistemas centralizados de computação e desenvolvimento. O downsizing poderá, em alguns casos, possibilitar significativas economias. E, talvez mais importante do que isso, o downsizing pode produzir aplicações que satisfazem melhor suas necessidades uma vez que são desenvolvidas por pessoas mais próximas de você e com uma melhor compreensão das necessidades do negócio. Estes dois importantes fatores de motivação provavelmente justificam uma filosofia de desenvolvimento que em primeiro lugar considere uma plataforma do downsizing, e venha a apoiar a mudança para um mainframe somente quando nisso houver uma real vantagem.

Alguns defensores do downsizing crêem que o mainframe já tenha ultrapassado o limite de sua utilidade e que, portanto, deveria ser eliminado. Outros, porém, têm ponto de vista oposto e argumentam que o mainframe deverá permanecer como a plataforma primária. Ambos estão errados. Há casos em que o downsizing proporciona economias substanciais, melhora a eficácia da rede e resulta em sistemas mais capacitados a satisfazer as necessidades do usuário final. De modo, semelhante, existem aplicações em que a implementação plena ou parcial de um mainframe proporciona nítida vantagem. O verdadeiro profissional de sistemas compreende as vantagens e as desvantagens de cada enfoque e, assim, faz uso de ambos, visando incrementar o valor do retorno sobre o investimento feito em tecnologia da informação pela empresa.

Custo e Benefícios: O objetivo da análise custo/benefício é diminuir os custos e benefícios relevantes de um projeto proposto, em grau de detalhe suficiente para permitir que a administração possa decidir levar o projeto adiante ou não. Antes que se dê início à análise, precisam-se obter as seguintes informações: Estimativa do custo operacional do sistema atual; Despesa do sistema proposto; Custos das fases subseqüentes do projeto de desenvolvimento; Descrição dos benefícios intangíveis; Base para se estimar como tais custos e benefícios se modificarão durante o decurso de alguns anos; Identificação dos riscos quantificáveis associados com a implementação ou não do projeto.

É preciso analisar os custos de sistemas de computadores, da seguinte forma: Custos iniciais de hardware, software, comunicações e pessoal; Custos de desenvolvimento de aplicativos; Custos de operação e manutenção.

Embora os novos sistemas normalmente apresentem despesas nas três categorias acima, o sistema existente é isento, exceto na categoria de custos de operação e manutenção. O primeiro obstáculo está na substituição do sistema grátis, por outro que custa dinheiro e poderá não dar certo, perdendo assim muito dinheiro com o projeto. Um bom planejamento é o principal destaque para um projeto bem sucedido. O downsizing aplicado em conjunto com um planejamento se torna essencial para sobrevivência da empresa. Na fase de implantação as armadilhas poderão ocorrer em uma dentre várias, inclusive as seguintes: Disparidade entre hardware e software; Proliferação ou esquecimento de ferramentas; Erros de julgamento em relação à capacidade.

A disparidade entre hardware e software ocorre quando múltiplos tipos de produtos, de múltiplos fornecedores, coexistem em uma organização. Estas disparidades surgem dois problemas que é a fragmentação e a falta de integração. A falta de consistência causada pela disparidade é geralmente encontrada quando cada aplicativo foi desenvolvido com suas próprias ferramentas e arquitetura, sem relação com os demais aplicativos. Torna-se então difícil fazer um aplicativo [A] fornecer para um aplicativo [B], ou mesmo fazer uso dos dados do arquivo [B]. A fragmentação de especialização ocorre em virtude de cada desenvolvedor poder ser fluente apenas em um pequeno número de produtos e técnicas.

O fato da proliferação de ferramentas se deve ao fato de determinado projeto estar sendo desenvolvido por uma determinada ferramenta e a medida que esteja pronto, ele é adotado apenas pelos membros do projeto específico. Outros projetos, em parte portadores da síndrome não inventado aqui, acabam tendo outras ferramentas, freqüentemente atendendo aos caprichos de preferências pessoais, em vez de satisfazer a necessidades tecnológicas.

Uma importante razão de ser do planejamento de aplicativos é a perfeita combinação de hardware e software a fim de atender os volumes de processamento e as características planejadas. O planejamento de capacidade é bastante diferente nos casos de sistemas de processamento de transações e de sistemas de apoio a decisão. Outro ponto importante em relação a implantação do downsizing, está no projeto detalhado de um sistema de downsizing: os aplicativos e sua plataforma de rede. O projeto detalhado para um aplicativo distribuído, no qual os processamentos de dados sejam distribuídos por múltiplos processadores que operam independente uns dos outros. Devido a esta característica o projeto esta sujeito as seguintes armadilhas: Estratagemas do projeto de rede de comunicações; Astúcias do projeto de banco de dados; Problema na integridade referencial.

Estratagemas do Projeto de Rede de Comunicações: A tecnologia de comunicações está mudando rapidamente, assim como os produtos oferecidos pelos fornecedores. Basicamente, a atividade de projeto de rede é o trabalho dos projetistas de rede e de telecomunicações, consistindo a previsão de pico, de volumes médios de transmissão de dados e de freqüências entre localidades diferentes. Todos esses tópicos devem ser levantados e minuciosamente estudados para que futuras modificações sejam de fácil implantação.

Astúcias do Projeto de Banco de Dados: Um dos mais difíceis casos de se resolver em termos de projeto é aquele em que uma determinada transação requer que diversos locais da rede atualizem dados localmente e que tais atualizações sejam sincronizadas: ou todas as atualizações são executadas, ou então nenhuma delas será executada. Tal sincronização geralmente é considerada como requerendo um tipo de procedimento denominado um restabelecimento em duas fases.

Problema na Integridade Referencial: O mais importante tipo de restrição em um banco de dados é denominado integridade referencial. Este termo se refere ao modo de se assegurar que os relacionamentos entre as entidades de dados encontram-se em conformidade com as regras documentadas durante o processo de JAD. A integridade referencial está assegurada quando todas as referências entre os termos ou entidades do banco de dados estiverem corretas.

“Este Trabalho é protegido pela Lei de Direitos Autorais: LEI Nº 9.610, de 19/02/1998, e pelos tratados e convenções internacionais”.
Alexandre Portela Barbosa Msc
Enviado por Alexandre Portela Barbosa Msc em 21/12/2008
Código do texto: T1346172
Copyright © 2008. Todos os direitos reservados.
Você não pode copiar, exibir, distribuir, executar, criar obras derivadas nem fazer uso comercial desta obra sem a devida permissão do autor.