Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

Microsoft Enterprise Platform para profissionais de UNIX: Conceitos básicos de migração

Capítulo 7 - Conceitos básicos de migração do UNIX

Publicado em: 10 de novembro de 2004

Este capítulo apresenta informações sobre erros comuns de concepção com respeito à migração, os princípios que devem nortear uma migração, estratégias de migração, uma visão geral resumida da Microsoft Solutions Framework e orientações prescritivas disponíveis para uma migração, desde o início até a conclusão.

Nesta página

Erros de concepção relativos à migração
Princípios de orientação
Estratégias de migração
Ambiente de produção Windows

Erros de concepção relativos à migração

Há vários erros de concepção muito comuns em relação à migração que devem ser reconhecidos e eliminados antes do início do processo de migração:

  • Uma migração é meramente um exercício técnico

    Uma migração exige muito trabalho de preparação para definir o escopo, as metas e os planos antes que as arquiteturas de destino sejam definidas. Essas atividades exigem o envolvimento ativo da administração, dos usuários e dos clientes. Se a migração for posicionada como um exercício exclusivamente técnico, provavelmente ela não receberá a atenção devida da administração e dos clientes e estará seriamente arriscada a falhar.

  • Profissionais qualificados antigos serão desvalorizados e haverá demissões

    Confrontar esse erro de concepção é um dos fatores de sucesso mais importantes para que a migração receba apoio. A qualificação técnica e as disciplinas de gerenciamento que mantêm o UNIX, por exemplo, o conhecimento dos negócios e dos seus aplicativos de apoio, também são necessários no ambiente Windows. Será necessário adquirir novas qualificações, mas elas não serão radicalmente novas e recompensarão os que as adquirirem com um ambiente de trabalho mais satisfatório e com um conjunto de qualificações profissionais de maior valor.

  • Os programadores serão obrigados a aprender novas linguagens

    Em muitos casos, a abordagem da migração de um aplicativo será a conversão do código, recompilando o código-fonte do aplicativo com o uso de uma nova versão da linguagem de programação original que poderá ser executada no novo ambiente. Nessa situação, os programadores poderão trabalhar com uma linguagem conhecida e, talvez, no contexto de um aplicativo que já conhecem.

  • Linhas de código implicam cronogramas e custos

    O uso de ferramentas de automação de análise e conversão torna a medida de linhas de código um tanto irrelevante. Por exemplo, pode ser necessário um minuto para recompilar um pequeno aplicativo, e dois minutos para recompilar um aplicativo grande, e, da mesma forma, o tempo necessário para analisar um aplicativo complexo pode ser um minuto a mais que para analisar um aplicativo mais simples. O escopo e o custo são muito mais profundamente afetados pelo volume de intervenção manual necessário para analisar, recompilar e testar individualmente todos os componentes de um aplicativo. Aplicativos arquitetados corretamente e codificados de acordo com padrões adequados de programação exigem muito menos intervenção manual.

Princípios de orientação

A observação dos princípios apresentados a seguir aumentará o êxito de qualquer processo de migração:

  • A migração deve ter um patrocínio bem definido e bem informado.

  • A migração deve ser gerenciada de maneira a gerar benefícios específicos.

  • A migração deve ser dirigida a um conjunto de recursos orientados pelos negócios.

  • A migração deve ter um alcance preciso.

Esses princípios serão discutidos nos subtítulos a seguir.

Patrocínio

Sem patrocínio, nenhuma iniciativa de migração sobreviverá às dificuldades encontradas em qualquer programa de mudança de larga escala. Normalmente, não basta que o CIO patrocine sozinho uma migração. O patrocínio mais eficiente é o da administração de negócios ou de um consumidor importante dos serviços de tecnologia da informação existentes, até mesmo um pequeno grupo de executivos importantes das áreas de negócios. Uma equipe patrocinadora permite a divisão do trabalho de patrocínio, além de evitar a idéia de que a migração pode estar sendo orientada pelas idéias de uma única pessoa.

