terça-feira, 26 de junho de 2012

Processo de Arquitetura em TI

Estava revisitando os artigos do Peter Eeles sobre Arquitetura de Software, quando percebi que meu ex-professor Zé Luis escreveu um post sobre o livro “The Process of Software Architecting”. Não cheguei a ler esse livro mas, por ter lido vários dos posts do autor, acredito que o conteúdo do livro seja de excelente qualidade.

E o post do professor me incentivou a expor minhas impressões sobre o “Processo de Arquitetura em TI”. Abaixo, faço isso através de várias referências, principalmente para os posts do Peter Eeles.

Como o professor cita, a arquitetura, no escopo de engenharia de software, é um tema recente, buscando amadurecimento. Um exemplo da falta de amadurecimento é a confusão de termos. Quando falamos em “Arquitetura de Software”, a que estamos nos referindo? Peter Eeles explora um pouco isso no artigo “What is a software architecture?”.

Na fase de formação acadêmica, não há uma visão clara do tema, é difícil vislumbrar uma carreira de arquiteto, e fica muito à cargo dos professores de engenharia de software o grau de abordagem do assunto. Por outro lado, dentro das empresas, também não é comum uma preocupação em formar um profissional para assumir as responsabilidades de um arquiteto de software. Não é muito difícil perceber isso, pois o preenchimento de vagas de arquiteto são demorados. É claro que as pessoas possuem inclinações para diferentes perfis de atuação. Em “Characteristics of a software architect”, o autor parece descrever um super herói da engenharia de software. Mas, claro que não é isso, a questão é que são requeridas experiências, vivências. E poucos analistas ou desenvolvedores irão passar por tanta variedade de experiências. Alguns vão buscar por isso, mas a grande maioria não irá traçar isso como objetivo de carreira, pois é uma carreira técnica, e provavelmente assim será por um período bem maior do que aqueles que buscam um caminho de gestão. E isso não é muito claro. Ou seja, a carreira de um arquiteto de software não é bem planejada. E a busca por esta evolução não se limita à arquitetura que é parte de um todo que é a engenharia de software. Um grupo de renomados autores está buscando uma definição comum (tanto para academia como para o mercado) para a disciplina de engenharia de software num trabalho chamado SEMAT.

Mas, voltando à arquitetura, a sua importância já está bem mais clara. As empresas já estão conscientes da importância em se ter um time de arquitetura. Se não é o caso de sua empresa, veja em “The benefits of software architecting” alguns motivadores para promover mudanças. Algumas empresas estão um passo adiante, perceberam a importância de se ter um processo de arquitetura corporativa ou, como alguns preferem dizer, um framework de arquitetura corporativa. Neste escopo maior, a visão vai bem além da construção de um software, direcionando a objetiva para as áreas de negócio e mantendo o processo de arquitetura “vivo”.

Esta evolução do processo de arquitetura está vivendo um momento interessante no Brasil. Cada vez mais o mercado está se habituando a lidar com o tema. Recentemente, aconteceu o evento “The Open Group Brazil Conference”. Foi a primeira conferência do “The Open Group” no Brasil abordando a Arquitetura Corporativa (ou Enterprise Architecture). No caso, mais especificamente do framework TOGAF que é mantido pela instituição. No final de 2011, foi promovido um workshop na sede da Serasa/Experian, onde foram compartilhadas as visões e importância de se customizar um processo/framework de Arquitetura Corporativa. Esta customização precisa definir papéis, responsabilidades, entregáveis, roadmaps de evolução e ciclo de governança. É uma máquina em constante funcionamento, recebendo os insumos de TI e de negócio, produzindo resultados de forma controlada e se retroalimentando deles.

Para finalizar, vale a pena dar uma lida no post do Silvio Meira sobre uma pane nos sistemas do RBS (Royal Bank of Scotland). Reparem nas palavras-chave do post que estão diretamente relacionadas aos requisitos arquiteturais que são a essência de uma arquitetura.

Dica: vale a pena conferir a comunidade PANGEA que discute Arquitetura de Software nos mais diversos níveis.

quarta-feira, 6 de janeiro de 2010

SEMAT – Repensando a Engenharia de Software

