Eu já abordei este tema antes no contexto de outros assuntos, mas hoje gostaria de explicar exatamente o que é e para que serve uma Plataforma de Aplicação.

A Plataforma de Aplicação é a Plataforma mais próxima à aplicação que fica em cima da Plataforma Virtual. Você deve dar uma olhada no cubo arquitetural e no conceito de plataforma antes de prosseguir.

A Plataforma Virtual é ocupada pela Plataforma Java ( ou .NET, ou outra similar). A Plataforma provê tipos de dados comuns à vasta maioria de aplicações que podemos querer desenvolver mas quase nunca fornece tipos úteis para o domínio de negócio da aplicação.

A Plataforma de Aplicação fornece os tipos e mecanismos úteis à aplicação em si mesma ou a um conjunto de aplicações no mesmo contexto, por exemplo, a uma familia de produtos.

A Plataforma de Aplicação sempre está presente em todos os projetos. Ela é conhecida como “a infra” ou “o framework que fizemos para …“, ou “a arquitetura“,  ou “as classes de base“, ou outros nomes semelhantes. Repare que o uso destes nomes e expressões já é um indicativo da falta de conhecimento e respeito, em geral, pela Plataforma de Aplicação.

A Plataforma de Aplicação não inclui as entidades nem as classes de domínio onde estão as regras especificas do funcionamento do software como serviços ou repositórios. Contudo ela é a base para a construção dessas classes. Ela fornece formas de ORM , I/O, decisões baseadas em ambientes, componentes UI, entre outras coisas.

Normalmente os desenvolvedores utilizam um conjunto de bibliotecas de terceiros para “facilitar” a criação da aplicação. Frameworks como o Hibernate, o Spring e o Stuts são comuns hoje em dia, além do onipresente Commons-Upload em aplicações web e o Swing em aplicações desktop. O “encaixe” destes frameworks forma, para a maioria dos projetos a sua Plataforma de Aplicação, mas a maioria dos desenvolvedores não vê que está decidindo como será a plataforma de aplicação.

A plataforma de aplicação é responsável pela evolução do software enquanto peça de tecnologia e pela maioria dos requisitos não-funcionais, enquanto a aplicação em si, é responsável pelos requisitos funcionais. Contudo, quando mal desenhada é a responsável pela obsolescência tecnológica da aplicação e pelo impedimento na evolução da aplicação.

O problema de definir uma plataforma de aplicação é garantir que ela poderá evoluir no tempo de forma independente da aplicação ao mesmo tempo que a aplicação evoluir independente da plataforma. Se a plataforma e a aplicação evoluem ao mesmo tempo ou com dependências isso significa que não existe realmente uma plataforma de aplicação, ou ela é fina demais, e a aplicação como um todos depende diretamente da Plataforma Virtual.

Muita gente não entende porque Java tem tantos frameworks, sendo a grande maioria para a “mesma coisa”. A razão para isso é que a Plataforma Java sempre se posicionou como uma plataforma virtual, ou seja, espera-se que o desenvolvedor crie uma plataforma de aplicação em cima dela e não saia programando diretamente sobre a plataforma virtual ( o Java “puro”). Mas poucos fazem isso, a maioria porque não sabe que deveria fazer isso e o resto porque acha que não tem tempo para isso.

O problema é mais evidente em Java para desktop onde existem menos frameworks de terceiros. O programador tende a cair na tentação de utilizar o Swing diretamente, por exemplo sem prensar que isso significa amarrar as capacidade da aplicação às capacidades “puras” do swing. Quando for necessário criar algo diferente o programador luta em procurar alguma API de terceiros, ou simplesmente modifica os requisitos para evitar problemas.

Porque o desenvolvimento com Java depende da escolha/construção de uma plataforma de aplicação ele tente a ser mais complexo e demorado que em outras tecnologias. Mas isto só acontece porque tantos os desenvolvedores quantos as empresas falham em entender que o custo do desenvolvimento da aplicação está na sua maioria no desenvolvimento da plataforma de aplicação e não na aplicação em si.

Ao ignorar a existência desta plataforma por baixo da aplicação as empresas não tiram vantagem dela deixando o custo de criar dita plataforma se multiplicar para todos os projetos da empresa. Exemplos como a Apache  Foundation  que partem sua plataforma de aplicação em pedaços independentes ( os famosos commons) são ainda raros.