A migração é uma iniciativa técnica apenas na superfície; na realidade, ela deve ser considerada uma transformação de negócios. Uma transformação desse tipo pode ser um processo complexo e trabalhoso. Sem um suporte sólido da alta administração de negócios, ela terá pouca chance de êxito.

Um patrocínio bem informado também é uma necessidade absoluta para o êxito do projeto. Ajudar os tomadores de decisões que não são técnicos a compreender os vários aspectos que orientam uma migração pode exigir muito preparo e esforço, mas isso é necessário porque, independentemente da elevada posição do patrocínio dentro da empresa, haverá resistência à idéia da migração. Se o patrocinador for capaz de enfrentar essas dificuldades apenas através da delegação ao grupo de TI, a migração estará em sério risco. Como todas as transformações, as migrações ameaçam muitos interesses estabelecidos, tanto internamente quanto entre fornecedores e parceiros tradicionais. Portanto, não faltarão voluntários dispostos a defender a manutenção do estado de coisas.

Caso comercial e vantagens evidentes

Pelas mesmas razões que um patrocínio graduado bem informado é necessário, também é necessário que os patrocinadores tenham um caso comercial que possa ser apoiado e advogado. Os casos comerciais devem ser adaptados às normas da empresa, mas uma parte importante de qualquer caso comercial dessa natureza são as vantagens que podem ser obtidas. Vantagens tais como “maior competitividade” podem ser adequadas em algumas empresas, mas elas são difíceis de sustentar e são inúteis para orientar a migração. As vantagens devem ser apresentadas de maneira clara e precisam ser específicas, verossímeis, atraentes e mensuráveis.

As vantagens de negócios definidas são as primeiras de uma série de muitos resultados que devem orientar todas as decisões. As vantagens para os negócios não devem ser definidas apenas com o intuito de eliminar um item de um plano de projeto e, depois, serem esquecidas. Este é um elemento essencial do êxito de uma mudança transformacional como uma migração: apresentar vantagens bem definidas e mutuamente acordadas que estejam sendo buscadas, utilizando-as para orientar as decisões e referir-se a elas ao assumir compromissos e concessões inevitáveis que ocorrem durante o projeto.

Recursos orientados pelos negócios

Um conjunto de recursos orientados pelos negócios deve ser estabelecido como pré-requisito da migração. Eles são orientados pelos negócios no sentido de que viabilizam recursos específicos de negócios, necessários à obtenção das vantagens. Por exemplo a capacidade de processar 100 mil pedidos de clientes por hora é um recurso orientado pelos negócios que afeta diretamente um grande número de decisões técnicas de projeto. Esse princípio mantém uma correlação direta entre as vantagens com que o patrocinador está contando e as decisões de projeto que serão tomadas. Dessa forma, o princípio acima torna a migração não apenas mais direta, mas também protege o caso comercial em que ela se baseou no início.

Essas exigências podem ser implícitas se um único aplicativo existente for migrado. Mas como as mudanças dos negócios são, freqüentemente, o impulso das migrações, até mesmo requisitos aparentemente evidentes precisam ser explicitados.

Escopo preciso

A ampliação do escopo é um fenômeno conhecido pelos que fornecem soluções de TI e pelos que pagam por elas e as patrocinam. A causa principal dessa ampliação é uma compreensão inicial imprecisa do problema de negócios que está sendo tratado. Definir o escopo de uma migração pode parecer um processo comparativamente simples, especialmente se o objeto da migração for um único aplicativo existente. Infelizmente, há muitos fatores capazes de mudar o escopo original pretendido:

  • O orçamento disponível pode restringir o escopo ao que pode ser aquém do ideal.

  • Dependências entre aplicativos podem exigir a ampliação do escopo para dar conta de interfaces e, até mesmo, de outros subsistemas de aplicativos.

  • As expectativas das partes interessadas podem levar à ampliação do escopo se algumas delas acharem que não estão obtendo vantagens suficientes em troca do seu apoio e da sua contribuição ativa. Além disso, ao planejar um projeto de grande porte como uma migração, algumas partes interessadas podem demonstrar interesse apenas como uma oportunidade de atender a necessidades em aberto que não apóiam a migração em si.