Recentemente, notáveis do mundo da engenharia de software, liderados por Ivar Jacobson, Bertrand Meyer and Richard Soley, criaram um movimento para rediscutir as bases da engenharia de software.

O “SEMAT (Software Engineering Method and Theory) – Call for Action” sugere que não há organização na engenharia de software, que suas práticas são imaturas e, assim, convoca a comunidade para trabalhar seus fundamentos. O ponto de partida é a definição de uma base mínima conceitual, nomeada pelos idealistas por “Kernel”. A importância deste Kernel está na necessidade de “elencarmos o conjunto de elementos que são essenciais a todos esforços do desenvolvimento de software, um BoK (Body of Knowledge) compartilhado para acadêmicos, pesquisadores e profissionais”.

De fato, um dos pontos elencados pelo grupo como o principal problema da engenharia de software atual é a divergência entre a teoria do mundo acadêmico e a prática nas empresas. Em boa parte, este gap é devido aos apelos de marketing e buzzwords a que nosso “mundo” (de TI) está sujeito e muitas vezes parece até idolatrar (por um tempo).

Além dos já citados Ivar Jacobson, Bertrand Meyer and Richard Soley, outros nomes bem conhecidos que já escreveram vários livros sobre processos, metodologias e melhores práticas na engenharia de software também apoiam a ideia. Para citar alguns: Scott Ambler, Philippe Kruchten, Robert Martin, Alistair Cockburn e Erich Gamma. É relevante notar que alguns destes foram autores de metodologias mais tradicionais e outros de boas práticas ágeis.

O movimento já consta com muitos adeptos mas também já provocou opiniões contrárias, como pode ser acompanhado no post: “Against SEMAT”. O autor é da opinião de que os formalismos comuns das engenharias já consagradas (diferente da jovem engenharia de software, de apenas algumas décadas) não são sempre aplicáveis no desenvolvimento de software.

Não sou adepto às comparações de engenharia de software com engenharia civil. Acho até injusta esta comparação, justamente pela diferença de maturidade entre as duas. Há um artigo interessante que tenta explicar o RUP através de analogia com a produção de um filme: “Introducing the IBM Rational Unified Process essentials by analogy”. Entretanto, dizer que o desenvolvimento de software é uma arte, apesar de poético, é assumir que não há maturidade para entregar software de qualidade e de acordo com as necessidades do cliente. E pior ainda do que assumir isso é não agir.

O movimento SEMAT tenta, de certa forma, colocar ordem no caos. Eliminar o estigma de que software é um produto imprevisível, instável e que bugs são normais.

Como profissional da área, ao ver tantos especialistas se unindo neste movimento, sinto-me na obrigação de participar. Se vc também deseja apoiar, pode se subscrever na página do SEMAT.

Que nós desenvolvedores e a engenharia de software tenhamos prosperidade em 2010!

terça-feira, 24 de novembro de 2009

SOA Manifesto

Após o mundo de TI passar por algumas rodadas de disseminação do conceito SOA, sem esquecer de alguns tumultos “provocados” pelo post “SOA is Dead; Long Live Services”, alguns bam-bam-bans no tema, motivados por Thomas Erl e incluindo a autora do post citado, compilaram o “SOA Manifesto”. Segue uma tradução livre:

 

Manifesto SOA

Orientação a serviço é um paradigma que direciona o que você faz.
Arquitetura orientada a serviço é um tipo de arquitetura que resulta da aplicação de orientação a serviço.

Nós aplicamos orientação a serviço para auxiliar organizações a entregar valor de negócio sustentável de forma consistente, com maior agilidade e eficiência de custo, alinhado às necessidades de mudança do negócio.

Através de nosso trabalho nós priorizaremos:
Valor de negócio acima de estratégia técnica
Objetivos estratégicos acima de benefícios específicos de projeto
Interoperabilidade intrínseca acima de integração customizada
Serviços compartilhados acima de implementações de propósito específico
Flexibilidade acima de otimização
Refinamentos evolutivos acima de busca da perfeição desde o início
Ou seja, enquanto nós valorizamos os itens da direita, nós valorizamos ainda mais os itens da esquerda.

 

