quarta-feira, 19 de agosto de 2009

Teoria da Nuvem

Em algumas discussões (normalmente de bar), eu faço algumas previsões de futuro um pouco fortes. O problema é que cada dia que passa eu me convenço mais delas :-)

Depois de uma estruturação de pensamentos, eu vi que as minhas previsões deparavam com a "teoria da nuvem". Confesso que ela não parece ser tão inovadora, mas vou correr o risco de plagiar alguém colocando ela aqui como se fosse minha.

Teoria da Nuvem: dentro de aproximadamente 10 anos, todo mundo terá uma presença física na terra e outra na grande nuvem de dados (que por enquanto conhecemos como internet) que dominará completamente qualquer tipo de troca de informação entre as pessoas.

Consequências da teoria da nuvem:
  • Jornais, revistas e qualquer tipo de meio de comunicação que se propõe deixar o leitor atualizado das notícias será descontinuado. Blogs, micro-blogs, nano-blogs, sites de conteúdo, RSS etc dominarão esse campo. Os livros ainda continuarão a existir, por não serem de notícias e sim de conteúdo permanente. Estes devem desaparecer em aproximadamente 20 anos :-)
  • Telefones fixo e celular deixam de existir. Bom, telefone fixo chega ser profecia do óbvio. Mas telefone celular também, pelo menos da maneira que conhecemos hoje. Todos utilizarão pequenos computadores (que chamamos hoje de smartphones etc) que possuirão funcionalidades de voz sobre IP. Mas eles serão muito mais que aparelhos de telefone, pois terão browsers, leitores de feed, vídeos, vídeos-conferências, GPS, editores de texto... enfim, serão computadores completos. O iPhone é um bom modelo mental para imaginar esse aparelho.
  • Qualquer tipo de mídia ou storage portátil de dados deixa de existir. Não teremos mais CD, DVD ou mesmo BlueRay. Nem teremos pen-drives etc. Todos os aparelhos, incluindo os atuais "DVD Players", estarão conectados na nuvem. Simplesmente iremos baixar o vídeo que queremos ou mesmo abrir um stream direto de dados para ver o que desejarmos... em altíssima definição.
  • A televisão que conhecemos hoje deixará de existir. Bom, isso pode demorar um pouco mais, mas em algum momento da história isso vai acontecer. Ao invés de uma programação fixa, existirá um conjunto de conteúdos disponível para ser acessado quando o usuário quiser. Será uma programação sob demanda. Os programas ao vivo serão exibidos com stream direto de dados. Um grande problema disso vai ser o modelo comercial das grandes empresas de televisão, que vendem comerciais.
  • A publicidade televisiva e de mídia impressa que conhecemos hoje deixará de existir. Isso como consequência da não obrigatoriedade que os usuário terão de ficar vendo TV (que será sob demanda) e da inexistência (ou ineficácia) da mídia impressa.
  • Etc... No fundo, quem não estiver adequado à nuvem, estará descontinuado!
Assutador? Mas isso gera uma série de oportunidades também. No fundo, no fundo, a verdade é: quem estiver melhor posicionado dentro da nuvem, dará as cartas e ditará as regras quando a teoria da nuvem se concretizar. Be prepared!

Abraços!

Agile Architecture

Acabo de ler o seguinte artigo: http://www.agilemodeling.com/essays/agileArchitecture.htm

Achei BEM interessante. Em um certo ponto, chega a ser um choque de realidade para alguns arquitetos e áreas de arquitetura.

O mundo de arquitetura de software está mudando...

domingo, 26 de julho de 2009

terça-feira, 14 de julho de 2009

De volta às aulas!

Após um breve período sem dar aulas, fui novamente convidado para ministrar o curso de Arquitetura de Software no IBTA-Campinas. Estou muito feliz pois o curso é muito legal e a matéria mais legal ainda :-)

Vamos ver se nesse ano consigo dar uma renovada no curso trazendo um pouco mais de discussões de metodologias ágeis vs RUP (dentro do contexto de arquitetura de software, logicamente) e (quem sabe) um pouco de Lean IT, que parece ser a onda do momento (estou extremamente entusiasmado com o tema!!).

As aulas serão dias 01, 08 e 15/08!

Abraços!

domingo, 21 de junho de 2009

Os 7 Mandamentos do Arquiteto de Software

Há algum tempo atrás, quando eu estava preparando material para o curso de Arquitetura de Software do IBTA, eu encontrei um artigo na Internet que falava dos 10 mandamentos para o arquiteto de software. Achei bem interessante o ponto de vista do autor e levei os 10 mandamentos para o meu curso para ilustrar as diferentes visões do que deveria ser um arquiteto.

O artigo mencionava os seguintes mandamentos:

  1. Se não for simples, não vale a pena.
  2. Se não for estável, não vale a pena.
  3. Se não for suportável, não vale a pena.
  4. Jamais justifique a tecnologia pela tecnologia.
  5. Seja flexível.
  6. Questione tudo.
  7. Não culpe o fabricante da tecnologia pelos erros que você cometeu.
  8. O ótimo é inimigo do bom.
  9. Faça uma trégua com a equipe de infra-estrutura.
  10. Não reinvente a roda.

