Home > Tendências

Os quatro estágios da arquitetura de TI

Estudo do MIT mapeia a evolução da arquitetura de TI e explica por que nenhuma etapa pode ser pulada

Galen Gruman

12/03/2007 às 20h06

Foto:

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.

++++

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.

++++

O passo seguinte é aprender a lidar com a transição dos sistemas existentes para os novos padrões. Você tem que migrar não só a tecnologia, mas também seus usuários. E, observa Saul, você está fadado a se confrontar com tecnologias não aderentes que estão executando, e bem, um trabalho importante. Para tratar destas questões, a State Street montou um comitê arquitetural no início do trabalho de padronização. Ao decidir prioridades de padronização, o comitê começou com os objetivos do negócio, garantindo que TI não padronizasse inadvertidamente uma tecnologia crítica para o negócio. A abordagem do comitê plantou as sementes da cooperação entre negócio e TI que seria necessária alguns anos depois, no estágio 3.
Um aspecto mais sutil da transição para o estágio 3 é o fator humano, de acordo com John Petrey, vice-presidente executivo e CIO da empresa de operações bancárias e financeiras TD Banknorth. No estágio 1, as empresas e seus funcionários estão focados (compreensivelmente) em resolver problemas individuais específicos. Para os solucionadores de problemas, a padronização de tecnologias pode significar perda de controle e talvez até de soluções ideais. “As pessoas demoram a perceber que é preciso compartilhar mais coisas para obter os benefícios que todo mundo busca”, aponta Petrey. Na verdade, esta mudança cultural ocorre aos poucos. “Você não acorda, um dia, e está em uma cultura diferente”, analisa Petrew.
As empresas também precisam de uma medida de resolução para obter êxito. Com freqüência, uma crise mostra com clareza por que a mudança é necessária. Outras vezes, os líderes da empresa possuem carisma, força ou personalidade para efetuar a mudança. Na TD Banknorth, Petrey implementou uma abordagem sem misericórdia para a padronização nas empresas adquiridas. “Nós tiramos e substituímos”, afirma. Assim, a heterogeneidade de plataforma não tem um pé de apoio na organização.

Estágio 3: hora da colaboração
Depois que uma organização padroniza suas plataformas, os processos de negócio e de TI são o próximo lugar lógico onde buscar eficiências. A fabricante de produtos químicos Celanese, por exemplo, economizou cerca de 40% dos custos de TI através de uma iniciativa de padronização e consolidação que consumiu quatro anos, recorda o CIO Karl Wachs. A empresa reuniu sete data centers em um e 13 sistemas ERP em um. A consolidação começou no estágio 2 como uma iniciativa de plataforma e foi concluída no estágio 3, quando a empresa conseguiu iniciar a padronização de processos de negócio necessária para administrar a empresa sobre um sistema ERP.
Entender processos de negócio o suficiente para padronizá-los não é tarefa pequena, na opinião de Wachs. Demanda colaboração intensa entre TI e o negócio. Mas o esforço ajuda ambos os grupos a entender que unidades de negócio diferentes utilizam muitos processos-chave iguais. “A unidade de produtos químicos básicos e as unidades de plásticos, por exemplo, operam de maneira diferente, com processos de vendas diferentes e, conseqüentemente, implementações de CRM diferentes”, diz Wachs. “Mas, na realidade, são variantes da mesma funcionalidade, o que nos permitiu colocar todas as funções no mesmo sistema e torná-las configuráveis para cada linha de negócio.”
Para fazer a análise profunda que permitirá este entendimento, você precisa de métricas contínuas, salienta Wachs. Sem elas, não pode garantir a governança apropriada de seus serviços, muito menos de seus processos de negócio. Schmelzer, da ZapThink, aponta que governança, neste caso, significa tanto as políticas para processos de negócio e de TI específicos quanto o sistema através do qual a empresa decide de que forma cria e implementa seus sistemas de negócio e de TI, como requisitos de análise arquitetural e prioridades de financiamento.
A transição do segundo para o terceiro estágio pode produzir benefícios sutis. Na TD Banknorth, as unidades de negócio precisavam de produtos mais sofisticados para competir. Isso exigia que TI aprimorasse continuamente suas habilidades e seus níveis de sofisticação. Ao mesmo tempo, pressões de custos exigem que o CIO forneça estas ferramentas mais sofisticadas com o mesmo nível de recursos. Esta pressão leva a uma abordagem de otimização, conduzindo a empresa ao terceiro estágio de arquitetura.

++++