Princípios que Guiam o Manifesto SOA

Nós seguimos estes princípios:
Respeitar a estrutura social e de poder de uma organização.
Reconhecer que SOA requer mudança em vários níveis.
O escopo da adoção de SOA pode variar. Manter esforços gerenciáveis e dentro de limites significativos.
Produtos e padrões sozinhos não lhe fornecerão SOA nem aplicarão o paradigma de orientação a serviços para você.
SOA pode ser concretizada através de várias tecnologias e padrões.
Estabelecer um conjunto uniforme de políticas e padrões corporativos baseado em padrões de facto da indústria e da comunidade.
Buscar uniformidade no exterior e permitir diversidade no interior.
Identificar serviços através da colaboração entre interessados de negócio e tecnologia.
Maximizar o uso de serviços considerando o escopo atual e futuro de utilização.
Verificar se os serviços satisfazem os objetivos e requisitos de negócio.
Evoluir os serviços e sua organização em resposta ao seu real uso.
Separar os diferentes aspectos de um sistema que mudam em ritmos diferentes.
Reduzir as dependências implícitas e publicar todas as dependências externas para aumentar a robustez e reduzir o impacto de mudanças.
Em todo nível de abstração, organizar cada serviço em torno de uma unidade de funcionalidade coesa e gerenciável.

 

E ai, concorda? Então vai e “assina embaixo”! :-)

quarta-feira, 18 de novembro de 2009

Engenharia de Software – Escopo, Prazo, Custo e Qualidade

Sempre que falamos em desenvolvimento de software surge o triângulo:

Não há mágica a ser feita. Para uma mesma área, aumentar um lado implica em diminuir um outro. Mas isto pressupõe que o escopo é (totalmente) conhecido e, o mais importante, não sofrerá mudanças. Já foi esse tempo, não dá mais pra atender ao cliente com escopo fechado. Já dizia o filósofo Heráclito: “a única constante é a mudança”.

No artigo do Ivar Jacobson “Closing the Gap between Business and IT”, ele cita:

“We need to deliver results often and with high quality, on frequent intervals.  IT will have to accept that the business will change its mind about what it wants. This is a natural part of seeing results more frequently, and the feedback obtained is valuable and important. Frequent demonstrations of progress creates confidence and increases productivity, quality and it gives quick results.”

Em resumo, temos que saber lidar com a mudança e demonstrar resultados rapidamente e com qualidade.

Em outro artigo, da Marília Coelho, “Precisamos ser mais psicólogos que engenheiros para ter sucesso com engenharia de software”, a autora fala das dificuldades no entendimento do problema do cliente e cita uma frase de Einstein:

“Einstein certa vez afirmou que se ele tivesse uma hora para salvar o mundo, gastaria 55 minutos definindo o problema e apenas cinco minutos buscando a solução.”

Isto tem a ver com a “pressa” e com a visão míope do “dá pra fazer”, sem buscar o entendimento sobre a real necessidade do cliente e sem explorar as alternativas mais apropriadas.

Ela também cita alguns dados do Standish Group:

“41% dos projetos falham em adicionar valor ao negócio e sobre o Retorno de Investimento – ROI.

49% dos projetos ultrapassam as estimativas iniciais de custo.

Somente 28% dos projetos acontecem no prazo e no orçamento.”

O escopo fechado traz, no início do projeto, a ilusão da certeza do prazo e do custo. Qualquer mudança posterior é temida! A tal da “change request”!

A autora ainda discorre sobre a necessidade de mudança de cultura na engenharia de software e conclui:

“Para que os três pilares – processo, ferramentas e pessoas – funcionem de forma harmônica na organização, o suporte executivo é fundamental, pois as ansiedades, e a pressão do “fazer para ontem” são forças que devem ser gerenciadas corretamente. Os números mostram que continuar como está não é bom para o negócio e não é bom para TI. Pense em fazer algo para mudar o futuro da engenharia de software, conseqüentemente mudando a percepção de que TI não é um centro de custo, mas sim uma área que agrega valor ao negócio através da inovação tecnológica.”

Pensamentos Finais

