Marco Mendes´s Blog

A IBM Rational, divisão de software da IBM que cuida da governança do ciclo de vida do desenvolvimento e entrega de softwares, fez o lançamento da nova versão do RMC (Rational Method Composer), um software que permite a criação e publicação de processos em portais Web. A nova versão 7.5 traz como grande novidade o conceito de práticas. Uma prática pode ser entendida como uma abordagem documentada para resolver problemas recorrentes no desenvolvimento de sistemas e possui as seguintes características:

• Uma prática pode ser adotada independentemente de outras práticas. Isso permite uma implementação de processos muito mais facilitada, suportada por pequenas ondas de implementação de um programa de melhoria contínua da maturidade de processsos.
• A adoção de uma prática pode ser medida. Este aspecto traz como raiz os conceitos de BPM, onde qualquer processo implementado deve ser medido para avaliar a sua efetividade.
• Uma prática está alinhada diretamente a uma melhoria no negócio. Novamente, os conceito de BPM estão aqui permeando a concepção do novo processo unificado.

As práticas centrais estão descritas abaixo:

As práticas estão agrupadas nas seguintes categorias:

• Gerência de Requisitos
• Práticas Ágeis
• Gerência de Arquitetura
• Gerência de Qualidade
• Controle de Mudanças e Entregas
• Governança e Regulamentações (Governance and Compliance)

Ao lermos esta documentação, percebemos uma grande dose de humildade ao reconhecer o valor das práticas ágeis. Virtualmente toda prática traz elementos das escolas ágeis. Pragmaticamente, isso é devido à grande influência do Scott Ambler no desenho desta nova arquitetura de processo. Outra forte influência foi o OpenUP, processo ágil baseado no UP e criado originalmente por um brasileiro, o Ricardo Balduíno!

Um ponto (negativo) no novo processo é que o corpo de conhecimento destas práticas ainda está isolado da documentação do RUP 7.0.1, como podemos observar na figura abaixo:

A documentação das práticas traz novos artefatos e tarefas que não estão presentes na outra documentação do RUP. Esperamos que no futuro estes corpos de conhecimentos sejam mesclados para maior simplicidade da leitura do processo.

Em artigos futuros iremos detalhar estas práticas e o seu valor real para o desenvolvimento de projetos de software.

Pensamento do Dia: “Continue Faminto, Continue Tolo”, Steve Jobs.

O conceito de Design Patterns se tornou relativamente popular dentro da TI. Entretanto, eles ainda mais citados que praticados e diversos profissionais de TI ainda acreditam que eles são peças tecnicistas que somente podem ser usados por especialistas em linguagens OO. Padrões, em verdade, significam melhores práticas provadas pela indústria de TI. Praticamente todo profissional de TI pode se beneficiar dos padrões.

Para contribuir na disseminação do conceito de padrões, compartilho neste blog corpos de conhecimentos sobre padrões que podem ajudar a maior parte dos profissionais de TI que estão envolvidos nos desafios do desenvolvimento de software.