É neste terceiro estágio que arquitetura começa a significar mais do que infra-estrutura de TI. Arquitetura de dados, governança de TI, otimização de processo Six Sigma e alinhamento entre negócio e TI se tornam aspectos críticos da arquitetura corporativa. O foco de TI muda: deixa de ser apenas o gerenciamento eficaz das instalações de tecnologia e passa a ser a contribuição para a excelência operacional do negócio. A eficiência continua importante, mas a meta não é mais economizar dinheiro reduzindo os custos, e sim liberar recursos para serem empregados no crescimento do negócio, segundo Petrey.
Ao entrar no estágio 3, a TD Banknorth começou a prestar muito mais atenção na arquitetura de dados, por exemplo. “Você precisa investir recursos expressivos para evoluí-la e planejá-la”, afirma Petrey. Isso envolve garantir definições de dados padrões para que múltiplos sistemas funcionem mais facilmente com os mesmos dados e os interpretem corretamente, e possam colher modelos que ajudem a servir melhor os clientes. A TD Banknorth designou membros da equipe de TI, que se entrincheiram nas linhas de negócio e agem como gerentes de relacionamento com seus colegas na empresa para assegurar o verdadeiro alinhamento de TI com o negócio.
Embora a TD Banknorth tenha padronizado suas plataformas de tecnologia, nem sempre impôs seus padrões arquiteturais sobre as aplicações que comprou ou criou. “O motivo foi o crescimento rápido, estávamos mais preocupados em trazer algo”, recorda Petrey. “Cometemos este pecado no passado e ele reduziu nossos níveis de serviço e interferiu na nossa capacidade de fazer a empresa progredir”, desabafa o executivo. Agora, Petrey está empenhado em fazer estes sistemas com desvio arquitetural encaixarem em sua nova arquitetura de TI para que a TD Banknorth possa continuar amadurecendo no estágio 4. A governança está mais rígida para que o problema não se repita.
O foco na arquitetura também cria as bases para futuros benefícios, acredita Joe Solfaro, diretor executivo de gestão de informação da Merck, fabricante de produtos farmacêuticos. Grande parte dos esforços de TI se concentra em padronizar plataformas, mas a empresa também está mapeando seus processos de negócio e sua arquitetura de dados para aumentar a agilidadel quando tiver uma plataforma mais eficaz em termos de custos. A Merck deu início a dois projetos distintos de padronização de dados há muitos anos, mas só recentemente contratou profissionais de arquitetura corporativa para desenvolver uma arquitetura de dados comum que esteasse a ambos. “Ainda que com diferenças táticas, os sistemas vão suportar a mesma direção estratégica”, diz Solfaro. Isso resulta em uma gestão de dados mais fácil, que acabará por suportar SOA completa no estágio 4.
Culturalmente, o estágio 3 requer que as equipes de TI e de negócio relaxem. “Você precisa deixar de ser tático. Tem que confiar a outros a tarefa de gerenciar os detalhes”, aconselha Petrey. Parte desta mudança acontece na transição do estágio 1 para o 2, mas no estágio 3 é mais difícil relaxar porque tipos de pessoas muito diferentes — TI e negócio— têm que depender umas das outras e confiar umas nas outras. E, assim como a migração do estágio 1 para o Estágio 2, a mudança para o estágio 3 acontece paulatinamente, à medida que a organização vê o ROI da nova abordagem e apóia a transformação.

Estágio 4: modularidade do negócio
Pouquíssimas empresas se encontram neste ponto. Não mais do que 6% das cerca de 450 empresas pesquisadas pelo CISR.
Os CIOs que estão na fase final do estágio 3 já podem vislumbrar como será o 4. De acordo com o CIO Wachs, algumas partes da Celanese passaram para o estágio 4, enfocando processos modulares que podem ser gerenciados facilmente em uma ampla arquitetura corporativa. “As empresas só são ágeis se conseguem ativar e desativar determinadas funções”, sustenta Wachs, e para tanto precisam entender que funções são essas, onde são utilizadas e o que elas afetam. Por sua vez, isso requer uma arquitetura projetada para flexibilidade e consistência.
A State Street também acredita que está no início do estágio 4. “Temos que melhorar os níveis de entendimento de processos de negócio e de comunicação do pessoal de TI”, reconhece Saul. “A linha que divide TI e negócio está desaparecendo e fica claro que alguém terá que gerenciar ambos.” Para algumas empresas, isso significa que TI poderá se tornar parte de uma iniciativa de serviços compartilhados. (Para conhecer melhor que tipo de função o CIO terá neste tipo de estrutura organizacional, leia o box “EA muda tudo”.)

++++

