O arquiteto das nuvens

A arquitetura de software existe como uma disciplina formal há quase 25 anos. Podemos destacar, ainda no início da sua base como disciplina, alguns artigos fundamentais como este: Larger Scale Systems Require Higher-Level Abstractions, da autora Mary Shaw, do ano de 1989.

Neste artigo ela escreve, de forma pioneira.

Over the past thirty years, abstraction techniques such as high level programming languages and abstract data types have improved our ability to specify and develop software. However, the increasing size and complexity of software systems have introduced new problems that are not solved by the current techniques. These new problems involve the system-level design of software, in which the important decisions are concerned with the kinds of modules and subsystems to use and the way these modules and subsystems are organized. This level of organization, the software archirecture level, requires new kinds of abstractions that capture essential properties of major subsystems and the ways they interact.

Desde 1989, o campo da arquitetura de software evoluiu muito e diversas outras especializações surgiram tais como o Arquiteto de Soluções, o Arquiteto de Dados ou o Arquiteto de Infra-estrutura . Destaco neste post um novo membro da fauna de arquitetos, o arquiteto das nuvens ou the cloud architect.

A fauna de arquitetos

Este novo membro da fauna requer competências diferenciadas a este novo mundo da computação nas nuvens, tais como:

  • Conhecer os novos modelos econômicos que podem ser alavancados por áreas de TI. Modelos de cauda longa (Big Tail), multi-inquilinos (Multitenancy), computação utilitária (Utility Computing) ou Computação Elástica (Elastic Computing) são exemplos destes modelos.
  • Conhecer e usar as diretrizes que influenciam e determinam que serviços de TI devem operar dentro da própria empresa (On-Premises) ou nas nuvens (Cloud).
  • Conhecer e saber comparar os diferentes tipos de nuvens tais como Nuvens Públicas, Nuvens Privadas ou Nuvens Híbridas.
  • Conhecer as principais soluções de mercado e fornecedores nos três pilares da Cloud Computing: Software as a Service – SAAS, Platform as a Service – PAAS e Infrastructure as a Service – IAAS.
  • Aplicar todos estes conhecimentos no desenho de soluções de software que utilizem software como serviço, plataformas como serviços e infra-estruturas virtualizadas como serviços em ambientes nas nuvens.
  • Acompanhar os projetos de ponta a ponta para garantir que atributos fundamentais como baixo acoplamento, segurança, confiabilidade e sustentabilidade (Green Computing), entre outros, estejam sendo corretamente implementados pelo time de desenvolvimento.
  • Ler mais sobre qualquer outra coisa que não seja TI. Arquitetos de nuvens devem falar a linguagem do negócio para recomendarem e sustentarem suas soluções.

Para os que querem adentrar no tema, é recomendável estudar na prática plataformas como o Database ou o Force, da Sales Force, o Microsoft Azure ou o Amazon AWS. Estes fornecedores, dentre outros, fornecem kits de desenvolvimento e uso gratuito de suas plataformas para provas de conceito e estudos.

Para uma fundamentação mais conceitual, recomendo a leitura de livros escritos na ótica de formação do conhecimento do arquiteto das nuvens. Seguem exemplos de livros nesta linha.

 

“In 2000, when my partner Ben Horowitz was CEO of the first cloud computing company, Loudcloud, the cost of a customer running a basic Internet application was approximately $150,000 a month”, Marc Andreessen .

 

 

Publicado em Arquitetura de Software | Deixar um comentário

O Scrum Master e o Screw Master

Tenho acompanhado muitos projetos que se beneficiam da filosofia ágil. Infelizmente, também tenho observado projetos batizados como  ”ágeis”, mas cuja essência é fundamentalmente violada pela ausência de um Scrum Master com formação sócio-técnica adequada.

É fácil reconhecer um bom Scrum Master em um projeto ágil saudável.