Embora o escopo possa evoluir em relação ao início da migração, uma empresa não deve adotar uma estratégia de migração sem um escopo bem definido.

Estratégias de migração

Quatro estratégias principais estão à disposição para a migração do UNIX. Os fatores decisivos ao escolher a estratégia adequada são a compreensão do escopo do projeto de migração, os recursos e as qualificações afetados e necessários, as metas de curto e longo prazo da empresa, e o nível de complexidade e compromisso envolvido na implementação da estratégia. Antes de iniciar uma migração, recomendamos que se compreendam totalmente os interesses que impulsionam a migração a partir das informações coletadas.

Embora as quatro estratégias estejam relacionadas individualmente no texto a seguir, algumas delas podem ser necessárias de uma só vez para que os resultados desejados sejam atingidos. Por exemplo, no caso de migrações iniciadas com um escopo em nível de negócios ou de aplicativos, nas quais o aplicativo migrado consiste em vários componentes diferentes, pode ser empregada mais de uma estratégia.

É necessário muito cuidado ao selecionar os aplicativos que devem ser migrados. É necessário determinar antecipadamente se apenas um aplicativo será migrado ou se todos os aplicativos serão migrados, e quais aplicativos específicos é mais importante migrar. Por exemplo, os motivos para a migração de aplicativos podem ser uma combinação de redução ou eliminação de custos, além da necessidade de modernizar os recursos.

Uma AVA (Avaliação de Valor de Aplicativos) é recomendada para ajudar a escolher e confirmar os aplicativos candidatos à migração. Por exemplo, um aplicativo de "valor menor" apresenta menor risco de falha e, normalmente, é migrado mais rapidamente, mas seus benefícios para a empresa também são menores. Entretanto, um aplicativo de "maior valor" apresenta maior risco de falha e, geralmente, é mais complexo; portanto, sua migração é mais demorada, mas gera um retorno maior sobre o investimento. A AVA está além do escopo deste livro, mas é um serviço prestado por muitas empresas de consultoria e suportado por vários pacotes de software de análise de portfólio.

Interoperação: Transferência de parte de um aplicativo

A interoperação envolve a transferência de um ou mais componentes de um aplicativo para a plataforma Windows. Por exemplo, uma situação pode ser transferir componentes executáveis, mas manter um banco de dados compartilhado com outros aplicativos no sistema UNIX. Componentes de aplicativos, tais como fluxos de trabalho de emissão de relatórios, impressão de grandes volumes ou consultas somente leitura podem ser separados do restante do aplicativo e migrados individualmente.

Muitas vezes, a interoperação é o primeiro passo dado por uma empresa na migração de um aplicativo, pois isso atenua os custos e os riscos. Entretanto, essa estratégia talvez não gere um nível suficiente de vantagens proporcional ao investimento exigido, em comparação com outras estratégias disponíveis que reduzem a necessidade do UNIX.

Migração de código: Transferindo um aplicativo inteiro

A migração de código envolve a recompilação ou a conversão do código-fonte do aplicativo para a nova plataforma. Ao usar essa técnica, é importante decidir se os erros existentes no código serão migrados ou se eles serão corrigidos na nova compilação do código.

Essa estratégia é um processo amplo e complexo que pode ser facilmente subestimado devido ao grande número de diferentes componentes técnicos que devem ser migrados. A recompilação do código talvez não atenda adequadamente às necessidades dos processos de negócios alterados, os quais podem ser o verdadeiro benefício do novo aplicativo.

Substituição: Adotando um novo aplicativo do Windows

A estratégia de substituição aproveita a disponibilidade de versões relativamente econômicas para Windows de muitos pacotes de software disponíveis comercialmente. O aplicativo antigo é retirado de operação e as suas funções são substituídas pelo aplicativo do Windows recém-adotado. Os problemas dessa estratégia se concentram na adaptação dos processos de negócios aos recursos dos novos aplicativos, que pouco provavelmente serão exatamente os mesmos que os do aplicativo antigo.

Evolução: Começando a desenvolver aplicativos no ambiente Windows

