Construindo um Business Framework
Antes de falar sobre o Orun (Open Runtime), vou tentar fazer uma reflexão, ainda que breve, sobre as linguagens e frameworks voltadas para o desenvolvimento de soluções empresariais e de que maneira nos influenciaram e ainda influenciam a construir ferramentas mais produtivas.
Não vou aqui abordar o que é um software ERP ou mais profundamente tecnologias de terceiros, existe um vasto material que versa sobre o tema na web. O objetivo é tratar das principais técnicas para a construção desse tipo de desenvolvimento.
Linguagens e tecnologias orientadas a negócios
No passado, líderes dessa indústria apostaram em novas técnicas como o desenvolvimento linguagens como COBOL para soluções de grande porte, ou dBase e Clipper para soluções mais compactas. Com o passar do tempo robustos softwares para gerenciamento de bancos de dados foram desenvolvidos e distribuídos no mercado, o viabilizou o desenvolvimento de sistemas “domésticos” dentro das próprias empresas que utilizariam.
A fragmentação
Se por um lado a democratização das linguagens e soluções de armazenamento e processamento de dados modernizaram e simplificaram o acesso das empresas ao desenvolvimento de sistemas construídos dentro de suas próprias estruturas. Por outro lado a falta de padrões de desenvolvimento e a grande fragmentação pela adoção tecnologias distintas consequentemente forçou as empresas a colocarem mais energia e investimentos em maneiras de integrar tais softwares.
A necessidade
Se torna clara a necessidade de se construir um sistema integrado objetivando unificar todos os setores da empresa e gigantes da tecnologia do segmento de soluções ERP surgem apostando em estratégias não somente para entregar um produto pronto para o uso que já integrava seus diferentes setores comuns, mas também buscaram disponibilizar um conjunto de ferramentas para simplificar e padronizar o desenvolvimento de customizações e extensões do produto enviado ao usuário final.
A razão óbvia para ofertar a customização é que, apesar das empresas terem necessidades básicas comuns, também possuem diferentes necessidades conforme sua cultura interna, fatores externos como burocracias governamentais ou até demandas específicas dos seus clientes.
Apesar de já existirem ERP’s opensource, ainda é comum que grandes empresas utilizem tecnologias fechadas seja por legado, confiabilidade, credibilidade ou até desconhecimento.
Construindo um sistema administrativo
No começo dos anos 2000, empresas de médio porte já se sentiam atraídas a construir sistemas com características mais domésticas que tivessem como objetivo atender exclusivamente suas demandas internas. Nessa época programadores Delphi eram bastante requisitados, e apesar de reconhecer o alto nível de entrega que softwares escritos com essa linguagem, por outro lado tal ferramenta de desenvolvimento era flexível demais e a falta de padrões fragmentava e isolava os diversos setores das empresas.
Mesmo com falta de um produto adequado para o fim específico de construir sistemas administrativos integrados, empresas muito organizadas conseguiam atingir um bom nível resultado com o desenvolvimento e manutenção adotando o conjunto de ferramentas da Borland com a adição de alguns componentes de terceiros.
Boa parte dos problemas encontrados com equipes Delphi e Java, por exemplo, simplesmente não existiam em empresas que dispunham de SAP, por exemplo, uma vez que o produto dessa empresa oferecia um conjunto de regras para integração, manual de boas práticas, além de um ambiente de desenvolvimento integrado que era adequado conforme necessidade de se construir soluções integradas à estrutura básica.
Geradores de aplicações
O principal objetivo de uma ferramenta que auxilie a produção de sistemas de gestão é a sua capacidade de acelerar a entrega dos recursos básicos de um software desse tipo, por exemplo a geração de formulários de entrada para CRUD com o mínimo possível de implementação de código (o que recentemente é conhecido por low-code)
No decorrer dos anos 2000 muitas ferramentas desse tipo surgiram e prometiam entregar a solução definitiva para o ambiente corporativo. Ocorre que alguns aspectos eram ou são simplesmente negligenciados através deste método. Entre os principais motivos há a dificuldade de realizar tarefas mais complexas ou até mesmo de ter controle sobre o produto final.
Outras dificuldades podem ser:
- Baixo engajamento ou ausência de comunidade
- Inexistência de uma forte API para integração
- Ausência de código-fonte ou de documentação
- Ausência de linguagem que possibilite concordar os obstáculos para a construção de ERP’s
- Ausência de um conjunto de componentes organizados
- Código gerado complexo, repetitivo ou práticas heterodoxas
Pontos como código-fonte proprietário dificultam o engajamento consequentemente empresas mais organizadas dificilmente fariam adesão.
Frameworks
Com a utilização de uma boa linguagem de fácil compilação ou interpretação por baixo do capô, não é difícil supor que esse caminho apresentaria um menor número de armadilhas ou resistências de aderência uma vez que os recursos são mais explícitos e geralmente a codificação pode ser realizada num editor textos comum.
Nessa abordagem, alguns pontos como quantidade excessiva de código produzido ou dificuldade de customizar o resultado não seriam necessariamente um problema. Apesar de alguns pontos negativos continuarem existindo, como a dificuldade de se portar o código final para outros frameworks, todavia esse tipo de deficiência não pode ser debelada exceto com adoção de uma linguagem específica para o fim de se construir ERP.
Contudo, é possível combinar um toolkit visual ou IDE com um framework para aumentar a produtividade ou geração de código específico para as bibliotecas padronizadas de uso.
Python e Javascript
Como descrevi anteriormente, uma linguagem sofisticada e com os recursos certos pode conceber um framework ou até uma lib para atender a nossa demanda. Conhecendo os web servers escritos em Python e estudando mais profundamente os recursos da linguagem, fica claro que essa linguagem possui as características necessárias e se torna forte candidata para a construção desse tipo de software.
O OpenERP serviu de bastante inspiração para que eu pudesse enxergar como Python facilitaria a construção de módulos permitindo a extensibilidade do ambiente através de recursos avançados da linguagem como metaprogramming, interpretação de blocos, dados estruturados, carga dinâmica dos módulos, entre outros.
Até 2018 usei pontualmente o framework que combinava Flask e SqlAlchemy para atingir resultado funções limitadas se comparada ao OpenERP.
A possibilidade de usar o próprio OpenERP foi descartada por principalmente por não permitir acesso a bancos SQL Server (que era uma condição para nós) e também pelo fato de ser GPL até essa época.
Levando em conta que construiria algo novo, os principais que aspectos que um framework precisaria ofertar seriam:
- Suporte a vários tipos de de banco de dados
- Simplificar testes unitários
- Web e Mobile-first
- Relatórios de primeira classe
- Simplificar acesso via HTTP API
- Padrão MVC
- Camada de abstração de dados
- Internacionalização/tradução
Recursos triviais necessários para a construção de um software ERP:
- Área de navegação ou menu
- Forms para CRUD
- Controle de permissão
- Editor e visualizador consultas
Recursos avançados adicionais:
- Linguagem orientada à negócios para facilitar a implementação de regra de negócios (business rules)
- IDE (Ambiente Integrado de Desenvolvimento)
- BI (Ferramentas para construção de dashboards)
Apesar de um IDE próprio não ser condição sine qua non, recursos que simplifiquem o desenvolvimento de um software modular tão complexo são bem-vindos e podem resultar em maior produtividade e facilidade de manutenção, principalmente quando se tratar de recursos mais heterodoxos que sejam específicos de um framework.
Django
Depois de atuar profissionalmente com Django e conhecer sua filosofia DRY por 5 anos, percebi que esse web framework já oferecia todos os recursos básicos de maneira bastante padronizada e madura, o que me levou a substituir o Flask.
Para evitar um grande número de monkey-patches em códigos Django, preferi criar um fork e consequentemente um projeto derivado, o que me levou a ter mais flexibilidade nas mudanças necessárias para que este fosse voltado para o desenvolvimento de ERP’s.
A maior parte dos recursos padrão do Django foram mantidos apesar da necessidade de profundas mudanças no ORM. Também foi ou está sendo necessário implementar novos recursos como os comandos de administração do ambiente.
Principais mudanças estruturais
Model Helpers
O objetivo de um Model Helper é adicionar recursos a um model existente. Este recurso se diferencia do Proxy Model do Django principalmente por permitir que novos campos sejam adicionados a um model pré-existente.
Um ambiente administrativo dinâmico pode permitir que novos módulos sejam adicionados sejam instalados como num ambiente plugável através de addons. Essa característica é extremamente eficiente ao se idealizar uma estrutura realmente hierarquizada de módulos. Imaginemos a construção de uma solução baseada em addons interdependentes que podem ser instalados on-demand, por exemplo: Um novo campo pode ser adicionado a um Model Helper para Partner em um módulo que adiciona novas características ao Model Partner Ancestral.
Até aqui, a simples adoção de OOP seria o bastante para se alcançar o objetivo almejado. Agora tornemos o exemplo mais complexo e imaginemos que 2 plugins adicionais contribuam adicionando características e comportamentos a uma classe ancestral, por exemplo: O módulo HR adiciona um campo is_employee ao Model Partner em base, e sempre que um objeto do Model Contract for criado o campo is_employee para o Partner relacionado por uma foreignkey seja modificado para true ou false conforme situação do contrato. Um segundo addon, Purchases, adiciona o campo is_supplier ao Model Partner ancestral para indicar que um parceiro é um fornecedor.
Modularização
Os apps Django são simples e seria necessário um grande número intervenções no bootstrap afim de permitir que sua carga fosse orientada à hierarquia dos módulos, bem como a determinação das novas propriedades.
Em contraposição, os apps do Orun são como addons, são mais complexos e permitem que seja especificado uma lista de dependências, o que resulta numa estrutura hierárquica modular.
Conclusão
O Open Runtime visa delinear os padrões que permeiam o desenvolvimento de soluções empresariais bem como instrumentalizar o desenvolvedor com recursos para acelerar as entregas e viabilizar a manutenção. Até o presente momento sua construção foi bastante complexa e ainda há muito a ser feito.
Nos próximos posts tentarei apresentar mais detalhadamente o core do framework com exemplos reais da sua implementação e sempre que possível estabelecendo uma linha comparativa com o Django.