Evidências da sua boa atuação incluem:

  • Ele está a serviço do seu time. A sua missão é limpar os impedimentos alheios, pela manhã, tarde ou noite, custe o que custar.
  • Ele assume responsabilidades. Ele sabe que ele é o responsável pelo bom andamento do sprint e pelo cumprimento do escopo nos prazos. Ele não delega os problemas para terceiros nem culpa ninguém por problemas externos.
  • Ele sabe ouvir críticas do seu time. Ele também sabe que não é perfeito e sabe que precisa do feedback da sua equipe para ser um líder melhor.

Também é fácil reconhecer o Scrum Master Bizarro, versão feita de anti-matéria do planeta Bizarro. Vou chamá-lo carinhosamente de Screw Master. Infelizmente, alguns destes seres habitam as terras Brasileiras.

Evidências da sua presença nefasta incluem:

  • Ele insiste no paradigma comando e controle, também conhecido como cenoura e chicote, tão comum ao modelo taylorista de gerir recursos fabris. 
  • Ele não assume responsabilidades. Ele é mais esguio que um porco ensebado quando os problemas lhe são apresentados. “É culpa do retardado do analista”, “É culpa do maldito desenvolvedor”, “É culpa da idiota do testador”.
  • Ele não é respeitado pelo seu time. Sintoma primeiro e último de um “chefe” que não é líder.

Se você encontrar um bizarro no comando do seu projeto, recomendo exorcizá-lo com a teoria de liderança servidora do Stephen Covey. Se nem isso adiantar, coloque-o em um vórtex multidimenstional e mande-o para o planeta bizarro antes que ele screw o seu projeto.

Publicado em Engenharia de Software | Deixar um comentário

Esqueletos andantes

Allistair Cockburn é um dos grandes pensadores de engenharia de software em atividade. É dele o melhor livro que conheço sobre casos de uso, chamado de Casos de Uso Eficazes. É dele também um conceito chave usado em arquitetura de software, o conceito do código mínimo que implemente uma funcionalidade fim a fim (o esqueleto andante).

O esqueleto andante é um conceito que permite que a funcionalidade e a arquitetura evoluam simultaneamente. Ele acomoda os principais componentes arquiteturais e é uma excelente técnica de redução de riscos em projetos complexos.

A fase de elaboração do RUP é um exemplo interessante da produção de esqueletos andantes, que reduzem os riscos e acomodam cenários de casos de uso críticos e complexos. Em métosos ágeis como o DAD (Disciplined Agile Delivery) também vemos este tipo de técnica.

Neste tipo de técnica, é fundamental uma boa gestão de configuração. O esqueleto andante é um código evolutivo, e não descartável. A gestão de linhas de base e mecanismos de testes de unidade e  integração contínua garante que o esqueleto possa acomodar  cartilagens, tendões, músculos, nervos e peles à medida que mais e mais código complexo seja adicionado ao sistema.

Um exemplo real

Tivemos a oportunidade de acompanhar um projeto, em nosso ambiente de trabalho, recentemente colocado em produção e que usou esta técnica.  A arquitetura candidata rapidamente foi evoluída para código executável que incorporou os principais componentes arquiteturais (tecnologias Microsoft, tecnologias Java, ambientes distribuídos, elemento de tempo real, BRMS, governança e elementos avançados de monitoração).

Neste projeto em particular, dois arquitetos e um desenvolvedor trabalharam em paralelo na criação do esqueleto. A partir do estabelecimento de linhas de bases periódicas que acomodaram cenários de uso reais, os componentes arquiteturais fim a fim foram enlaçados. Em cada rodada, mais e mais requisitos (arquiteturais) eram acomodados, dando forma ao esqueleto.

Após algumas semanas com esta sistemática, o esqueleto tornou-se robusto e foi autorizado para produção. Pudemos observar que uma comunicação contínua entre o time de negócio e o time de arquitetura foi fundamental para o sucesso desta técnica. O esqueleto deve ser mostrado, testado, experimentado. É apenas isso que permite a sua evolução. No fim, pudemos ver o valor da arquitetura em termos concretos.

