O documento fornece informações sobre a história e o crescimento de uma empresa de tecnologia ao longo de 15 anos, desde o lançamento da primeira versão de seu framework Java EE até investimentos, clientes, certificações e presença geográfica atual.

1. Apresentação Executiva
Justino
Diretor Comercial

2. Timeline
• 2002 – Início do desenvolvimento
• 2003 – Lançamento da versão 1.0
• 2003 – Aporte BNDES – 1.2 Milhões de Reais
• 2003 – Lançamento da versão 1.5
• 2005 – Lançamento da versão 3.0
• 2007 – Lançamento da versão 5.0
• 2007 – MPS.BR Nível F com metodologia Scrum
• 2009 – Lançamento da versão 5.5
• 2010 – MPS.BR Nível C com metodologia Scrum
• 2010 – Lançamento versão “6.0 Preview”
• 2010 – Aporte BNDES – 2.4 Milhões de Reais

3. O jCompany em números
• Um framework estável com 7 anos de mercado.
• Atualizado tecnologicamente (Up-to-Date).
• Em 7 anos, mais de 26 lançamentos de versões e releases.
• Mais de 1.500 subscrições.
• Mais de 200 clientes corporativos e órgãos públicos.
• Mais de 1.100 projetos em produção.
• Mais de 180.000 Pontos de Função desenvolvidos.
• 3.421 profissionais treinados.
• 111 profissionais certificados.
• 54.736 horas de treinamento já realizados.
• 164.208 horas de mentorias já realizadas.

4. O Futuro
• Investimento para 2011/2012 de 3,4 Milhões de Reais
• 2,4 Milhões Prosoft – BNDES.
• 1 Milhão em recursos próprios.
• Java EE 6 (2010)
• Suporte às novas APIs Java EE 6: CDI 1.0, JAX-RS 1.1, JAX-WS
2.1, Bean Validation 1.0, JSF 2.0 (Facelets incluído) e JPA 2.0.
• Web 2.0 (2011)
• Arquitetura MVP com uso do SOFEA/SOUI.
• HTML5.

5. Presença Nacional
• Rede de canais altamente especializada, dentro de um
rigoroso processo de certificação e capacitação.
• Presente em 80% das capitais brasileiras.
• Presente em 23 estados brasileiros.
• Fábricas de software homologadas e certificadas em todas
as regiões do país.
• Padrão de desenvolvimento Java EE nos Estados de Minas
Gerais, Espírito Santo e Rondônia.

6. Presença no Judiciário
• Tribunal de Justiça do Rio Grande do Sul
• Tribunal de Justiça de Rondônia
• Ministério Público de Rondônia
• Ministério Público de Minas Gerais
• Tribunal de Contas do Piauí
• Tribunal de Contas do Maranhão
• Tribunal Regional Eleitoral do Maranhão
• Justiça Federal de Santa Catarina
• Tribunal Superior do Trabalho
• 24 Tribunais Regionais do Trabalho
• IPRAJ

7. Presença – Setor Público
• BNDES
• Prodemge
• Prodabel
• Prodaub
• Prodest
• Seplan de Rondônia
• Marinha do Brasil
• Capes
• BHtrans
• Cepel
• Ipsemg
• CBMES
• CEFET
• CEPEL
• CETEM
• Dataci
• DER-MG
• HSE-RJ
• IPM
• Jucemg
• Prefeitura Municipal da Serra
• Sefaz-AL

8. Presença – Setor Privado
• Drogaria Araujo
• Tacom
• Datapuc
• Pague Menos
• Qualicorp
• Sal Cisne
• Santana Têxtil
• Têxtil Bezerra de Menezes
• Carol
• Edusoft
• Fundação Sidertube
• Cenibra
• Grupo Multi
• Hermes Pardini
• J.Macêdo
• JP Industria Farmacêutica
• Magnesita
• Medisoft
• Mestra
• MicroUniverso
• Nortel
• Softplan
• Unimed Maceió
• Command Perfect

9. O negócio da sua organização é
desenvolver framework de
integração Java EE?