(http://www.enterpriseguys.com/Artigos.aspx?ColunistaID=29&id=40 )

Concordo com todos os pontos acima, mas fiquei pensando quais seriam os mandamentos que eu escreveria. Quais seriam as principais práticas que qualquer arquiteto deveria conhecer, entender e praticar. Foi nesse misto de curiosidade e um pouquinho de inveja que resolvi escrever esse artigo com os 7 mandamentos que considero vitais para um bom profissional de arquitetura.

Vamos lá!

1o Mandamento: Seja Orientado a Valor

Onde “valor”não significa a última onda em termos tecnológicos. Acho que um dos grandes problemas das áreas de arquitetura das empresas é colocar o técnico na frente de negócio. Eu concordo 100% com a frase: “jamais justifique tecnologia pela tecnologia”.

Todos os projetos de software existem com um plano de negócio por trás. Ou seja, ele possui um propósito claro de gerar um valor financeiro dentro de um prazo que costuma variar de 3 a 5 anos. Todas as decisões de arquitetura desse sistema deve enfocar nisso: trazer o retorno financeiro esperado e projetado para a empresa. O propósito não é ratificar os blue prints de mercado, massagear o ego dos papas da Engenharia de Software e nem resolver todos os problemas que ainda não existem. “Mas e se tal coisa acontecer um dia? Se a gente criar 8 camadas lógicas, poderemos abstrair a complexidade dessa mudança na sexta camada...”. E lá se vai prazo e custo...

2o Mandamento: A Beleza Está na Simplicidade

O seu objetivo como arquiteto não deve ser criar modelos, diagramas e códigos-fonte que fariam os rascunhos de Einstein ao desenvolver a teoria da relatividade parecerem brincadeira de criança. Lembre-se que pessoas mais juniores que você (implementadores) irão precisar entender e construir um sistema baseado nas suas decisões. Por várias razões: quanto mais simples melhor! Várias pessoas terão contato com o sistema ao longo do tempo, desde a criação até manutenção e evolução. É papel do arquiteto garantir o entendimento adequado do sistema para essas pessoas.

3o Mandamento: Arquitetura é 5% Inspiração e 95% Transpiração

Não adianta tomar uma série de boas decisões, criar um documento de arquitetura super completo e depois virar as costas para o projeto durante a construção deste. Vai dar errado! Pessoas vão interpretar erroneamente o que você escreveu, não vão conseguir fazer algumas coisas determinadas por você ou simplesmente vão ignorar todos os seus direcionamentos para ir pelo caminho mais simples... que pode levar a grandes problemas.

Invista tempo na passagem de conhecimento. Invista tempo averiguando junto à equipe se as coisas estão em ordem, crie scripts para fazer inspeções automáticas, teste... se envolva!

4o Mandamento: Seja Cuidadoso com o Aspecto Funcional, Seja Paranóico com o Não-Funcional

Entendo perfeitamente preocupações relacionadas a aspectos funcionais do sistema que está sendo desenvolvido. Precisa mesmo! Agora... muito cuidado principalmente com os requisitos não-funcionais. E por um simples motivo: eles costumam ser horizontais a todo o sistema. Isso significa que falta de cuidado e atuação arquitetural nesses pontos pode significar um impacto violento em todo o sistema, podendo chegar a refactoring, re-trabalho ou re-construção de partes significativas dele.

Se houver problemas sérios de performance e chegar a conclusão que o banco de dados está muito normalizado, o banco inteiro pode ter que sofrer alterações, e consequentemente a aplicação. Se o sistema está fazendo muito uso de sessão e descobre que, por questão de alta disponibilidade, vai haver balanceamento de carga sem afinidade de IP, uma fatia significativa do código terá que ser revista. Enfim, todo cuidado é pouco.

5o Mandamento: Acredite no Plano Que Você Está Inserido... Sob Todos os Aspectos

Olhe o plano do projeto no qual você é o arquiteto e acredite nele. Não apenas do ponto de vista de arquitetura, mas sob todos os pontos. De nada vai adiantar o sistema estar bacana do ponto de vista arquitetural mas possui muitos defeitos, estar atrasado, não atender o negócio etc. Seu foco sempre deve ser a parte arquitetural, mas nunca deixe de dar feedbacks para outros membros da equipe (gerentes de projeto, testers, implementadores etc) se você enxerga algum risco para o seu projeto que seja relevante ser compartilhado.

O projeto só será de sucesso se todos os aspectos forem bem. Nunca lave as mãos.

6o Mandamento: Faça Gestão de Riscos na Medida Certa

O arquiteto é o principal responsável por fazer gestão (identificação, planejamento e resolução) de riscos técnicos. Mantenha sempre tudo no seu radar. Crie o instrumento que você achar adequado para catalogar riscos e planos de ação e mãos à obra.

Importante: fazer uma boa gestão não significa ficar procurando pêlo em ovo. Se você não tiver um bom critério na gestão de risco, a única coisa que você vai conseguir é deixar todo mundo louco (principalmente o gerente de projetos) com os trocentos riscos que insistentemente você faz questão de ficar levando em todas as reuniões de status.

7o Mandamento: Comunicação é Tudo

Como é importante se comunicar bem! Eu diria que mais da metade dos problemas que vejo são, de alguma forma, derivados de problemas de comunicação.

Saiba apresentar bem a sua arquitetura, para clientes, áreas de negócio, implementadores e outros arquitetos. Note que a linguagem para cada um desses públicos é completamente diferente uma da outra. Saiba abstrair termos técnicos ao conversar com público executivo, reforce aspectos de custo e prazo (provavelmente o principal interesse dele). Saiba usar termos simples para que os implementadores entendam as suas decisões e direcionamentos técnicos.

Comunique pendências, transmita com clareza suas necessidades, seja cordial com todos os envolvidos... Enfim, são infinitas as orientações que podem ser dadas dentro desse grande guarda-chuvas que é a comunicação. Sugiro uma forte reflexão do que pode ser feito para evoluir nesse assunto.


Esses são os meus 7 mandamentos. Certamente muito mais fácil de colocar num artigo do que conseguir aplicar no dia-a-dia, mas essa é a vida na cidade grande.

Abraços,
Daniel V.

segunda-feira, 8 de junho de 2009

Iniciando...

“- Daniel, com o que você trabalha mesmo?
  - Sou arquiteto de software
  - Sério? E o que é isso? É o mesmo que ciência da computação?
  - Arquiteto de software é quem projeta os principais aspectos técnicos relevantes de um sistema computacional.
  - ????
  - Por exemplo: imagine um grande site de venda de produtos… como o Submarino.
  - Tá bom…
  - O site não é estático, é dinâmico. Tem que fazer pagamento junto a operadoras de cartão de crédito, tem que fazer controle de estoque…
  - Hummmm…
  - Provavelmente tem que gerar relatórios de produtos mais vendidos, cruzando com outras informações como localidade, período do ano…
  - Huuuummmmmmm…
  - Tem que fazer tudo isso
e ainda garantir um tempo de resposta adequado do ponto de vista do usuário, não pode cair em picos de utilização, como por exemplo no Natal, Dia das Mães…
  - Aahhhh…
  - Você não está entendendo nada, né?
  - Não. Só que você vai ficar rico e não vai esquecer de mim J
  - …………………… ok L


A personagem com quem eu estou conversando no diálogo acima não foi identificada mas poderia ser qualquer pessoa da minha família, ou amigos que não são da área técnica. Não consigo culpá-los por não entenderem muito bem minha profissão. Até pouco tempo atrás, ainda era muito comum divergências de interpretações a respeito de arquitetura de software. Será um evangelista de tecnologia? Será um super-implementador? Será um recurso de infra-estrutura? 

Bom, existem várias definições para um arquiteto de software. Eu sempre gosto de dizer que o arquiteto de software é: o responsável pelo sucesso ou fracasso do ponto de vista técnico de um projeto. Isso para mim é o objetivo, a finalidade. O restante é meio.

Não vou me alongar muito na conceituação. É bem provável que eu escreva posts específicos sobre os diversos conceitos. O que eu quero na verdade é iniciar o blog DuasCanecas, que tem como objetivo apresentar meu ponto de vista sobre “Arquitetura de Software na Prática”. Por que o “na prática”? Longe de mim criticar a visão acadêmica da computação (sou professor!), mas eu quero realmente expor minhas opiniões e discutir o tema sobre o ponto de vista prático, gerando valor na linha de frente da produção.

Percebo que não existe muito material a respeito de arquitetura de software, principalmente aqui no Brasil. Existem bons livros traduzidos que falam de pontos teóricos importantes, muitos relacionados a metodologias, mas nenhum deles consegue capturar a realidade do mercado nacional. Como a arquitetura de software está sendo praticada nas empresas? O que tem dado certo? E errado? Eu tenho as minhas percepções e gostaria de criar um espaço para compartilhar e trocar essas experiências com outros profissionais.

Sendo assim, estou inaugurando 3 espaços de discussão:

  • Blog DuasCanecas: onde colocarei artigos sobre o tema mostrando o meu ponto de vista.
  • Site (www.duascanecas.com.br ou www.danielviveiros.com.br): informação um pouco mais estruturada, onde também me apresento um pouco mais.
  • Fórum de Discussão (arqsw@googlegroups.com): tenho a ambição de conseguir reunir uma boa quantidade de arquitetos de software do Brasil nesse alias para conseguirmos discutir e trocar idéias. Por enquanto apenas eu estou lá, conto com a participação de todos J

É isso! Em breve postarei meu primeiro artigo!

Abraços,
Daniel V.