Neste caso, pudemos destacar também o valor dos processos ágeis. Ao promover comunicação e criar um ambiente de colaboração para suportar a experimentação do esqueleto, o mesmo foi fundamental para suportar uma evolução contínua dos requisitos e da arquitetura.

Publicado em Arquitetura de Software | 2 comentários

Tendências de Arquitetura para 2012-2014

O Forrester Group lançou agora em Outubro seu relatório de tendências de tecnologias de negócio para arquitetura corporativa os próximos três anos (2012-2014). Faço um brevíssimo resumo do mesmo abaixo, focado em quatro das tendências apresentadas.

BPM
O  Forrester prevê uma expansão do BPM e uma fusão com eventos complexos e gestão de regras de negócio. Um conceito que surge neste contexto de unificação é o de BLMS (Business Logic Management Systems), que une em um mesmo ambiente processos, regras e eventos. Em termos tecnológicos, as soluções de BPMS, CEP e BRMS precisarão ser harmonizadas a partir de tecnologias e fornecedores distintos para gerar este valor de negócio.

BI
O BI se torna pervasivo nas organizações e se expande para analisar quantidades absurdas de informações (Big Data). Em termos arquiteturais, as arquiteturas de EDW e projetos que incorporem mercados de dados departamentais (DM) e ETLs ganham cada vez mais espaço na agenda dos arquitetos de dados.

Governança e Gestão de Dados
O MDM (Gestão de Dados Mestres) ganha espaço e começa a se integrar com iniciativas BPMS (gestão de dados de processo). As iniciativas de governança de dados ganham espaço. Em termos arquiteturais, as arquiteturas de dados mestres e questões de replicação e federação de dados se tornam cada vez mais presentes na agenda dos arquitetos. Talvez seja o momento para que os arquitetos de dados ganhem o espaço que os arquitetos de software na década 2000-10.

Computação nas Nuvens e o XAAS
A computação nas nuvens ganha ainda mais espaço e gera cada vez mais pressão econômica sobre a TI (e os gestores). Em termos arquiteturais, a análise sobre as vantagens e desvantagens da virtualização bem como sobre (qualquer coisa) como um serviço devem ser corretamente analisadas pelos arquitetos de infraestrutura.

Originalmente publicado em marcomendes.com/blog

Publicado em Arquitetura de Software, Processos de Negócio - BPM | Deixar um comentário

Potencialize a maturidade SOA do seu projeto com o SOA Source Book

O Open Group é um dos grandes pílares da indústria no desenvolvimento de arquiteturas corporativas. Um trabalho de excelente qualidade deste instituto é o SOA Source Book, uma verdadeira enciclopédia sobre SOA.

Destaco aqui as principais seções deste livro, disponível para consulta no site do Open Group, e que recomendo para todo arquiteto que queira trabalhar seriamente com SOA.

  • O capítulo Service Oriented Architecture traz importantes definições sobre o que é SOA, a sua relação com arquiteturas corporativas e o seu benefício para as áreas de negócio.
  • O capítulo Service Integration Maturity Model apresenta o modelo de maturidade SOA chamado OSIMM, que permite que você avalie a maturidade da sua TI para a integração de serviços, bem como aumentar esta maturidade. O OSIMM apresenta sete níveis e seis dimensões de análise (do negócio à infra-estrutura).

  • O capítulo SOA Reference Architecture apresenta os principais componentes de uma arquitetura SOA em um modelo de camadas técnicas e de governança.
  • O capítulo Service Oriented InfraStructure apresenta os padrões mais adequados para a integração de aplicações, dados e hardwares para a montagem de uma fundação SOA (infraestrutura). Além disso, este capítulo traz um modelo de referência para a infraestrutura SOA.
  • O capítulo SOA e TOGAF apresenta o SOA no contexto do TOGAF , que é o framework de arquitetura corporativa do Open Group.
  • O capítulo de Governança SOA traz um dos elementos mais críticos a qualquer implementação SOA