10. O Nosso Negócio é
• Equipes distintas em cada etapa do processo.
• Gerência de P&D - Equipe dedicada e especializada com
mais de 20 engenheiros de software para a realização de
pesquisa e desenvolvimento em Java EE.
• Gerência de Mentoria - Equipe especializada formada por
profissionais da empresa e por profissionais certificados
de parceiros para a realização de treinamento e mentoria
de alto nível.
• Gerência de Suporte - Equipe dedicada de suporte de 1° e
2° níveis.
• Gerência de Pré-vendas – Equipe responsável pelo apoio
comercial, realizações de apresentações, prova de
conceito e projeto piloto.

11. • Equipes distintas em cada etapa do processo.
• Gerência de P&D - Equipe dedicada e especializada com
mais de 30 engenheiros de software para a realização de
pesquisa e desenvolvimento em Java EE.
• Gerência de Mentoria - Equipe especializada formada por
profissionais da empresa e por profissionais certificados
de parceiros para a realização de treinamento e mentoria
de alto nível.
• Gerencia de Suporte - Equipe de suporte de 1° e 2° níveis
dedicada.
• Gerencia de Pré-vendas – Equipe responsável pelo apoio
comercial, realizações de apresentações, prova de
conceito e projeto piloto.
O Nosso Negócio é

12. Por que ter uma arquitetura ou
framework de integração
em Java EE?

13. • Uma arquitetura ou framework de integração é importante
para garantir um padrão de desenvolvimento e aumentar a
produtividade.
• Seria praticamente impossível o desenvolvimento de
projetos em Java sem utilizar as bibliotecas (frameworks) de
base; a produtividade seria próxima a zero.
• Felizmente nos últimos anos surgiram várias iniciativas e,
sem dúvida, o movimento de Software Livre e a Internet
tiveram um papel importantíssimo.
• Há várias iniciativas acadêmicas, autônomas e empresariais.
• A grande questão é como trazer estas iniciativas para o
mundo corporativo.

14. Desenvolver um
framework integrador interno
é a melhor opção?

15. Antes de Começar, Responda:
• Qual o conhecimento real da equipe?
• Quantos da equipe já desenvolveram ou participaram do
desenvolvimento de um framework que teve projetos em
produção? Há quanto tempo?
• Por quanto tempo os profissionais mais qualificados
estarão envolvidos neste trabalho?
• O orçamento deste projeto contempla todos os custos de
P&D, testes, homologação, desenvolvimento,
documentação, treinamento, consultoria externa, repasse
de conhecimento para equipe?
• Quantos projetos de negócio da empresa deixarão de ser
feitos durante este período?
• E se o arquiteto líder sair deste projeto?

16. Se todas as respostas foram
satisfatórias, quais os passos
para se desenvolver um
framework interno?

17. Passos para Framework Interno
• Definir a arquitetura: MVC? MVP (SOFEA)? Other?
• Requisitos não funcionais
• Compatibilidade entre browsers
• Compatibilidade entre servidores de aplicação
• Portabilidade de Banco de Dados
• Segurança das aplicações a serem desenvolvidas
• Performance e capacidade de escalar para projetos
corporativos
• O que deve ser generalizado para incluir no framework,
evitando redundância de código dos desenvolvedores?
• Como garantir um padrão de codificação evitando
possíveis problemas pelo nivelamento de conhecimento
da equipe?

18. Passos para Framework Interno
• Qual o framework de base (agnóstico) será usado:
• Spring x jBoss Seam x GWT x Weld x Struts x ADF x Struts 2.
• Esta escolha normalmente é feita tomando como base a
experiência pessoal dos arquitetos.
• Que outros frameworks serão usados para complementar
a arquitetura, tais como:
• Visão: RichFaces x Myface x Trinidad x Tomahawk...
• Leiaute: Tiles x Facelets.
• Persistência: Hibernate, JPA (e/ou EJB3), iBatis?.
• Outras para: Buid & Deploy, Teste unitário, SOA, BPM,
repositório, integração contínua, JavaScript, validação,
relatórios, gráficos, Ajax, CSS, XHTML, etc.

19. Passos para Framework Interno
• Desenhar a arquitetura integrada
• Desenvolver e integrar os diversos frameworks de base
• Congelar uma linha de base das tecnologias
• Desenvolver um projeto piloto para validar
• Qual o tamanho ideal do projeto piloto?
• Como validar a segurança e performance?
• A arquitetura ficou robusta para sustentar os aplicativos?
Quais os seus limites?
• Quais os requisitos de hardware?
• Desenvolver a documentação (parte chata que nenhum
arquiteto gosta)
• Desenvolver material de treinamento para equipe

