Dynamic table mapping - Hibernate

Ao longo dos anos se tornou comum utilizar frameworks ORM na construção de softwares que necessitem armazenar informações, esse tipo de framework facilita a manipulação dos dados fornecendo muitos recursos como: controle da conexão, transação, sessão, desacoplamento com as particularidades dos SGBD's, entre outros.

No meu caso, estou utilizando JAVA + Hibernate sendo o mapeamento entre classes/tabelas feito por XML e Annotations, porém nesse software eu precisei mapear a mesma classe para tabelas diferentes durante a execução, ou seja, eu precisei alterar o mapeamento dinamicamente. Junto da equipe a primeira idéia que surgiu foi alterar o xml de configuração (hibernate.cfg.xml), o que não fazia nenhum sentido pois teríamos que ao final da execução, retornar a configuração inicial. 

A partir daí o raciocínio foi simples, em algum momento o Hibernate tem que carregar o mapeamento para algum dos seus objetos e de alguma forma ele deve expor essa “facilidade”. Após algum tempo para a busca, não encontramos nada que resolvesse algo que é aparentemente simples: “Se estamos trabalhando com um framework de mapeamento objeto-relacional, nada mais óbvio que a necessidade de alterar o mapeamento em tempo de execução”.

Eu acredito que sempre que esse tipo de coisa acontece, o jeito é forçar a solução e como diria meu pai: “a necessidade faz o ladrão”, abrimos o código do Hibernate 3.5.6 para entender as estruturas de mapeamento. Realmente o Hibernate é muito bem construído é não deixou a galera na mão, encontramos uma classe interna da org.hibernate.cfg.Configuration, que implementa a Mappings, a partir dessa classe conseguimos fazer nosso dynamic table mapping.

Segue abaixo a parte mais importante do post, o exemplo:

// instancia o org.hibernate.cfg.Configuration
conf = new AnnotationConfiguration();
//carrega o hibernate.cfg.xml
conf.configure();
// carrega o mapeamento class-entity/table
conf.buildMappings();
// cria o manipulador de mappings
Mappings mps = conf.createMappings();

// Exemplo de alteração do mapeamento
Table t = mps.getTable(null, null, "tabela_antiga");
t.setName("tabela_nova");

Vale lembrar que após a alteração do mapeamento um novo SessionFactory deve ser criado, assim como os objetos que são criados a partir dele (Session, Transaction, etc). Espero que esse post ajude as outras pessoas que como nós não encontraram essa "simples" resposta, nem na documentação do Hibernate.

Observação: Como o mapeamento está sendo alterado direto no código, é importante lembrar que essa estrutura deve existir no banco de dados, caso não exista também é possível criá-la pelo Hibernate, mas  essa questão não faz parte desse post.

Referência: Documentação Hibernate - 2.Arquitetura

BPO - Uma questão de atitude

Business Process Outsourcing (BPO) é a terceirização de um processo de negócio de uma empresa, que geralmente não faz parte de seu core business. É justamente aí que as grandes barreiras começam. Pela atividade terceirizada não fazer parte de sua atividade fim, geralmente os clientes possuem pouco conhecimento imediato a respeito do objeto de terceirização. É comum que esse conhecimento seja construído à medida que a relação de terceirização amadureça. Claro que existem clientes de maturidade variada, mas aqui o intuito é analisar a média.

Em setores de terceirização de alta competitividade entre players, o que se percebe acontecer de forma repetida é a construção de um "not know how" empírico por parte do cliente, pautado em más experiências passadas. Nesses casos, o cliente adota uma postura defensiva que intimida qualquer fornecedor.

Como contribuir para o aumento da maturidade de seu cliente em uma situação como essa?

Como não se deixar intimidar por essa barreira entre cliente e fornecedor?

A responsabilidade nesse caso é do fornecedor, detentor do know how, da expertise, direcionar o cliente de forma que este possa mudar sua atitude perante ele e a empresa fornecedora. A maior dificuldade é que enquanto o objetivo maior (mudança de atitude e aumento da maturidade do cliente) não acontecer, os conflitos serão comuns.

A falha maior nesse caso, é que para evitar desgastes imediatos, evita-se por vezes um posicionamento que a princípio pode parecer áspero, mas que em longo prazo pode ser determinante na construção de uma relação duradoura. Não há mal em dizer que o cliente está errado, pelo contrário, não fazê-lo é um ato de negligência grave. O desafio consiste em evidenciar esse erro ao cliente da melhor forma possível, mas deve-se ter cuidado para não atribuir menos ou mais relevância do que tal pauta deveria ter.

