Os quatro estágios da arquitetura de TI

Mas, mesmo que você extraia alguns pontos positivos de uma implementação prematura de SOA, ressalta Jim McGrane, ex-CIO (atual VP) da fabricante de papéis MeadWestvaco, também pode deparar-se com pontos negativos. “Pôr uma interface de web services sobre um processo ruim apenas o torna mais visível”, diz McGrane. Entender por que a empresa ainda não está pronta para uma abordagem SOA completa ajudará o CIO a descobrir quais benefícios podem ser obtidos em relação à maturidade em que a organização se encontra no momento.

Estágio 1: dos silos à modularidade do negócio
Mesmo que não saibam, diz Ross, a maioria das empresas bem-sucedidas está atravessando os estágios de maturidade identificados na pesquisa do CISR. A maior parte das empresas se encontra no estágio 2: tecnologia padronizada. No decorrer da década de 90, ficou claro que o estágio 1 — silos de negócio com iniciativas de TI focadas em necessidades departamentais específicas — gerou overhead e requisitos de suporte excessivos. Tal nível de complexidade, que caracterizou os primórdios de TI, não foi capaz de sustentar o crescimento corporativo (sem mencionar o fato de que custou muito dinheiro). Isso levou a maioria das empresas a adotar tecnologias de plataforma-padrão onde era possível, utilizando apenas uma ou duas configurações de PC, uma tecnologia de banco de dados padrão para todos os departamentos ou o mesmo tipo de hardware e sistema operacional para todos os servidores.
O terceiro estágio -- processos de negócio padronizados – é onde estão hoje muitas empresas modernas. O negócio é visto holisticamente e os líderes de TI e negócio se consideram parceiros. O quarto estágio, no qual poucas empresas ingressaram até agora, é o de modularidade do negócio. Os processos de negócio e as tecnologias que o suportam se transformam em módulos que podem ser reutilizados para promover eficiência e recombinados para proporcionar agilidade — a promessa quintessencial de SOA. As organizações sabem quais processos devem ser restritos a unidades de negócio específicas e quais devem ser padronizados na corporação, com a arquitetura suportando o mix.
“Não é complicado passar do estágio 1 para o 2”, diz McGrane. Apesar de consumir muito esforço, nesta altura do campeonato os fornecedores, os consultores e a equipe de TI já conhecem as táticas e estratégias para a padronização bem-sucedida de uma plataforma. “Passar do estágio 2 ao 3 exige mudança organizacional e responsabilidade empresarial, o que é muito mais difícil.” A transição para o estágio 4 é ainda mais complexa, segundo McGrane. “Requer uma redefinição daquilo que você, como empresa, está fazendo.”
A evolução do estágio 1 para o 2 está a cargo, principalmente, do departamento de TI. O ROI prometido é redução de custos. A evolução para os estágios 3 e 4, entretanto, exige uma mudança de enfoque fundamental — o foco não é mais o modo como TI é capaz de satisfazer necessidades imediatas e definidas das unidades de negócio, e sim o desenvolvimento de processos de negócio que possam ser fornecidos através de serviços de TI modulares. O ROI prometido é agilidade empresarial. “A questão não é simplesmente gerenciar custos, mas transformar a empresa. Se o CEO e o CFO não entenderem isso, você está acabado”, alerta McGrane.

Estágio 2: sanidade da plataforma
No estágio 1, o CIO identifica facilmente a pressão para migrar de silos à plataformas padronizadas. O negócio reclama de custos de TI crescentes e cronogramas de entrega mais longos enquanto TI luta com a complexidade cada vez maior de todas as peças que precisa gerenciar e integrar. Mas padronizar a plataforma de uma empresa não é tão simples quanto pode parecer. O primeiro passo é decidir exatamente o que deve ser padronizado.
“Faz sentido padronizar no nível da rede, mas não em uma área de negócio específica”, explica Saul, da State Street. Uma rede de armazenamento e um sistema de e-mail comuns reduzem os custos e aprimoram o compartilhamento de informação. Mas operadores de ações talvez precisem de funções de aplicação diferentes dos operadores de derivativos, por exemplo, mesmo que muitas funções subjacentes, como gestão e relatório de clientes, sejam idênticas. “Hoje, nossa arquitetura corporativa é em camadas, começando com elementos como a rede, o hardware e os sistemas operacionais, e prosseguindo com middleware e bancos de dados, até alcançar as aplicações. As diferenças nas empresas podem ser muito sutis e restritas à camada de aplicação. A idéia é padronizar em torno de funções onde for possível, mas não no nível do negócio. Assim, os designers podem se concentrar em serviços de negócio que nos dão dianteira, ao mesmo tempo reutilizando componentes core”, diz Saul.