IT Forum 365
Aplicações sempre atualizadas são mito ou realidade?

Aplicações sempre atualizadas são mito ou realidade?

O ambiente corporativo está mudando em um ritmo cada vez mais frenético e as áreas de negócios esperam que o departamento de TI adapte seus aplicativos na mesma velocidade. Como isso nem sempre é possível, não é incomum ver outras áreas adquirindo soluções sem autorização da tecnologia da informação, o que coloca em risco toda a infraestrutura da empresa. Fica a dúvida: é possível que as aplicações estejam sempre atualizadas sem muito esforço, no conceito conhecido como “evergreen”?

Nem todos os aplicativos têm os mesmos ciclos de atualização

Antes de tudo, vamos olhar para o portfólio de aplicativos. Nem todos têm os mesmos ciclos de atualização. Alguns, na verdade, precisam não mudar. O consultor norte-americano Geoffrey Moore propôs a divisão das soluções em dois grupos: “Sistemas de Registros” e “Sistemas de Engajamento”. Adiciono o conceito de “Sistemas de Mudança”:

  1. Sistemas de registro:  são aqueles como o ERP (Enterprise Resource Planning), voltados para a gestão da empresa: além de finanças, estão os de manufatura, CRM (Costumer Relationship Management) e gestão de pessoas. Eles têm de ser “corretos” e “integrados” para todos os dados serem consistentes e, historicamente, foram concebidos para serem preenchidos, independentemente da escolha dos usuários. É ideal que sejam estáveis, uma vez que registram a história da empresa, e têm suas versões atualizadas somente quando necessário, o que muitas vezes ocorre uma ou duas vezes por ano. Em diversas indústrias, inclusive, passam por normas regulatórias e de certificação, o que engessa ainda mais as atualizações.

  2. Sistemas de engajamento: são voltados diretamente aos funcionários para “usos envolventes” – como e-mail, sistemas de colaboração, redes sociais e soluções de aprendizagem. A necessidade de adaptar o sistema caminha conforme as transformações do mercado e de projetos, então, as atualizações são constantes. Pode-se argumentar que a ferramenta de e-mail deve ser adaptada com menos frequência do que os sistemas de colaboração, e isso provavelmente é verdade, mas, mesmo assim, há mudanças com recorrência semanal a mensal.

  3. Sistemas de mudança: cada vez mais o software faz parte dos produtos e serviços disponíveis no mercado. O mundo rapidamente se torna digital e, ao longo do último ano, várias empresas fizeram experimentos em todas as áreas. Departamentos de marketing criam variações de suas interações com clientes, separando-os em grupos para identificar qual oferece os melhores resultados de negócios; e, em sua busca de apps adequados para a Internet das Coisas, departamentos de P&D (Pesquisa e Desenvolvimento) experimentam formas de entregar experiência ao usuário. Esses são apenas alguns exemplos de como as novas tecnologias e a tendência de se tornar digital mudam a forma como as companhias fazem negócios e buscam oportunidades. A capacidade de adaptação rápida é muito importante para lidar com novos desafios e entregar ideias. Nesses casos, então, é preciso lidar com várias mudanças diariamente.

Se pensarmos que os departamentos de TI são adaptados para lidar as atualizações exigidas pelos estáticos sistemas de registro, é fácil concluir que são incapazes de responder às exigências dos outros dois, que são, exatamente, os que demandam novas abordagens com mais recorrência. Tudo precisa acontecer muito mais rápido, e isso inclui o tempo gasto do desenvolvimento à implantação. A questão é: como?

Crie uma cultura colaborativa

Os desenvolvedores de software devem ser apaixonados, curiosos e criativos, enquanto os funcionários de operações devem ser analíticos, solucionadores de problemas, focados e orientados. Ter os dois trabalhando em conjunto nem sempre é fácil devido às diferenças de ponto de vista, mas a colaboração é fundamental para reduzir drasticamente o ciclo de desenvolvimento.

A metodologia Agile estimula essa interação, integrando programação e testes. Agora precisamos estender isso para as equipes de operações. Existem três caminhos que descrevem os valores e filosofias que guiam processos e práticas de DevOps (termo para Desenvolvedor e Operações, metodologia de desenvolvimento de software que explora a comunicação, colaboração e integração entre desenvolvedores de programas e profissionais de TI):

  1. O primeiro caminho envolve o fluxo de trabalho em blocos, passando do desenvolvimento a operações de TI, e está focado em reduzir desperdícios no processo. Para maximizar os fluxos, é necessário produzir em pequenos lotes com intervalos – e defeitos nunca podem ser passados para frente. Isso demanda desenvolvimento, integração e implantação contínuas. É aqui que entram automação e o conceito de Lean, para redução de perdas no desenvolvimento.

  2. O segundo caminho abrange o feedback rápido em todas as fases da cadeia, evitando que problemas aconteçam novamente ou permitindo sua rápida detecção e recuperação. Aqui o sistema Kanban, uso de sinalizações na linha de produção para controlar o fluxo, desempenha um papel importante. É preciso parar o processo quando algo falha e se concentrar na correção do problema antes de reiniciar as atividades.

  3. O terceiro caminho implica a criação de uma cultura de fomento à experimentação contínua, o que exige assumir riscos e aprender com o sucesso e fracasso, entendendo que a repetição e prática são os pré-requisitos para a maestria. Tudo gira em volta da melhoria contínua.

Todos as três vias estão interligadas. É importante repassar o ciclo de desenvolvimento atual e, a cada passo, perguntar se essa etapa é realmente necessária.

Automatizar e padronizar
Quantas vezes os desenvolvedores reinventam a roda, ou recriam algo em outro lugar na organização? Muitas. Parte do retrabalho se justifica pelo “não foi inventado aqui”, mas outra grande amostra está relacionado com a falta de saber o que existe no resto da empresa. A comunicação e governança devem ser claras para todos. Para isso, é importante definir normas e ter um comitê decidindo sobre a necessidade de criação de padrões. Se um desenvolvedor precisa de algo novo, recorre ao órgão de administração para explicar a necessidade. Esse processo normalmente elimina 90% das requisições.

Também é possível automatizar a implantação e teste para os ciclos se tornarem mais curtos. Um colega de nossa equipe de software me relatou um exemplo: eles programavam de segunda-feira a quinta-feira e passavam a sexta-feira preparando a compilação e executando testes, para que, na próxima segunda-feira, soubessem o que tinha de ser corrigido.

É possível ter aplicações “evergreen”?

Acredito que destruir a barreira desenvolvimento/operação é uma base sólida para garantir a viabilidade das aplicações atualizadas de maneira constante e sem esforço, no conceito evergreen. Isso requer uma mudança cultural, uma boa compreensão de todo o processo e colaboração entre as partes.

Leia o artigo na íntegra, em inglês

http://h30507.www3.hp.com/t5/Cloud-Source-Blog/Evergreen-Applications-A-Myth-or-Reality/ba-p/183781

Comentários

Notícias Relacionadas

IT Mídia S.A.

Copyright 2016 IT Mídia S.A. Todos os direitos reservados.