20. Passos para Framework Interno
• A equipe interna não possui experiência; contrata-se uma
consultoria externa. Ótimo, para a consultoria externa.
• Em quais etapas do processo a consultoria irá atuar?
• Na definição da arquitetura, na implementação, na documentação,
no projeto piloto, no material de treinamento, no suporte, no
repasse para toda a equipe, na atualização e evolução do ambiente?
Por quanto tempo?
• Normalmente o consultor envia um excelente/experiente
arquiteto que apóia a equipe interna no desenvolvimento da
arquitetura e sua implementação básica. O restante das
atividades, quando feitas, são responsabilidade da empresa.
• A consultoria conclui o trabalho e vai embora fazer o mesmo
trabalho em outra empresa, sem repassar ganhos de escala.

21. Passos para Framework Interno
• Ufa! Acabou a primeira versão. Hora de medir.
• Qual o resultado estratégico ou de negócio alcançado ao
se concluir o framework interno?
• Quanto tempo levou?
• Quanto efetivamente custou?
• Durante este período, todos os frameworks de base
tiveram versões novas, novas tecnologias. O que fazer?
• Como se trata de um framework interno, quem irá dar
apoio ou suportar? E se apresentar um erro em produção
com suspeita de ser no framework interno?
• Seguramente, se usou uma consultoria externa, o
arquiteto que apoiou este trabalho estará envolvido em
outra empresa.

22. A organização possui um
framework interno

23. Quanto Custa Manter e Evoluir?
• Meça o nível de gestão da sua arquitetura:
• Qual a versão do framerwork interno? Existe apenas uma
ou uma salada de versões é fornecida?
• Quanto efetivamente custou o seu desenvolvimento?
• Quanto vai custar para mantê-lo/atualizá-lo?
• Qual o seu nível de documentação?
• Qual o nível de dependência das pessoas que a
desenvolveram?
• Se a corporação não tem boas respostas para as
perguntas acima, é sinal de que algo não vai bem.

24. A minha organização não se
preocupa com uma
Arquitetura e
contrata fábrica de software

25. Fábrica de Software
• Se os sistemas fossem produtos descartáveis a
preocupação na manutenção evolutiva e adaptativa não
seria importante.
• Os sistemas são ativos da organização, desenvolvidos para
serem capazes de evoluírem e mudarem segundo as
necessidades da organização.
• Sem uma arquitetura própria a organização que contrata
fábrica de software fica refém do fornecedor e, o que é
pior, em muitos casos de um arquiteto do fornecedor.
• As equipes internas não conseguem dar manutenção nos
sistemas produzidos desta forma e nem repassar para
outras fábricas de software.

26. Fábrica de Software
• Normalmente as fábricas de software possuem seu
framework proprietário interno e repassam sem custos
para os projetos. Excelente, desde que:
• Repasse toda a documentação e os códigos fontes
• Repasse o material de treinamento do framework
• Assuma a responsabilidade de suporte no framework
• Assuma a responsabilidade de atualização
• Garanta a compatibilidade com novas versões
• Fora deste contexto, fique atento: o barato sai muito caro.
• Se uma organização possui 3 fábricas de software, terá 3
arquiteturas ou frameworks para aprender e manter.

27. Fábrica de Software
• O modelo de fábrica de software se inspirou no modelo
de fábrica de outros setores. Entretanto, nestes setores a
responsabilidade das definições estruturais e de
qualidade do produto é de quem contrata.
• Como garantir um padrão de desenvolvimento?
• Como garantir a qualidade do sistema?
• Como garantir que foram usadas as melhores práticas?
• Como garantir a qualidade do código?
• A inspeção de código somente, é inviável e onerosa; a
solução é a automação de testes, sendo este um dos
recursos básicos de um framework de integração.

28. Minha organização não se
preocupa com que o framework
possua uma Arquitetura de
Referência

29. Arquitetura de Referência
• Quando se diz uma arquitetura de referência, espera-se
uma arquitetura completamente documentada, com
material de referência, material de treinamento, projeto
piloto desenvolvido e prova de certificação?
• Ou aceita-se apenas uma lista de frameworks de base a
serem utilizados?
• A composição molecular de uma pedra de carvão e de um
diamante é a mesma. Porém, com estruturas moleculares
totalmente diferentes.
• As combinações possíveis em um cenário com essa
liberalidade aceita resultados completamente diferentes
para problemas similares. Ou seja, não há um padrão de
fato.

