É hora de TI descentralizada?

O surgimento de um departamento de TI em muitas organizações nas décadas de 1980 e 1990 indicou que uma função tecnológica centralizada em toda a empresa era a forma “correta” de implantar e gerenciar a tecnologia na maioria das organizações. A tecnologia era geralmente cara e complexae a maioria dos trabalhadores desta época não cresceu usando tecnologia em sua vida cotidiana.

Em muitos casos, as caixas bege que caíram sobre as suas mesas eram um acréscimo indesejável ou mal tolerado. Certamente, seria melhor deixar seu funcionamento interno e o software nele contido para especialistas de outro departamento.

À medida que as novas gerações entraram no mercado de trabalho e trouxeram conhecimentos tecnológicos adicionais, as funções tecnológicas centralizadas na maioria das organizações continuaram. A aquisição de hardware beneficiou da centralização, enquanto a aquisição de conhecimentos especializados em desenvolvimento de aplicações permaneceu demasiado complexa e desafiante para a maioria das linhas de negócio.

Da mesma forma, uma ampla o impulso para a padronização estava em andamento na maioria das empresas. Os departamentos de TI tornaram-se “lojas Dell” ou “lojas Oracle”, utilizando um conjunto limitado de hardware e software para impulsionar a interoperabilidade e reduzir custos. Com o desenvolvimento e a manutenção de software sendo uma despesa tão significativa, um pequeno grupo de especialistas em um punhado de ferramentas facilitou a aquisição de novas ferramentas.

Mais recentemente, o desejo de padronização e redução de custos sustentou o argumento comercial da centralização. Áreas dispendiosas e complexas, como a segurança cibernética, beneficiam tanto tecnicamente da gestão centralizada como financeiramente. Muitos líderes de tecnologia também aplicaram essas suposições à sua abordagem de desenvolvimento de aplicativos, tentando reunir e gerenciar os tecnólogos da empresa para exercer controle sobre os padrões da empresa e reduzir custos.

APIs e gargalos: o caso da descentralização

Embora a redução de custos e a promoção de padrões comuns sejam empreendimentos nobres, a TI tornou-se um ponto de estrangulamento para a inovação em muitas organizações. Depois de ser informado de que a TI executaria com prazer sua solicitação para criar um novo aplicativo voltado para o cliente depois que o grupo apropriado resolvesse seu backlog de 18 meses, o líder de uma unidade de negócios com a qual trabalhei brincou que “É onde os sonhos vão morrer.”

Além disso, um dos maiores impulsionadores da tecnologia centralizada tornou-se essencialmente obsoleto. Durante anos, um pilar do argumento da centralização foi o facto de permitir a aplicação de padrões comuns sobre a forma como as aplicações eram desenvolvidas, que conjuntos de ferramentas eram utilizados e como eram suportados.

Este era um objetivo nobre numa época em que software e hardware raramente funcionavam juntos, mesmo quando adquiridos do mesmo fornecedor, e os esforços de integração eram caros e demorados. A ascensão das APIs RESTful eliminou em grande parte a preocupação com o software moderno, permitindo que aplicativos e serviços comunicar através de interfaces padrão independentemente da tecnologia subjacente.

Assim como qualquer coisa, desde um drone de consumo até uma ferramenta de diagnóstico industrial, pode ser conectada a um laptop por meio da agora onipresente porta USB, diversas tecnologias e aplicações podem interoperar por meio de uma interface comum.

Usando essa técnica, a TI não é mais uma guardiã do desenvolvimento de tecnologia e pode passar a assumir a função de consultor estratégico.

Catálogos de serviços centralizados, não gerenciamento centralizado

Talvez a inovação técnica mais significativa em empresas como a Amazon tenha sido a exploração desta interoperabilidade a um nível extremo. À medida que a Amazon crescia, os seus líderes tecnológicos contrariaram a tendência de padronização num conjunto limitado de fornecedores de tecnologia. Em vez disso, a empresa insistiu que qualquer nova tecnologia fornece uma coleção publicada de interfaces.

Inicialmente, esta decisão política permitiu que as unidades de negócios da Amazon tomassem suas próprias decisões técnicas, desde que fornecessem uma interface bem documentada e mantivessem essa interface à medida que ela evoluía. Em última análise, este foco está em interfaces padrão, em vez de tecnologia comum desenvolvida em Amazon Web Services.

Hoje em dia, as empresas não precisam ter sofisticação ou orçamento no nível da Amazon para se beneficiarem da construção de serviços de tecnologia com interfaces padrão. Essa mudança permite que unidades de negócios individuais projetem e implementem serviços que melhor atendam às suas necessidades de negócios, ao mesmo tempo que fornecem pontos de integração na organização maior.

Essas unidades podem adquirir competência técnica ou alavancar um parceiro e eliminar o trabalho caro de ter a TI selecionando, examinando e gerenciando todos os empreendimentos relacionados à tecnologia. O departamento de tecnologia corporativa pode continuar fornecendo todos os tipos de serviços, mas focando na integração oferece outras opções para unidades de negócios e coloca a TI no papel de facilitadora e guia, em vez de ser um gargalo.

A chave para o sucesso desta mudança é manter um catálogo centralizado dos serviços que existem em toda a organização. Afinal, você provavelmente não precisará que cada unidade de negócios desenvolva seus próprios serviços de gestão financeira ou permaneça completamente desconectado da organização como um todo. Fornece diretrizes para serviços internos e externos com foco em coisas como segurança, autenticação e validação.

Depois que um serviço é avaliado e publicado, a TI deve adicioná-lo a um catálogo de serviços prontamente acessível. Bem feito, este catálogo serve como um mercado de alguma forma, permitindo que qualquer pessoa na organização identifique e integre a tecnologia existente de maneiras novas e úteis. Por exemplo, se você fornecer um serviço padrão de status de pedido bem documentado em um catálogo, sua equipe de marketing poderá criar uma nova campanha interessante sem qualquer intervenção de TI, enquanto sua equipe de atendimento ao cliente poderá criar um novo aplicativo de “autoajuda” que usa dados do pedido.

Se você é uma organização menor, investindo seus escassos recursos no fornecimento de um catálogo de serviços e ajudando parceiros selecionados a criar novos serviços multiplica seu valor significativamente. Um desenvolvedor de software júnior provavelmente pode integrar um conjunto de serviços bem definidos em uma nova ferramenta útil muito mais rapidamente do que a melhor equipe do mundo pode começar do zero com coleta de requisitos, análise e construção de uma nova ferramenta.

Embora muitos líderes tecnológicos se considerem consultores, a mudança para design e construção descentralizados acelera o processo. A TI pode fazer a transição de uma organização que gerencia recursos escassos e de alta demanda para um shopping center de serviços pré-construídos e orientação especializada sobre como trabalhar com um parceiro interno ou externo para realizar o trabalho.

Se você gostou disso, não deixe de conferir nossos outros artigos sobre DevOps.

• Por que as empresas estão migrando para 'TI como serviço'
• O que seus desenvolvedores precisam saber antes de começarem a trabalhar com Kubernetes
• O que é engenharia de confiabilidade de sites e como ela pode impactar positivamente o DevOps?
• Como acelerar o desenvolvimento de software adotando a cultura DevOps
• A onda de MLOps (aprendizado de máquina e Devops)