Deve-se buscar um comprometimento com o cliente e não um comprometimento de subsistência com seu próprio emprego.

E você, está realmente comprometido com seu cliente? Ou acha mais fácil agir como o avestruz da foto?

A revolução dos bichos

Quando eu vi esse título “A revolução dos Bichos”, de George Orwell, logo imaginei que era um livro para crianças (confesso que fiz cara feia!), quando comecei a ler percebi que era uma fábula e que realmente poderia ser lido por crianças, mas aos poucos percebi que haviam mensagens escondidas para os adultos, reflexões sobre a vida em sociedade.

Em um breve resumo, com uma pitada de opinião, a história se passa em um sítio (país), que é dominado por um homem muito rígido (autoritário). Um certo dia um porco (revolucionário) mostra como será o mundo depois que o homem desaparecer (depois que o atual regime cair), porém dias depois o idealista morre, mas seus sete mandamentos para o novo mundo (novo regime) permanecem escritos na parede como sonhos distantes.

Todos os animais na história representam “tipos” de posturas sociais, como: manipulação, alienação, ignorância, teimosia, passividade... Tipos que você já conhece!

De alguma forma a expulsão do dono (a revolução) ocorre. E então os animais se reorganizam para criar aquele novo mundo apresentado pelo idealista falecido, seguindo fielmente os mandamentos. Porém surgem as primeiras divergências entre os comandantes do novo regime e então as primeiras deturpações das idéias começam a ocorrer, logo os mandamentos um a um foram removidos ou alterados de acordo com as pretensões do novo ditador, até que no fim é impossível distinguir as diferenças entre o homem (antigo ditador) e o porco (novo ditador).

É engraçado como essa sátira da revolução russa, possui tantos pontos em comum com outras revoluções (a Cubana por exemplo), mostra claramente o caminho percorrido quando os mais fracos tomam o poder e são, por ele corrompidos. Se pensarmos um pouco, é curioso como reconhecemos esses “tipos” em nossas equipes, realizando as mesmas ações (de liderança ideológica ou autoritária) em diferentes níveis. Para quem conhece a história, você age como qual dos “animais” do sitio?

Princípios Gerenciais: Seu gerente se lembra deles?

Normalmente, gerenciamento é definido como a arte e/ou ciência de realizar tarefas por intermédio de outras pessoas, ou seja, os gerentes são responsáveis por planejar e orientar o trabalho dos outros, o que para muitos dos “não-gerentes” parece como a arte de não fazer nada, quem nunca ouviu a frase: “O meu gerente não faz nada o dia inteiro!”, isso pode ser verdadeiro em alguns casos, mas acredito que são raros, pois em um ambiente competitivo os demais membros da equipe já teriam tomado o seu lugar.

Escuto muito sobre equipes auto-gerenciáveis (vide SCRUM), e apóio por acreditar que funcione bem no lugar certo, mas com certeza em algum nível hierárquico ainda precisa existir a figura do gestor que mantém a coesão do grupo, administra os conflitos, direciona os esforços para atingir as metas da empresa...

Existem várias definições sobre o qual o papel do gerente em uma organização, eu prefiro a seguinte definição: “Gerente é aquele que consegue que o resultado da equipe seja maior do que a soma do resultado de cada individuo”. Se eu precisasse dar nota para o trabalho de um gerente esse seria um dos meus critérios mais valiosos.

Equipes com bons profissionais parecem uma embarcação com capitão de férias, o barco segue em movimento, mas quando ocorrem imprevistos e a situação se agrava o consenso também desaparece, é como uma nação sem governo cada um trabalha em interesse próprio. Imagine um exército sem general, parece absurdo!? Essa é a importância da figura do gestor.

No gerenciamento assim como no jogo de xadrez, tem a vantagem quem consegue considerar mais lances adiante e realizar a melhor estratégia se adaptando conforme o jogo. Imprevistos sempre podem acontecer e alguns são até bem vindos, exemplo disso é quando um profissional chave para o projeto comunica a sua saída da equipe repentinamente, comumente vejo gerentes encarando isto apenas como um contratempo, mas também pode ser visto como uma gama de oportunidades, tais como contratação de um profissional com perfil diferente (ou melhor), reestruturação da equipe, desafios e reconhecimento aos demais membros da equipe, etc..