• Padrões de Desenho (Design Patterns). São os padrões clássicos para o projetista de TI, compilados inicialmente por Erich Gamma no começo dos anos 90. Uma referência lúdica sobre o tema pode ser encontrada aqui e é especialmente indicada para os iniciados. Para os mais experientes, recomendo os artigos do Erich Gamma na Artima - How to Use Design Patterns, Design Principles from Design Patterns, Erich Gamma on Flexibility and Reuse, Patterns and Practice. Uma comunidade muito ativa sobre este tópico é o HillSide.
• Padrões de Gerência de Configuração. Problemas sobre manter versões de manutenção evolutiva e corretivas consistentes, como criar ambientes estáveis para desenvolvimento de código e técnicas de como melhorar builds podem ser encontradas no excelente SCM Patterns.
• Padrões Arquiteturais. Estes padrões lidam com estratégias de organização de aplicações, como decomposição em camadas, integrações, técnicas de persistência, entre outros. Impossível não citar o trabalho de Martin Fowler nesta área e o seu site de padrões arquiteturais. Para os arquitetos de integração, um excelente site é o mantido por Gregor Hohpe (EAI PAtterns). Para os adeptos .NET, o APP Arch Guide é também um excelente site sobre o tema. Para os adeptos Java, os J2EE Patterns são obrigatórios.
• Padrões de Análise. Indispensável para analistas de requisitos e sistemas, padrões de análise nos permitem estruturar modelos de domínios mais consistentes. Neste aspecto, Martin Fowler (novamente!) mantém um excelente repositório sobre estes padrões de análise.
• Padrões de Processo. Dicas e técnicas sobre a implementação de processos de software em organizações de TI podem ser encontradas no site da AmbySoft, empresa do Scott Ambler. O modelo IDEAL do SEI também é uma excelente fonte de idéias sobre processos de implementação de processos.
• Padrões de Implementação. O site sobre refactoring é uma coleção de práticas valiosas sobre como manter a estabilidade e qualidade de um código à medida que ele se desenvolve em um projeto. Para os programadores Java, recomendo também o site do C2 sobe Java Idioms.
• Padrões de Teste. Um bom local a respeito é o artigo da Microsoft sobre Testing Patterns. Um outro bom artigo sobre padrões de teste está aqui, na base de conhecimento da IDE Java NetBeans. Uma excelente série de artigos também foi publicada pelo autor Marc Clifton - Advanced Unit Testing, Part I - Overview, Advanced Unit Testing, Part II - Core Implementation, Advanced Unit Testing, Part III - Testing Processes e Advanced Unit Testing, Part IV - Fixture Setup/Teardown, Test Repetition And Performance Tests.
• Padrões para Aplicações Web - A IBM desenvolveu um excelente catálogo de padrões para desenvolvimento de aplicações Web que ela batizou de e-Business Patterns.

Indispensável fonte de conhecimento também é a série de artigos das conferências do PLOP, o mais influente congresso mundial sobre padrões. Uma vertente Brasileira existe também e pode ser encontrada aqui (sugarloafplop).

O senso comum nos diz que a coleta de requisitos nos ajuda a entender um determinado problema. Entretanto, requisitos são uma forma de definir uma solução e não de entender um determinado problema. Para entender um problema, devemos trabalhar em suas causas raízes através de técnicas formais chamadas de identificação e análise de problemas.

Estas técnicas de identificação e análise de problemas são trabalhadas em uma excelente apresentação por um autor chamado Kurt Bittner que trabalhou anos na Rational como gerência de requisitos e possui excelentes livros de modelagem de casos de uso. Faço aqui um resumo destas técnicas, que devem estar no arsenal de qualquer analista de requisitos, e compartilho ao final deste blog o excelente material disponibilizado por este autor.

• Técnicas dos Cinco Porquês (5P). Esta técnica é uma abordagem usada para explorar relações de causas e efeitos de um determinado problema. Por exemplo, se recebemos uma requisição do tipo “Precisamos de um novo Web Site”, devemos recursivamente nos perguntar o porquê desta requisição. Por exemplo: “Estamos perdendo espaço para os competidores”. Mas porque estamos perdendo espaço para os competidores? Talvez seja porque o nosso site não reflita as nossas ofertas atuais de produtos. E continuamos neste processo até que a verdadeira causa raiz do problema (e não o sintoma) esteja elicitado. O número 5 é uma referência básica (número mágico) do número de questionamentos a serem feitos.
• Espinhas de Peixe (Diagramas de Ishkawa). Esta técnica permitir categorizar as causas raízes de um problema e agrupá-las adequadamente. Como esta técnica utiliza esquemáticos gráficos, ela é ideal para brainstorming de grupos e permite representar muitas perspectivas associadas a causas de um determinado problema.
• Mapas mentais. É uma alternativa a diagramas de espinha de peixe em um formato gráfico mais livre. Esta técnica tem se tornado bastante popular com a disseminação de ferramentas para a montagem de mapas mentais (MapMinds).
• Gráficos de paretos. Um gráfico de pareto (Pa Ray To) é um gráfico de barras onde os valores plotados são arranjados em ordem decrescente. Entretanto, esta técnica somente se aplica se possuimos dados sobre as possíveis causas de um problema.

Além destas técnicas, um outro aspecto interessante na análise de problemas é a determinação de “objetivos” ou resultados desejados. Isto porque é inútil trabalhar em um problema (e suas causas) se não existe um objetivo claro ou preciso a ser alcançado. Neste caso, a técnica de “resultados desejados” pode ser usada. Um “resultado desejado” é algo que o usuário ou cliente deseja alcançar no uso da solução. Para isso, devemos associar a cada requisito um resultado desejado e garantir através de uma matriz de rastreabilidade que não existe um “resultado desejado” sem a cobertura de requisitos.

