Como Montar uma IBM de Software Livre

Eu sempre acreditei que, usando SL, eu posso criar uma empresa que não fabrique nenhum produto, mas mesmo assim fature alto com soluções de TI. A idéia é bem simples, até. Por exemplo, vamos dizer que um ministério lance um edital para isso:

Precisamos de um sistema para pagar conveniados do programa X, com todos os pagamentos a partir de R$100k auditados, com interface web para o conveniado acompanhar seu processo de pagamento e/ou auditoria, para que ele possa tomar as providências necessárias. Queremos que todos esses números apareçam no Portal da Transparência automaticamente, atualizado mensalmente. Todo acesso dos conveniados e funcionários da administração pública federal devem ser controlados com criptografia.

Até ontem à noite, eu não tinha uma idéia clara de como montar essa empresa, que pudesse atender esse tipo de demanda com SL. Minha visão, para mim, sempre foi muito clara – empresa três-em-um: Centro de Dados + Software House + Soluções. Se, eventualmente, o cliente decidir usar o próprio CD ou de um terceiro, como o Serpro, a empresa poderia passar tudo para lá facilmente (eu construiria as soluções para rodar em máquinas virtuais, como uma nuvem.)

Dai, digamos que essa empresa examina sua linha de produtos de SL (todos adotados, nenhum inventado por eles) e concluem que:

• O módulo financeiro de um ERP (Compieri, digamos) pode controlar as contas do convênio.
• Um AlFresco pode manter scans da documentação.
• Um Bonita Open Solution pode executar o fluxo de auditoria.
• Um eXo Portal pode ser o link com o conveniado.
• Uma solução de BI com Pentaho pode publicar os relatórios no Portal da Transparência.

Suponha que apenas metade desses aplicativos suporta SSO com criptografia. Como resolvemos?

Assim:

• Cada SL em uso na nossa linha de produtos tem sua própria equipe de desenvolvimento.
• Enquanto o 2/3 da empresa cuida de montar a infra-estrutura (CD) e implantar a solução (Soluções) o outro 1/3 (Software House) define as funcionalidades necessárias que ainda não existem.
• Em conjunto com a comunidade, as equipes de cada um desses programas evolui o SL.
• Na última etapa da implantação, a infra-estrutura atualiza o SL para a última versão comunitária, que foi desenvolvida por essa empresa hipotética.

Na verdade, já existem empresas que fazem isso para si mesmas: usam tudo livre e quando um determinado software não tem tudo, eles pagam alguém para fazer e devolver a contribuição à comunidade. Assim eles ganham duas vezes, com o resultado e alimentando o círculo virtuoso do SL.

E existem empresas como a Pentaho e a RedHat, que também fazem isso. Só que elas dão manutenção apenas nos seus próprios softwares, e tem um foco mais ou menos estanque. Elas atendem aqui e pronto. A minha idéia é um passo adiante: vender soluções e atuar como integrador, que é uma prática habitual no mercado de automação industrial.

O truque é a equipe de desenvolvimento: usar Scrum para dar manutenção em SL, como se essa equipe não fosse da empresa, mas uma equipe da comunidade que, por acaso, podemos direcionar para onde precisarmos. Se, de repente, não há demanda interna para melhorias em um determinado produto, essa equipe pode colaborar implementando as melhorias demandadas pela comunidade.

Há um grande impecilho nisso tudo: a equipe de vendas. Imagine ter especialistas em trocentos assuntos diferentes numa mesma pessoa, capaz de examinar a necessidade do cliente e desenhar uma solução Lego com SL. Provavelmente cada equipe de venda teria um especialista em pares de assuntos (Bancos de Dados e SO, BI e ERP, Workflow e BPM etc.), com um generalista capaz de analisar a demanda do cliente e definir a estratégia de implantação.

A vantagem competitiva viria do fato de essa empresa ser especialista na integração e ser co-autora em todos esses SLs. O preço também precisa ser competitivo, claro, mas com o custo de hardware caindo e a sofisticação dos SLs aumentando, isso não deve ficar caro.

Fábrica de Software? Não mesmo!