Recentemente eu acompanhei a saída do líder de uma equipe, logo ficou claro para todos que não havia alguém já qualificado para assumir, portanto curiosamente a solução dada pela direção foi a promoção de dois profissionais da equipe, pois havia um com mais habilidade no relacionamento interpessoal e o outro com um profundo conhecimento técnico, então os papéis foram redefinidos na tentativa de um complementar o outro.

De acordo com Tom Gorman existem cinco princípios mais importantes que todo gerente deve saber:

Valor para o cliente: Os clientes pagam pelo valor do produto ou serviço, não é possível atender a todos os desejos dos clientes, portanto deve-se criar um tipo específico de valor, ou seja decidir o que a empresa vai entregar aos clientes e a partir daí organizar-se.

Organização: Empresas menores tendem a ser menos estruturadas, com menos departamentos e recursos para organizar e empresas maiores exatamente por terem muitos recursos para gerir tendem a ser mais organizadas, porém determinado departamento pode ser organizado ou não independente do tamanho da empresa, e grande responsabilidade disso é do gerente realizar seu trabalho corretamente.

Vantagem competitiva: É o “algo mais” no produto ou serviço oferecido e qual é o seu público-alvo, porém isso deve estar bem claro a todo momento nas decisões dos gerentes, muitos fracassos empresariais estão baseados no “esquecimento” desse princípio.

Controle: Os controles asseguram que o gerente possa saber o que está acontecendo. Os controles são baseados em autonomia e informações. Porém o que não é medido não é gerenciado.

Lucratividade: O negócio só existe para gerar lucros. Se por incompetência do gerente a empresa perder dinheiro provavelmente não ficará com o emprego por muito tempo. Com certeza cada empresa possui suas metas, mas a principal é obter lucro.

Muitas empresas obtêm bons resultados financeiros, mas isso não significa que o trabalho está sendo bem feito e que os problemas não estão sendo escondidos por trás desses resultados. Até que ponto as pessoas sabem o que acontece dentro da empresa? Será que os gerentes na sua empresa realizam seu papel?

Vai estudar meu filho!

Depois de um longo período sem posts, lá vai um post leve. Me certifiquei em ITIL V3 Foundation e gostaria de compartilhar a experiência. Já faz algum tempo que me interessei por ITIL, seu conteúdo, processos, termos e conceitos. Ao começar a trabalhar em uma empresa onde existem áreas buscando aplicar cada dia mais esses conceitos, conhecer esse conjunto de boas práticas se tornou uma necessidade para mim.

Plano de estudos: o livro oficial de introdução possui conteúdo mais do que o necessário para estudar para o certificado. Li o material apenas uma vez fazendo um resumo e revisei esse resumo. Para facilitar o estudo assisti algumas aulas em um curso online e fiz alguns simulados, em torno de uns 7.

A prova foi tranquila, em geral as questões foram a respeito das definições dos termos. O tempo é suficiente para fazer a prova e revisar tudo sem pressa.

Espero que esse post possa ajudar alguém. Boa sorte para quem for fazer a prova.

O assistente do analista

Eu quero contar uma história: um belo dia alguém da Empresa X disse que era preciso rever a política de cargos e salários para corrigir alguns problemas. Realmente havia sobreposição de funções, cargos de maior responsabilidade com menor remuneração e uma certa confusão sobre as atribuições de cada cargo. Então, uma equipe foi reunida para redefinir essa política. No início do trabalho, ficou bem claro que existiam muitos “Analistas” e “Assistentes” dentro da empresa; foi encontrado até assistente que gerenciava analista.

Pela definição, assistente é quem auxilia em alguma coisa e analista é quem realiza a “análise” de como é, porque é, e o que fazer a partir daí. Considerando então que o assistente segue as orientações de alguém e faz algo já definido, podemos entender que o analista, por sua vez, possui um perfil mais flexivel, sabendo lidar com as variações que o seu trabalho pode apresentar.

Essa então foi a parte fácil. Mais fácil ainda foi promover os assistentes que trabalhavam como analistas para o seu cargo de direito. O complicado foi mostrar aos analistas que apesar de possuírem o cargo, eles desempenhavam as funções de assistente.