O resumo de toda esta questão é que a “análise de problema” é algo diferente das técnicas de “coleta e elicitação de requisitos”. Requisitos definem soluções. Antes da definição de requisitos, entretanto, devemos conhecer os problemas e oportunidades que queremos tratar.

A apresentação com estas técnicas está disponível aqui para download.

Pensamento do dia:

“Quem tem somente um martelo como ferramenta, tende a achar que tudo que existe no mundo são pregos”

.

A metodologia ágil de gestão de projetos e demandas SCRUM tem se tornado cada vez mais popular e praticada no mercado Brasileiro. Embora este método possa ser implementado em quadro brancos e post-its, ferramentas ágeis podem ser usadas para implementá-lo também. Uma interessante ferramenta lançada este ano, o Rational Team Concert, gratuita para times de até 3 pessoas, possui um suporte completo e personalizável do SCRUM. Li recentemente um excelente paper de como tornar o SCRUM executável, disponível aqui. Este paper discute o uso do Rational Team Concert para implementar o SCRUM na prática.

Para quem ainda não conhece o SCRUM, recomendo um vídeo que recebi recentemente. O vídeo é do Ken Schwabber, um dos seus criadores. Este autor também mantém um excelente blog sobre o SCRUM aqui.

Finalmente, para não banalizar o método, uma entrevista bacana do nosso guru Martin Fowler foi disponibilizada recentemente no InfoQ com informações interessantes sobre como não deturpar esta metodologia

O termo domínio é utilizado para denotar ou agrupar um conjunto de sistemas ou de áreas funcionais que exibam funcionalidades similares.

Exemplos de domínio incluem:

• Domínio de Telecomunicações
• Domínio Logístico Atacadista
• Domínio Bancário
• Domínio de Seguros de Saúde
• Domínio Acadêmico Escolar

Podemos então descrever o domínio aplicacional como sendo uma coleção de aplicações de software que partilham um determinado conjunto de características. Da mesma forma, o domínio é definido por um conjunto de características que descrevem uma família de problemas para os quais uma determinada aplicação pretende dar solução.

Um modelo de domínio é um artefato comum em várias metodologias (RUP ou escolas ágeis) usado para expressar um determinado domínio, normalmente em linguagem UML.