A revolução industrial trouxe a indústria como nós a conhecemos: uma linha de produção, em geral com algum grau de automação, que produz um determinado item em grandes volumes, e o mais parecidos entre si possível.

Quando a "indústria" de software começou a nascer muitos se debruçaram sobre o processo de construir programas. Depois de algum tempo começaram a perceber que a transposição dos conceitos de engenharia civil (desenhar, planejar, construir) para a informática era muito mais uma idéia bonita do que boa arte de programação.

A compreensão de porque é difícil se projetar software veio aos poucos, mas o destilado de décadas de experimentação na construção de programas de computador pode ser sintetizado em um conceito muito simples: repetibilidade.

É simplesmente impossível desenhar um processo de criação de software, genérico e repetível, que torne o processo completamente previsível e mais, que fabrique itens diferentes um do outro a cada iteração.

O mais fascinante é que tudo isso é óbvio. A fábrica fordiana mais produtiva, azeitada e veloz gasta um bom tempo sendo alterada para produzir cópias de um novo modelo de carro. A linha de produção, a indústria, fabrica itens iguais, xerocados. Inventar um novo item ou aperfeiçoar um antigo é um processo na melhor das hipóteses histórico e na pior totalmente experimental. Não existe fábrica de projetos de, por exemplo, carros ou máquinas de lavar louça. Cada marca tem o seu modo de desenvolver, aprendido a duras penas. Um novato vai precisar cometer muitos erros e ralar muito até dominar um processo criativo.

Como então alguém pode propor uma coisa maluca como uma fábrica de software? Para começo de conversa o propósito de uma fábrica de software é produzir itens novos ou, na melhor das hipóteses, reaproveitar o que já foi desenhado - nunca fazer apenas uma cópia dos itens pré-existentes!

O contra-argumento à essa linha é a indústria da construção civil: cada novo prédio é algo inédito e o mero sucesso de um largo número de projetos indica que é possível, sim, definir um processo dessa complexidade que seja repetível.

Bom, basta observar essa indústria um pouco mais atentamente para notar que ela confirma a regra: o processo de construir um novo prédio é conhecido e repetível. Todos são estruturas calculáveis, definidas e com quantidades de materiais previsíveis. Aliado ao conhecimento histórico sobre produtividade em construção civil, hoje praticamente item de livro-texto de Engenharia Civil, gestão de projetos etc. construir um novo prédio - qualquer um, em qualquer formato! - é uma tarefa domada, não uma tarefa inédita a cada prédio.

Na minha opinião, usar Software Livre pode mudar esse jogo: evite construir cada programa de novo, mas monte coisas complexas com programas simples. Um bom exemplo são as distribuições Linux.

Case X

Como eu já comentei pelas listas da vida, eu criei e ocasionalmente ministro o curso de BI com Pentaho da 4Linux, presencial e EAD.

Entre setembro e outubro eu ministrei uma turma de Pentaho EAD. Um dos meus alunos manteve contato comigo e fomos trocando figurinhas até que ele veio a São Paulo e marcamos uma pizza. Entre outras coisas, conversamos sobre seu futuro e sua carreira em BI. Dei minha opinião sobre algumas de suas idéias, pá e tal. Isso foi em 14/11/11.

Hoje, 12/12/11, nem um mês depois, ele me liga para contar que vai abrir uma empresa de soluções de BI. Uau, isso foi rápido! Mas o mais legal é o que ele conseguiu, e como isso o motivou:

1. Ele seguiu a dica básica "trabalhe de graça e consiga um case": ele implantou uma solução de BI completa, de modelo dimensional e ETL à cubo OLAP e metamodelo em algumas semanas.
2. O resultado ficou tão bom (crédito para ele, que já tinha alguma experiência com Pentaho, e entende o que é atender bem), que o case virou cliente: devem trocar o ERP em breve, mas não vão mudar o BI, vai continuar sendo Pentaho.

Ele está finalizando a criação da empresa e prometeu-me que, quando estiver tudo assinado e pronto, me libera para eu contar os detalhes (porte da solução, nome do cliente, da empresa etc.) Por isso o nome Case X: ainda não posso contar nada.