Foram abertas oportunidades para essas pessoas de realmente se tornarem analistas. A empresa reconheceu seus erros “estruturais”, apresentou um generoso programa de capacitação e a promessa de aumento de salário aos analistas que concluíssem o programa. Para o espanto da equipe que conduzia essa reestruturação, muitas pessoas nessa situação se recusaram a participar do programa por entender que não era necessário estudar para obter um “status” que já possuíam. Houveram várias discussões sobre os ganhos que a capacitação traz, independente da área.

Essa resistência se mostrou como um problema cultural na empresa. Novamente, a equipe responsável pelas mudanças entendeu que eram necessárias iniciativas não apenas da perspectiva técnica desses profissionais, mas também pessoal. Foram apresentadas à diretoria algumas alternativas para a resolução desse problema, porém veio a seguinte decisão de um dos diretores: “É melhor, financeiramente, a demissão das pessoas que estão resistentes às mudanças para a contratação de outras com o perfil que agora desejamos”.

Conclusão: as pessoas que se indignaram, mesmo recebendo a mais pelo tipo de trabalho que desempenhavam e não concordaram a participar do programa de capacitação, perceberam que apesar do “barulho” que fizeram representavam menos de 2% dos funcionários e, como na prática eram assistentes, poderiam ser facilmente substituídos.

Na sua empresa, essa visão entre assistente e analistas é bem definida? Existe resistência às mudanças? As pessoas se consideram insubstituíveis? E você?

Torre de Hanói usando F#

Lendo sobre F# resolvi implementar alguma coisa para distrair. A sintaxe me lembrou muito Haskell, outra linguagem funcional, assim como a estrutura da documentação, os módulos, as tuplas e as listas também me lembraram Haskell. Foi então que me lembrei de um problema que resolvi na época da faculdade, Torre de Hanói (http://pt.wikipedia.org/wiki/Torre_de_Hanói).

Para encontrar o menor número de movimentos, a estratégia que usei foi bem simples, baseado na regra que um disco maior não pode ficar sobre um disco menor, a função segue os seguintes passos:

1. Movimenta todos os N-1 discos para a torre intermediária;
2. Movimenta o último disco para a torre de destino;
3. Movimenta todos os N-1 discos da torre intermediária para a torre de destino.

A forma como a função “sabe” os movimentos para N-1 discos é algo que a recursão resolve (ainda bem!), o importante é a existência de um caso base que para nós é a solução de Hanoi (1), ou seja, o movimento do disco 1 da torre de origem para a torre destino.

O código que calcula os movimentos, se resume basicamente nas 2 linhas de implementação da função hanoi:

#light

// Função recursiva que gera a lista de movimentos dos discos
// n -> Número de discos
// origem -> Torre de origem
// inter -> Torre intermediária
// destino -> Torre de destino
let rec hanoi (n:int) (origem) (inter) (destino) : (int* string* string) list =
  if (n = 1) then [(1,origem,destino)]
  else hanoi (n - 1) origem destino inter @ [(n,origem,destino)] @ hanoi (n - 1) inter origem destino

// Função que imprime o movimento do disco a partir de uma tupla
let imprime (n,origem,destino) =
  "Move disco " + n.ToString() + " da " + origem + " para a " + destino + "\n"

// Função que aplica o Map a cada tupla da lista
// n -> Número de discos
let imprimeJogadas (n:int) =
   List.map imprime (hanoi n "Torre A" "Torre B" "Torre C")

O resultado da execução:

A escolha da demonstração desse problema se deve ao fato que sua resolução apesar de ser bem pequena explora vários recursos do paradigma funcional e de F# como o uso de funções, recursão, tuplas, listas e funcões de alta ordem.

Espero ter ajudado no trabalho de faculdade de alguém!

Dominação Gloobal

Não é de hoje que ouvimos frases do tipo: “O Google vai dominar o mundo”. Os adeptos de teorias da conspiração são os que mais produzem lendas sobre os perigos do poder desse fenômeno da internet. Steve Ballmer, presidente executivo da Microsoft, já brincou em várias apresentações públicas dizendo: “O Google lê os seus emails!”.