Escopo muda, é um fato, e assim deveria ser tratado. Com entregas ágeis, frequentes e com qualidade o prazo (final) deixa de ser um “bicho-papão” e a previsibilidade sobre o custo torna-se maior. Ganhar a confiança do cliente, mantendo-o sempre envolvido, aumenta as chances de sucesso pois, no fim das contas, há um relacionamento humano.

Vida longa e próspera à engenharia de software!

domingo, 15 de março de 2009

Certificação - Análise e Design

Análise e Design são atividades do ciclo-de-desenvolvimento de software que lidam, respectivamente, com o tratamento/entendimento do problema e a "criação" da solução técnica para atender os requisitos de software do projeto.

No contexto do RUP (Rational Unified Process), Análise e Design são apresentadas no formato de uma disciplina. Esta disciplina engloba fluxo de trabalho, atividades, papéis e artefatos que orientam o entendimento do problema e a elaboração da solução técnica do software a ser desenvolvido. É nesta disciplina que um dos assuntos mais relevantes do processo unificado é tratado: Arquitetura de Software.

Este post cita, para os amigos leitores, duas certificações relacionadas a A&D.

A primeira não se trata realmente de uma certificação de A&D, mas de UML. Ou seja, tem o intuito de avaliar o quanto você domina a linguagem visual mais usada para representar os modelos de A&D.

 

Certificação UML - OMG:

Site para certificação UML 2 da OMG:

OMG Certified UML Professional (OCUP)

Há 3 níveis de certificação:

  • Fundamental: conceitos básicos, principais elementos e diagramas;
  • Intermediate: amplia o escopo e exige conhecimentos mais avançados dos elementos da UML;
  • Advanced: amplia ainda mais o escopo chegando a exigir conhecimentos sobre a arquitetura da linguagem, representação de semântica usando UML, relação com MDA, conhecimento da OCL (Object Constraint Language) que é uma linguagem de texto que estende a UML para definições e restrições de modelos e metamodelos que não são simples ou mesmo possíveis de serem feitos por diagramas, etc.

Para nós, reles mortais, não parece valer muito a pena ir além da Intermediate. Talvez a Fundamental já baste.

Apesar de interessante (principalmente para o mercado), a certificação de UML, como já dito acima, é limitada à especificação de UML. No escopo de A&D, UML é uma ferramenta (poderosa) que pode ser usada para representar os modelos, através de seus vários diagramas: caso de uso, classes, sequência, implantação, para citar alguns.

De outra forma, uma certificação que avalie o grau de maturidade de um analista quanto ao emprego da UML como ferramenta, além do conhecimento de padrões de design e boas práticas de A&D (baixo acoplamento, alta coesão, poder de abstração, identificação de interfaces, etc) parece ser mais relevante.

A certificação de A&D da IBM Rational abrange todos estes quesitos. Entretanto, é bom deixar claro que ela é fortemente baseada na disciplina de A&D do RUP. Ou seja, além de avaliar estes quesitos, ela também exige seus conhecimentos específicos na disciplina de A&D do RUP. Não sei se isto pode ser ruim, visto que RUP é um dos processos mais seguidos no mundo. Assim, mesmo que sua empresa não siga o RUP, um profissional com conhecimento profundo sobre esta disciplina só tem a acrescentar. Isto se aplica especialmente para arquitetos de software e designers.

 

Certificação A&D - IBM Rational:

Site para certificação de A&D da Rational:

IBM Certified Solution Designer - Object Oriented Analysis and Design, vUML 2

Para obter a certificação é necessário passar em 2 testes:

  1. Test 833 - Object Oriented Analysis and Design - Part 1 (Analysis): trata questões relacionadas ao entendimento do problema;
  2. Test 834 - Object Oriented Analysis and Design - Part 2 (Design): exige conhecimentos que afetam a definição da solução técnica para os requisitos de software.

Referências

- Livros sobre o assunto que vale a pena conferir:

- Um colega blogueiro postou algumas dicas sobre A&D, confiram em: Análise e Design: Para que serve e como fazer? [José Papo].

 

Dicas

- Estude bem a disciplina de A&D do RUP

- Leia os livros UML Distilled e Applying UML and Patterns

- Entenda a aplicação de design patterns