O que ainda não está muito claro é como será uma organização plenamente amadurecida no estágio 4, observa McGrane, da MeadWestvaco. “Estamos apenas começando a entender como usar TI para promover agilidade e virar o jogo versus aprimoramentos incrementais.” McGrane não está seguro de que tecnologias capacitadoras já existam realmente. De uma coisa, porém, ele tem certeza: “a empresa não pode passar para o estágio 4 sem ter atingido o 3, porque ele estabelece a orientação de processos necessária para que a empresa seja vista como módulos, conforme exige o último estágio”.

Um longo caminho
Embora seja tentador pensar em cada estágio como um lugar onde chegar, o mais correto é encará-lo como um processo transformador, com a corporação migrando gradualmente de um estágio para outro, define Ross, do CISR. O volume de mudança é imenso e, mais importante, as pessoas têm que mudar junto com a tecnologia. Os CIOs devem promover implementações incrementais e prometer valor incremental, tanto para suavizar o impacto da mudança quanto para alimentar o entusiasmo da gerência pela iniciativa, orienta Wachs, da Celanese.
Na verdade, tendo em vista o legado das fusões, os diferentes níveis de necessidade e de adesão do negócio e as forças externas como as regulamentações, é freqüente as empresas descobrirem que se encontram em estágios diferentes simultaneamente. Na Celanese, por exemplo, o sistema de RH continua no estágio 2 por causa de requisitos da folha de pagamentos, ao passo que outras partes da empresa já estão entrando no estágio 4.
Por maior que seja a pressão para aumentar a eficiência e a agilidade — “É pra ontem!” — as empresas, ao contrário de X-Men, não podem queimar etapas em sua evolução, alerta Ross, da CISR. Cada estágio prepara o terreno tecnológico, procedural, cultural e comportamental para o estágio seguinte. A impossibilidade de pular estágios é real até mesmo em empresas onde uma entidade está à frente das outras. Em 2002, McGrane achava que a Mead estava no estágio 3, mas aconteceu a fusão com a Westvaco, que se encontrava no estágio 1. No cargo de CIO da nova MeadWestvaco, McGrane teve que fazer a empresa recém-adquirida atravessar o estágio 2 antes de levá-la ao estágio 3. Agora, a organização unificada está perto de atingir um nível de maturidade uniforme.
As empresas também precisam entender que a arquitetura nunca estará concluída. “A idéia é sempre ajustar o serviço, não necessariamente a implementação: reunir dois serviços mais granulares em um serviço composto ou vice-versa, por exemplo”, diz Schmelzer, analista da ZapThink. Normalmente, os CIOs não contam com talentos para isso. Schmelzer recomenda que os CIOs tenham um arquiteto chefe ou uma equipe de arquitetura reportando a eles.
Não importa como uma empresa gerencia a evolução de sua arquitetura, ela precisa ter em mente que a recompensa é a jornada em si, aconselha Ross, da CISR. “O ponto final é muito menos importante do que o aprimoramento contínuo conquistado. Você tem que melhorar um pouquinho a cada dia. Não se trata simplesmente de chegar ao estágio 4.”

++++

Não há lugar melhor que o lar
O ideal é que as investidas em estágios de arquitetura mais amadurecidos tenham início no próprio departamento de TI. Assim, você pode testar abordagens, assegurar que elas funcionam e reduzir as chances de que algum passo em falso em uma unidade de negócio impeça a evolução, recomenda Jim McGrane, ex-CIO da MeadWestvaco. Estes esforços dentro de TI também dão aos CIOs a prova de conceito de que necessitam para conquistar a adesão do negócio. Além disso, começar com TI rebate uma queixa muito freqüente: os CIOs gostam de mudar os processos de todo mundo, menos os deles.
A Merck também está seguindo este caminho, de acordo com Joe Solfaro, diretor executivo de gestão de informação. “Vamos agir de dentro para fora”, revela. TI está usando uma plataforma de integração para unificar a arquitetura de mensagem da empresa, o que, a princípio, parecia um ganho de eficiência muito focado em tecnologia da informação. Mas a iniciativa está obrigando TI a mudar suas próprias operações internas e proporcionando uma interface natural com o negócio. “Colocar a informação em uma única base nos dá acesso a informação que nós sabemos que o negócio vai querer, como gestão de processos, e mais visibilidade dos processos de negócio”, diz Solfaro.
Abordagens como Capability Maturity Model for Integration (CMMI) e IT Infrastructure Library (ITIL) são bons métodos de processos que ajudam TI a migrar para o estágio 3, observam McGrane e Solfaro. “Ajudam a organização a focar em processos e obrigam você a determinar o valor de serviços e a operar como um negócio”, afirma McGrane.

++++