A edição 3 do livro, lançada em Outubro de 2010, trouxe um excelente apêndice sobre ontologias SOA, para arquitetos que querem compreender os meta-modelos que formam os elementos SOA.

Publicado em Outros | Deixar um comentário

Como construir um Curriculum Mortis (em dez lições)

A maioria dos profissionais constroem um belo Curriculum Vitae ao longo das suas carreiras. Outros profissionais criam, ao invés, um pavoroso Curriculum Mortis à medida que passam por algumas empresas.

Compartilho aqui dez lições para criar um Curriculum Mortis (baseado em casos reais).

  1. Mudar de empresa a cada 6 meses. Vemos profissionais com 5 anos de profissão e quase 10 empresas no currículo. Promiscuidade similar, somente em micaretas.
  2. Negociar com uma empresa enquanto já estiver empregado em outra para conseguir uma oferta salarial melhor e então usar esta oferta para conseguir um aumento na empresa original. Leilão de salário.
  3. Faltar no trabalho e mentir sobre o motivo. E hajam tias e vós mortas para justificar estas desculpas.
  4. Não investir nenhum tempo pessoal para se atualizar na profissão. Vemos profissionais com 20 anos de experiência (em fazer a mesma coisa errada).
  5. Gastar 40 minutos diários nos cafés e conversas de corredor.
  6. Se intitular pleno após colocar o primeiro projeto em produção. Para que você possa pensar a respeito, a palavra plenitude, no dicionário, significa: “s.f. Estado ou qualidade do que está completo, cheio, inteiro. Totalidade.”
  7. Se intitular sênior após colocar o segundo projeto em produção.
  8. Se intitular Mestre Jedi após colocar o terceiro projeto em produção.
  9. Se certificar sem nunca ter trabalhado com o assunto alvo da certificação (e ostentar esta certificação na assinatura do seu email para todos).
  10. Manipular e usar indevidamente o trabalho dos colegas de profissão para agradar e ganhar o respeito dos chefes.

Pensamendo do dia: “Try not to become a man of success but rather try to become a man of value”, Albert Einstein

Publicado em Pessoas | 2 comentários

Casos de Uso 2.0

O conceito de casos de uso foi criado em 1986 por Ivar Jacobson, metodologista e um dos pais do processo unificado. Depois de 25 anos, temos uma evolução na teoria de casos de uso feita pelo próprio autor, influenciado fortemente por métodos ágeis. Descrevo aqui as principais novidades do conceito de Casos de Uso 2.0, publicado pelo autor agora no fim de Setembro em um congresso do IIBA (International Institute of Business Analysts).

Abordagem Iterativa – Fatias de Casos de Uso

Um caso de uso é um conjunto de histórias estruturadas na forma de narrativas. Casos de uso complexos podem ter diversos fluxos alternativos e dezenas de casos de teste. Muitas vezes o tamanho do caso de uso é proibitivo para acomodar entregas curtas em métodos ágeis.

Uma fatia de caso de uso é criado através da seleção de uma história para implementação. É fundamental que uma fatia de caso de uso entregue “valor”, i.e, gere uma experiência de teste para o usuário.

 

Uma fatia de casos de uso é, então, um combinação de fluxos que permite que casos de teste sejam realizados. A figura abaixo exemplifica este conceito para um caso de uso complexo que tenha 15 fluxos alternativos (um verdadeiro épico). Ele é então fatiado em pequenos pedaços, que podem ser adequadamente mastigados pelo time.


O próprio levantamento do requisito pode ser iterativo. Isto é, não precisamos conhecer todo o caso de uso para que o fatiemos para desenho e implementação.

Fatias de Casos de Uso e o Backlog de Tarefas