A estratégia de evolução defende o uso do aplicativo existente como especificação funcional de base e, em seguida, a recriação do aplicativo através de linguagens de programação e ferramentas modernas. Nesse caso, o desafio é manter os aplicativos e a infra-estrutura existentes de acordo com a necessidade e, ao mesmo tempo, criar novos aplicativos e uma nova infra-estrutura. Essa pode ser uma estratégia eficaz quando um novo aplicativo importante for necessário, sem que seja necessário eliminar o aplicativo antigo.

Ambiente de produção Windows

Estabelecer um ambiente de produção é um passo importante na migração para a plataforma Windows. É necessário levar em conta como o ambiente de produção Windows Server deve ser projetado, quais funções de produção devem ser estabelecidas, e quais processos precisam estar à disposição. Vários recursos diferentes são colocados à disposição pela Microsoft e seus parceiros com informações sobre os seguintes assuntos:

  • WSSRA (Arquitetura de Referência do Sistema Windows Server). Orientação arquitetônica com configurações certificadas específicas estabelecidas pelos fornecedores de hardware e software para o Windows Server.

  • Microsoft Frameworks. O MSF (Microsoft Solutions Framework) é uma abordagem de planejamento, criação e implantação de soluções tecnológicas; e o MOF (Microsoft Operations Framework) possui processos para operações de produção baseados no internacionalmente reconhecido conjunto de práticas recomendadas da ITIL (Biblioteca de Infra-Estrutura de Tecnologia da Informação).

  • UMPG (Guia de Projeto de Migração do UNIX). Orientação de processos de projetos de migração com base nos conceitos básicos do MSF.

WSSRA (Arquitetura de Referência do Windows Server System) – Antiga MSA (Microsoft Systems Architecture)

A WSSRA é um conjunto de documentos que orienta as empresas na implantação de tecnologias da Microsoft em todos os estágios do ciclo de vida de implementação de TI. A orientação oferece uma estrutura arquitetônica testada e aprovada em laboratório com importantes parceiros de hardware e software.

O uso geral da documentação auxilia as empresas que estão desenvolvendo abordagens padronizadas para a infra-estrutura de tecnologia. Esta abordagem de arquitetura resolverá muitos problemas típicos de nível empresarial que surgem quando há um crescimento não estruturado, fragmentado e sem padrões. O uso detalhado da documentação nas áreas de projeto, criação, teste e operação é uma abordagem tática para solucionar problemas de implementação ou simplesmente aproveitar as orientações de práticas recomendadas a fim de reduzir tempo, risco e custo na implementação.

Para obter mais informações sobre a WSSRA, consulte:
http://www.microsoft.com/technet/itsolutions/
techguide/wssra/raguide/default.mspx
(em inglês)

O ciclo de vida de TI e as estruturas da Microsoft

Em qualquer empresa, os serviços de TI e os aplicativos e a infra-estrutura que oferecem suporte a esses serviços têm um ciclo de vida limitado. Esse ciclo pode ser dividido em três conjuntos principais de atividades:

  • Compreender as necessidades operacionais e de negócios do serviço e criar uma solução que os disponibilize dentro dos limites especificados.

  • Implantar a solução de maneira eficiente e eficaz para os usuários com a menor interrupção possível dos negócios, conforme especificam os níveis de serviço.

  • Operar a solução com competência para prestar um serviço em que a empresa confie.

A Microsoft oferece orientações e pacotes de implementação para o emprego eficiente das tecnologias da Microsoft em toda a gama do ciclo de vida da TI. Essas orientações são agrupadas em duas estruturas — MSF (Microsoft Solutions Framework) e MOF (Microsoft Operations Framework). A MSF trata do primeiro conjunto de atividades, ou seja, analisar a necessidade e criar uma solução de alto valor; a MSF e a MOF coordenam processos e atividades para implantar a solução no segundo conjunto; e a MOF trata do último conjunto de atividades até que a solução seja colocada fora de serviço. A MOF também incorpora e estende um grande número de orientações já colocadas à disposição por outras organizações de normas de TI existentes e em desenvolvimento.

O ciclo de vida da TI e a interação da MSF e da MOF em todo o ciclo são ilustrados no seguinte gráfico.

