apresentação executiva
DESCRIPTION
Apresentação Executiva.TRANSCRIPT
Apresentação Executiva
JustinoDiretor Comercial
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
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.
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.
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.
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
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
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
O negócio da sua organização édesenvolver framework de
integração Java EE?
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.
• 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 é
Por que ter uma arquitetura ouframework de integração
em Java EE?
• 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.
Desenvolver um framework integrador interno
é a melhor opção?
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?
Se todas as respostas foram satisfatórias, quais os passos
para se desenvolver um framework interno?
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?
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.
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
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.
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.
A organização possui umframework interno
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.
A minha organização não sepreocupa com uma
Arquitetura econtrata fábrica de software
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.
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.
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.
Minha organização não sepreocupa com que o framework
possua uma Arquitetura deReferência
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.
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“.
O que a minha organizaçãoganha em utilizar o
jCompany Suite?
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.
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
• 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?
• 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
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.
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.
Ú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?