Mudanças na arquitetura transformam o papel do CIO
À medida que uma empresa evolui através dos diversos estágios de maturidade arquitetural, a função do CIO evolui junto, diz Jeanne W. Ross, pesquisadora-chefe do MIT Sloan Center for Information Systems Research. Nas empresas que estão no estágio 1, o trabalho do CIO é manter as instalações de tecnologia. No estágio 2, o CIO desempenha um papel mais estratégico: coordenar a transição para uma plataforma comum e seu impacto na empresa. “Às vezes, quando as organizações estão percorrendo o estágio 2, é observada uma estranha tendência a trazer alguém que não é de TI”, observa Ross. À proporção que a tecnologia se estabiliza no estágio 2, questões de processo vêm para o primeiro plano e um CIO focado em tecnologia talvez pareça menos capaz de lidar com elas, justifica Ron Schmelzer, analista sênior da ZapThink, empresa de consultoria sobre SOA.
A função do CIO começa a cruzar as fronteiras organizacionais na jornada para o estágio 3. Ironicamente, quando uma empresa ingressa no estágio 4 e os líderes de negócio ganham mais controle sobre a implementação de serviços de TI, a função do CIO, outra vez, pode se tornar mais tática, diz o ex-CIO e atual VP da MeadWestvaco, Jim McGrane. Ao detectar o início desta mudança na empresa, McGrane decidiu que não era este o trabalho que queria. (Em abril, ele deixou o cargo para se dedicar a outras áreas.) Mas a perda da dimensão política do cargo de CIO não é inevitável, argumenta Judith Hurwitz, CEO da empresa de consultoria Hurwitz & Associates. “Você pode focar em inovação porque as eficiências operacionais proporcionadas [por SOA] lhe dão este tempo.”
Quando as empresas atravessam os estágios de maturidade mais avançados, a área de TI também é afetada. “TI deve fazer parte de algo maior, como serviços compartilhados, operações ou finanças”, despindo-se de seu papel de mera fornecedora de tecnologia”, diz  Ross. Nesta evolução, o CIO se torna o chefe — ou líder — de uma operação mais ampla. A gigante de serviços financeiros State Street, por exemplo, promoveu a fusão entre TI e operações. Na Merck, fabricante de produtos farmacêuticos, TI passou a fazer parte de serviços compartilhados. Recentemente, o mesmo aconteceu na MeadWestvaco, fabricante de papéis.
Mas é a visão da empresa sobre as habilidades individuais do CIO que vai determinar realmente que função ele terá em uma organização no estágio 4. De acordo com Schmelzer, muitas empresas têm um vice-presidente de marketing e vendas, cargo que reúne duas funções muito diferentes. Outras empresas têm um executivo separado para cada atividade. A função de TI é ainda mais ampla, diz Schmelzer, combinando arquitetura, design, e integração e operações. Poucos CIOs serão fortes em todas as três áreas. Alguns serão fortes em apenas duas. A gerência talvez veja TI como uma função distinta ou um subconjunto de uma organização de serviços maior. Porém, independentemente da estrutura organizacional, o CIO precisa ser tão cônscio do negócio quanto da tecnologia.

O que muda no mundo pós-SOA
A arquitetura orientada a serviços veio para ficar e terá repercussões no mercado de software na próxima década e adiante

ABC do SOA
O que é a arquitetura orientada a serviços (SOA)? Você realmente precisa dela? Se precisar, quais são os primeiros passos para partir para o novo modelo?

SOA ganha espaço
O conceito de arquitetura orientada a serviços (SOA) despertou a atenção dos CIOs, conforme pesquisa realizada por CIO e COMPUTERWORLD

O momento da adoção de SOA
Estudo mostra que companhias priorizam áreas de missão crítica

Mudanças no coração da TI
Com a meta de estar mais preparada para atender às demandas de negócios, a área de TI da GVT não poupa esforços para se transformar com a arquitetura orientada a serviços

SOA, o segredo de uma estratégia
Grupo VR adapta-se ao conceito de arquitetura orientada a serviços com o objetivo de levar adiante aposta em parcerias e expandir seu mercado

O lego da infra-estrutura de TI
Inovar é uma questão de sobrevivência no mercado. As companhias precisam ser flexíveis, menos complexas e usar tecnologias que garantam menor custo de propriedade

SOA no caminho da maturidade
Para Rob Levy, CTO da BEA Systems, em até cinco anos a arquitetura orientada a serviços será algo natural no dia-a-dia das empresas. Por isso, este é o momento de sair na dianteira e conquistar uma fatia desse mercado.

 

Leia também as últimas notícias sobre o assunto:

SOA: Europa vê como redução de custo, EUA como agilidade aos negócios 

HP e SAP reforçam parceria em torno do SOA

Ci&T aposta em contratações para atender demanda em SOA 

Empresas fundam consórcio para promover SOA

 

Junte-se a nós e receba nossas melhores histórias de tecnologia. Newsletter Newsletter por e-mail