Para conversar sobre arquitetura de sistemas, a liderança da empresa deve responder a uma pergunta: qual é o principal objetivo da TI? Ou, para que serve a TI? A maioria das respostas costuma ser genérica, e pode ser resumida em frases como: “TI é estratégico”, “garantir que as operações funcionem”. Isso é verdade, claro, mas a definição mais completa é construir, dar suporte e fazer evoluir uma arquitetura de sistema que não somente proporcionará um alto grau de automação dos processos de negócios (menor custo, maior eficiência) mas também suportará as ações estratégicas do negócio (sejam elas relacionadas a aquisições de empresas, ampliação do portfólio de produto, ampliação da cobertura geográfica, internacionalização, etc).
Toda empresa tem uma cadeia de valor, entendida como o conjunto de macroprocessos por meio dos quais a operação ocorre. Os principais processos são os que refletem o “core business”, outros desses macroprocessos são de apoio ao negócio (o backoffice), outros são mais estratégicos, como a inteligência de mercado e o relacionamento com stakeholders, por exemplo. A arquitetura é o conjunto de sistemas e suas integrações que automatizam essa cadeia de valor e esses processos. Com isso, permite que a empresa foque nas análises, na interpretação dos dados de inteligência e nas tomadas de decisão, em lugar de gastar tanta energia simplesmente para garantir que “as coisas andem”. O chamado “apagar incêndios”.
Ou seja, os sistemas são construídos para conferir velocidade, escala, inteligência e automação à empresa, assegurando que o quadro de pessoas será o mais otimizado possível, focado em competitividade, aumento das margens e atração de novos talentos. A arquitetura de sistemas, ainda em outras palavras, traduz o conceito de automação do negócio.
Nessa linha, o papel da TI é desenhar o conjunto de soluções (o modelo de arquitetura) que dará o melhor resultado. Isso significa entender como os macroprocessos (a cadeia de valor) estão sendo atendidos com os sistemas existentes — identificando lacunas, problemas de aderência funcional, obsolescência tecnológica, uso de planilhas, dependência inadequada de pessoas ou fornecedores e outros aspectos que dificultem as operações e a gestão do negócio.
A partir daí, é preciso ir além e analisar cada um dos componentes da arquitetura. Uma vez modelado o que precisa ser construído ou mantido, é hora de passar aos requisitos funcionais. E aqui recorro a um exemplo prático para tornar essa visão tangível.
Digamos que o objetivo seja construir uma arquitetura para suportar a logística. Isso requer entender muito bem o funcionamento dessa operação, os dados necessários ao seu bom andamento e as características dessa cadeia (por exemplo, regras específicas com cada cliente, tempos de atendimento, etc). A automação deve contemplar todas essas propriedades para que entregue ao negócio o que ele realmente necessita, e cabe à TI decidir se deve desenvolver algo específico para isso ou adquirir/adaptar uma solução que o mercado já oferece.
Quanto mais detalhada for a definição dos requisitos funcionais, mais assertiva será a análise do processo. Mas essa é apenas uma parte do trabalho, pois a logística, voltando ao nosso exemplo, consiste em apenas um macroprocesso entre os vários que a empresa opera. A verdadeira automação conquista-se ao identificar como cada processo “atravessa” os sistemas para ser executado, fazendo com que a integração se torne um elemento adicional fundamental. Ou seja, os processos determinam a arquitetura, e não o contrário.
Após escolhidas as soluções, aí sim haverá a necessidade da empresa adaptar-se às soluções escolhidas, evitando ou minimizando customizações.
Um caos conhecido
O fluxo de integração é o que fará a automação se concretizar. E fluxo, para seguir seu curso, requer menos transcrições, menos reconciliação, menos instâncias de validação. O desafio é entender o negócio a tal ponto que a TI consiga implantar sistemas que não requerem que o usuário lance mão de planilhas paralelas para completar suas atividades. A multiplicidade de planilhas denota uma arquitetura ineficaz.
A verdade é que poucas empresas se dedicam a parar em algum momento e pensar em sua arquitetura como um todo. A maioria acaba resolvendo os problemas à medida que eles aparecem, isoladamente. Uma área qualquer, que queira apurar melhor seus custos, por exemplo, solicita à TI um projeto para automatizar o pequeno conjunto de informações associado àquela operação. Só que, ao fazer isso de forma contínua, o resultado é um backlog de pedidos que não necessariamente forma a melhor arquitetura possível. A demanda é possivelmente legítima, mas a solução pontual de uma área pode estragar dois anos de trabalho na construção de uma arquitetura eficaz.
A TI deveria sempre pensar que um pedido afeta toda a arquitetura. Porém, se ela não tem um modelo de referência, a própria área de tecnologia não tem a dimensão real desse impacto. Por outro lado, se o modelo está bem estabelecido, ela consegue avaliar se o pedido faz sentido tecnicamente — e se é oportuno dedicar tempo e dinheiro a ele agora. É um trabalho de organização sistêmica, dentro do qual as solicitações individuais sempre devem ser discutidas em um contexto mais amplo.
Existe um elemento técnico adicional a isso, que é igualmente importante. Sobre qual infraestrutura tecnológica as operações vão rodar no futuro? Essa definição requer estabelecer uma série de requisitos a serem analisados, como as tendências do mercado, os custos, a obsolescência tecnológica de alguns sistemas. A investigação, então, continua: a infraestrutura será toda na nuvem ou híbrida? Os fornecedores e fabricantes que me atendem hoje vão continuar evoluindo tecnicamente? E assim por diante.
E, então, voltamos à questão do artigo: como explicar a relevância e o papel da arquitetura de sistemas para o negócio?
É preciso partir da visão abrangente (cadeia de valor, grau de aderência dos sistemas atuais, grau de automação existente) e mostrar onde existem oportunidades de ganhos para a empresa com maior automação e mais informações. Então, explicar o papel de cada componente da arquitetura e indicar como ele será aplicado — trata-se de novo sistema? De revitalização ou substituição de um sistema legado? De soluções de mercado ou proprietárias? Qual a estratégia de implantação dessa arquitetura? Quanto tempo levará? Qual será o investimento?
Mesmo reconhecendo que a dinâmica do mercado pode exigir intervenções pontuais nessa visão geral, é preciso demonstrar que um plano de arquitetura bem elaborado faz a diferença. Que o rompimento da arquitetura — por má governança das prioridades e o famoso “quem grita mais leva” — pode até gerar uma crise, como aumento de custos, contratos leoninos com fornecedores, dependência de pessoas para a realização de determinadas operações, entre outros problemas.
É um trabalho que exige maturidade — da TI e do negócio. As pressões por resultados e a instabilidade do mercado sempre provocarão oposição a um processo de planejamento que coloque as iniciativas em uma perspectiva mais longa — e, algumas vezes, será preciso ceder.
Se o negócio entender que uma arquitetura bem construída pode contribuir diretamente para os resultados e, além disso, colocar a empresa em prontidão para lidar com as instabilidades, talvez o jogo do “backlog” de tecnologia comece a mudar.
Leia mais: