Este artigo foi publicado pela primeira vez na revista IEEE Software e é aqui disponibilizado através de uma parceira entre o InfoQ e a IEEE Computer Society.
Como arquitetos, queremos que nossa arquitetura seja relevante. Queremos que os projetos implementem nossos grandiosos designs, um pequeno passo de cada vez, com cada pedaço se encaixando perfeitamente dentro do grande quebra-cabeças que é a arquitetura de software. Queremos alcançar os desenvolvedores em toda a empresa e fazê-los usar um determinado software de banco de dados ou servidor web. Tudo com o objetivo de que o código seja de fácil manutenção e siga princípios sólidos de design arquitetural.
Mas a realidade é mais complicada. Na Statoil, empresa norueguesa de petróleo na qual trabalham os autores, costumávamos manter portais de arquitetura sofisticados, contendo muitos modelos e designs complexos. Mas descobrimos que ninguém lia o que escrevíamos ou fazia o que dizíamos. Com o tempo, isso levou a despesas adicionais, conforme nos esforçávamos para manter múltiplos ecossistemas de servidores web, ecossistemas de middleware e muito mais. Há alguns anos, a empresa aumentou seu foco em gestão de compliance (cumprimento de normas), após alguns acidentes, e implementou um "sistema de gestão corporativo". Esta nova abordagem, visando comunicar todos os diferentes requisitos que a Statoil enfrenta em suas operações, trouxe uma oportunidade de ouro para aumentar o conhecimento sobre nossa arquitetura e estender seu impacto.
Voltar à prancheta?
A maioria das grandes empresas tem um departamento de TI, e a Statoil não é exceção. Nossa organização de TI compreende mais de mil funcionários, terceiros e consultores espalhados pelo mundo; todos precisam das ferramentas de TI adequadas para o trabalho que realizam. Em uma grande empresa como essa, não podemos depender de relações pessoais para alcançar todos os envolvidos com a arquitetura (analistas de negócio, desenvolvedores de software, gerentes de TI, operadores de infraestrutura, e mais); em vez disso temos que confiar em outros meios de comunicação.
A abordagem tradicional para este problema é criar um documento de arquitetura de software ou, mais recentemente, um portal de arquitetura que os interessados possam consultar. Devido à grande importância em se ter uma arquitetura de software de qualidade, queríamos um link na primeira página do portal corporativo na intranet, de fácil acesso a que todos os interessados. Nós "descobrimos" que, em uma empresa petrolífera, a TI não é considerada parte do núcleo dos negócios; então nosso belo portal de arquitetura ficou escondido; e por mais que trabalhássemos com a organização da TI, a equipe raramente o consultava. Pior, quando consultavam, tinham problemas para entender os documentos e ver a relevância das informações para seu próprio trabalho.
Após algumas situações indesejadas quase acontecerem, a gerência decidiu aumentar o foco em compliance corporativo para fazer cumprir todos os diferentes requisitos que a Statoil enfrenta em suas operações. Esse esforço foi dirigido de cima para baixo, com metas claras e expectativas passadas do CEO para o vice-presidente executivo, vice-presidente, gerentes, e todos os indivíduos trabalhando ao redor do mundo.
Naquele momento, esses requisitos eram encontrados no sistema de gestão corporativo na forma de milhares de documentos detalhando tudo, da construção submarina de poços de petróleo até a segurança de TI. Era esperado que os empregados e terceiros da Statoil conhecessem o material, mas os documentos se provaram difíceis de ler e entender. Além disso, frequentemente se contradiziam, confundindo os leitores sobre quais requisitos eram válidos.
Organização
Para enfrentar os desafios do sistema de gestão corporativa, a Statoil decidiu organizar as exigências de acordo com os processos de trabalho, seguindo o princípio de que "usamos a organização para organizar as pessoas, e os processos de trabalho para organizar o trabalho". Para todo trabalho repetido regularmente, foi desenvolvido um processo e designado um dono para mantê-lo e garantir que continue atualizado.
Os donos dos processos ficam responsáveis por garantir melhores práticas adequadas incluindo ferramentas de TI, e todos os donos de processos têm uma equipe para ajudá-los a desenvolver melhores práticas e requisitos para suas respectivas áreas de processos. Depois que esses processos foram desenvolvidos, todos os documentos antigos do sistema de gestão foram quebrados em requisitos individuais e atribuídos para atividades de processo relevantes. Durante o curso deste trabalho, requisitos foram também simplificados e ajustados para um nível de detalhe adequado.
Dentro da TI, temos o nosso próprio dono de processo (que é também o CIO) e desenvolvemos um conjunto de processos descrevendo como o trabalho de TI deve ser realizado na Statoil. A Figura 1 mostra um exemplo:
Figura 1. Exemplo de processo de trabalho da área de TI, indicando em que eventos se inicia o processo, quais papéis são envolvidos, quais atividades devem ser realizadas e quando o processo termina. Junto a cada atividade estão seus requisitos e melhores práticas, fácil ao leitor saber exatamente o que é esperado.
Dado o foco de gestão em compliance, a empresa gasta uma quantidade significativa de recursos em treinamentos e garante que o conteúdo do sistema de gestão esteja atualizado. A Statoil também gasta muitos dos recursos no próprio sistema de gestão para tornar fácil encontrar as informações necessárias.
Novos recursos e benefícios
Uma característica importante no nosso novo sistema de gestão é a possibilidade de definir áreas específicas onde é válido um processo ou requisito específico. Essas áreas de validação podem ser baseadas na organização, geografia, papel ou uma combinação de todos esses. Quando um leitor navega no sistema de gestão, o sistema considera a unidade organizacional, a localização e o papel do usuário, para com isso exibir apenas os processos e requisitos relevantes, escondendo requisitos não-aplicáveis que podem confundir o leitor.
Como arquitetos de software, vimos imediatamente o potencial no sistema de gestão para comunicar arquiteturas. Os recursos de personalização significam que podemos mostrar aos desenvolvedores SAP as arquiteturas e os requisitos relevantes para o desenvolvimento SAP, além de mostrar aos desenvolvedores Java as arquiteturas e os requisitos de relevância para o desenvolvimento em Java (veja a Figura 2). Graças à implementação do sistema de gestão, foi possível divulgar a arquitetura para a empresa com muito menos esforço e muito mais impacto, em comparação à tradicional abordagem orientada a documentos. Arquiteturas e requisitos estão agora disponíveis ao alcance do desenvolvedor, tornando-se relevantes graças aos recursos de personalização incorporados ao sistema.
Figura 2. Diferentes requisitos para diferentes leitores: (a) uma atividade do sistema de gestão na forma que é exibida para um desenvolvedor SAP; (b) a mesma atividade mostrada para um desenvolvedor Java. Pelo fato de somente mostrar requisitos relevantes ao leitor, o leitor fica ciente do que exatamente é esperado.
Após alguns anos, estamos começando a ver os efeitos de usar o sistema de gestão corporativo para comunicar requisitos de arquitetura. Ao desenvolver padrões e requisitos corporativos, pudemos reduzir o número de plataformas de banco de dados em uso, assim como a forma que são usadas. Hoje, nosso departamento de operações de banco de dados lida com dez vezes mais servidores de bancos de dados, se comparado com dez anos atrás, e o número está crescendo a uma constante de 15% por ano. Entretanto, ainda temos o mesmo número de pessoas que tínhamos há 10 anos, e não há planos para mais contratações. Percebemos o mesmo tipo de efeito em outras partes do departamento de TI, como infraestrutura de rede, plataformas de servidores web, software de integração, e mais.
Outro efeito observável é que nossa estabilidade em aplicações e infraestrutura cresceu, e se tornou tão boa que grandes indisponibilidades raramente acontecem. Ao olhar para o futuro, percebemos que a TI está se tornando mais importante para as operações da Statoil. Muito poucos dos nossos processos (se houver) podem funcionar por muito tempo sem o suporte de TI, e está se tornando fundamental manter as aplicações e infraestrutura funcionando 24 horas por dia, 365 dias por ano, para suportar a empresa. É nesse ponto em que o sistema de gestão se torna uma ferramenta poderosa, para comunicar os requisitos necessários para um portfólio de TI com alta disponibilidade.
A lição mais importante que aprendemos é que, para a arquitetura ser relevante, temos que levá-la a todos os interessados; não podemos esperar que os interessados nos procurem. Somente ao tornar os requisitos de arquitetura parte integrante do trabalho diário de toda a TI, conseguimos atingir mais pessoas e tornar a arquitetura mais relevante; muito mais do que se tivéssemos usado os tradicionais portais ou documentos de arquitetura. Mesmo se a sua organização não tem um sistema de gestão similar, pode-se atingir mais interessados e se causar mais impacto ao usar qualquer sistema de gestão que já se tenha, ao invés de implementar algo fora das práticas existentes.
Sobre os autores
Harald Wesenberg é desenvolvedor de software com mais de 15 anos de experiência no desenvolvimento de aplicações corporativas de missão crítica, para a indústria de petróleo e gás. É arquiteto de soluções corporativas da Statoil, uma empresa petrolífera global e uma das Fortune 100; frequentemente faz apresentações e escreve sobre suas experiências em conferências ao redor do mundo.
Einar Landre é profissional de software com 25 anos de experiência como desenvolvedor, arquiteto, gerente, consultor e autor/palestrante. Trabalha como gerente de linha na Statoil.
Este artigo foi publicado pela primeira vez na revista IEEE Software. A missão da IEEE Software é construir uma comunidade de líderes e futuros profissionais de software. A revista fornece informações inovadoras, confiáveis e úteis sobre desenvolvimento de software para manter engenheiros e gerentes lado a lado com as rápidas mudanças tecnológicas.