Mas até que ponto todo esse poder, refletido em dezenas de serviços que o Google oferece, representa uma ameaça? Para entrarmos nessa discussão, devemos antes esclarecer os indicadores que caracterizam um monopólio. Primeiro vamos a etimologia: monopólio do grego monos = um, e polein = vender. Conceitualmente, significa uma situação de concorrência imperfeita em que uma empresa detém o mercado de um determinado produto ou serviço impondo preços aos que comercializam. Geralmente, monopólios infringem leis em benefício próprio. Como o Google não se enquadra em nenhuma das duas situações, o mínimo que podemos dizer é que se trata de uma empresa muito grande que desempenha enorme influência nas têndencias do mundo digital e dispõe de uma imensa base histórica de nossos costumes, desejos, segredos e etc.

Ano passado, uma britânica pediu divórcio após ‘flagrar’ o carro do marido em frente a casa de uma suposta amante pelo Google Street View. Esse é o ponto! Por vezes, a informação por si só já é destruidora, imagine quando na “mão” de alguém/empresa mal intencionada.

Discussões sobre a índole do Google à parte, o que mais me impressiona são as correlações entre os serviços disponibilizados por ele. Muitas vezes, quando é lançado um novo serviço, a impressão que temos é do tipo: “Onde esse cara quer chegar?”. É impressionante como o Google aproveita um recurso já desenvolvido e o encaixa em um contexto ou aplicação muito mais rica. Veja um “rascunho mental” sobre as correlações entre alguns serviços oferecidos pelo Gigante, modelado por Leonardo Piedade:

Um serviço que me chamou atenção essa semana foi o Google Voice. Com ele, você pode ter um número de telefone pessoal universal. Universal, por que é um único número para os mais diversos dispositivos. Estranho? Vamos ao exemplo: imagine que você possui um Google Number (como se fosse um número de telefone qualquer). Ele não é vinculado ao seu celular, telefone fixo ou computador. Ele é vinculado à você! Nele é possível incluir todos os números de telefone que possui. Quando perguntarem qual seu telefone, bastará que você diga o seu Google Number, e essa pessoa possuirá ao mesmo tempo seu celular, telefone fixo, ramal do trabalho e etc. Via web, é possível programar para que quando seus amigos liguem para o seu Google Number, ele os redirecione automaticamente para a sua casa e seu celular ao mesmo tempo. Quando sua família ligar, você pode redirecioná-la para sua casa, emprego e celular. Quando seu chefe ligar, redirecione-o direto para o correio de voz. :)

Por falar em correio de voz, através do Google Voice, é possível transformar suas mensagens de voz recebidas em mensagens de texto de forma automática.

Realmente, diante disto, o que nos resta é perguntar: “Onde esse cara quer chegar?”

Veja a história do Google contada em dois minutos aqui.

Assista um vídeo explicativo do Google Voice aqui.

Sourcing + Comunidade = Crowdsourcing

Novamente lendo alguns textos sobre ITIL me deparei com a descrição dos tipos de fornecimento de serviços. Logo, se você tem um trabalho para ser feito, é necessária a decisão de qual a melhor estratégia para realizar esse trabalho. Essas opções apresentam vantagens e desvantagens, algumas descritas no livro Service Design são:

Insourcing: Utiliza os recursos internos da organização.

Outsourcing: Utiliza os recursos de outra empresa através de um acordo formal (contrato).

Co-sourcing: Combinação da utilização de recursos internos e externos.

Multi-sourcing: As atividades são dividas entre várias organizações (parcerias).

Business Process Outsourcing (BPO): O fornecedor gerencia por completo processos de negócio.

Application Service Provision (ASP): Fornece serviços compartilhados, como infra-estrutura por exemplo.

Knowledge Process Outsourcing (KPO): É a evolução do BPO, onde o fornecedor conta com competências de alto nível, para interpretação de dados para a tomada de decisão.

Existe uma opção não listada aqui, considerada por alguns, que é o Crowdsourcing, envolvendo vários recursos, muitas vezes voluntários, as pessoas participam porque gostam e dedicam seu tempo livre para isso. Um bom exemplo são as comunidades open source, que resultaram em produtos como o Linux.

A utilização dessa forma de recurso não é simples, e tem desvantagens como tornar muitas informações púbilicas e não ter o controle da entrega sem um time interno, por outro lado, o custo é baixo e se tira proveito da inteligência coletiva. Uma variedade maior de soluções são propostas e os testes são executados em ambientes diferentes.