30. Arquitetura de Referência
• O produto retornado por uma fábrica de software em
uma arquitetura fraca de referência não tem o que se
validar em termos de arquitetura, porque qualquer tipo
de implementação deve ser aceita e não há o que possa
ser questionado.
• O que não pode ser medido, não pode ser gerenciado.
• É um modelo totalmente Laissez faire, literalmente
"deixai fazer, deixai ir, deixai passar“.

31. O que a minha organização
ganha em utilizar o
jCompany Suite?

32. O Que Ganho com o jCompany?
• O jCompany não é a bala de prata ou a caixa de Pandora.
É um ambiente de referência pronto para ser estendido e
adaptado às necessidades de negócios.
• O nível de discussão dos arquitetos altera da escovação de
bit-byte de frameworks de base para as necessidades de
negócios da organização.
• Garantia de escalabilidade das aplicações desenvolvidas.
• Garantia de compatibilidade com os principais Browsers.
• Garantia de portabilidade para os principais servidores de
aplicação, sendo: Tomcat, JBoss, WebSphere, Weblogic...
• Garantia de portabilidade para os principais servidores de
banco de dados.

33. O Que Ganho com o jCompany?
• Aderência imediata a padrões de mercado
• Segurança (controle de acesso) dos aplicativos
• Redução da curva de aprendizado
• Padronização de fato, em nível de código
• Automação de testes, possível em todos os níveis
• Gerência de configuração
• Governança de arquitetura
• Transferência total do conhecimento para organização
• Liberdade na contratação de fábricas de software
• Foco da organização nas necessidades do negócio

34. • Um framework padrão de mercado, de fato
• Uma arquitetura com 7 anos de maturidade
• Acesso ilimitado aos código fontes
• Suporte dedicado e formal
• Atualização continuada nas tecnologias
• Treinamentos formais e padronizados
• Documentação completa em português
• Vasto material de referência e de pesquisa
• Inúmeras implementações de referência
• Processo formal de certificação de profissionais
O Que Ganho com o jCompany?

35. • Acesso ao comitê de arquitetura para definir Backlogs e
prioridades
• Indicação de arquiteto para participar de Release Planning
e Release Review
• Acesso a Diretoria de Tecnologia
• Garantia contratual de compatibilidade entre as versões
• Responsabilidade com a base instalada
Os Ganhos Institucionais

36. 7 anos de jCompany Developer
• Nestes 7 anos do lançamento do jCompany Developer
vimos o surgimento e ocaso de vários frameworks de
base. Entretanto, o mercado está cada vez mais maduro e
a prova disso é o lançamento dos padrão Java EE 6 e
MVP/SOFEA no jCompany Suite 6.0.
• O maior desafio não é fazer um framework, é mantê-lo
atualizado ao longo dos anos.
• Cada vez mais as organizações buscam focar nas suas
atividades fins, repassando riscos, minimizados custos e
maximizando resultados.

37. Algumas Lições Aprendidas
• Muitas ‘sopas de letrinhas’ surgiram nos últimos anos.
Porém, o que importa de fato são sistemas rodando em
produção sobre padrões práticos.
• O sistemas são Ativos de Software das organizações, bem
como sua arquitetura, separadamente.
• Cada vez mais a governança corporativa e a segurança da
informação são vitais para as organizações.
• Se de um lado temos a dependência e o alto custo dos
softwares proprietários, de outro temos a liberdade sem
compromisso do software livre; o que se deve buscar é o
equilíbrio dos lados.
• Liberdade com responsabilidade.

38. Últimas Considerações
• Ao se definir por adquirir uma arquitetura corporativa de
um fornecedor, é importante destacar alguns aspectos de
negócios:
• Quão importante é a sua organização para o fornecedor
escolhido?
• A sua organização consegue acesso a todos os níveis de
decisão do fornecedor?
• A sua organização consegue voz ativa na definição das
próximas versões ou fica a mercê de um ‘grupo de gurus’?
• Existe um contrato formal que garanta a compatibilidade
das novas versões e que preserve o investimento realizado?

39. A decisão cabe a você
EXECUTIVO!
Obrigado.
Justino
(31) 9313-4910
justino@powerlogic.com.br