A figura abaixo mostra três fatias de um caso de uso. É interessante notar que as pequenas fatias podem gerar os itens de trabalho de um backlog no nível necessário para acomodar pequenas entregas, conforme a velocidade do seu time.


O processo da narrativa do caso de uso – Foque na amplitude

É importante mencionar um aspecto também enfatizado por Jacobson, à luz do que Allistair Cockburn já fazia no livro Escrevendo Casos de Uso Eficazesque é uma narrativa iterativa. Em outras palavras, começamos a narrativa do caso de uso de forma bem leve, sempre trabalhando em amplitude. Com a identificação dos nomes dos fluxos alternativos, por exemplo, já podemos derivar as fatias de casos de uso.

Fatias de casos devem ser unidades testáveis

O leitor mais atento já deve ter percebido isso. Casos de uso devem guiar os testes e o conceito de fatia de caso de uso é o elo para este trabalho. A figura abaixo mostra esta ligação. Uma fatia de caso de uso permite que todo o trabalho do time de desenvolvimento e testes seja acionado até que os testes passem e esta fatia de casos de uso seja marcada como realizada.

Considerações Finais

Ao final de sua apresentação, Ivar Jacobson faz o seguinte resumo:

  • casos de uso ainda são casos de uso;
  • eles provem contexto para nossas conversações (usuários e sistemas);
  • nós devemos apenas modelar o que for importante;
  • nós fatiamos os casos de uso para dirigir o desenvolvimento;
  • nós eliminamos o desperdício usando o nível de detalhamento mais leve possível;
  • nós definimos o caso de teste como parte do caso de uso para definir o PRONTO PARA O USUÁRIO;
  • nós usamos cartões e backlogs para suportar métodos ágeis;
  • nós adicionamos detalhes para lidar com comunicação distribuída (times geograficamente distribuídos)
Publicado em Requisitos | Deixar um comentário

O Manifesto SOA

(traduzido para o português)

A orientação por serviços é um paradigma que orienta o que você faz. A arquitetura orientada por serviços (SOA) é um tipo de estilo arquitetural que resulta da aplicação da orientação por serviços. Nós aplicamos a orientação por serviços para ajudar organizações a entregar valor de negócio de forma sustentável, com agilidade aumentada e custos eficazes, alinhado às necessidades de mudanças nos seus negócios.
Através do nosso trabalho nós priorizamos:

Valor para o negócio sobre estratégias técnicas.
Objetivos estratégicos sobre benefícios específicos de projetos.
Interoperabilidade intrínseca sobre integrações personalizadas.
Serviços compartilhados sobre implementações com propósitos específicos.
Flexibilidade sobre otimização.
Refinamentos evolucionários sobre a procura da perfeição inicial.

Isto é, embora nós valorizemos os valores da direita, nós valorizamos mais os itens à esquerda.

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.
Devemos manter os seus esforços gerenciáveis e dentro
de limites significativos

Produtos e ferramentas sozinhos não lhe
fornecerão SOA ou aplicarão o paradigma
de orientação de serviços para você

SOA pode ser implantado através de uma gama variada de
tecnologias e padrões

Estabelecer um conjunto uniforme de políticas e
padrões corporativos baseado em padrões da indústria,
padrões de facto e padrões da comunidade.

Buscar uniformidade no exterior a medida que
permita diversidade no interior

Identificar serviços através da colaboração de pessoas
de negócio e tecnologia

Maximizar o uso de serviços considerando o escopo
atual e futuro da organização

Verificar se os serviços satisfazem os objetivos e
requisitos de negócio

Evoluir os serviços da organização em resposta ao seu real uso

Separar os diferentes aspectos do sistema para
mudar em velocidades diferentes

Reduzir as dependências implícitas e
publicar as dependências externas para
aumentar a robustez e reduzir o impacto das mudanças

Em qualquer nível de abstração, organizar
cada serviço em torno de unidades
de funcionalidades coesas e gerenciáveis

 

