Os quatro estágios da arquitetura de TI

O ano era 1999. Abordar potenciais falhas relacionadas ao ano 2000 - o bug do milênio - em todos os sistemas de computador consumia a atenção de TI na State Street, líder mundial em serviços financeiros para investidores institucionais. Apesar da gigante de serviços financeiros estar extremamente focada em garantir que “00” fosse interpretado como 2000 ao invés de 1900, David Saul, gerente de software de sistemas e líder em correção de bugs do ano 2000, percebeu algo mais. Todos os projetos estavam interligados. Para assegurar que nenhuma mudança envolvendo Y2K na aplicação “A” trouxesse problemas para a aplicação “B”, a equipe de projeto precisava entender a relação entre as aplicações e todos os seus inputs e outputs.
As aplicações da State Street usam dados de referência para processar transações com valores mobiliários (moeda, Bolsa de Valores onde a transação é realizada etc.). Tendo em vista que estes dados permeiam todas as aplicações, fazia sentido para a equipe de Saul lidar com eles independentemente das aplicações financeiras específicas que os exploravam. Na época, a maioria das aplicações lidava com seus próprios dados de referência, ao invés de se apoiar em um serviço comum distinto. A State Street reconheceu o valor dos serviços comuns e montou um escritório de arquitetura (que Saul dirige desde então) para criar o ambiente arquitetural para eles. “Nada mais natural que o fornecimento de dados de referência sob a forma de serviço evoluísse para as atuais arquiteturas orientadas a serviços (service-oriented architectures – SOA)”, diz Saul.
A abordagem SOA alinha diretamente serviços de dados e software com processos de negócio para que serviços específicos possam ser reutilizados e mesclados conforme a necessidade.  Assim, as empresas reduzem os custos de desenvolvimento de tecnologia e aperfeiçoam a capacidade de oferecer serviços novos ou aprimorados para clientes e parceiros de supply chain.
Tudo muito bom. Mas, mesmo que sua empresa precise realmente de SOA, talvez você não esteja preparado para implantá-la. Foi a conclusão a que chegaram dois estudos recentes do MIT Sloan Center for Information Systems Research (CISR), “Arquitetura de TI como Estratégia” e “Escolhas Estratégicas Norteadas por TI”, ambos baseados em uma série de projetos de pesquisa envolvendo 456 empresas entre 1995 e 2006. A pesquisa do CISR identificou quatro estágios arquiteturais distintos: silos, TI padronizada, processos de negócio padronizados e modularidade do negócio — que tanto as unidades de negócio quanto TI precisam percorrer para usufruir plenamente os benefícios de SOA. E ninguém pode pular nenhum estágio. Na melhor das hipóteses, o processo pode ser acelerado. Para os pesquisadores do CISR, a conclusão foi inesperada. “Mas, quando contamos para as pessoas, elas retrucam que é por isso que não está dando tão certo”, revelou a pesquisadora-chefe Jeanne W. Ross.
Considerando-se que a vasta maioria das empresas se encontra no primeiro ou no segundo estágio (e, repito, não podem queimar etapas), vai levar anos, décadas talvez, para que SOA seja ampla e eficazmente adotada, prevê Ross.
A pesquisa do CISR proporciona um road map que o negócio e TI podem seguir para evitar desvios improdutivos, não desanimar no longo percurso e entender o que é o sucesso quando ele finalmente for alcançado. Felizmente, observa Ross, cada estágio tem seus próprios benefícios, com retornos de curto prazo sobre o investimento arquitetural de longo prazo.
Cada estágio tem cerca de cinco anos de duração, explica Ross, mas este período pode diminuir à medida que mais empresas passem pelo processo e aprendam quais erros devem ser evitados. “Sete anos atrás não havia práticas arquiteturais nas empresas de pesquisa”, diz Saul, da State Street. As empresas de hoje não precisam tatear tanto o caminho. A boa notícia, de acordo com Ross, é que seus concorrentes provavelmente – ou quase – atingiram o mesmo nível de maturidade arquitetural que você e também não podem pular nenhum estágio. Os que tentam podem desperdiçar tempo e esforço ao implantar processos de negócio e infra-estruturas de TI sem estarem preparados para usá-los.
Ao invés de tentar dar grandes saltos, Ross sugere que os CIOs se unam ao resto da empresa para promover um avanço incremental, ganhando conhecimento, conquistando adesão e colhendo o ROI que irá sustentar a maturidade no longo prazo. Ross acredita que ter em mente o framework de maturidade arquitetural durante esta evolução dá aos CIOs e seus pares na área de negócio uma maneira de avaliar se estão progredindo realmente,.

O frenesi SOA
Hoje, os CIOs não podem mais ignorar SOA. As empresas de pesquisa e as publicações de negócio alardeiam sua capacidade de tornar as corporações ágeis e eficientes. Os fornecedores utilizam este rótulo, muitas vezes enganosamente, para ajudar a vender seus produtos. Para onde quer que se voltem, os CIOs ouvem a mesma mensagem: você tem que implementar SOA rapidamente ou ficará em desvantagem competitiva.
Na realidade, SOA apresenta vantagens ainda que você não se encontre no estágio em que, segundo o CISR, é possível usufruir todos os benefícios desta abordagem. “Mesmo que você implemente tecnologia baseada em SOA antes de sua organização estar preparada, pode obter um sistema de integração mais eficiente na área de TI”, afirma Ron Schmelzer, analista sênior da ZapThink, empresa de consultoria sobre SOA. “A implementação de conceitos SOA, ainda que de maneira limitada como a criação de web services, também ajuda a produzir um vocabulário comum para que os grupos de negócio e TI comecem a caminhar na mesma direção”, enfatiza Judith Hurwitz, CEO da empresa de consultoria Hurwitz & Associates.