Antes de definir este artefato, vamos dizer o que não é este modelo. Um modelo de domínio não é um diagrama de classes em nível de análise, um diagrama de classes em nível de desenho, muito menos um modelo de entidades e relacionamentos (DER). Um modelo de domínio não carrega informaçães técnicas (Java ou C#), que devem estar presentes em um modelo de desenho. Um modelo de domínio também não carrega todo o detalhamento do comportamento e estrutura (operações e atributos), que devem estar presentes em um modelo de análise. Um modelo de domínio também não carrega informações de armazenamento de informações ou normalizações, que devem estar presentes em um DER.

Mas, afinal, o que é um modelo de domínio?

1. Um modelo de domínio é um produto da modelagem de negócios, i.e., ele representa, em certa escala, o negócio sendo modelado e compreendido.

2. Um modelo de domínio deve, por consequência, ser realizado inicialmente pelos analistas de negócios e usuários do projeto, e revisado e complementado pelo máximo de participantes de um projeto. O modelo de domínio deve ser um artefato colaborativo, compartilhado por todo o time do projeto.

3. Um modelo de domínio captura o vocabulário do sistema ou negócio sob modelagem. Como exemplo, um modelo de domínio de um sistema acadêmico de uma faculdade irá possuir os elementos Aluno, Professor, Curso, Disciplina ou Matrícula, entre diversos outros. Podemos perceber, então, que o modelo de domínio expressa o glossário do negócios sob modelagem.

4. Um modelo de domínio é uma representação lógica e estrutural de elementos do domínio e seus relacionamentos. Um diagrama de classes UML possui os elementos necessários para esta estruturação. Normalmente os conceitos de classes, associações e generalizações são suficientes para estruturar um modelo de domínio. Como consequência, um modelo de domínio não captura interações temporais ou representações físicas de modelagem.

5. Um modelo de domínio expressa uma visão conceitual preliminar acerca de um sistema e é chamado de diagrama de classes conceitual por alguns autores. Um exemplo extraído do excelente site do Scott Ambler (http://www.agilemodeling.com) de modelagem de domínio representa esta idéia.

(c) Scott Ambler, 2003-2006.

6. Um modelo de domínio deve ser feito no começo do projeto. Temporalmente, ele deve ser expresso e ganhar maturidade até o primeiro décimo do projeto. Por exemplo, se você tem na sua mão uma demanda de dois meses, devemos conseguir um modelo de domínio relativamente estável até o fim da primeira semana. Isso requer, como pode ser imaginado, um esforço intenso com os usuários chave para capturar o vocabulário, glossário e representá-lo em UML.

7. Um modelo de domínio (enquanto artefato) não precisa ser evoluído formalmente no restante do projeto. Isto pode parecer estranho, mas o objetivo do modelo de domínio é capturar o negócio e servir de insumo para a geração de modelos mais formais como o diagrama de classes ou o DER e depois o código executável. Em outras palavras, podemos imaginar o modelo de domínio como um estágio evolucionário para gerarmos os diagramas estruturais, comportamentais e o código de um projeto de software. Cabe citar que o modelo de domínio, enquanto conceito, como bem capturado pelas resenhas a este blog, evolui sempre, isto é, o diagramas de classes, o DER e o código também refletem conceitualmente o domínio do problema e por isso podem ser entendidos como “modelos de domínio”.

8. Um modelo de domínio também é um padrão arquitetural para a modelagem de sistemas OO, padrão este que encapsula lógica de negócios e dados em entidades coesas. Uma referência mais densa sobre este aspecto pode ser encontrada no excelente livro Patterns of Enterprise Application Architectures (http://martinfowler.com/books.html#eaa), do autor Martin Fowler. Recomendo também o artigo Anemic Domain Model (http://www.martinfowler.com/bliki/AnemicDomainModel.html) como anti-exemplo do uso deste padrão.

9. Um modelo de domínio pode carregar padrões de análise. Um padrão de análise não é um padrão técnico (desenho ou arquitetura), mas uma representação conveniente para expressar um aspecto de negócio em sistemas de informação. Exemplos de padrões de análise envolvem a representacão de quantidades (monetárias ou medicamentos), a representação de faixas de valores (início/fim), padrões contábeis (parcelamentos de dívidas, contratos) ou representação de papéis (roles). O site sobre Analysis Patterns (http://martinfowler.com/articles.html#ap) do autor Martin Fowler traz informações valiosas sobre este tópico.

Se você não entendeu nada até o momento, um exemplo pode ajudar a colocar alguma luz neste conceito. Vamos assumir que você precise representar o domínio de sistemas de gestão da geração e transmissão de energia elétrica. Um modelo de domínio que mostra este negócio em termos de seus elementos (ex: transformador, consumidor de energia) e relacionamentos é mostrado aqui.

Compilo aqui, para os mais interessados neste artefato e nesta técnica, uma lista de referências mais técnicas de modelagem de domínio de vários especialistas de mercado.

• ICONIX: http://www.ddj.com/architect/184414689 - Fornece uma visão sobre os 10 erros mais comuns na modelagem de domínio de sistemas computacionais.
• Introduction to Class Normalization - http://www.agiledata.org/essays/classNormalization.html - Fornece uma visão evolutiva sobre modelagem de classes em UML.
• Agile Modeling – http://www.agilemodeling.com/essays/amddPresentation.htm - Traz princípios complementares sobre a modelagem ágil de sistemas.
• Análise Robusta – http://www.agilemodeling.com/artifacts/robustnessDiagram.htm e http://www.ddj.com/architect/184414712 - Técnica complementar à modelagem de domínio para capturar entidades, comportamentos e fronteiras de um sistema.

Estive semana retrasada no evento RSDC (Rational Software Development Conference) em São Paulo, que tratou de tópicos de alta relevância no desenvolvimento de software e focou no anúncio oficial da plataforma Jazz, uma nova geração de ferramentas de desenvolvimento baseadas no conceito CDE (Collaborative Development Environments). É muito bom saber que no Brasil temos eventos deste nível na área de TI. Para aqueles que não puderam acompanhar o evento, a boa notícia é que as apresentações estão disponíveis para download.
Apresentações do Evento On-line

Para os mais atarefados, recomendo em particular três apresentações:

• Abertura Executiva - Marco Bravo - Diretor de Software Group IBM Brasil
• Keynote Speaker: Investimentos em Software: Agregando valor aos negócios em tempos instáveis - David Lubanko, Consultor Rational
• Jazz: Desenvolvimento na Era da Colaboração - Roberto Argento - Gerente Rational - Brasil

Para os céticos, recomendo os estudos de casos que mostram a implementação de práticas de processo e ferramentas em empresas do calibre do Banco do Brasil e Vivo/Telefonica, entre outras.

Finalmente, é importante mencionar também a disponibilidade de vídeos e podcasts do evento RSDC dos EUA, que congregou mais de 3000 participantes. O link para assistir a estas apresentações estão aqui: IBM RSDC 2008. (caso você não tenha uma conta no site da IBM, basta criar uma conta para ter acesso à IBM TV, onde estão os vídeos).

Entregar sistemas de software não é uma arte. É uma complexa ciência que requer, dentre vários outros fatores, muito estudo. Para apoiar neste aspecto, compilo artigos que me muito me ajudaram nos últimos anos, escritos por “mestres” na arte de desenvolver sistema e que são uma eterna fonte de inspiração.

1. Processos ágeis - The Seven Habits of Effective Iterative Development
2. Projetos Iterativos - Planning an Iterative Project e Iterative Development
3. Bom planejamento de Projetos - Project planning best practices
4. Gerência de Riscos - Gambling with Success: Software Risk Management
5. Estimativa de Tamanho de Software - Estimating Software Development Effort based on Use Cases - Experiences from Industry
6. Modelagem de Negócios - Effective Business Modeling with UML: Describing Business Use Cases and Realizations
7. Gerência de Requisitos - So You Want to be a Requirements Analyst? e The Five Levels of Requirements Management Maturity
8. Modelagem de Casos de uso - Why Use Cases Are Not Functions, Features, Requirements, Use Cases, Oh My e The Top Ten Ways Project Teams Misuse Use Cases – and How to Correct Them.
9. Escrita Estruturada de Regras de Negócio - Business Rule Overview e Business Rules.
10. Especificação de Glossário de Termos - Glossary Overview.
11. Mapas de Navegação e Prototipação - User experience storyboards: Building better UIs with RUP, UML, and use cases.
12. Análise Robusta e Modelagem de Domínio - Robustness Diagram Overview e Driving Design: The Problem Domain.
13. Modelagem Arquitetural - Reference Architecture: The Best of Best Practices e Capturing Architectural Requirements.
14. Modelagem de Estruturas de Análise e Desenho - Driving Design: The Problem Domain
15. Modelagem Comportamental - Sequence Diagrams: One Step at a Time
16. Mapeamento Objeto Relacional - The Object-Relational Impedance Mismatch.
17. Gerência de Mudanças - Software Change Management.
18. Gerência da Qualidade - Software Quality at Top Speed e Determining Your Project’s Quality Priorities
19. Desenvolvimento Centrado em Testes Generating Test Cases From Use Cases, Test-Driven Development.
20. Refactoring e Testes de Unidade - Refactoring, a first example.

Uma execução saudável de um projeto requer profissionais e recursos de primeira linha para a disciplina de teste. Compilo abaixo algumas informações muito interessantes para analistas e engenheiros de testes nos tópicos de gerência de testes , testes funcionais, testes de desempenho, testes de WebServices/SOA e testes de caixa branca (para desenvolvedores) e sistemas embutidos. Estes excelentes materiais fazem parte do portal do DeveloperWorks da IBM e trazem experiência provada para auxiliar times de testes a serem mais efetivos.

• Kit de Gerência de Testes
• Kit de Testes Funcionais (Manuais e Automatizados)
• Kit de Testes de Desempenho
• Kit de Testes de Arquitetura SOA e WebServices
• Kit de Testes de Caixa Branca e Sistemas Embutidos

Interessante notar que a plataforma IBM para testes é baseada em uma plataforma *aberta* para testes, que implementa muitas das funcionalidades mostradas nos kits acima, especialmente para as áreas de testes funcionais e desempenho. Esta plataforma se chama Eclipse Test and Peformance Tools Platform. Um passeio rápido por esta plataforma pode ser feito aqui.

A Internet nos trouxe as bibliotecas digitais. Bibliotecas digitais são excelentes mecanismos para conhecer novos assuntos, nos aprofundarmos em assuntos já conhecidos ou mesmo aumentar a nossa produtividade enquanto engenheiros de software.

Melhor ainda se a biblioteca digital puder ser usada sem a violação de direitos autorais, fato que infelizmente não ocorre com outras “bibliotecas” de endereço e reputação duvidosa.

Em particular, recorro sempre à um biblioteca de excelente qualidade chamada RedBooks. O RedBooks (http://www.redbooks.ibm.com) é uma biblioteca pública de livros diversos de TI. O download dos livros em formato digital é gratuito e os livros podem eventualmente ser comprados em formato impresso.

O segredo do Redbooks é que esta é uma rede social, i.e., qualquer pessoa com conhecimento técnico suficiente pode se inscrever e participar de um projeto que irá escrever um novo livro. Vários Brasileiros participam ativamente deste processo, inclusive.

Existem vários domínios (assuntos) dentro desta bibliotecas. Destaco três em particular:

• RedBooks para Desenvolvimento de Aplicações.
• Software Rational (Ferramentas para Governança do Desenvolvimento e Entrega de Aplicações)
• Software WebSphere (Ferramentas para Operações de Aplicações e SOA)

A qualidade dos RedBooks, de forma geral, é muito boa. É possível, inclusive, votar na qualidade e criticar os livros, que eventualmente são melhorados ao longo do tempo. Dados de pesquisa da IBM junto a seus clientes mostraram dados interessantes do aumento de produtividade no uso dos RedBooks. Coloco aqui um fragmento desta pesquisa.

Para não perder o hábito de falar sobre SOA, coloco aqui as dezenas de ocorrências que encontrei sobre SOA no RedBooks Online.
- Redbooks de SOA

Milhares de empresas em todo o mundo sofrem da síndrome do búfalo mais lento, que atrasa a movimentação de uma manada de búfalos nas migrações nas savanas africanas nas suas constantes buscas por novos locais de alimentação e procriação.

A notícia ruim, para a área de TI, é que nós somos este búfalo mais lento. A TI, historicamente, mostra uma impressionante falta de flexibilidade para responder às necessidades de negócio cada vez mais dinâmicas de toda empresa. Isso tem transformando áreas de TI em pesados dinossauros, inflexíveis às mudanças.

O tema modernização corporativa de TI é cada vez mais uma prática chave para permitir a evolução das empresas e suas pesadas áreas de TI. Mas o que é a modernização corporativa?

A modernização corporativa é um conjunto de boas práticas que tem por objetivo promover maior flexibilidade às organizações, reduzir o custo operacional de TI e promover alinhamento entre as áreas de negócio. Podemos entendê-la em cinco grandes áreas:

• Reuso de Ativos
• Arquitetura
• Habilidades das pessoas e equipes
• Processos e ferramentas
• Racionalização dos Investimentos

O reuso de ativos tem por missão promover uma maior gestão do conhecimento através da montagem de inventários eletrônicos dos ativos de software de toda organização de TI. Padrões OMG como o Reusable Asset Especification padronizam e formalizam os mecanismos de reuso corporativos de ativos. Ferramentas open-source como o Reusable Asset Specification Repository for Workgroups ou profissionais como o IBM Rational Asset Manager ou IBM WebSphere Service Registry and Repository fornecem mecanismos para inventariar eletronicamente os softwares. A montagem de um robusto inventário de meta-dados sobre os ativos existentes permite às organizações gerir o seu conhecimento tangibilizado em milhares ou milhões de linhas de código. Outras ferramentas, como o IBM WebSphere Studio Asset Analyser, permitem manter e estender ativos já existentes, com suporte também a controle de mudanças e análise de impacto nestes ativos. Ferramentas ainda mais avançadas, como o IBM WebSphere Asset Transformation Workbench permitem um suporte a gestão do conhecimento, com mecanismos e técnicas para manter e evoluir ativos, descobrir e registrar regras de negócio em sistemas legados e também a analisar o potencial de reuso de trechos de aplicativos.

Independentemente de ferramentas, a mensagem é clara. Um programa de reuso de ativos é fundamental para o reaproveitamento dos investimentos realizados ao longo de décadas em tecnologias legadas como Natural, PowerBuilder, COBOL, PL/1, versões antigas de VB e Delphi, entre outras. Uma metodologia para suporte a um desenvolvimento orientado a reuso de ativos pode ser encontrada aqui.

A arquitetura também é uma peça chave para modernizar empresas. Nexte contexto, a palavra chave é SOA. A arquitetura SOA é uma arquitetura de negócio que busca o alinhamento das ações de TI. Uma das premissas de SOA é permitir que os ativos já existentes sejam expostos como serviços para consumo por outras aplicações. Um bom ponto de partida para o desenvolvimento de uma arquitetura corporativo é o TOGAF, que comentamos em um blog anterior uma excelente base de conhecimento para arquitetos corporativos.

O terceiro aspecto neste processo de evolução de um réptil legado em uma ave é o uso dos talentos corporativos. Solicitar a uma pessoa com dez, vinte ou trinta anos de experiência de negócios que ela se capacite em complexos middlewares de aplicações distribuídas como Java EE é um contra-senso. Estes “analistas de negócio” devem ser potencializados onde agregam mais valor: conhecimento do negócio. Opcionalmente, eles podem operar ferramentas de mais alto nível com linguagem chamadas de EGL. Linguagens EGL permitem a abstração de complexos detalhes de arquitetura tais como clusterização, controle transacional, segurança e aspectos avançados de programação OO. Um exemplo de ferramenta que suporta este paradigma é o IBM Rational Business Developer, que opera sobre o Eclipse em uma linguagem trivial para pessoas sem fluência em OO e arquitetura e gera código executável em COBOL ou Java EE.

O quarto aspecto no processo lida com o fênomeno negativo dos silos em empresas de porte médio ou grande. Nestas organizações, cada time tem o seu próprio processo de coleta de requisitos, gerência de defeitos, uso de práticas tecnologicas ou de manutenção de aplicações. É o que CMMI descreve como processo ad-hoc, que alguns gostam de chamar perversamente de caótico. Devemos combater isso com a intitucionalização de boas práticas de engenharia de software e mecanismos de automação do ciclo de vida de projetos de software. Iniciativas inovadoras como o projeto JAZZ ou ferramentas para automação do ciclo de vida do desenvolvimento de software com o IBM Rational ClearQuest podem apoiar esta questão. Uma outra interessante iniciativa neste contexto também e o Eclipse Process Framework, solução open-source para a documentação e publicação em Web Sites de processos de qualquer natureza. Novamente, a mensagem é clara. Silos de comunicação devem ser combatidos e o conhecimento destas ilhas deve ser promovido para toda a organização para a criação de processos consistentes, ágeis e produtivos.

O último aspecto é a racionalização dos investimentos necessários ao suporte de TI. Uma análise comentada neste interessante podcast sobre modernização corporativa mostra que entre 15 e 25% do código mantido em produção nas organizações nunca é alcançado, isto é, nunca é usado pelos usuários. Este código morto é claramente um fonte de custo e complexidade nas áreas de TI. Uma outra fonte de gasto o tremendo esforço gasto para testes de regressão em aplicações ou para tratar graves defeitos em produção. Ferramentas open-source como o Eclipse TPTP ou profissionais como o IBM Rational Functional Tester e IBM Rational Purify Plus podem apoiar na automatização de testes e análise de cobertura de código, racionalizando desta forma os investimentos de TI.

Obviamente, o esforço de modernizar uma empresa ou uma TI é bastante complexo. Devemos escolher uma ou duas áreas acima e começar um programa de modernização com metas e focos claros e dentro da gerência de um projeto coordenado.

Finalmente, é importante citar que empresas que ainda operem em modo legado vão ter cada vez mais dificuldade em responder aos negócios e irão sofrer uma lenta e dolorosa morte empresarial. As empresas ágeis que aprenderam a evoluir, inovar e se re-inventar como aves de rapina irão sobreviver.

Recomendo, para os interessados neste tema, outras fontes de informação sobre isso, colocadas abaixo:

• PodCast (em inglês) sobre modernização corporativa. The growing importance of enterprise modernization
• Página sobre Modernização Corporativa da IBM
• Demonstrações de Ferramentas