Publicado em SOA | Deixar um comentário

O complexo caminho da simplicidade em Java

Para um novato Java que queira criar um EJB na especificação 3.1, o processo é muito simples. Você cria uma classe Java e com apenas uma anotação você tem um objeto distribuído que responde via protocolo RMI/IIOP.

@Stateless
class Cliente {
   public void metodo() {
     // Meu metodo remoto….
   }
}
Se você desejar criar um objeto distribuído que responda através de SOAP, i.e, um WebService, basta adicionar uma outra linha de código, conforme mostrado abaixo.
@WebService
@Stateless
class Cliente {
   public void metodo() {
     // Meu metodo remoto…
   }
}
Entretanto, se olharmos as especificações anteriores do EJB, veremos que esta simplicidade foi alcançada depois de muito trabalho na remoção de complexidades.

Por exemplo, o mesmo código em EJB 3.0 requer uma classe e duas interfaces Java, conforme mostrado abaixo:

 

@Local
interface ClienteLocal {
   public void metodo();
}
@Remote
interface ClienteRemote {
   public void metodo();
}
@Stateless
public class Cliente implements ClienteLocal, ClienteRemote {
  public void metodo() {
     // Meu metodo remoto….
  }
}
Mais impressionante é notar que na especificação EJB 2.1 este mesmo exemplo seria implementado como uma interface local, uma interface remota, uma interface home, uma classe de implementação de negócio, uma classe de implementação da interface home e alguns arquivos XML. Um exemplo arqueológico pode ser encontrado aqui para os mais curiosos. Para criar um único método distribuído, precisamos de várias dezenas de linhas de código.

Se observamos ainda mais atrás no tempo um objeto CORBA, fonte de inspiração dos primeiros EJB, veremos ainda um código mais complexo.

Felizmente temos observado este movimento de simplificação de APIs em vários outros lugares da API Java. O JBOSS Seam inspirou a simplificação do JSF na nova especificação do JSF (JSF 2.0), conforme podemos observar neste artigo em anexo.

O modelo de servlets também foi simplificado. Agora podemos ter Servlets que são configuradas puramente com anotações ao invés de arquivos XML, conforme podemos ver no exemplo abaixo:

@Servlet(urlMappings={“/MinhaAplicacao”})
public class MinhaServlet {
    @GET
    public void tratadorGet(HttpServletRequest request,
                          HttpServletResponse response) {
                ….
    }
}
 

Um ambiente que já suporta estas novidades de simplicidade é o NetBeans 6.8. Notavelmente, o NetBeans tem conseguido “roubar” muita audiência dos desenvolvedores Java justamente por ser mais simples do que o poderoso (mas complexo) Eclipse. Para os programadores Java que nos leem, um tutorial é fornecido aqui.

Pensamento do dia: “Tudo deveria ser mantido o mais simples possível, mas não mais simples que isso”, Albert Einstein.

Pensamento do dia seguinte: “Se em tudo o mais forem idênticas as várias explicações de um fenómeno, a mais simples é a melhor””, William de Ockham

Publicado em Java | Deixar um comentário

Guias MPS-BR

MPS-BR, modelo Brasileiro de maturidade de software, está evoluindo a pleno vapor. Três novos guias estão disponíveis no portal do MPS-BR.

Guia de Implementação – Parte 8: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações que adquirem software.

-Guia de Implementação – Parte 9: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações do tipo Fábrica de Software.

Guia de Implementação – Parte 10: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações do tipo Fábrica de Teste.

Estes novos guias mostram a necessidade de personalização de processos para segmentos específicos da indústria e também indicam um caminho de aumento de maturidade para organizações de TI sérias mas que infelizmente não possuíam um modelo de referência para trabalhar.

Pensamento do dia revisitado: “Um longo tempo é necessário para trazer a excelência à maturidade”, Publius Syrus, Séc. I A.C.

Publicado em Engenharia de Software | Deixar um comentário