Por que uma abordagem de “design para operações” é essencial para TI baseada em serviços?

News Article -- Setembro 29, 2020

Para entregar resultados em transformação digital e melhorar a performance dos negócios, algumas corporações estão adotando uma abordagem de “design para operações” para desenvolver e entregar softwares. Com “design para operações”, queremos dizer que o software é projetado para rodar continuamente, com atualizações frequentes que podem ser feitas em escala. A abordagem leva em consideração não apenas os custos iniciais de desenvolvimento, mas também os custos para manutenção de ponta-a-ponta e entrega do software. Ela é baseada na aplicação da automação inteligente em escala e conexão com as necessidades dos clientes, que estão sempre mudando para uma infraestrutura automatizada de TI. DevOps é o conjunto de práticas que fazem isto, ativado pelos pipelines de software que suportam Entrega Contínua.

O desafio: design para operações

Produtos e serviços passam por vários estágios de evolução do design:

• design para propósito (o produto serve para uma função específica)
• design para fabricação (o produto pode ser produzido em massa)
• design para operações (o produto engloba o uso recorrente e o ciclo de vida completo dele)

Os automóveis são um bom exemplo disso: da carruagem sem cavalos de Daimler até o modelo T da Ford e, finalmente, ao Toyota Prius. Incluir o plano de serviço significa que o fabricante insere os custos de manutenção do carro depois que ele é comprado. Assim, o é responsável agora pelo ciclo de vida de ponta-a-ponta do carro. A tecnologia da informação não é diferente — de antigos computadores decodificadores, como o Colossus, até softwares empacotados, como a Oracle, e até mesmo serviços baseados em software, como a Netflix.

O ponto-chave é que empresas de serviços baseados em software, como a Netflix, descobriram que têm responsabilidade sobre o custo de ponta-a-ponta na entrega de seus softwares e têm otimizado seu trabalho de acordo com isso ao usar as práticas de DevOps.

Alguns resultados só podem ser conquistados com software desenhado para operações. Isto significa que empresas que rodam software sob medida (desenhado para propósito) e software empacotado (desenhado para fabricação) têm um gap de maturidade, onde a responsabilidade é maior que o valor. Se esse gap é fechado, a entrega pode ser melhor, mais rápida e mais barata (sem precisar escolher só duas opções).

É essencial fechar esse gap porque se os competidores podem entregar melhor, mais rápido e mais barato, isso os coloca em vantagem. Isto inclui até o setor público, já que os departamentos governamentais, agências e autoridades locais estão sob pressão para entregar serviços de melhor qualidade aos cidadãos, com um menor impacto nos impostos.

A razão pela qual “desviamos para a esquerda”

Um resultado típico da abordagem de design para propósito é que requisitos funcionais (o que o software deve fazer) têm prioridade sobre requisitos não-funcionais (segurança, compliance, usabilidade e manutenção). Como resultado, itens como segurança só são levados em conta mais tarde. Em muitos casos, essa falta de funcionalidade começa a se acumular como débito técnico - isto é, decisões que podem parecer convenientes no curto prazo se tornam custosas a longo prazo.

O conceito de “desviar para a esquerda” é sobre se certificar de que todos os requisitos estão inclusos no processo de design desde o início. Pense na linha do tempo de um projeto e “mova para a esquerda” os itens nela, como segurança e testagem, para que aconteçam mais cedo. Na prática, isso não precisa significar muito trabalho de desenvolvimento extra, já que escolhas cuidadosas de plataformas e frameworks podem garantir que aspectos como a segurança estejam desde o começo.

Um bom exemplo de práticas de desenvolvimento contemporâneas que dão embasamento a isto é manifestado quando perguntamos “Como sabemos que este aplicativo está performando como esperado no ambiente de produção?”. Isto é muito mais do que “Funciona?” e leva ao questionamento “Como pode não funcionar, e como saberemos?”.

As corporações precisam adotar um modelo de “design para operações”, que inclua uma abordagem compreensiva para a automação inteligente que combine analytics, técnicas enxutas e capacidades de automação. Este modo de operar produz insights, velocidade e eficiência melhores e permite que soluções baseadas em serviços estejam operacionais no primeiro dia.

Sobre o autor

Chris Swan é DXC Fellow, vice presidente e Chief Technology Officer para Global Delivery na DXC Technology. Lidera a mudança para o design para operações que englobam as famílias de ofertas e o uso de dados para impulsionar a otimização da transformação do cliente e da plenitude de serviço. Já atuou como CTO da empresa para Global Infrastructure Services e General Manager para x86 e Distributed Compute. Antes disso, ocupou funções de CTO e diretor de R&D na Cohesive Networks, UBS, Capital SCF e Credit Suisse, onde trabalhou em servers de app, grades de computação, segurança, mobile, nuvem, rede e contêineres. Veja o blog de Chris e suas observações no InfoQ. Siga-o no Twitter: @cpswan