Construir uma plataforma de aplicação que possa ser usada por mais do que uma aplicação não é trivial, mas nunca vai conseguir construí-la se não tentar. Errar ao construí-la é fácil e caro, portanto,  prepare-se. Mas não construí-la é mais caro ainda.

A Plataforma de Aplicação pode ser tanto um bem (asset) como um risco (liability) dependendo da sua qualidade. Entender o que significa isto requer ter desenvolvido mais de três tipos de aplicação com mais de três tipos de arquitetura e não é uma tarefa para estagiários e juniors … às vezes nem para seniors. Desenvolver uma plataforma de aplicação própria deve ser a primeira preocupação de uma produtora de  software pois é o seu centro de maior  custo e maior risco. Deixar cada equipe desenvolver sua plataforma torna o ambiente heterogêneo e impossível de migrar os benefícios de uma aplicação para outra. Obviamente, se a produtora de software utiliza mais do que uma plataforma virtual, deverá ter mais do que uma plataforma de aplicação, mas mesmo assim, muitos conceitos podem ser comuns variando apenas na implementação. Hoje em dia com linguagens que funcionam em mais do que uma plataforma virtual – como Ruby em Jruby (Java) e IronRuby (.NET) e na Ruby VM –  é possível até antever a possibilidade de desenhar uma plataforma de aplicação única para diferentes plataformas. No extremo a plataforma de aplicação pode até implicar em desenvolver uma linguagem própria que funcione em várias plataformas para eliminar mais esse fator de diferença. Obviamente o perigo de desenhar errado aumenta quando mais fundo você que ir ( até o nivel da linguagem) ou mais abrangente (diversos tipos de arquitetura e aplicação).

Criar e manter uma Plataforma de Aplicação não é simples,  não é rápido, e não é barato, mas é essencial para cortar custos.  Um modelo atual para lidar com o imenso esforço que é criar e manter uma Plataforma de Aplicação passa por oferecê-la como Open Source. Afinal, ela não contém nenhum “segredo” da sua aplicação. Ao disponibilizá-la como Open Source mais pessoas a irão usar, mais bugs serão corrigidos, mais flexível e expansível será e o custo será rateado entre todos os utilizadores. Este modelo é seguido por diferentes companhias como a Apache Foundation , já mencionada, a Eclispe Foundation e a Nokia, por exemplo.

Seja como for que você decidir seu modelo de negocio em relação à Plataforma de Aplicação, esteja pelo menos consciente da sua inexorável existência, os risco que implica e os custos que trás a cada projeto.

Em qualquer opção o(s) empresário(s) responsável(eis) pelo software precisam suportar a idéia de criar uma plataforma de aplicação e a ver como um investimento para cortar custos e não como um forno de queimar dinheiro. Contudo, têm que saber escolher as pessoas para a equipe que poderá concretizar esse projeto e ter sempre em mente que ninguém com menos de 3 a 5 projetos de experiência poderá alcançar esta meta. Ou seja, precisará de pessoas competentes e capacitadas.

Se você é free-lance, não muda muita coisa. É mantendo uma Plataforma de Aplicação que você poderá ganhar mais e produzir mais depressa. Claro que sendo sozinho é complicado manter uma, portanto, neste caso é melhor partir para a integração de framework já existentes e ir criando classes que os vão abstraindo aos poucos. Assim, a sua plataforma cresce a cada projeto e cada projeto tem menos custo que o anterior. Outra opção é aproveitar-se do Open Source da mesma forma que uma empresa normal.

Se você trabalha numa filosofia ágil entenda que é a Plataforma de Aplicação que lhe dá a velocidade na implementação. Sendo que ela é comum a mais do que uma aplicação ela é mais estável, mais bem testada e isso ajuda a se concentrar apenas nas features da aplicação. O seu backlog técnico diminui cada vez mais à medida que sua plataforma matura. Em particular é possivel ter duas equipes uma para a plataforma e outra para a aplicação tal que os seus membros sejam intercambiáveis dando a todos o conhecimento de ambos os lados do problema.

Agora, volte no seu projeto e entenda o que é aplicação e o que é plataforma de aplicação …