finito

Tag: CIO

  • TI: Mente Sã e o Corpo na Nuvem

    TI: Mente Sã e o Corpo na Nuvem

    Terceira e última parte de uma pequena série não planejada. As anteriores foram “TI: O Início do Meio do Fim” e “TI: Começando de Novo“. Tentei me concentrar nas perguntas mais relevantes e neste artigo procurarei responder a principal: quem são as pessoas que formam a Nova Organização de TI?

    A lista de profecias da dupla Gartner/McKinsey comentada na primeira parte cravou que “não haverá mais espaço para o profissional eminentemente técnico. Quem quiser trilhar carreira técnica deverá trabalhar num fornecedor de tecnologia”. Será verdade? Será que um banco, seguradora ou varejista pode realmente abrir mão de desenvolvedores, administradores de bancos de dados e afins? Será que a codificação da inteligência do negócio pode ser 100% terceirizada?

    David P. Feeny e Leslie P. Willcocks, acadêmicos da Universidade de Oxford na Inglaterra, há tempos escreveram que não. Eles listam em O Que Não Terceirizar, artigo publicado na HSM Management¹, nove competências essenciais que toda empresa deveria manter internamente. Em todas há demanda, média ou grande, pelo que os autores chamaram de “aptidões técnicas”. Está além do escopo deste artigo um debate sobre todas as competências. Vou me ater ao que julgo essencial.

    Dependendo do modelo operacional e do ramo de atividade, uma organização pode ter algo entre 10% e 30% de processos de negócios onde ela realmente faz (ou tenta fazer) a diferença. Os chamarei de Processos Vitais. Como colocado no artigo anterior, todos os demais podem ser cozidos em um panelão ERP e periodicamente condicionados ao que o mercado convencionou chamar de melhores práticas. Não há o que (re)inventar aqui. Assim como não há justificativa para que uma organização siga torrando grana em algo que já deveria estar resolvido desde o final do século passado. Aquelas que seguem brigando com processos de apoio e processos básicos de gestão devem acionar o desconfiômetro. Sentiu um cheiro estranho? Xi, Brocotó²…

    A quantidade e a complexidade dos processos vitais determinarão o porte da organização de TI. Novamente, não há receita. Mas como eu gostaria de chutar que uma pequena equipe com 7±2 pessoas por família de processos é a ideal. Não nos percamos nas complicadas (e custosas) questões quantitativas. O que interessa aqui é a formação do time de TI. Quais competências são necessárias?

    Há quem cuide dos encanamentos para água e esgoto. Outro cuida da rede elétrica. Um olha a fundação enquanto outro ocupa-se do acabamento. Unindo a todos, um Arquiteto. Por que será que ainda é tão difícil pensar assim quando o assunto é TI? Lembra-se daquele (envergonhado) diagrama que traduzia a aparentemente indecifrável arquitetura corporativa? Bom, ele está aí do lado novamente. Não é factível supor que cada componente deste sanduíche teve um construtor diferente?

    Mesmo a arquitetura tecnológica quando 100% evaporada para a Nuvem. Porque a empresa ainda precisa ter um mínimo de inteligência para dimensionar recursos, projetar consumo e saber quando o fornecedor de nuvens está furando seus olhos. No mínimo!

    A arquitetura de informações precisa ser reconstruída. Pelo menos aquela que sustenta os processos vitais. Do ponto de vista tecnológico, não há camada mais defasada. Do ponto de vista do negócio, não há camada mais zoneada. Imaginar que fantásticos desenvolvedores e seus maravilhosos esquemas XML ou que os maravilhosos especialistas em BI e seus fantásticos cubos têm a resposta para a bagunça instalada depende de muita, mas muita boa vontade (e dose equivalente de ignorância).

    Quantos bons sonhos não serão inspirados pela possibilidade de se reescrever do zero a arquitetura de aplicações que suporta os processos vitais de uma empresa? Quantos excepcionais desenvolvedores não gostariam de participar de tão desafiadora empreitada? Vimos surgir, nos últimos dez anos, uma pancada de teorias que, de uma maneira ou de outra, pedem por essa coragem. SOA e BPM, assim – de mãos dadas, só fazem sentido quando amparadas em iniciativas de tamanha grandeza³. DCI, um novo, controverso e promissor padrão arquitetônico, idem. À parte a sopa de letrinhas, o fundamental é entender que as funções (serviços) oferecidas por um sistema devem apoiar a execução de processos de negócio. E que esse apoio só será realmente eficaz se ele entender (e medir e monitorar) os processos. Um por um, de ponta a ponta.

    Esse entendimento vem da cobertura que justifica e dá sentido à tudo – a arquitetura do negócio. E aqui surge outra grande pergunta: é TI quem a domina? Ou, colocando de outra maneira, é TI quem deve cuidar da arquitetura do negócio? NÃO! Se organizações de TI se meteram nisso foi porque: i) Tiveram muito senso de oportunidade e nenhum senso de ridículo; ou ii) Não souberam dizer “não, obrigado!” Embriagadas pela falsa impressão de poder, se meteram a inventar escritórios de processos, escritórios de análise de negócios e afin$. Como se os processos pudessem ser compreendidos e confinados em salas de 10m² ou em diagramas BPMN.

    Analistas de negócios e de processos deveriam estar alocados nas próprias áreas de negócios – onde a ação de fato acontece. Onde o conhecimento de verdade é criado e utilizado. Como ainda contam-se nos dedos as organizações orientadas por processos, esses analistas residiriam nos departamentos. E se estruturariam para representar as atividades e processos de negócios. Desta forma, seriam a interface natural para a comunicação entre as áreas de negócios e a organização de TI. Não um canal imposto por TI, mas apoiado e, em certa medida, orientado por ela. Como eu espero trabalhar esta sugestão de forma mais detalhada em futuros artigos, a encerrarei por aqui.

    Conclusão?

    Escrevi mais de uma vez que esta pequena série é pretensiosa demais. Mal resvalei nas diversas questões que aporrinham as organizações de TI. Mas fui sincero na urgência – não dá mais para esperar uma grande revisão da estrutura e processos de TI – e nas sugestões. Acredito que a economia gerada através de uma terceirização bem pensada seria mais do que suficiente para financiar a reconstrução dos sistemas que atendem aos processos vitais de uma organização. E, se por ventura não ficou claro, insisto: esta reconstrução não deveria ser terceirizada de maneira alguma.

    Ao atender com a devida atenção e seus melhores times os processos que de fato geram valor, a organização de TI se livrará dos questionamentos diários acerca de sua utilidade. TI, assim como um bom juiz de futebol, aparecerá menos. E agradecerá aos céus (e às nuvens) a graça de ser e ter uma mente sã.

     

    Notas

    1. O artigo também foi publicado em e-Business e Tecnologia – Autores e Conceitos Imprescindíveis (Coletânea HSM Management – Publifolha, 2001).
    2. “Xi, brocotó…” era o único diagnóstico do Urubulino, um dos diversos tipos inesquecíveis criados pelo grande Chico Anysio.
    3. Programação de férias, reembolso de despesas e registro de chamados foram alguns dos processos bestas que ajudaram a mostrar o valor de um tal Lotus Notes. Mais de uma década depois, estão sendo revistos em graciosos (e nada gratuitos) BPMS’s. Passa da hora de entender que tais “soluções” só serão levadas a sério quando toparem processos de negócio realmente sérios.
    4. A imagem utilizada, sem título, é uma pintura de Stan Dominguez.
  • TI: O Início do Meio do Fim

    TI: O Início do Meio do Fim

    Este artigo não estava em meus planos, assim como não estava o penúltimo. Aquele acidente gerou conversa boa a partir de sentimentos e colocações ruins. No fechamento daquele texto escrevi que “se a Análise de Negócios seguir submissa à TI, terá o mesmo triste fim“. A colega Cristina Belderrain interpretou que “o fim que aguarda TI é a passagem para a nuvem”. Não era o que eu sugeria. Confesso que, até a participação da Cris, não havia parado para pensar no “fim que aguarda TI”. Vou pensando enquanto escrevo – zeloso a la Veloso (ou não).

    Na resposta onde prometi este artigo eu conclui que “TI já acabou”. E que já faz um tempão! Claro, não estou falando da Tecnologia da Informação de maneira geral, e sim dos departamentos de TI nas empresas que têm outros fins. Saca só esta breve cronologia de matérias de capa de algumas publicações tupiniquins:

    • EXAME, 20/fev/2002: Tecnologia – Como Matar o Desperdício
    • Info Corporate, Jul-Ago/2003: O CEO não manja de Tecnologia?
      Como convencê-lo de que TI é essencial para o negócio
    • Info Corporate, Nov-Dez/2003: CIOs X Usuários: o que precisa mudar nessa histórica rixa
    • EXAME, 4/fev/2004: Tecnologia da Informação – Dá para se livrar dela?
    • Info Corporate, Set/2004: É o fim da TI como a conhecemos
      A área de tecnologia vai mudar para sobreviver. Como fica o CIO?
    • Info Corporate, Mai/2005: A tecnologia perdeu poder?
      Só 20% dos CIOs brasileiros se reportam ao presidente. O que isso significa?

    A Info Corporate não existe mais – e já foi tarde. A EXAME, quando fala de tecnologia, tem dois assuntos:  gadgets da moda e “bilionários” fenomenais, não necessariamente nesta ordem. Não devo ser o único que sente saudades dos artigos do Helio Gurovitz. Mas o que quero ilustrar é que… desistiram. Falar que TI não funciona – não entrega, deixou de ser novidade. Deixou de vender revistas, se é que um dia o fez. E, pelo visto, deixou de motivar soluções milagrosas. Faz tempo que não aparece uma sigla de três letras prometendo mais que político em período eleitoral, não?

    Lembrado pelo amigo Igor Couto, mostro ao lado a explicação do Jurgen Appelo para o estado atual das coisas. Seu alvo é o desenvolvedor de software, mas o modelo serve como uma luva para explicar como e porque os departamentos de TI chegaram onde estão.

    Perdão, mas vou resumir: falta de disciplina e de competência detonam a qualidade e a produtividade. Baixas qualidade e produtividade deixam clientes e usuários muito insatisfeitos, P’s da vida mesmo. O que aumenta a pressão que eles exercem sobre TI. Uma pressão que só faz erodir a motivação e, consequentemente¹, a produtividade.

    Assim, de tanto não entregar ou entregar soluções de péssima qualidade, TI perdeu o direito de dizer NÃO. Onde deveria haver motivação há medo, puro medo. Ciclo montado, circos incendiados diariamente em organizações dos mais diversos portes e ramos de atividades.

    Perdemos muito tempo correndo atrás de extintores e mangueiras. E, preciso dizer, a contratação de analistas de negócios foi só o uso de um extintor diferente. Ferramenta inútil em incêndios de grandes proporções.

    O CLD (Diagrama de Ciclos Causais) do Jurgen sugere três soluções de amplo espectro: Educação e, a partir dela, Competência e Disciplina. Nunca foi segredo para ninguém que qualidade e produtividade dependem desses fatores. Acontece que Educação é investimento de longo prazo. Pronto, consegui colocar em uma frase com oito palavras três termos aparentemente incompatíveis com muitas organizações de TI: Educação, Investimento e Longo Prazo.

    Se Tudo tem que Terminar Assim

    Que pelo menos seja até o fim, diz a letra do Herbert². As letras do Gartner e do McKinsey, traduzidas na Info Corporate de setembro de 2004, não alimentavam nenhuma esperança:

    • O departamento de informática como o conhecemos desaparecerá;
    • Algumas áreas de TI, como infraestrutura, vão mesmo virar commodities e serão inevitavelmente terceirizadas;
    • A TI deixará de ser uma área de suporte aos usuários para ser absorvida pelas próprias unidades de negócio;
    • Não haverá mais espaço para o profissional eminentemente técnico. Quem quiser trilhar carreira técnica deverá trabalhar num fornecedor de tecnologia;
    • Nesse cenário, o CIO tem dois caminhos a seguir: ou se torna um executivo de processos de negócios ou continua a gerenciar ativos de TI, tornando-se, assim, um ser em extinção.

    Dramática lista, não? Dramática, um tanto equivocada e, como este artigo até aqui, pouco construtiva. Não sei se tenho respostas (construtivas), mas meu balaio tá repleto de palpites:

    • A Nuvem não curará aplicações bugadas e mal integradas. Acima de uma inchada camada de commodities residem dados e sistemas que pedem, há tempos, por drásticas revisões. A mesma metralhadora do Gartner já havia sugerido, no final do século passado, uma interessante solução: aposente algo entre 3 e 5 sistemas legados por ano. O remédio pode ser amargo e caro, mas parece ser a única alternativa.
    • Serviços de manutenção de hardware, impressão, suporte ao uso de equipamentos e outros que não lidem nem dependam de conhecimentos do negócio já deveriam estar terceirizados desde mil novecentos e pedrinha. A Nuvem, se bem utilizada, pode tirar outros pesos das costas de TI. Desde que tal movimento não comprometa ainda mais os níveis de serviços atuais.
    • Cogitar que áreas de negócios assumam responsabilidades sobre a administração de TI é ingenuidade que ignora três fatores: i) as soluções que realmente interessam ao negócio suportam processos, não departamentos. A pulverização sugerida só faria aumentar o caos instalado, nada mais; ii) Pouquíssimas organizações possuem uma arquitetura de negócios que não dependa de um mínimo nível de integração e padronização; e iii) unidades de negócio têm suas responsabilidades bem determinadas. Não sei de nenhuma que faça sua própria contabilidade ou limpeza ou folha de pagamentos. Por que assumiriam a gestão de TI?
    • Aquele papo de CIO virando “executivo de processos” era conversa para BOI dormir. Bad trip provocada pela onda BPM que então surgia, nada mais.

    Pois é, TI acabou. Mas, como disse Voltaire em outro contexto, precisaremos (re)inventá-la. Exercício para a próxima semana: se você pudesse desenhar um departamento de TI do zero, como ele seria?

     

    Notas

    1. Descrever diagramas já é um atentado contra a inteligência. Escrever “consequentemente” na descrição de um CLD deve resultar em uns 100 anos de cadeia e solidão, mais ou menos. Perdão!
    2. “Caleidoscópio”, composição de Herbert Vianna gravada pelos Paralamas numa época em que existiam o Rock Nacional e os departamentos de TI.

     

  • Analistas de Negócio Valem Ouro

    Quem diz é a CIO Magazine: Analistas de Negócios valem Ouro. O artigo, que comenta uma pesquisa da Forrester, foi publicado lá fora no dia 16/abr e mereceu outro título: “Why Business Analysts Are So Important for IT and CIOs“. Why? Uai…

    Por duas décadas, o CIO foi visto como o elo central entre as funções de negócio e tecnologia. Embora esta talvez seja a percepção exata da sala da diretoria, nos bastidores os analistas de negócio são os encarregados de fazer essa ligação ao elaborar os business cases para desenvolvimento de projetos de TI, suavizando as relações entre concorrentes e impulsionando projetos.

    Nos “bastidores”? O Analista de Negócios (AN) atua “nos bastidores”? Parece que ele faz coisas “por baixo dos panos”, não? Quanta infelicidade. A Madame Katyusha (prima da Natasha do Gaspari) acha que a nobre publicação pretendia dizer o seguinte: “é o AN que põe a mão na massa!” E, creiam, os tais “business cases” não têm, por si só, o poder de fazer a tal ligação entre TI e o negócio. Muito menos de “impulsionar projetos”. E “suavizar relações”? “Entre concorrentes”?… sem comentários.

    Nossa área, pelo visto, nunca perderá a mania de criar Super-Heróis que resolvem todos os problemas. Há pouco eram os Coordenadores de Projetos. Como a coisa não andou como prometido, agora elegem AN’s como a bola da vez. Apesar de um certo gelo na barriga, acho que a turma já está vacinada. E não cairá nessa reciclada armadilha.

    AN’s são importantes, mas não mais ou menos que qualquer outro integrante de uma equipe de TI. Se eles valem ouro, então todos valem. Perdão turma, mas não se trata de demagogia, ok? Apenas um lembrete que, vez por outra, se faz necessário.

    O AN ganha importância (e espaço na prensa “especializada”) porque sua área de conhecimento foi paulatinamente reduzida e negligenciada nas últimas duas décadas: o Domínio do Problema. A academia e as empresas passaram a valorizar o domínio da solução: e foi uma enxurrada de “analistas-programadores”, de anúncios pedindo “analistas de sistemas com 10 anos de experiência programando em C# e Java” e assim por diante. Agora estamos aprendendo que, sem um correto domínio do problema, não há solução que vingue. Entram os AN’s!

    Mas quem são os AN’s? O artigo fala que eles valem ouro e, no parágrafo seguinte, confessa:

    Todo mundo concorda com a importância do papel do analista de negócio, porém pouca gente sabe exatamente o que faz um profissional como esse.

    Não é hilário? Não é uma coisa bem típica da nossa área? Engraçado é que a mesma publicação, há quase 1 ano, já falava que o AN era uma “hot commodity” e apresentava, com relativa felicidade, o seu job description. Felicidade que sumiu no segundo parágrafo do artigo atual: “a maioria dos analistas de negócio bem-sucedidos mescla o temperamento e a habilidade de comunicação de um diplomata com o talento analítico de um oficial do serviço secreto.” Céus, pra que dourar tanto a pílula? Madame Katyusha sugere: “O AN é bom no entendimento de problemas e na percepção de oportunidades.” Para tanto, é claro que o cara deve ser um excelente comunicador. Mas esta não é a única ‘soft skill’ que ele deve desenvolver / apresentar.

    Encerro o azedume com minha maior preocupação: sei lá porque cargas d’água, insistem em Analistas Orientados ao Negócio e Analistas Orientados para TI. Na publicação original ficou um tanto pior. Falaram em “Business-Oriented Business Analyst”… já pensou se vira sigla? BOBA! Céus! 10x Céus!! Quem nada entende tudo complica, né? Analista de Negócio é Analista de Negócio. Ponto! Se ele é subordinado ao CIO ou qualquer outra área é outro papo. Mas o nome é o mesmo! Deveria ser… o artigo fala que o pessoal da Forrester achou uma solução: Analista de Tecnologia do Negócio! Céus!!! 1000x Céus!! Detalhe: este é o nome adotado por um grande banco tupiniquim para o departamento de AN’s: DTN: Depto de Tecnologia do Negócio. Então… corre o risco de vingar. Céus…

    Mas não importa. O que importa é que finalmente os AN’s estão ganhando um certo espaço, a devida atenção. Deixemos o “ouro” para nossos compatriotas que irão para Pequim e vamos falar sério sobre a função-profissão.

    Quer saber quem é o AN, onde ele mora, qual a sua formação, habilidades e responsabilidades? Quer saber porque ele pode ajudar na concepção e entrega de projetos? Quais matérias ele deve dominar? Os motivos pelos quais ele se tornou tão importante? Segue o convite:

    No dia 31 de maio, sábado, apresento uma edição especial do evento “Formação de Analistas de Negócios“. Será em Sampa, na Av Paulista. Programação, localização, inscrição e demais informações você encontra no site da Tempo Real Eventos.

  • Quem Paga a Dolorosa?

    O negócio não interessa. O que interessa, isso sim, são os maravilhosos badulaques, frameworks, caixinhas-caixões e código. Adoramos esquecer que, no final das contas, quem ‘morre com a dolorosa’ é o tal do negócio. Há mais de uma década o Gartner estampa no Top 5 das preocupações dos CIO’s: “Alinhamento Estratégico“. Perdemos o novelo ou o papo sobre alinhamento não é sério?

    É claro que é sério. Na maioria das empresas é. O problema é mudar uma cultura de décadas de “cara-caixa-preta”. Não são poucos os exemplos de modelos, processos e metodologias que colocam TI como um fim e não um meio. Não por acaso, a Análise e Modelagem de Negócios é a disciplina mais ignorada em projetos de TI, particularmente em iniciativas para desenvolvimento ou implantação de sistemas. É comum que a Modelagem de Negócios seja vista como papo furado, desperdício ou algo do tipo.

    .:.

    A edição 903 da revista Exame (10/out/2007) apresenta uma série de artigos especiais. Mostra como o Brasil mudou nos últimos 40 anos. Alguns números são tão espetaculares que nos fazem questionar essa eterna mania de achar que tudo por aqui está ou dá errado. Ops… o assunto mudou ou o editor viajou? Não.

    Pense nas empresas que estão aí há 40, 20 ou 10 anos. Como elas passam por tantas ondas de mudanças? Processos de negócio envelhecem e adoecem. Quando o mesmo ocorre com recursos da empresa, máquinas por exemplo, eles são trocados. E o que acontece com os processos de negócio?

    Em grande parte das vezes eles são ajustados ou remendados. Várias empresas optaram pela implantação de ERP’s – grandes sistemas corporativos que em seu conceito original propunham a adoção de novos processos. Grande parte dos problemas com a adoção desse tipo de solução acontece exatamente na diferença entre processos existentes e os novos desenhos.

    Mas a questão está longe de ser uma exclusividade das empresas mais velhas. Mesmo empresas muito novas convivem diariamente com a pressão por mudanças em parte de seus processos de negócio. A demanda ocorre, particularmente, nos processos primários – aqueles que lidam diretamente com o mundo exterior, com os clientes.

    Processos ultrapassam as fronteiras de uma organização. Para frente, na direção dos clientes, e para os outros lados, no sentido dos fornecedores e parceiros de negócios. Na economia atual, têm nítida vantagem as empresas que oferecem processos abertos e flexíveis. Então, testemunhamos o surgimento de propostas muito boas para a realização dos requisitos de abertura e flexibilidade, notadamente SOA (Arquitetura Orientada a Serviços) e BPM (Gerenciamento de Processos de Negócio).

    Mas, como quase sempre ocorre em TI, caixinhas e ferramentas monopolizam discursos, press-releases e budgets. Passa desapercebido o fato de que processos remendados, velhos e doentes seguirão remendados, velhos e doentes numa SOA ou sob os cuidados de um BPMS. É muito velha a máxima que diz que “engessamos processos equivocados”. Tão antiga quanto nossa teimosia em ignorá-la.

    .:.

    A Análise e Modelagem de Negócios, uma das duas macro-disciplinas que formam o corpo de conhecimentos dos Analistas de Negócios (AN’s), está longe de ser papo-furado ou desperdício. Na realidade, quando bem executada, pode ser a diferença entre um projeto de sucesso e o total fracasso.

    A correta compreensão dos requisitos do negócio – seus objetivos e as metas específicas de seus processos – possibilita que projeto e produto tenham um horizonte e escopo bem definidos. Por isso a modelagem de negócios é bem mais que o mapeamento de processos. Ela pode compreender o estudo da estratégia da empresa, suas oportunidades e limitações, estrutura e relações.

    O que não pode significar, de maneira alguma, que projetos de TI devem ficar ‘congelados’ por um bom tempo, aguardando a realização da tal Modelagem do Negócio. Trata-se de um mito bastante comum que acompanha a disciplina. Uma primeira visão, a primeira iteração, pode demandar apenas alguns dias. E ela ocorre de forma simultânea com sua co-irmã, a Engenharia de Requisitos (a outra macro-disciplina que forma BoK do Analista de Negócios, aquela que mereceu maior atenção do BABoK).

    Ao incorporar práticas de Análise e Modelagem de Negócios em seus processos para desenvolvimento ou implantação de sistemas de informação, a organização fortalece equipes e projetos. Indica que está falando sério quando fala em alinhamento estratégico. Entende que o negócio é tudo o que importa. Afinal, quem paga a dolorosa?

    .:.

    Modelagem de Negócios é o primeiro módulo do curso para Formação de Analistas de Negócios, que o finito realizará em conjunto com a Tempo Real Eventos. Conheça mais detalhes sobre o curso, e veja aqui o seu conteúdo programático.

    .:.

  • Hot Commodity

    Hot Commodity! Jeito legal de dizer que a profissão “Analista de Negócios” está em alta. Foi assim que a revista CIO da Alemanha apresentou o AN, em artigo do último dia 16/ago. Em novembro, também na Europa (Barcelona), acontece o “Project World & World Congress for Business Analysts“. Em 9 meses, o IIBA conseguiu certificar pouco mais de 70 profissionais. Um neozelandês, o resto dos EUA e Canadá. Ou seja, é tudo muito novo.

    Ao mesmo tempo em que é tudo muito velho. A função existe há muito tempo, com nomes e responsabilidades um pouco diferentes, mas nova ela não é. Pode ser vista como uma releitura dos saudosos “Analistas de Organizações, Métodos e Sistemas”, uma profissão que ficou esquecida depois da ‘ascensão’ dos “Analistas de Sistemas” (AS). Veio a inevitável ‘queda’ dos AS’s, vieram os métodos ágeis e muito mais água debaixo da mesmíssima ponte, até que (re)descobrimos a importância desse cara que, na maioria das vezes, é apresentado como uma “ponte entre todos os stakeholders“. No artigo da CIO o job description é o seguinte:

    “O AN é uma ponte entre o negócio e TI, trabalhando em ambos os lados para propor mudanças em processos e sistemas, visando satisfazer as necessidades do negócio.”

    Definição meio perigosa, já que pode levar à falsa impressão de que um AN é um tipo de tradutor; que suas funções são um tipo de retrabalho; um passo ou uma fase adicional no processo de desenvolvimento. Enfim, um custo ou, pior ainda, um desperdício.

    Em meu trabalho, logo no primeiro capítulo, reforço que um AN passivo não é um AN de verdade. Vira quase um “garoto de recados”. A razão para o rótulo “hot commodity” ficou, de certa forma, implícita na descrição acima: “trabalhando em ambos os lados para propor mudanças em processos e sistemas”. O ponto de vista de um AN é super-privilegiado. Ao navegar entre TI e o negócio, ele pode desenvolver uma perspectiva única, caríssima para qualquer empresa que fale seriamente sobre “alinhamento estratégico”.

    Há dois dias estive em um dos maiores bancos brasileiros. Eles têm quase 150 AN’s, alocados em um departamento independente. Seu esforço: fazer com que os AN’s compreendam e assumam sua responsabilidade estratégica.

    Não tem nada a ver com o banco, mas é por essa e outras que reafirmo: o BABOK, mesmo com as alterações previstas para a versão 2.0, está um tanto distante do alvo correto. Sua ênfase em documentação, no desenvolvimento e gestão de requisitos, cria uma visão um tanto equivocada das responsabilidades dos AN’s. Oportunamente, e com uma maior freqüência, espero explorar melhor o tema por aqui.

    Por enquanto vale o registro da tendência: AN é um hot job. Resta torcer para que ele não seja recebido como um ‘salvador da pátria’; que sua certificação não se torne uma indústria com fim em si mesma; que os livros e cursos não mirem exclusivamente as provas de certificação; que os AN’s, fortalecidos, não tentem se fechar em “Escritórios de Análise de Negócios”… Enfim, que o AN aprenda com os erros dos outros.

    .:.

    Momento “Oportunista, eu?”

    A próxima turma do workshop “Formação de Analistas de Negócios” acontece no distante 27/set. Quem se inscrever até a próxima sexta, 31/ago, receberá 50% de desconto. Quem se inscrever e falar comigo antes receberá a versão eletrônica da apostila e um passe para o grupo de discussão exclusivo. A próxima versão da apostila, 0.7, será disponibilizada para os participantes das turmas anteriores no dia 20/set. Será a primeira versão com a formatação mais próxima da versão final do livro. Aliás, já está acertado que o livro será lançado em 27/Março/2008.

    Até lá, melhor dizendo, até dezembro, é tratar de amadurecer e enriquecer o texto. Daí os workshops e o grupo de discussão. Daí que, logo, serão lançados os treinamentos. Espero falar sobre eles muito em breve.

    .:.

  • [SOA # 4] – O Programa SOA

    SOA representa uma nova forma para se desenvolver, manter, comprar e vender aplicações de negócios. Ela pode afetar praticamente todos os sistemas de informação de uma empresa. E, quando bem sucedida, não possui um prazo para terminar. Como a construção de cada novo Serviço pode ser gerenciada como um projeto em si, é recomendável que uma iniciativa para implementação de uma SOA seja tratada e gerenciada como um Programa. Como tal, deve possuir definições acerca de sua Estrutura, Processos e Padrões.

    Um programa SOA deve ser dirigido por um Comitê Gestor, desenhado e populado especificamente para a iniciativa. Dentre as responsabilidades deste Comitê destacam-se :

    • Estabelecimento e revisão das estruturas, processos e padrões utilizados tanto no âmbito do programa quanto no nível dos projetos;
    • Acompanhamento da execução de todos os projetos SOA;
    • Garantia do apoio e participação das áreas de negócio durante todo o programa;
    • Manutenção do plano estratégico e do foco da iniciativa; e
    • Execução de atividades de evangelização, como treinamento, coaching e divulgação dos benefícios e restrições do programa para toda a organização.

    O Comitê Gestor de um programa SOA possui algumas funções bastante particulares. A figura 3 abaixo apresenta um modelo padrão desta estrutura, destacando seus principais atores:


    O Gestor do Programa responde por ele perante toda a organização. Dada sua importância estratégica não será estranho se algumas empresas optarem por alocar o próprio CIO ou Diretor da área de TI nesta função. Ele é apoiado diretamente por um Engenheiro do Processo, que pode ser um representante do Escritório de Projetos (PMO – Project Management Office), caso exista. A uniformidade e respeito aos processos de desenvolvimento e manutenção são fatores críticos de sucesso. O Engenheiro do Processo deve garantir que tanto o programa quanto os projetos SOA estejam sendo executados dentro dos padrões estipulados pela corporação. Também é sua responsabilidade a indicação dos Coordenadores de Projetos, seu acompanhamento e apoio.

    No entanto, o “braço direito” do gestor do programa é o Arquiteto SOA. Ele é o principal responsável técnico pela elaboração e implementação da arquitetura orientada a serviços. Devido a abrangência, complexidade e criticidade de tal iniciativa, o Arquiteto SOA compartilha suas responsabilidades com outros 5 arquitetos, cada um especialista em uma parte do programa.

    O Arquiteto de Negócio é o principal representante do programa perante as áreas de negócio. Visto de outra maneira, ele também representa as comunidades usuárias no Comitê Gestor. Ele deve coletar, avaliar, apresentar e defender os requerimentos de negócio. Portanto ele faz uso, em alto nível, das disciplinas Modelagem de Negócios e Engenharia de Requisitos. Se estivessem representadas na figura 3 acima, as áreas de negócio estariam no lado esquerdo do desenho. Entende-se então que os membros do comitê gestor que se relacionam de maneira direta com a comunidade usuária, além do Arquiteto de Negócio, são o Gestor do Programa, o Engenheiro do Processo e o Arquiteto SOA. Mas sua representação é uma atribuição exclusiva do Arquiteto de Negócio.

    O Gestor da Biblioteca de Ativos (GBA) é um personagem raríssimo nos ambientes e projetos de TI. Mas sua existência é fundamental para o sucesso de um empreendimento SOA. Além do gerenciamento do Repositório, apresentado anteriormente, o GBA também é responsável pelos principais processos de reutilização de ativos , ou seja: publicação e manutenção dos Contratos; introdução e coordenação do reuso de ativos; evolução do processo de reutilização etc. Com o tempo e conseqüente aumento no número de serviços disponíveis cresce também a importância do GBA.

    O Arquiteto dos Frontends das Aplicações tem sua alocação no comitê justificada pelo fato destas interfaces serem o único ponto de interação dos usuários com a SOA. São críticas as atividades de padronização das interfaces e garantia de usabilidade, que são atribuições exclusivas deste arquiteto.

    O Arquiteto de Serviços, por sua vez, concentra-se na padronização, acompanhamento do desenvolvimento e avaliação dos Serviços. Nos momentos iniciais do projeto são de sua responsabilidade a elaboração de padrões para os quatro tipos de Serviços existentes em uma SOA, ou seja: Básicos, Intermediários, Processos e Públicos.

    Por fim, temos o Gestor da Infra-estrutura Tecnológica, o membro do comitê responsável por garantir que os recursos computacionais disponíveis sejam adequados para atender a demanda que SOA e seus serviços gerarão. Além do sizing e estudo de capacidade de carga dos servidores, redes e softwares de infra-estrutura, este Gestor também acompanha os serviços em ambiente de produção visando garantir os níveis de serviço esperados.

    Percebe-se que o Comitê Gestor é praticamente uma representação do corpo gerencial de uma organização de TI. Em muitos casos talvez seja uma estrutura ainda mais sofisticada e completa. Acontece que em um “mundo ideal”, quando SOA encontra-se em estágio avançado de maturidade e todos os processos de negócio são representados por Serviços, o comitê gestor do programa SOA torna-se praticamente a equipe de gestão de toda a organização de TI. Apesar de ser um conceito relativamente novo, alguns casos de sucesso comprovam que tal “metamorfose” é uma conseqüência bastante plausível de uma implementação SOA bem sucedida. É curioso notar também que em uma situação onde a empresa decide pela total terceirização de sua área de TI, as 8 funções apresentadas acima talvez sejam as únicas que a empresa decida manter internamente. Para não correr o risco de perder o alinhamento de TI com o negócio.

    >>>>>>>>>> SOA #5 – Processos

    3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
    Prentice Hall (PTR) (2005).
    4. “Practical Software Reuse”, Michel Ezran, Maurizio Morisio e Colin Tully
    Springer (2002).