No mundo de TI, tudo que é realmente novo gera mudanças culturais. SOA propõe e depende muito de uma série de mudanças culturais. A forma como uma organização percebe e gerencia seus processos de negócio talvez seja uma das mudanças mais visíveis – mais claras. Mas existem outros tipos, relativamente menores, que também são críticos para o sucesso da iniciativa.
Alguns princípios que regem o gerenciamento de projetos, por exemplo, precisam ser revistos. Recentemente aconteceu uma boa discussão no grupo CMM-Brasil que envolveu, entre outras coisas, o balanceamento do ‘trio de ferro: Preço x Prazo x Escopo’. Resumindo: quem defende uma abordagem Ágil* diz que, após a negociação e contratação formal, o único item que deveria variar na equação acima é o escopo. Deveríamos eliminar algumas funcionalidades com o intuito de manter intactos o valor e o prazo inicialmente acordados.
De uma maneira geral, e não exclusivamente no caso de um programa SOA, a regra é questionável e polêmica. Agilidade combina com flexibilidade. E regras escritas em pedra não combinam com flexibilidade. Está aí um tipo de princípio que não deveria ser adotado no nível da organização. Alguns projetos podem exigir o total atendimento dos requisitos apresentados. Neste caso, clientes e usuários podem concordar com uma flexibilização dos preços e prazos apresentados. A negociação do(s) ponto(s) de variabilidade do ‘trio de ferro’ deveria fazer parte do acordo inicial, seja ele um contrato ou um convênio. Ao contrário do que foi dito naquela thread do grupo de discussão, não deixo de ser ágil porque concordei com a entrega de todas as funcionalidades requeridas por um cliente. Mesmo que isso signifique algum atraso em relação aos prazos acordados anteriormente.
Agora, quando se trata especificamente de uma iniciativa SOA, a fixação do escopo como o único fator variável do ‘trio de ferro’ pode ser um engano ainda mais nocivo. Um engano bastante comum que, segundo Todd Biske, deriva de uma mentalidade ‘schedule-driven’. Vou surrupiar seus argumentos:
Muitas organizações com as quais trabalho têm a tendência de ser ‘guiadas pelos cronogramas’ (schedule driven). Ou seja, o elemento menos flexível do projeto é o cronograma. Assim, a coisa que mais ‘sofre’ é o escopo. Infelizmente, não se trata do escopo propriamente dito e sim da diferença entre o caminho mais rápido (tático) versus o melhor caminho (estratégico). Se você está tentando implementar uma SOA, saiba que esse tipo de governança de TI tornará sua vida bem difícil. Você está premiando o sucesso do cronograma, não o sucesso da arquitetura.
Todd encerra dizendo que se trata de uma “grande mudança cultural”. É sim, particularmente onde impera o imediatismo. SOA deve, de alguma forma, ser vacinada contra esse mal. E isso não significa, de forma alguma, deixar de ser ágil.