Essa forma de trabalho é considerada por muitos como não aplicavel ao ambiente corporativo. Porém, muitas grandes empresas investem em comunidades como apoio ao desenvolvimento dos seus produtos. Alguns poucos já fizeram fortunas baseadas nos produtos do trabalho de milhares de anônimos espalhados na internet, e muitas dessas pessoas continuam contribuindo por considerar que os beneficios que o produto traz para si é recompensador. Há alguns que acreditam que essa é uma das formas de aproveitar melhor os conhecimentos da humanidade que sempre foram extremamente dispersos.

Disciplina X Metodologia

É engraçado como em computação as pessoas se preocupam em usar os nomes corretos. Mesmo assim, alguns nomes são trocados o tempo todo. Um exemplo clássico é o de Disciplina e Metodologia que conceitualmente possuem o seguinte significado:

Disciplina: É como uma estrutura que fornece orientação, permite a análise mesmo para itens não previstos. (O que fazer).

Metodologia: Fornece direções especificas para lidar com situações conhecidas, consiste em um conjunto de métodos, sendo um método a abordagem passo a passo para realizar tarefas. (Como fazer).

Parecem coisas como água e óleo, mas funcionam muito bem quando combinadas, um exemplo, é o próprio RUP (Rational Unified Process) que é uma metodologia divida em disciplinas, ou seja, em níveis superiores é fornecido a forma de fazer e em níveis mais detalhados é uma orientação do que fazer.

As pessoas aprendem esses termos de diversas formas e utilizam como bem entendem, eu nem sei dizer se a descrição feita acima é a mais utilizada. Agora o que fica estranho é durante uma conversa você ouvir a mesma palavra com 4 ou 5 significados diferentes vindos da mesma pessoa. Eu acredito que em conversas técnicas o ideal seria procurar manter a semântica, pois esse é o propósito do uso de conceitos. Não é mais complicado quando é necesssário explicar o que você está tentando dizer?

O melhor de dois mundos

Por muito tempo, as empresas gerenciaram seu software sob premissa. Os softwares eram instalados em seus computadores e quem fornecia o suporte era a equipe de TI interna. Com a evolução da internet muita coisa mudou. Agora o software não está apenas disponível sob premissa, mas também como serviço na internet. Para o computador, web e celular, os serviços na internet oferecem um mundo de novas possibilidades. E é justamente essa equação, S+S (software + serviços), que está criando um novo horizonte e a proposta é que Microsoft e parceiros suportem essa nova composição de uma TI híbrida e altamente combinada.

Mas o que software + serviços significa para uma empresa?

Para exemplificar, imagine-se na pele de um executivo de uma empresa X que depende de um software para seu negócio. Você comprou esse software e o instalou em seus computadores. Seu sucesso depende diretamente de um software que seja compatível com suas necessidades e capacidade de infra. Nesse cenário, sua equipe de TI deve garantir a segurança, disponibilidade e performance desse software, entre outras coisas. Com a expansão de sua empresa, você precisou viajar mais e mais. Mas o software que utiliza não funciona via web ou via celular. Eis que você se sente preso ao escritório. Além do mais, é um processo muito dolorido instalar todos os softwares em uma nova filial, por exemplo. Claro que a esta altura, seu sentimento de limitação realmente te incomoda.

Agora, imagine-se na pele de outro executivo que fez uma escolha diferente. Ao invés de instalar o software, você usa serviços na internet - também conhecidos como SaaS (Software as a Service). Você só depende da internet para conectar seus computadores e celulares e, assim, 'tocar' o seu negócio. E o tal software como serviço deixa para trás muitas preocupações que você poderia ter com sua equipe de TI. Atende prontamente quando seus funcionários estão longe do escritório e oferece escalabilidade caso sua empresa cresça de forma rápida. Mas mesmo assim você, como no exemplo anterior, se sente limitado, pois o software como serviço requer uma conexão constante com a internet e, se algo sair errado, sua empresa literalmente pára. Ainda existe outro ponto: geralmente os softwares como serviço são desenvolvidos para fazerem coisas similares para todos os clientes, o que implica dizer que, por vezes, eles não atendem necessidades muito específicas de sua empresa.

Eis que você e você mesmo (é a dualidade do eu!) se encontram e chegam a conclusão de que seria muito melhor juntarem “software sob premissa + software como serviço” pois, empresas não podem conviver com esse sentimento de limitação. Precisam de que a tecnologia ofereça flexibilidade e suporte para que seu negócio cresça e seu software deve ser capaz de servir como uma luva para as necessidades de seu negócio tão logo se faça necessário.