- Por último, mas talvez o mais importante: pratique A&D!

Boa Sorte!!!

terça-feira, 17 de fevereiro de 2009

Refatoração em Banco de Dados

Muitos de nós já estamos acostumados com o termo Refactoring, uma boa prática amplamente divulgada por Martin Fowler

Refatoração = remodelar (reprojetar) sem alterar comportamento.

O termo tornou-se comum quando falamos em programação orientada a objetos, mas o conjunto de boas práticas pode ser estendido a outros nichos, como programação em banco de dados.

O livro “Refactoring Databases”, do Scott W. Ambler, trata das técnicas de refactoring empregadas em banco de dados (mais informações ao final).

Selecionei deste livro 2 exemplos de Refatoração em Banco de Dados: “Replace Column” e “Merge Columns” . Segue resumo.

 

1 – Replace Column (página 126)

Motivação: O tipo da coluna deve ser alterado (ex.: numérico para alfanumérico).

Exemplo: Para um dado sistema, a informação que identifica um Usuário deve ser mantida no formato Alfanumérico. Atualmente, esta informação é armazenada no BD no formato Numérico. Vejam na figura abaixo os schemas original, do período de transição e o final.

Mecânica de Alteração:

1) Cria-se a nova coluna (CustomerID);

2) Torna-se a coluna que será substituída (CustomerNumber) deprecated. Ou seja, a coluna é marcada para eliminação. No exemplo, isto é representado através da indicação “{drop date = June 14 2007}”

a. Deprecate é um termo comum em Java utilizado para indicar que um método de uma classe está defasado e, possivelmente, será eliminado desta classe em uma próxima versão.

3) Cria-se uma trigger (SynchronizeCustomerIDNumber) para manter as informações das colunas sincronizadas. A trigger deve ser invocada para qualquer mudança nas colunas. Esta trigger já deve “nascer” deprecated. No exemplo, isto é representado através da indicação “{event = update | insert, drop date = June 14 2007}”;

4) Converter os dados da coluna original para a nova coluna (CustomerNumber para CustomerID);

5) Durante o período de transição, deve-se atualizar outras tabelas e os programas que acessam o dado alterado (refatorar os códigos e atualizar validações de dados).

6) Após o período de transição, elimina-se a coluna anterior (CustomerNumber) e a trigger.

image

Figura 1. Exemplo de alterações em um schema utilizando a Técnica de Refatoração BD “Replace Column”.

 

2 – Merge Columns (página 92)

Motivação: Existência de colunas que guardam a mesma informação (replicação de informação); Informação “quebrada” em várias colunas; Colunas com informações similares que convergiram para uma mesma informação.  

Exemplo: Para um dado sistema, o número de telefone do Usuário deve ser mantido como uma informação única obtida da concatenação de Código de Área e Local. Atualmente, é guardado no BD separando os códigos de País, Área e Local. Vejam na figura abaixo os schemas original, do período de transição e o final.

Mecânica de Alteração:

1) Cria-se a nova coluna (PhoneNumber);

2) Marca-se as colunas anteriores como deprecated. No exemplo, isto é representado através da indicação “{drop date = December 14 2007}”

3) Cria-se uma trigger (SynchronizePhoneNumber) para manter as informações das colunas sincronizadas. A trigger deve ser invocada para qualquer mudança nas colunas. Esta trigger já deve “nascer” deprecated. No exemplo, isto é representado através da indicação “{event = update | insert, drop date = December 14 2007}”;

4) Converter os dados das colunas originais para a nova coluna (PhoneNumber = merge column);

5) Durante o período de transição, deve-se atualizar outras tabelas e os programas que acessam o dado alterado (refatorar os códigos e atualizar validações de dados).

6) Após o período de transição, elimina-se as colunas anteriores (PhoneAreaCode e PhoneLocal) e a trigger.

image

Figura 2. Exemplo de alterações em um schema utilizando a Técnica de Refatoração BD “Merge Columns”.

 

Mais sobre o livro

Antes de apresentar as técnicas de refatoração em si, o livro explica como a idéia surgiu e evoluiu. Também é apresentado um processo que visa orientar na aplicação destas técnicas. A importância sobre Testes em Banco de Dados é ressaltada.

