Quanto mais as coisas permanecem iguais, mais elas mudam. Não é exatamente assim que diz o ditado, mas é a frase que deve ser gravada em cada porta que leva a TI. Certamente é melhor do que “Abandone toda esperança, vocês que entram aqui”.
Não mudou muita coisa desde os nossos primeiros dias, quando a TI era a EDP e os programadores eram os sumos sacerdotes da casa de vidro.
Exceto por tudo. Felizmente, muito da sabedoria fundamental dos primórdios da TI ainda se aplica, apenas em um aspecto diferente e modernizado. Aqui estão 11 princípios da velha escola que irão guiá-lo através da TI de próxima geração e as diferenças fundamentais nas maneiras como você deve aplicá-los.
A tecnologia que você compra é um compromisso de longo prazo de sua parte. Você precisa que seja um compromisso de longo prazo por parte do fornecedor também.
Para jogar pelo seguro, a TI costumava comprar de grandes fornecedores. Agora? Não apenas o open code pode ser tão seguro, como às vezes você pode obtê-lo da IBM ou de outros grandes fornecedores.
Nem toda tecnologia de open code tem uma base de suporte ampla o suficiente, mas muitas têm. Se o PHP, por exemplo, fizesse o trabalho, você examinaria o Java duas vezes devido ao seu péssimo histórico de segurança? E ainda assim o Java é suportado (talvez “fornecido” seja mais preciso) pela Oracle, uma das maiores empresas de software do mundo.
Isso também não é inteiramente novo. Afinal, a biblioteca SHARE, de open code, data da década de 1970.
Sempre mantivemos o hardware trancado, limitando o acesso ao data center a um pequeno número de crachás de funcionários e mantendo registros automatizados de quem entra e quando. É que agora, nem todo cômodo trancado é nosso.
Especialmente para SMBs, existem alternativas, que vão desde instalações co-lo até nuvem completa.
Mas não embolse todas as economias de não construir seu próprio data center. Invista um pouco em uma conexão de rede de baixa latência e alta largura de banda para seu provedor externo. Melhor ainda: aplique outro princípio dos velhos tempos – nunca tenha apenas um de qualquer coisa. Faça essas duas conexões, com pontos de presença em lados opostos do seu edifício, para que uma enxada traseira não possa derrubar seu negócio cavando um buraco em um local inoportuno.
Antigamente, frustrar as ameaças à segurança significava principalmente cronometrar as sessões do CICS para que os hackers não pudessem discar e herdá-las. Em seguida, vieram PCs, sistemas distribuídos, a Internet e muitas outras ameaças. Respondemos bloqueando desktops e protegendo o perímetro com firewalls cada vez mais sofisticados.
Muitos ainda pensam que a melhor contramedida é bloquear tudo e não deixar ninguém ser criativo. Mas as empresas vivem e morrem de inovação, e inovação significa mais do que novos produtos para vender. Significa pensamento criativo e a implementação desse pensamento em todos os setores da empresa.
Hoje em dia, devemos gastar mais tempo protegendo os ativos do que o perímetro, e ainda mais tempo apoiando ativamente os usuários, porque a maior ameaça é uma força de trabalho que não tem permissão para inovar.
Os testes de regressão e estresse separam os profissionais dos amadores. Sempre fizeram isso e ainda fazem. O teste de regressão garante que novos itens não quebrem os antigos. O teste de estresse garante que tudo funcionará bem o suficiente quando todos começarem a se esforçar.
A TI, sendo profissional, mantinha pelo menos três ambientes – desenvolvimento, teste e produção. Isso significava comprar três de tudo. E mantê-los também. Ai!
Agora, mesmo quando você mantém seu próprio data center, criar um ambiente de teste na nuvem geralmente faz mais sentido, porque você só precisa pagar por ele enquanto precisa dele. Dependendo do seu ambiente de produção, ele também pode funcionar muito bem para testes de regressão.
Teste de estresse? Ainda não. Muitas variáveis, pelo menos por enquanto.
Já passamos muito dos dias em que os desenvolvedores podiam simplesmente colocar seu novo código em produção. Há um processo a ser seguido. Ninguém realmente gosta do processo, mas não se trata de gostar do processo. É sobre garantir que a mudança não interrompa a produção e, se interromper a produção, é sobre como garantir que haja um plano de recuo.
Acha que a nuvem muda as coisas? É verdade. Isso torna o controle de mudanças mais difícil porque agora, se você não tiver cuidado sobre como você gerencia seus provedores de nuvem, eles simplesmente podem colocar suas mudanças em produção sem passar pelo seu processo.
Afinal, é a infraestrutura deles.
Muito antes de as metodologias de desenvolvimento formal esgotarem a diversão da TI, os gerentes de negócios costumavam perambular e perguntar: “Você pode fazer com que o computador faça isso?” O programador tentaria algo, mostraria para o usuário empresarial e eles tentariam até que ficasse certo.
Eles não chamam isso de agile. Eles chamaram isso de “ter uma conversa sobre o que o computador deve fazer”, mas era agile, mesmo assim.
Então surgiram as metodologias em cascata. Elas também funcionariam… se os gerentes de negócios pudessem imaginar perfeitamente um sistema de trabalho completo e descrevê-lo com precisão. Mas eles não podem, então perdemos 30 anos de produtividade.
Entra o Scrum, que exige iteração e interação, e adiciona metodologia suficiente para drenar a maior parte da diversão de TI que outras versões do agile colocaram de volta.
Antes de os negócios serem qualquer outra coisa, eles são coleções de relacionamentos. Com bons relacionamentos, tudo pode funcionar. Sem eles, nada pode.
Na época em que as empresas eram hierarquias rígidas, o CIO gerenciava os relacionamentos com os outros executivos importantes e isso era o suficiente. Se os outros executivos importantes não confiassem no CIO, a TI não teria sucesso. Era tão simples quanto isso.
Mas toda vez que qualquer membro do departamento de TI interage com qualquer outra pessoa na empresa, isso afeta o relacionamento entre negócios e TI. Não se trata apenas do CIO e de outros executivos. Se o resto da empresa não confiar na TI, ela não terá sucesso. Se isso acontecer, tudo sobre TI será mais fácil.
Não é fácil, mas é mais fácil.
Quando os humanos recodificaram as informações de relatórios gerados por computador em telas de entrada de dados, a TI percebeu que uma de suas responsabilidades mais importantes era integrar sistemas distintos para manter os dados sincronizados.
Portanto, ele construiu interfaces. Muitos deles. Todo ETL de lote personalizado.
Agora há tantos que é uma bagunça difícil de manter. Portanto, a TI inteligente investe em um barramento de serviço, ou algo semelhante, e projeta suas interfaces também, porque apenas empilhar uma em cima da outra significa que a tecnologia nova e brilhante recria o mesmo emaranhado de idade.
Hoje, muita TI está acontecendo fora do departamento de TI, principalmente na forma de SaaS trazido pelos gerentes de negócios como ilhas de automação. Eventualmente, eles se cansarão de ter sua equipe reinserindo dados nele. Esteja pronto para eles.
Tecnologia pela tecnologia é uma coisa ruim. Isso não significa que a TI deve limitar sua função ao processamento de ordens de serviço. Tem que ir muito além disso e fornecer liderança em tecnologia.
Qualquer departamento de TI que falhe em fornecer liderança em tecnologia – sugerir e discutir, não apenas aceitar e entregar – está falhando em um nível fundamental.
Liderança em tecnologia também significa apoiar gerentes e usuários que estão prontos para comprar ou construir sua própria tecnologia. É hora de reconhecer que “shadow IT” é uma coisa boa, porque aumenta a largura de banda de TI.
Claro, existem riscos. Tudo o que vale a pena fazer tem riscos.
A TI deve ajudar todos na empresa a ter sucesso com toda a sua tecnologia, não sufocar nada que “não foi inventado aqui”.
Projetos em cascata não falham porque têm planos organizados. Eles falham porque os projetos do mundo real são sempre exercícios de aprendizado contínuo, não progressões ordenadas de requisitos de alto nível a projetos detalhados.
O Agile lida com a realidade do aprendizado contínuo. Isso não significa que os líderes de negócios podem aprovar propostas de projetos que não fornecem estimativas de escopo, esforço e orçamento. Isso significa que eles têm que aceitar que a aprendizagem contínua significa que os planos não serão corrigidos e não devem ser corrigidos – eles serão e devem evoluir para se adequar ao entendimento em evolução da equipe da situação.
O que também acontecia em projetos em cascata de sucesso, mas sem todo o drama.
Quando os computadores eram novos e brilhantes, os executivos contavam com eles para impulsionar as mudanças em todos os lugares, tornando os processos de negócios mais rápidos e baratos, ao mesmo tempo reduzindo os erros manuais.
Isso durou até que a TI teve que oferecer suporte a tantos sistemas interconectados que fazer qualquer coisa nova era demorado, caro e arriscado. Sua confiança em metodologias de cascata também não ajudou.
Estamos finalmente nos libertando novamente. Entre ferramentas de integração melhores e ágeis e TI não relacionada à TI, a tecnologia da informação está começando a impulsionar a mudança novamente, em vez de acompanhá-la.
O IT Forum traz, semanalmente, os novos executivos e os principais anúncios de contratações, promoções e…
A Microsoft está enfrentando críticas após um relatório revelar um aumento alarmante em suas emissões…
O Grupo Centroflora é um fabricante de extratos botânicos, óleos essenciais e ativos isolados para…
Toda semana, o IT Forum reúne as oportunidades mais promissoras para quem está buscando expandir…
Um estudo divulgado na segunda-feira (13) pela Serasa Experian mostra que a preocupação com fraudes…
A Honeywell divulgou essa semana a sexta edição de seu Relatório de Ameaças USB de…