Com a equação "software sob-premissa + software como serviço", temos o S+S (Software mais serviços) que é o melhor dos dois mundos para você e para você mesmo. (?!) :)

Do bit ao dinheiro

Bom, talvez eu esteja “chovendo no molhado” mas, mesmo assim, queria comentar sobre um aspecto da dicotomia entre a vida acadêmica e a profissional. Quando estamos na graduação, somos doutrinados a ter um pensamento técnico, buscamos nos tornar especialistas em tecnologia, seja ela qual for. Isto fica bem claro quando conversamos com estudantes e recém-formados. Porém, esse tipo de pensamento não serve para os cargos de decisão.

Com o tempo esses profissionais se tornam executivos de TI, sendo que muitos deles tendem a se focar no know-how, assim como aprenderam, e se esquecem que no ambiente corporativo é importante conhecer bem o modelo de negócio da empresa para se concentrar no know-why.

Imagine uma reunião de diretoria onde são apresentadas propostas sobre a expansão da empresa, a necessidade de redução de custos, aumento das vendas e outras. Obviamente que para apoiar essas estratégias é solicitado a participação da área de TI que, rapidamente com sua forma de pensamento equivocado, surge com vários “planos bem elaborados” para converter todos os sistemas para SOA, incluir mais relatórios, implantar governança baseada em ITIL e Cobit, migrar sistemas para as tecnologias atuais, virtualizar máquinas do datacenter ou implantar outra tendência atual. Será que esses planos estão realmente alinhados com as necessidades do negócio?

Em geral tais planos devem passar por aprovação e é ai que acontece o inverso, executivos que por sua vez não têm conhecimento em TI aceitam as idéias sem criticá-las, ou seja, ambas as partes erram, a primeira por não pensar nos resultados reais para o negócio e a segunda por não exigir argumentos claros sem o costumeiro "tecniquês". Isto acontece muitas vezes de maneira silenciosa nas empresas, faltou o tão comentado “alinhamento entre TI e negócio”, desta vez por ausência de competência dos gestores de TI que não perceberam que o conhecimento técnico que possuem deve guiar as decisões ao invés de ser o foco delas.

As conseqüências disso são projetos fracassados, baixos resultados, investimentos literalmente jogados fora. Esse é um dos motivos pelo qual a TI continua ocupando o lugar da “área de serviço”, quando poderia ser a “vitrine” das empresas.

Utilidade X Garantia, simples?

Estava lendo um material sobre ITIL e me deparei com um conceito relativamente simples:

Utilidade (Utility): É o que o cliente precisa, caracteriza o que o serviço faz.

Garantia (Warranty): É como o cliente precisa, caracteriza como o serviço é entregue (entenda entrega como o serviço em produção).

Na prática também parece simples, a “Utilidade” é descrita pelos requisitos funcionais e a “Garantia” é descrita pelos requisitos não-funcionais.

No entanto é ai que começam alguns dos problemas. Em geral, os requisitos não-funcionais (usabilidade, confiabilidade, desempenho e suportabilidade) são descritos de forma incompleta e nesse “deslize” as promessas feitas para o cliente e para si mesmo dizendo que, dessa vez, nesse novo projeto, “tudo vai ser diferente”, devem tomar mais tempo para acontecer.

Existem desculpas para os requisitos mal escritos. Um argumento padrão é aquele “Não há como ter uma boa estimativa de carga”, mas e quanto a estimativa de capacidade do sistema? Que tipo de profissional não conhece o resultado do seu trabalho!?

Como um sistema pode ser entregue sem ao menos um conjunto de testes de confiabilidade e desempenho? Isso parece um absurdo mas é a realidade em muitas empresas no Brasil. Depois de pronto, o sistema é implantado e aos poucos os problemas surgem. O diagnóstico em produção é mais dificil do que no ambiente de testes e, em muitos casos, o cliente paga para arrumar o que ele já pagou para não estar “quebrado”.

O conceito “tão simples” do efeito da combinação de Utilidade e Garantia exige bem mais trabalho do que parece para ser posto em prática. A habilidade de entrega de um serviço com determinado nível de garantia é realmente um grande diferencial competitivo.

Links:

• http://www.baguete.com.br/blogs/post.php?id=3,246
• http://itilblues.wordpress.com/2007/12/14/itil-v3-utility-and-warranty-two-sides-of-the-same-coin/