Várias outras técnicas são apresentadas. Elas são subdivididas nas categorias: Estruturais (os 2 exemplos acima estão aqui), Qualidade de Dados, Integridade Referencial, Arquiteturais e Métodos.

Sobre o Autor:

O autor, Scott W. Ambler, é bem conceituado e já escreveu vários livros sobre os assuntos: Orientação a Objetos, Processo Unificado, Métodos Ágeis, EJB, Bancos de Dados, UML, etc

Ele mantém um site sobre suas obras.

URL: http://www.ambysoft.com/scottAmbler.html

Há também o site do livro que apresenta um “Catálogo de Refatorações de Banco de Dados”.

URL: http://www.agiledata.org/essays/databaseRefactoringCatalog.html

Boa leitura!

domingo, 3 de agosto de 2008

WebServices - Integração X SOA

(Depois de um longo tempo sem postar, mas acumulando muita informação, vamos retomar o compartilhamento.)

Uma das primeiras dúvidas que surge quando se inicia o estudo de SOA é se "WebServices e Serviços em SOA" são a mesma coisa. A dúvida é natural, até mesmo por conta do termo "serviço".

Nota: Aliás, o termo "serviço" gera confusões a todo momento, não somente com relação a WebServices, mas porque se trata de um termo com aplicabilidade em vários contextos. E (felizmente ou infelizmente) não costumamos empregar "namespaces" ao estabelecermos diálogos. Assim, enquanto a adoção de SOA se encontra em processo de disseminação na empresa, conversas do tipo "melhorar a eficiência dos serviços da empresa" geram dúvidas sobre se estes "serviços" têm relação com SOA ou não. Pode ser que haja a relação, caso se trate de um processo de negócio automatizado, ou em vias de ser automatizado, que demandará o uso de Tecnologia da Informação para acesso a alguma funcionalidade de negócio, como por exemplo uma "reserva de tickets". Mas, pode ser que os "serviços" a serem melhorados sejam trabalhos operacionais que envolvam, por exemplo, a redistribuição de tarefas entre funcionários. Parece estranho, mas acontece. Vez por outra você estará questionando ou explicando que o "serviço" em questão trata-se ou não de SOA. E não raramente, passará a usar de termos como "Serviços SOA".

Um dos erros mais comuns é achar que o uso de WebService (WS) significa adotar SOA. SOA não se trata de uma tecnologia ou linguagem, mas uma mistura de um estilo arquitetural e método de desenvolvimento refletindo uma estratégia de negócio.

Alguns projetos requerem a integração entre aplicações de diferentes tecnologias. Isto pode ser realizado através de WS. Para projetos suportados por uma estratégia SOA, WS também podem ser utilizados como tecnologia para "concretização" dos serviços.

Segue um quadro comparativo do uso da tecnologia de WebServices nestas abordagens:

 

WS para Integração

WS em SOA

Foco

Técnico

Negócio

Requisitos

Interoperabilidade

Consumo (ou exposição) de funcionalidade de negócio

Desafios

Governança TI, Versionamento

Governança SOA, Versionamento, Granularidade

Benefícios

Flexibilidade para alterações na camada de integração

Interoperabilidade, Agilidade na mudança de processos de negócio

Ferramentas

UUDI, ESB

Registry, ESB, BPMS

WS - Integração X SOA

Algumas diferenças são sutis, como a questão da interoperabildiade. Em um problema de integração a interoperabilidade surge como um requisito, uma condição que deve ser atendida. Apesar de também ser importante em SOA, a interoperabilidade, ao utilizar WS, surge mais como um benefício.

A relação entre estas abordagens permeia entre a estratégia de negócio e o uso de tecnologia. Um problema de integração pode não demandar qualquer estratégia orientada a serviços. Entretanto, uma SOA tratará a integração como um de seus pilares.

 

Pensamentos Finais

Há uma diferença crucial na estratégia de uso da tecnologia WebServices para realização de Serviços em SOA e para Integração: "Meio e Fim". Enquanto que para Integração, WS pode ser a solução (fim). Para SOA, WS é o caminho mais apropriado atualmente (meio).