IMSEPU01.gif


Ver a imagem no tamanho normal

O desenvolvimento e a implantação de uma solução de TI normalmente envolvem duas equipes de TI. A equipe de projeto é reunida por um período limitado para planejar, criar e implantar a solução. A MSF é uma maneira flexível e escalonável de planejar, projetar, desenvolver e implantar soluções de TI bem-sucedidas. A orientação da MSF consiste em princípios, modelos e disciplinas de gerenciamento das pessoas, dos processos, dos elementos tecnológicos, dos riscos e das concessões existentes na maioria dos projetos.

Especificamente, o Modelo de Processos da MSF estabelece uma série de tarefa reunidas em cinco seções, ou “fases” distintas; Prever, Planejar, Desenvolver, Estabilizar e Implantar.

IMSEPU02.gif


Ver a imagem no tamanho normal

Por outro lado, a equipe de operações é permanente, sendo responsável pelas operações e pelo gerenciamento da solução no dia-a-dia. O MOF foi criado para orientar as equipes de operações. Oferece orientações técnicas permitindo que as empresas obtenham confiabilidade, disponibilidade, flexibilidade de suporte e gerenciamento para sistemas de missão crítica de soluções de TI criadas com produtos e tecnologias da Microsoft. As orientações da MOF tratam os aspectos de pessoas, processos, tecnologias e gerenciamento referentes à operação de ambientes de TI complexos, distribuídos e heterogêneos.

As duas estruturas são complementares, reduzindo o time to value — ou seja, o tempo entre o reconhecimento da necessidade e a prestação do serviço. A uniformidade terminológica e conceitual entre as duas estruturas também oferece suporte à prestação de um serviço de alta qualidade.

Além disso, as duas estruturas são bem integradas. Por exemplo, a implantação de uma solução de TI exige o conhecimento das necessidades da solução e o controle dos usuários, além das necessidades do sistema para operá-la. O MSF e o MOF oferecem orientações para as funções e os processos das equipes, que garantem uma implantação bem-sucedida no ambiente de produção. Em todo o desenvolvimento, o MSF e o MOF enfatizam a instituição de processos para assegurar que a solução, ou que qualquer alteração no ambiente de TI, seja criada de maneira a ser fácil de operar e suportar, além de assegurar o atendimento às necessidades do lançamento.

As orientações do MOF baseiam-se no conhecimento direto e na experiência da Microsoft, dos seus parceiros e dos seus consultores na operação diária de ambientes de TI de grande e pequeno porte, além da execução de projetos de desenvolvimento de software e serviços de TI. A Microsoft também incorpora e se alinha com padrões reconhecidos do ramo de TI em todo o mundo, muitas vezes melhorando e ampliando padrões genéricos para facilitar o seu uso nos ambientes operacionais Windows.  

Para obter mais informações sobre o MSF, consulte:
http://www.microsoft.com/technet/itsolutions/
techguide/msf/default.mspx

Para obter mais informações sobre o MOF, consulte:
http://www.microsoft.com/technet/itsolutions/
techguide/mof/default.mspx

Orientações para projetos de migração

O UMPG (Guia de Projetos de Migração do UNIX) apresenta uma estrutura geral para a migração de aplicativos, bancos de dados e infra-estruturas de um ambiente UNIX para um ambiente Microsoft Windows. O UMPG é um assistente para os guias de soluções de migração, contendo orientações técnicas específicas para projetos.

O UMPG é organizado de maneira seqüencial no nível mais genérico para representar os estágios do ciclo de vida da TI: planejamento, criação e implantação. No nível seguinte, o guia de projetos de migração é estruturado de maneira a seguir o Modelo de Processos do MSF para projetos de TI.

Para obter mais informações sobre o UMPG, consulte:
http://www.microsoft.com/technet/itsolutions/
migration/unix/umpg/default.mspx

Links relacionados

Download

Veja a Introdução à Microsoft Enterprise Platform para profissionais de UNIX

Notificações de atualização

Inscreva-se para receber informações sobre atualizações e novas versões

Comentários

Envie seus comentários ou suas sugestões


Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft