Quanto mais a tecnologia se espalha pela empresa, mais crítica a TI se torna – e portanto, aumentam também os riscos que essa dependência traz

*Por Ricardo Stucchi

Com a diversidade de soluções, aplicativos, dispositivos e outros itens conectados à rede corporativa, o termo “arquitetura de sistemas” ficou insuficiente. Há quem fale em “arquitetura de soluções”; outros, em “arquitetura de TI”. Porém, mais importante que cravar novas expressões, é entender por que continuar pensando “da maneira antiga” pode gerar lacunas importantes na estrutura tecnológica da empresa.

 O ponto de partida é o nível de especialização demandado hoje. Cabe aqui uma analogia com a medicina: até poucos anos atrás, havia um ortopedista que “dava conta” do corpo todo quando o problema era de ordem osteomuscular. Hoje, porém, essa área da medicina evoluiu tanto que há médicos específicos para patologias específicas de cada parte da nossa anatomia – se você já precisou de um ortopedista especializado em joelho (ou pé, mão, coluna lombar, coluna cervical, etc), sabe exatamente do que estou falando.

 Algo semelhante acontece com a tecnologia: há soluções cada vez mais especializadas e elas, por sua vez, são acopladas a outras plataformas. Só que, até bem pouco tempo atrás, não havia a preocupação – ou tecnologia disponível – para criar aplicações que “conversassem” entre si. O resultado são legados isolados ou com integrações insuficientes e muitas vezes inseguras. O cenário mudou, com uma cultura de integração estimulada por novas tecnologias e principalmente pela grande adoção de soluções por assinatura – afinal, para que o modelo as a service seja viável, suas aplicações precisam se “encaixar” ao que já está em operação na empresa.

 Pensar antes de arquitetar

Uma boa arquitetura deve ter vida longa. É razoável pensar em pelo menos 10 anos de vida útil para grandes componentes, que demandam maiores investimentos e tempo de implantação, e 3 a 5 anos para aqueles menos complexos. Para se chegar a esse resultado, a escolha precisa ser exaustivamente estudada – o que nem sempre acontece. O mais comum é que uma boa dose de pressa norteie as decisões.

A afobação é suicida: escolher em poucos dias o desenho de uma estrutura que deve durar anos é uma imprudência comparável a comprar um imóvel  contando apenas com o anúncio da imobiliária. Por vezes, bastariam algumas poucas semanas a mais de estudos, pesquisas, eventualmente consultorias e análises para chegar a uma decisão mais assertiva.

 Bons exemplos são a implantação de ERPs, CRMs, bancos de dados, soluções de analytics. Substituí-las é caro e complicado. As chances de conviver por anos com as consequências de uma má decisão são enormes. É preciso olhar, em cada solução, as camadas de integração que ela oferece.

 Essa necessidade de se antecipar ao futuro e entender a integração entre tecnologias de diferentes naturezas é o que torna o conceito de “arquitetura de sistemas” insuficiente para o modelo atual. Hoje, o guarda-chuva que abriga as soluções precisa ser amplo, e a TI tem que entender que nem tudo que estiver debaixo dele vai estar 100% sob seu controle.

 Por isso prefiro o termo “arquitetura de soluções”. Embora ainda possa ser questionável, tem a vantagem de tirar o foco do sistema, orientando um pensamento para um ecossistema onde novas soluções podem se enraizar e frutificar sem causar danos ao ambiente como um todo.

Reputação não é tudo

As discussões sobre uma nova arquitetura não devem ser feitas somente do ponto de vista técnico. Em uma conversa com lideranças, é preciso orientar os argumentos para o resultado estimado de determinadas escolhas – incluindo financeiro e operacional, por exemplo.

Com esse embasamento, fica mais fácil entender, por exemplo, que nem sempre a “melhor” solução é a mais indicada. Ser referência em determinado mercado não é sinônimo de adequação a todo e qualquer tipo de negócio. Orientar-se pela reputação, pelo status ou mesmo pelo hype do fornecedor não é uma atitude das mais inteligentes. Parece óbvio, mas fica claro que o óbvio é frequentemente deixado de lado quando surge – geralmente do do Conselho – a pergunta: “por que ninguém pensou nisso?”.

O único modo de evitar que essa incômoda questão se torne uma constante é apontar e registrar as obviedades antes da tomada de decisão.

 Esse backlog do processo decisivo deve ser revistado até o último minuto, e mesmo após a escolha ser feita, deve ser revisitado. Apostar na prática não só diminui os riscos de um equívoco oneroso como também é essencial para apontar que a decisão errada não ocorreu necessariamente na TI.

 “Surpresas previsíveis”

Ambientes complexos precisam ser gerenciados. O que vemos, porém, é a complexidade aumentando e a governança se perdendo. Claro que mesmo o melhor dos planejamentos está sujeito a imprevistos e problemas dos mais variados tipos, mas não faz sentido ser surpreendido por situações previsíveis.

 Ao montar uma arquitetura, as integrações são um elemento tão previsível quanto a chuva em um grande festival. Essa verdade é ignorada pela falta de governança e pela juniorização das equipes de TI – o que às vezes ocorre até mesmo na média gestão.  É aqui que a experiência e a senioridade mostram muito explicitamente o seu valor.

 Romper o ciclo vicioso de pressa, pensamento defasado e atuação imatura é possível. Para tanto, essa maturidade precisa ser cultivada dentro da própria organização. A mudança do paradigma da “arquitetura de sistemas” é um ótimo pretexto para iniciar essa jornada.