Waldemir Cambiucci - Solutions Architect - Microsoft Brasil : Opinião

Opções para processamento distribuído...

wcamb — Thu, 17 Dec 2009 13:52:00 GMT

Olá pessoal, tudo certo?

Ontem tive uma discussão interessante com o arquiteto da Microsoft Services, Marcos Pedroso. Ele sempre está envolvido em projetos de impacto no mercado, seja pela complexidade ou pelas restrições e SLA’s envolvidos na solução. Grande Pedroso! :)

Uma questão que conversamos foi sobre o uso de um modelo de cloud para cenários de paralelismo e distribuição de processos em cálculos financeiros. Existem mesmo diversos cenários onde patterns como o Map Reduce se aplicam de forma natural. Para quem não conhece, o desenho abaixo ilustra esse pattern, que apesar de antigo, ficou mais conhecido pelo pessoal da Google, quando o utilizaram para processos de search na Web.

Explicando: A idéia é termos um processo master que divide uma massa para processamento entre diversos workers, que executam a tarefa programada em blocos da massa de dados original. Dessa forma, distribuímo o processamento inicial entre diversos nós de computação, gerando um paralelismo na solução. Ao final, os vários resultados são devolvidos para o master, que realiza a consolidação dos resultados. Simples não? Já tive diversos projetos em .NET que fizeram algo parecido, utilizando classes como Threads para a divisão manual dos blocos de processamento entre as diversas threads. Funciona muito bem!

Porém, a implementação manual desse tipo de pattern não é trivial e exige alguns cuidados quando falamos de cenários mais complexos. Como alternativa para a programação manual, podemos usar algumas opções de paralelismo e escalabilidade na plataforma Microsoft.

1) HPC – High Performance Computing

A primeira delas é o HPC – High Performance Computing, que oferece um motor de paralelismo e distribuição de processamento pronto para essa divisão de workers, aproveitando ainda uma infraestrutura de vários processadores (multi-core) ou várias máquinas colocadas. Entre as características do HPC temos a possibilidade de trabalhar com mais de 1000 nós workers, execução sobre o Windows Server 2008 R2, suporte para bancos de dados remotos envolvidos na solução, Job Scheduling (um recurso importante para alguns cenários), etc.

Um desenho que ilustra o cenário de distribuição de processamento com o Microsoft HPC aparece abaixo:

Explicando: o desenho acima ilustra um cenário simples de aplicação do Microsoft HPC, onde vemos a rede privada com os vários nós de computação (Compute Node), coordenados pelo WCF Broker Node, que realiza o papel de Master no modelo Map Reduce. Também vemos o cluster de SQL Server e os demais componentes de infraestrutura da solução, como AD, File Server, System Center e Mail Server.

É um cenário aplicável para diversas empresas e vale muito ser estudado! Para saber mais sobre HPC na plataforma Microsoft, confira:

Ref.: http://www.microsoft.com/hpc/en/us/default.aspx

2) Private Cloud e o Dynamic Data Center Toolkit

Outra opção interessante é a chamada private cloud. Na plataforma Microsoft isso aparece através do Dynamic Data Center Toolkit (DDCT), que hoje está disponível para cenários de Hosting, mas em breve, estará com uma versão para Enterprise. Conversei rapidamente com o Fábio Hara (outro monstro sagrado do mundo de TI, hi! arigato!), que me apresentou alguns cenários corporativos que podem implementar um modelo de private cloud, aproveitando toda a infraestrutura e investimentos já feitos internamente.

Veja ainda o post abaixo, do time de produto falando sobre a solução DDCT/E para o mundo Enterprise:

Ref.: http://blogs.technet.com/ddcalliance/archive/2009/09/28/dynamic-data-center-toolkit-coming-to-an-enterprise-near-you.aspx

Para saber mais sobre Dynamic Data Center Toolkit e private cloud, confira o link abaixo:

Microsoft Private Cloud Computing Infrastructure
Ref.: http://www.microsoft.com/virtualization/en/us/private-cloud.aspx

3) Public Cloud e o Windows Azure

Finalmente, podemos aplicar um cenário de paralelismo e distribuição de processamento com alta escalabilidade e alta disponibilidade através do modelo de public cloud, na Microsoft oferecido pelo Windows Azure. Aqui, nosso pattern de Map Reduce ficaria assim:

Explicando: uma Web Role, por exemplo, pode implementar um serviço WCF para o recebimento de dados para processamento, realizando a distribuição entre os vários Workers internos da solução. Essa passagem pode ser feita por filas (Queues), para o desacoplamento entre Web e Worker. Ao final, os vários blocos de resultados são devolvidos para a camada Web por tabelas, preparadas para o cenário de alta escalabilidade na plataforma Azure. A consolidação é feita pela Web Role Master, que devolde o resultado final do processamento.

Nesse cenário de provisionamento elástico, podemos ainda configurar on-demand o número de nós de processamento, conforme alguma variável de dimensionamento colocada. Vale lembrar que, como são cenários de cálculo intenso, mas feitos de forma pontual, podemos dinamicamente controlar essa alocação de instância, reduzindo os custos envolvidos na solução final. Com certeza, ficará mais barato do que investir inicialmente milhares de dólares em uma super máquina, que pode amargar vários minutos ou horas de osciosidade ao longo do dia. Falei ainda com o Danielzinho, aqui do time de DPE, que ficou louco pensando em modelos matemáticos de cálculo em engenharia elétrica, que poderiam aproveitar esse paralelismo sobre o Azure. :)

Vimos assim três cenários interessantes de processamento distribuído na plataforma Microsoft:

1. Paralelismo via HPC
2. Paralelismo via private cloud, com o Dynamic Data Center Toolkit
3. Paralelismo via public cloud, com a plataforma Windows Azure

Faça uma avaliação de seus cenários e veja se você não tem uma oportunidade de paralelismo com essas opções. Fique atento!

Por enquanto é só! Até o próximo post :)

Waldemir.

Cloud Computing para CIO e Gerentes de TI

wcamb — Thu, 10 Dec 2009 13:02:00 GMT

Olá senhores, tudo bem?

Estamos chegando ao fim de mais um ano e com certeza, 2009 será marcado como um ano de discussões sobre cloud computing ou computação em nuvem.

De fato, a nuvem nos foi apresentada como a próxima grande onda, a nova tendência da próxima década ou mesmo a salvação para nossos problemas em tempos de crise, revolucionando a maneira como consumimos TI. Nada como uma promessa de redução de custos em tempos de busca pela eficiência financeira, concorda?

Tanto é verdade que durante esse ano, muitos dos leitores aqui participaram de eventos nacionais e internacionais sobre Governança na Cloud, Gestão de Recursos com Cloud Computing, Segurança na Nuvem, ou ainda "Você está tranquilo com o datacenter onde seus dados passam a noite?" :), além de outros eventos afins.

Mas por de trás desse "hipe" de lançamento e atenção exagerada podemos destacar duas questões importantes:

1. Como reduzir custos e economizar em TI com cloud computing? Isso é possível?

2. Como aproveitar cloud computing para atender as necessidades de negócio de uma forma mais ágil, rápida e dinâmica? Isso também é possível?

Você deve concordar que reduzir custos e ser ágil é o que está na pauta de muitos dos CxO's de grandes empresas, assim como de pequenas e médias que buscam um lugar ao sol em seus mercados. Ao mesmo tempo, reduzir custos e ser mais ágil pode parecer mesmo conflitante em muitos casos: o eterno "fazer mais com menos"... você já ouviu essa história antes…

Como vimos ao longo de 2009, cloud computing torna-se uma oferta comum em diversos fornecedores, atraindo CIO's e Gerentes de TI em torno da potencial redução de custos com gestão de hardware, administração de infraestrutura, investimentos iniciais em datacenters, compras de máquinas ou mesmo custos operacionais diversos com pessoal de TI e software básico de operação.

Através da escolha de um fornecedor de cloud computing, as empresas poderão focar no negócio, enquanto aproveitam um provisionamento dinâmico de infraestrutura mais próximo das reais necessidades de crescimento e demanda junto a aplicação. Trocaríamos o gráfico atual abaixo:

Por algo mais suave e aderente a demanda dinâmica de nossas aplicações, como ilustrado a seguir:

Porém, apesar dos mais de 300 dias falando sobre o assunto, ainda vemos muitas empresas discutindo aspectos de segurança, conectividade, latência, integração, etc. Outro tópico frequente é a interoperabilidade entre o ambiente on-premise e a infraestrutura na nuvem: como garantir que aplicações locais falem fluentemente com soluções na nuvem? Todas essas questões são relevantes e precisam ser discutidas sim!

Mas você deve concordar que esse período de dúvidas deve passar logo e então, estaremos numa nova fase: quais aplicações vou colocar na nuvem? Algumas empresas já iniciaram esse estágio, escolhendo soluções candidatas para a cloud, enquanto avaliam os riscos de operação e o comportamento da nova infraestrutura.

Terminadas as festas de final de ano, estaremos num novo momento: 2010 será um ano de decisões e apostas interessantes em torno de um nova TI, parte on-premise, parte public cloud, parte private cloud; uma TI mais híbrida em muitos casos.

Sabemos que as empresas que rapidamente aproveitam os benefícios de uma nova tecnologia conseguem um posicionamento estratégico melhor em seus mercados. Sabemos também que a novidade da computação em nuvem vai passar e teremos uma alternativa de fato sendo oferecida por diversos fornecedores, em diversas regiões do mundo, com sabores de contratação dos mais diversos.

Então a pergunta que realmente fica e que gostaria de deixar com vocês é: quanto tempo mais você vai esperar para realmente avaliar o futuro de sua TI?

ROI, TCO, TI Estratégica, TI Operacional, como a computação em nuvem vai mudar o custo final de seu produto? Qual será o impacto dessa nova composição de TI para seu negócio?

Realmente, meu amigo(a) CIO, meu amigo(a) Gerente de TI, aproveite pelo menos 1 dia de seu merecido descanso de final de ano para um óscio criativo em torno desse tema…

…só não vale deixar para dezembro de 2010 :)

Um abraço!

Waldemir.

pdc09: Um resumo sobre o evento!

wcamb — Mon, 23 Nov 2009 16:50:00 GMT

Olá pessoal, tudo certo?

O pdc09 terminou semana passada e deixou saudades! O evento começou com a plataforma Azure, apresentada em seu roadmap pelo Ray Ozzie – Chief Software Architect da Microsoft.

Após seu anúncio em Outubro de 2008, a versão 1.0 de seu SDK e ferramentas de desenvolvimento foi publicada em Novembro de 2009. A plataforma entrará em produção em Janeiro de 2010, iniciando a fase de billing e cobrança de seus serviços em 1 de Fevereiro de 2010.

A página com as informações de pricing e billing também mudou, veja:

Windows Azure Pricing
Ref.: http://www.microsoft.com/windowsazure/pricing/

Além de muitas sessões sobre Tables, Queues, Blobs, tivemos a apresentação do tipo Drive, que permite o tratamento de arquivos na plataforma Azure. Veja mais sobre ele na sessão abaixo:

Windows Azure Blob and Drive Deep Dive
Ref.: http://microsoftpdc.com/Sessions/SVC14

Ainda sobre o Windows Azure, algumas surpresas foram muito interessantes, como a presença de Matt Mullenweg, criador do WordPress (a maior plataforma open-source de blogs do mundo) afirmando que estava entrando em produção com o WordPress sobre o Windows Azure. Veja abaixo:

WordPress has Gone Live on Windows Azure
Ref.: http://www.infoq.com/news/2009/11/WordPress-Azure

Silverlight 4 também teve seu espaço, começando com a keynote de Scott Guthrie, com diversos recursos e funcionalidades para aplicações RIA e Web. As demos do Scott foram muito legais, tirando boas risadas do pessoal. Veja um pouco mais sobre SL4 na sessão abaixo:

Building Line of Business Applications with Microsoft Silverlight 4
Ref.: http://microsoftpdc.com/Sessions/CL19

.NET 4 esteve muito presente no evento, com diversas sessões sobre WCF 4, WF 4, WPF e muito mais. Recomendo aqui duas sessões em especial, veja:

Spice Up Your Applications with Windows Workflow Foundation 4
Ref.: http://microsoftpdc.com/Sessions/FT17

What’s New for Windows Communication Foundation 4
Ref.: http://microsoftpdc.com/Sessions/FT13

Diversos outro produtos e tecnologias estiveram presentes, como BizTalk ESB Toolkit 2.0, Visual Studio 2010, SharePoint 2010, RIA Services, Surface, entre outras.

Na sessão de expositores, uma surpresa: um dos containers de datacenter do Windows Azure estava em exposição, ligado e aberto! Agora posso realmente dizer que eu entrei no Windows Azure :)

Note acima a alegria de Rogério Cordeiro, ao descobrir onde suas aplicações Live Services realmente rodavam! :)

Creio que o pdc09 foi mais Evolucionário que Revolucionário esse ano. Isso significa que a Microsoft optou pela apresentação de conclusões e principais roadmaps a partir da visão Software + Serviços e Cloud Computing apresentados durante o pdc08, em Outubro de 2008. Achei isso adequado, pois completou uma entrega, sinalizando ao mercado que a visão continua a mesma. Algumas mensagens foram reforçadas, como o multi-touch para a plataforma PC e os recursos do Windows 7 (uma unanimidade para todos do evento); a visão das 3 telas, com Mobile, TV e PC; e a plataforma Azure, mais completa e com recursos mais integrados para o mundo cloud computing e serviços online.

Saimos desse evento com muitas lições de casa, principalmente em relação ao nosso dia-a-dia: como evoluir nossa TI local, para aproveitar os benefícios e recursos que a evolução tecnológica tem oferecido?

Recentemente li uma frase interessante: os desenvolvedores de hoje querem desenvolver menos e viver mais!!! Alguns da antiga podem discordar aqui, sem problemas!! :) Mas para os mais novos, isso só é possível com uma plataforma de TI mais fácil, integrada e ágil. E que venha o próximo pdc.vNext!

Por enquanto é só! Até o próximo post :)

Waldemir.

Algumas palavras sobre Projetos de Missão Crítica

wcamb — Fri, 06 Nov 2009 22:01:00 GMT

Olá pessoal, tudo certo?

Essa semana acompanhei algumas discussões no forum do Grupo .NET Architects. Entre vários assuntos, um em especial chamou minha atenção: projetos de Missão Crítica.

O que você entende por um Projeto de Missão Crítica?

Do wikipedia temos que o termo Missão Crítica refere-se a qualquer fator (equipamento, processo, procedimento, software, etc.) que seja crucial para o sucesso ou completude de uma atividade ou projeto. Também pode se referir a um projeto cujo o sucesso é vital para a missão da organização ou negócio da empresa.

Falando em projetos, vejamos alguns exemplos que considero de Missão Crítica:

- Um sistema de controle e coleta de dados de um projeto em Física Experimental para criação de estado de plasma, rodando sobre sistema operacional Debian/Linux, com processos em C, usando pilha TCP, pode ser considerado de missão crítica para o laboratório, devido as restrições e riscos envolvidos na monitoração e controle de equipamentos;

- Um núcleo de negociação para o mercado financeiro, tratando milhões de operações/dia, envolvendo mensageria em banco de dados, cache distribuído, gerenciamento de recursos em memória, etc., com requisitos rígidos de baixa latência, também é um exemplo de missão crítica;

- Um SDCD – Sistema Digital de Controle Distribuído – para monitoração e atuação de bicos de óleo em caldeiras para a geração de vapor num planta industrial, também é um belo exemplo. Vapor é um elemento chave em diversos processos industriais, de petroquímicas a processamento de atum em lata :)

- Um monitor transacional de alto desempenho, aplicando conceitos como ACID, MUTEX, CRITICAL SESSIONS, SEMÁFOROS, árvores de falhas, etc, é outro exemplo. Uma leitura obrigatória sobre o assunto é o livro Transaction Processing, confira aqui!

- Um sistema SaaS – Software as a Service – sobre algum provedor em nuvem, para uma solução multi-inquilino com interfaces Web, responsável pelo núcleo de faturamento da empresa, é de missão crítica, com requisitos de disponibilidade, responsividade e desempenho. Imagine um sistema SaaS para a venda de ingressos do show de Eric Clapton ou B.B. King! :)

- Um sistema de automação para controle de caixas margem de via, por exemplo, para determinação de presença de trens de metrô e vagões em trechos da via, abertura de portas, desvios de ramais, movimento, etc. O próprio controle do carrossel de composições na via também é crítico. Qual é o trem mais seguro? Um trem parado ou um trem na oficinal, fora da via? :)

- Um sistema para contabilidade e bilhetagem de chamadas em telefonia celular, também é crítico;

- Em muitos cenários, até mesmo um sistema de emails é um sistema de missão crítica para a empresa. Algumas corporações simplesmente param ou perdem negócios em casos de falha em suas caixas postais, por mais commodities que possam parecer. Impacto financeiro a vista!;

- Um sistema de controle de equipamentos médicos, como scanners, tomógrafos, dispositivos de ultra-som, leitores dopplers em tempo real (opa!), entre outros mais sofisticados em medicina, são extremamente críticos em seus resultados.

Considero todos os exemplos acima como sistemas de Missão Crítica em diferentes níveis, pois envolvem riscos para o negócio da empresa.

Assim, podemos destacar três tipos de riscos envolvidos:

Riscos Materiais;
Riscos Financeiros;
Riscos envolvendo Vidas Humanas;

Alguns sistemas de Missão Crítica podem envolver requisitos de Tempo Real (Real Time), isto é, janelas de atuação e tempos resposta bem definidos, que devem ser respeitados. Nesses casos, o número de processos envolvidos, o volume ou o número de chamadas disparadas não deve interferir no tempo de resposta do sistema.

Qual é o tempo de resposta envolvido no tempo real (em milisegundos, por exemplo)? Dependerá do cenário que estamos tratando, seja um canal de feeders de notícias com filtros sobre política ou mensagens para a abertura de cofres em sistemas de segurança bancário.

Normalmente, condições de tempo real estão envolvidas em cenários de missão crítica, mas não são obrigatórias.

Meu ponto aqui é que não podemos considerar como Missão Crítica apenas o aspecto de desempenho e tempo de resposta envolvidos. Para algumas indústrias, outros atributos são tão importantes quanto, como o impacto financeiro, disponibilidade e riscos diversos.

Quão crítico é o sistema em que você está trabalhando hoje? Ele envolve riscos financeiros, riscos humanos ou riscos materiais?

Em resumo, qual é o impacto de uma falha em seu sistema para a execução do negócio de sua empresa? Aspectos como recuperação de falhas, tratamento de exceções, árvore de falhas, etc., tornam-se importantes em muitos casos.

Uma vez identificado o cenário de missão crítica, como conduzir o projeto?

Algumas perguntas são recorrentes neste momento, como:

Qual é o melhor sistema operacional para cada cenário?
Qual é a melhor linguagem de programação para cada cenário?
Qual é a melhor abordagem de patterns para cada cenário?
Quais são as restrições de memória e disco para o SO? Poucos recursos? Desktops? Servidores?
Quais são as necessidades de comunicação com dispositivos e periféricos diversos nesse ambiente de missão crítica?
Quais são os drivers disponíveis para o SO escolhido? Teremos que implementar esses drivers? Existem fornecedores no mercado?
Quais são as latências de rede e pilhas de transporte suportados? O TCP é suficiente? IPv6? Vamos precisar adotar protocolos de Tempo Real (RTP – Real Time Transport Protocol)? Vamos implementar bindings customizados para a entrega de mensagens com baixa latência? Transporte customizado?
Qual a necessidade por tempo real, paralelismos de processos, high performance computing, cluster computing ou grid computing?

Sem falar ainda em questões adjacentes, como:

Qual será o suporte necessário para a solução?
Como será evolução da pilha de software ao longo do tempo?
Qual é o perfil de profissionais capacitados, exigidos para o projeto?
Quais são os guias de desenvolvimento e patterns disponíveis?
Quais são as ferramentas para a construção de software, metodologias, documentação, etc.

Através aqui do blog, temos acompanhado a plataforma Microsoft e seu suporte para aplicações de missão crítica em diferentes níveis.

Existem diversos recursos que atendem esses cenários, seja sobre a plataforma .NET ou mesmo sobre código não gerenciado, com processos em C++ sobre Windows Server. No ambiente gerenciado, recursos como interfaces de serviços em WCF – Windows Communication Foundation, mensageria com MSMQ, paralelismo, sincronização e sistemas de integração com baixa latência são alguns exemplos. Em todos os casos, o impacto para o negócio da empresa está presente.

Em breve, teremos ainda novos recursos disponíveis na plataforma Microsoft, como o Dublin (para hospedagem de serviços e processos sobre o Windows Server), o Velocity (para cache distribuído e aplicações de alto desempenho), novos recursos sobre WCF 4 e WF 4, além da integração com a plataforma de alta escalabilidade e disponibilidade do Windows Azure, que já está em contagem regressiva para seu lançamento, durante o PDC 2009.

Finalizando, procure identificar em quais cenários de Missão Crítica você está pessoalmente envolvido e como será a evolução destes nos próximos meses. Você vai perceber que sua TI tem um impacto direto para o sucesso de sua empresa!

Por enquanto é só! Até o próximo post :)

Waldemir.

.NET 4.0 e Visual Studio 2010 Beta 2, no ar!

wcamb — Wed, 28 Oct 2009 22:04:00 GMT

Olá pessoal, tudo certo?

O .NET 4.0 Beta 2 foi disponibilizado recentemente, confira:

Microsoft .NET Framework 4 Beta 2
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=DED875C8-FE5E-4CC9-B973-2171B61FE982&displaylang=en

Da mesma forma, o Visual Studio 2010 Beta 2 também já está disponível para testes:

Microsoft Visual Studio 2010 Professional Beta 2 - ISO
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=A80DFB5D-51C6-4778-8656-A9FF29D3A132&displaylang=en

Microsoft Visual Studio 2010 Ultimate Beta 2 - ISO
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=DC333AC8-596D-41E3-BA6C-84264E761B81&displaylang=en

E como não podia faltar, o Training Kit da dupla .NET 4 e VS2010 já está no ar:

Visual Studio 2010 and .NET Framework 4 Training Kit - October Preview
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=752CB725-969B-4732-A383-ED5740F02E93&displaylang=en

Nesses pacotes, você vai encontrar novidades sobre C# 4.0, ASP.NET 4.0, WCF e WF, Parallel Extensions (que vai merecer um post dedicado sobre o assunto), Entity Framework, além das novidades do próprio Visual Studio Team System. Vale a pena conferir!

Em tempo, conversei hoje com uma empresa sobre a construção de frameworks de desenvolvimento e como torná-los desacoplados de tecnologias e versões de plataformas. Isso é possível? Minha resposta é simples: todo framework, seja horizontal ou vertical, está acomplado de alguma forma à plataforma base escolhida. Se você escolhe Java como base para seu framework, estará acomplado ao Java, da mesma forma se escolher .NET, estará acoplado ao .NET. Sem segredo aqui. Isso vai acontecer pelo uso de interfaces como WCF, J2EE, WF, JBOSS, ASP.NET MVC, AJAX, etc.

Porém, para uma dada plataforma, você pode fazer escolhas na definição interna de seu framework, a fim de minimizar os custos de evolução e manter um acompanhamento leve com o próprio versionamento da plataforma hospedeira. Isso é obtido através de uma boa definição de quais capacidades serão atendidas pelo framework, da definição clara de quais cenários de aplicação serão tratados, evitando-se a construção de frameworks horizontais “balas de prata’, que servem para tudo e para todos, além de cuidados com a camada de persistência, uma boa definição de interfaces de serviços, qual a abordagem para regras de negócio, etc.

Não se iluda: as plataformas e frameworks horizontais de fornecedores vão continuar evoluindo, espere sempre por mudanças! Prepara-se para elas!

.NET 4.0 está chegando e com recursos incríveis, fique atento e procure identificar quais capacidades você realmente precisa e pode aproveitar desse novo framework.

Por enquanto é só! Até o próximo post :)

Waldemir.

Sessões Back to Basics? Por que não?

wcamb — Mon, 14 Sep 2009 19:56:00 GMT

Olá pessoal, tudo certo?

Estamos em tempo de mudança. Como o Markus fala de vez em quando, “o Mundo Mudou!”. Concordo com vocês, as vezes é difícil acompanhar o ritmo das mudanças e inovações que atingem nossa área. TI é assim! Durante o último Tech-ed Brasil 2009, eu ouvi o mesmo comentário de vários participantes: “Qual tecnologia eu devo usar?”, “O que eu preciso estudar agora?”, “Porque temos tantos frameworks e opções diferentes disponíveis?”, “O que eu uso para uma aplicação Web?”, entre outros.

De fato, não temos uma resposta padrão ou simples para todas essas perguntas. Tenho trabalhado em TI nos últimos 15 anos e já vi diversas mudanças em arquitetura, alavancadas por diferentes fatores. Quem aqui não viu (tudo bem, alguns aqui não viram) o nascimento do cliente/servidor, aplicações com C++, VB6, componentes em COM+ sobre Windows Server 2000, as novidades do mundo Web, a adoção de Web Services em alta escala pelas empresas, etc. Você viu também a publicação do .NET Framework, sua evolução com as versões 2.0, depois 3.0 com o WCF e o WPF, o uso de serviços REST, o .NET 3.5 SP1. Finalmente, vimos o crescimento da discussão em torno de SOA, SOI, SAAS e mais recentemente o Cloud Computing, o provisionamento dinâmico, a computação de alta escala, o Windows Azure, etc.

Durante o Tech-ed Brasil, tive a oportunidade de falar sobre a iniciativa Software + Serviços da Microsoft, que oferece uma visão para a TI do futuro. Um dos slides que usei mostra a evolução das arquiteturas dominantes nas últimas décadas. Claro, é uma simplificação do que aconteceu em TI, mas vale como ilustração, veja:

Em cada década, tivemos uma arquitetura dominante, que definiu o estilo e o comportamento do software que era construído para o mercado e para nossos usuários. Vale destacar que cada nova arquitetura apareceu como uma nova alternativa de infraestrutura, adicionando valor e novas opções de recursos para as arquiteturas existentes. Essa combinação tem sido observada até hoje e muitas empresas ainda convivem com várias dessas arquiteturas, ao mesmo tempo.

Mas retornando às dores de nosso dia-a-dia e pensando nas perguntas que vimos no começo deste post, existe ao menos uma coisa que é constante nessa evolução toda: a aplicação de bons príncípios de engenharia de software. Independente do tipo de framework, camada, componente ou novos recursos que você adote, lembre-se sempre de princípios como:

Programação Estruturada;
Programação Orientada a Objetos;
Modelagem de Dados e Teoria de Conjuntos;
Bons Patterns de Arquitetura;
Tipos Abstratos de Dados, Filas, Pilhas, Listas Ligadas, Caches;
Otimização de Algortimos, etc.

Como arquitetos de software, creio que é saudável manter “frescos na memória” esses conceitos. Separe um tempinho de seu corrido dia para relembrar os tópicos acima.

Creio que uma sessão “back-to-basics” de vez em quando vai ajudá-lo a olhar os vários recursos e frameworks sob um prisma diferente. Isso também vai ajudá-lo a reconhecer quais tecnologias você pode aplicar em sua empresa, no momento certo de sua necessidade.

É o que eu tenho feito e tem funcionado!!!

Por enquanto é só! Até o próximo post :)

Waldemir.

Pensando na evolução da TI de uma empresa.

wcamb — Fri, 11 Sep 2009 20:54:00 GMT

Olá pessoal, tudo certo?

Durante o Tech-ed Brasil 2009, tive algumas discussões que mais ou menos foram replicadas essa semana, com outras empresas e arquitetos.

Uma dessas discussões foi sobre a evolução da TI numa empresa, com o foco em sua organização e maturidade. Veja o desenho abaixo:

No primeiro bloco, vemos o que é chamado de uma arquitetura “Spaghetti” ou “Macarronada” ou digamos “Noooooossa” :) É muito comum encontrarmos esse tipo de organização de TI, onde para cada comunicação entre sistemas temos um tipo dedicado de conexão, sem padronização, reuso de funcionalidades ou normalização de mensagens e formatos de dados. O custo de manuteção desse tipo de arquitetura é alto, assim como sua administração é complicada, com erros recorrentes. Atualmente, tenho visto muitas empresas iniciando ações para sair desse tipo de arquitetura e organização em TI.

Um segundo estágio nessa evolução pode ser o uso de um motor de EAI – Enterprise Application Integration. Uma infraestrutura de EAI oferece um cenário padronizado de conectividade entre sistemas, facilitando a comunicação entre os serviços existentes através de adaptadores padronizados, schemas de mensagens, formatos de dados versionados, além de uma série de patterns para transformação de mensagens, subscrição, publicação, auditoria, tracing, entre outros, de forma centralizada. Porém, algumas empresas aplicam cenários de EAI em alguns departamentos, enquanto ainda permitem a continuidade de arquiteturas “macarrônicas” em outros andares, seja por problemas históricos, políticos ou de investimentos.

Finalmente, coloco aqui um terceiro estágio de evolução, o ESB – Enterprise Service Bus, ou barramento corporativo de serviços. Podemos pensar num ESB como um conjunto de patterns de EAI, adicionado a patterns de roteamento de mensagens, composição de mensagens e serviços, tratamento de exceção, resolução de chamadas para serviços, etc. Uma grande diferença entre EAI e um ESB é a possibilidade de composição dinâmica de serviços. Enquanto que num cenário de EAI temos links estáticos entre clientes e provedores, no modelo ESB o desacoplamento é ainda maior, sendo possível a composição dinâmica de chamadas. A presença de um repositório ou catálogo de serviços também é parte desse tipo de solução, seja através de um UDDI ou mesmo de catálogo em bancos de dados.

O que achei interessante essa semana foi ver como cenários assíncronos de mensageria, assim como a possibilidade de publicação de serviços ou dados num ambiente na nuvem tornam-se participantes dessa nova TI que arquitetos começam a imaginar. Mensageria não é novidade de forma alguma, mas mensageria entre diferentes infraestrutura de TI me pareceu interessante.

Como tenho dito para algumas pessoas, nossa TI no futuro será cada vez mais híbrida, combinando serviços e dados ora no ambiente local (on-premise), ora no ambiente hospedado (em hosters e provedores) ora na nuvem. Um dos aspectos importantes que teremos será a combinação de SLA’s e níveis de operação, assim como mecanismos de monitoração, logging e administração unificados, que torne a vida do ITPro mais fácil para esses cenários.

Cloud Computing é uma evolução de SOA? Depois de um EAI, sigo para um ESB? E depois de um ESB, sigo para o uso de um ISB – Internet Service Bus? De fato, penso que essas perguntas não têm muita relevância. O mais importante será mesmo aproveitar o melhor de cada infraestrutura, de acordo com as reais necessidades de sua aplicação, solução ou negócio. Fique atento ao que realmente interessa para sua empresa! Se você é um ITPro, fique atento às ferramentas de administração que estão aparecendo. Se você é um desenvolvedor, fique atento aos frameworks e opções de tecnologias que surgem para a construção de aplicações. E se você é um arquiteto, seja de soluções ou de infra, fique atento na hora de aplicar a melhor tecnologia que atende sua empresa.

Seja usando SAAS, EAI, ESB, ISB, ERP, CRM, SC, UDDI, SOAP, REST, HTTP, TCP, etc. o que vale mesmo é atender corretamente seu usuário final, não é mesmo?

Por enquanto é só! Até o próximo post :)

Waldemir.

Qual a importância de um arquiteto?

wcamb — Fri, 14 Aug 2009 15:19:00 GMT

Olá pessoal, tudo certo?

Semana passada, o Markus Christen havia iniciado uma discussão sobre o papel do arquiteto no ARQBR. Algumas pessoas avançaram as discussões offline e tivemos algumas conclusões. Gostaria de colocar aqui uma visão consolidada sobre o tema.

Pessoalmente, tenho visto diversos tipos de profissionais atuando como arquitetos no mercado.

Pensando em arquitetos de soluções, focados em projetos e na construção de sistemas, qual a importância deles? Gosto muito da seguinte frase para explicar a importância do arquiteto de soluções: "Arquitetura de software é o conjunto de decisões de design as quais, se feitas incorretamente, podem provocar o cancelamento de seu projeto". :)

Ainda pensando na construção de software, a SEI - Software Engineering Institute | Carnegie Mellon, tem conduzido uma pesquisa sobre definições para arquitetura de software em todo o mundo, através do link abaixo:

Ref.: http://www.sei.cmu.edu/architecture/community_definitions.html

Lendo as várias definições, fica claro que mesmo pensando na construção de software, o papel do arquiteto e suas atividades são muito diversificados. Mas é sempre direcionado pelas decisões que podem conduzir uma solução para o sucesso ou fracasso, decisões essas relacionadas com a escolha e a combinação de tecnologias aplicáveis para aquela solução. Assim, creio que podemos resumir a importância do arquiteto de solução nessa palavra: direção! Direção para a melhor arquitetura de software que será empregada, buscando a aplicação de uma boa engenharia de software sempre.

Pensando em arquitetos enterprise ou corporativos, esses estão mais distantes do mundo de soluções, muito envolvidos com o negócio da empresa. Qual o papel da TI para a missão da empresa? Qual o impacto de longo prazo do investimento em uma determinada tecnologia ou abordagem de solução. Alguns exemplo? Pense na adoção de um sistema Web para o terminal de auto-atendimento de um banco de varejo. Estamos falando de quantos terminais espalhados pelo Brasil? Pense na adoção de uma plataforma baseada em serviços para a oferta de produtos para corretoras de valores? Qual o impacto de segurança e velocidade de implantação de novos produtos nessa infra-estrutura? Enfim, uma decisão tomada pelo arquiteto corporativo é apresentada para o núcleo de negócios da empresa e normalmente, tem um tempo de maturidade e implantação de médio e longo prazo. Mas são importantes pelo poder de influência e impacto no dia-a-dia de todos da corporação. Qual a importância desse profissional hoje em dia?

Finalmente, pensando em arquitetos de infra-estrutura, estamos num momento muito especial em TI, vendo o nascimento de uma nova plataforma de infra-estrutura disponível na nuvem. Nos próximos anos, o cloud computing será uma realidade para muitas empresas, que buscam a composição de custos entre software e infra-estrutura on-premise e software e serviços na nuvem. O arquiteto de infra-estrutura e IT Pros, que atuam diretamente nesse ambiente de suporte a software poderão focar cada vez mais nas capacidades de TI, oferecendo uma infra-estrutura combinada que irá permitir a construção de soluções mais flexíveis, dinâmicas e transparentes para o usuário final. Qual a importância do arquitetura de infra-estrutura? Suas decisões, o quanto mais alinhadas com a direção de negócio e desenvolvimento da empresa, permitirão uma maior velocidade na adoção de novas tecnologias, consequentemente, um posicionamento melhor no mercado de atuação de sua empresa.

Agora, uma nova pergunta: você que está na carreira de arquiteto, como está se preparando para tomar as decisões corretas em sua empresa?

O impacto de suas decisões pode ser tão grande quanto o sucesso ou fracasso de uma campanha, de um projeto, de um produto ou de um lançamento em sua empresa. Prepare-se!

Alguns links interessantes:

Worldwide Institute of Software Architects - WWISA
Ref.: http://www.wwisa.org/

IASA - International Association of Software Architects
Ref.: http://www.iasahome.org/web/home/home
http://www.wwisa.org/

The Architecture Journal
Ref.: http://msdn.microsoft.com/en-us/architecture/bb410935.aspx

Dev Center de Arquitetura no MSDN Brasil
Ref.: http://msdn.microsoft.com/pt-br/architecture/default.aspx

Por enquanto é só! Até o próximo post :)

Waldemir.

O ritmo da inovação e o papel do arquiteto

wcamb — Wed, 05 Aug 2009 17:15:00 GMT

Olá pessoal, tudo certo?

Semana passada estive com uma equipe de arquitetura de uma empresa do setor financeiro, discutindo sobre tendências em TI e a visão para a computação na nuvem. Com certeza, 2009 está sendo o ano do Cloud Computing.

Uma pergunta que aparece nesse tipo de discussão é sobre quando adotar uma nova plataforma. Vale a pena investir na computação na nuvem? Quais benefícios a plataforma pode oferecer para o meu negócio?

Esse é o mesmo dilema quando pensamos em investir em treinamentos sobre novas tecnologias, como frameworks, ferramentas de desenvolvimento ou plataformas de aplicações. O cenário é mais crítico quando a TI da empresa está desatualizada em relação ao mercado. Se você ainda desenvolve em ASP com componentes COM+ em VB6 e possui alguns sites em ASP.NET com .NET 1.1, por exemplo, o impacto de uma evolução é maior, tanto na capacitação de sua equipe como na percepção de melhorias para o usuário e para o negócio da empresa.

Veja o gráfico abaixo, onde temos o tempo no eixo “x” e a vantagem competitiva de uma empresa num determinado mercado no eixo “y”.

O desenho ilustra o impacto da adoção de uma inovação tecnológica ao longo do tempo. Imagine 3 empresas para uma determinada área de atuação.

A primeira é uma empresa ágil, que rapidamente incorpora inovações estratégicas e consegue um melhor posicionamento no mercado em relação a seus concorrentes. Para isso, essa empresa investe em novas tecnologias, acompanha o lançamento de novas plataformas e ferramentas de mercado, assim como mantém uma cultura de constante avaliação de suas soluções em relação ao negócio da empresa. Como resultado, é reconhecida como uma empresa inovadora e que lança tendências ou aproveita os benefícios de uma nova tecnologia, melhorando sua produtividade, tempo para o lançamento de novos produtos, redução de custos, alcance para novos mercados, etc.

Com o passar do tempo, uma segunda empresa adota a mesma inovação, ainda conseguindo um bom posicionamento no mercado. Muitas vezes, essa empresa é uma seguidora de líderes da indústria, um cenário muito comum no mercado financeiro e entre bancos.

Finalmente, uma terceira empresa adota as inovações estratégicas de forma tardia, não aproveitando os benefícios e oportunidades da adoção de uma nova tecnologia, apenas corrigindo sua posição no mercado. Muitas vezes, essa empresas trata a área de TI como um universo apenas operacional, de suporte ao negócio da empresa sem relevância, não reconhecendo o impacto e possíveis oportunidades que a primeira empresa conseguiu aproveitar.

Existem diversos motivos que posicionam uma empresa em cada um desses 3 perfis, como cultura organizacional, histórico de projetos, tamanho da empresa, tolerância ao risco, burocracia, inércia das áreas envolvidas, resistência a novas formas de trabalho, etc. Reconhecer em qual grupo sua empresa está é o primeiro passo nessa auto-análise tecnológica. A partir desse diagnóstico, identificar quais benefícios e o impacto de uma nova tecnologia para o negócio da empresa deve oferecer bons argumentos para uma tomada de decisão.

Ao mesmo tempo, um tópico que aparece é o chamado “dilema da inovação”. O aparecimento de novas tecnologias e inovações estratégicas também pode criar empresas emergentes, que aproveitam com maior sucesso de novas demandas do mercado ou de seus clientes, que também percebem os benefícios da inovação disponível.

Entre 2009 e 2010, vamos acompanhar de perto uma das maiores ondas de lançamentos de tecnologias e inovações na plataforma Microsoft. Teremos Office 2010, SharePoint 2010, Exchange 2010, Visual Studio 2010, .NET 4.0, Windows Azure, Windows Server 2008 R2, Windows 7, entre tantos outros.

Em tempo de crise, investir em inovação é tão importante quanto controlar os custos operacionais da empresa. Cada empresa possui um histórico próprio que explica seu posicionamento e seu grau de inovação no mercado.

Como arquitetos, como podemos ajudar nossa empresa no entendimento dessas questões, para dar o próximo passo evolutivo no ritmo das inovações em TI? Fica para pensar…

Por enquanto é só! Até o próximo post :)

Waldemir.

Estudo de caso : um mapa para decisões de projeto

wcamb — Wed, 29 Jul 2009 18:04:00 GMT

Olá pessoal, tudo certo?

Recentemente, acompanhei algumas discussões interessantes sobre aspectos para a decisão pela plataforma .NET em um determinado projeto.

A partir desse bate-papo, achei que seria bom comentar aqui uma solução que acompanhei para um projeto Web multi-tenant de média/alta complexidade no ambiente corporativo. Assim, vamos explorar alguns dos pontos avaliados pela equipe para a decisão pela plataforma .NET.

Considere esse projeto apenas como uma abordagem possível, já que:

projetos são sempre diferentes entre si, seja em recursos, tempo ou equipes. Faça suas adaptações e avaliações de acordo com a sua realidade;
pessoas bem capacitadas é sempre importante, para qualquer plataforma, seja .NET, JAVA, PHP ou RUBY;
um mapa claro das reais necessidades da empresa também ajuda para manter as expectativas sob controle, assim como a escolha pela tecnologia mais aderente.

Considere ainda a necessidade por uma boa engenharia de software versus o atendimento de um cenário mais simples, com pouco perspectiva de evolução.

Para começar, veja o desenho de arquitetura escolhido para o projeto, conforme temos no Application Architecture Guide 2.0:

A partir desse mapa, vejamos alguns pontos que a equipe considerou ao escolher a plataforma .NET:

1. EVOLUÇÃO: A plataforma .NET tem evoluído desde 2002. Desconsiderando o .NET 1.0 (2002) e o .NET 1.1 (2003), da versão 2.0 em diante (2005) tem sido adicionado novos recursos e protocolos de forma integrada ao framework, atendendo uma série de cenários no mercado. Alguns exemplos são serviços REST, consultas integradas via LINQ, AJAX, padrões MVC, frameworks de sincronização, caching, etc. Como a evolução é contínua, isso garante o atendimento de novos cenários não originalmente previstos;

2. LINGUAGEM: A plataforma .NET oferece 2 grandes linguagens para o desenvolvimento de aplicações, C# e VB.NET. Claro, existem outras, mas são as de maior presença no mercado. A equipe considerou a linguagem C# como alternativa por decisão de projeto apenas, já que os recursos e namespaces oferecidos são os mesmos sobre .NET. A síntaxe de C# também pesou na decisão, devido alguns membros trabalharem em Java em projetos paralelos;

3. WEB+RIA: Para cenários de aplicações WEB evoluindo para RIA - Rich Internet Application, a dupla ASP.NET + AJAX foi bem avaliada, considerando uma evolução para ASP.NET + SILVERLIGHT em alguns cenários. Na época, era o Silverlight 2.0. Hoje, temos o Siverlight 3.0 com o framework em desenvolvimento .NET RIA SERVICES, que promete implementação interessante, integrando serviços Web Services em JAVA, camadas em nHibernate e bancos ORACLE, serviços REST, etc. A solução hoje é 80% ASP.NET + AJAX, considerando algumas funcionalidades de LOB para Silverlight 3.0. Por ter iniciado antes do lançamento, o ASP.NET MVC está sendo avaliado somente agora;

4. SERVIÇOS: De modo geral, o suporte de serviços no lado do servidor e na camada de negócios foi bem implementado com o WCF - Windows Communication Framework, presente na plataforma .NET desde sua versão 3.0 (2006). Uma das grandes características do WCF é sua extensibilidade com a adição de novos Bindings de conectividade, seja através de soluções domésticas ou de mercado. Na solução em questão, foram aplicados os bindings padrão TCP, wsHTTPBinding e basicHTTPBindig para integração Java;

5. PERFORMANCE: A estabilidade e robustez do modelo ASP.NET+WCF foi bem avaliada desde as provas de conceito. Isso contou para garantir uma plataforma que tivesse alta escalabilidade ao longo do tempo. Os números para mensagens por segundo e suporte para múltiplas instâncias de serviços foram muito bons! Realize provas de conceito, sempre. Veja um artigo clássico sobre performance do WCF, aqui. Para os testes usaram o Web Capacity Analysis Tool do Internet Information Services (IIS) 6.0 Resource Kit Tools, além das ferramentas de Web Testing do Visual Studio 2008.

6. PROCESSOS: Em cenários de coordenação de processos, o WF - Windows Workflow Foundation também foi avaliado, uma vez que sua implementação é visual e integrada a própria IDE do Visual Studio. Alguns desses workflows fazem chamadas para serviços WCF, coordenando processos de negócio. O template Sequential Workflows Service Library foi o mais adotado. Já falamos dele por aqui, veja;

7. TRANSAÇÃO: O suporte transacional obtido com o WCF e WF garantiu também a aplicação de transações distribuídas, integrando serviços em .NET e JAVA, através do protocolo WS-AT (Atomic Transaction), suportado pelo WCF e WF no .NET. Como alguns web services participantes estão em Java, foi usado o WSIT para o suporte transacional, com interoperabilidade Java e .NET. Veja mais aqui.

8. HOSTING: Outro aspecto importante avaliado foi o HOSTING, isto é, onde as camadas de apresentação e lógica seriam hospedadas. No cenário sobre .NET, as páginas ASP.NET e porções em Silverlight foram hospedados em baterias de máquinas de apresentação, sobre IIS7 (Windows Server 2008). Para a camada de negócios e serviços, máquinas W2k8 foram dedicadas para hospedagem de serviços sobre a dupla IIS7/WAS - Windows Process Activation Service. Desse modo, foi possivel garantir o "desacoplamento" desejado para o projeto, separando a frente de apresentação e balanceamento de carga Web da frente de serviços e negócios, permitindo a futura exportação de serviços para outros sistemas. Avalie esse cenário como uma expansão futura real e desejável. De modo geral, pense em Web Services sobre HTTP/SOAP. Para cenários de serviços com alta performance, usamos o WAS para suportar o transporte em TCP/Binário e não em HTTP/SOAP/XML apenas. Veja mais sobre arquitetura WAS aqui;

9. ADMINISTRAÇÃO: Foi avaliado que a construção de serviços WCF e WF e a preparação da equipe sobre a plataforma .NET garantiria a adoção de Dublin sobre o Windows Server 2008 no futuro. O Dublin deve ampliar as funcionalidades de gerenciamente e administração de serviços WCF e WF no servidor de aplicações, criando um hosting com melhor governança para a solução. Mais um ponto para a adoção do .NET. A equipe começou com W2k3 e passou logo para W2K8 durante o projeto;

10. SEGURANÇA: Para cenários de autenticação, autorização e controle de acesso, aplicamos os exemplos disponíveis na Enterprise Library, o que ajudou muito na produtividade;

11. TESTES: Avaliamos também a aplicação de cenários de testes sobre o Visual Studio 2008, diretamente relacionado a plataforma .NET;

12. CONFIGURAÇÃO: Considerando a dupla ASP.NET+WCF, tivemos bons resultados na velocidade de configuração do ambiente de produção, devido principalmente o desacoplamento entre ambos. A configuração via XML e EndPoints também foi um ponto interessante de avaliação no uso de serviços em WCF, recurso muito bem avaliado na plataforma .NET;

13. PRODUTIVIDADE: Em relação ao processo de desenvolvimento em si, aplicamos alguns templates customizados, criados em tempo de planejamento e arquitetura. Desse modo, foi possível disponibilizar em servidores da rede de desenvolvimento alguns templates específicos para páginas CRUD e serviços WCF, aumentando muito a produtividade da equipe de desenvolvimento. Avaliamos também o uso de guias de automação sobre o Visual Studio, como a dupla GAT/GAX, mas o cenário foi bem atendido apenas com os templates puros em .vstemplate para páginas ASP.NET e serviços WCF/WF;

14. PERSISTÊNCIA: Considerando bancos de dados em Oracle e SQL Server, foi aplicada uma camada ORM com nHibernate, em .NET. A equipe está realizando testes com o Entity Framework, aguardando a versão 2.0 ser lançada. Para a manipulação das coleções obtidas de consultas, diversos módulos de negócio manipulam os itens através de consultas LINQ, integradas ao C# no .NET. Essa abordagem de manipulação integrada permitiu um grande ganho de produtividade, devido o uso do intellisense em tempo de desenvolvimento, assim como facilidade de construção de consultas e filtros sobre coleções;

15. CAPACITAÇÃO: Em relação a capacitação da equipe, foi planejado 40 horas de treinamento formal em WCF e 24 horas de treinamento formal WF. O uso de templates bem formatados para cada camada do projeto garantiu uma curva de aprendizado suave para a equipe;

16. RECURSOS: Foram considerados alguns sites importantes para o apoio da equipe. Entre os links principais, cito:

WCF – Windows Communication Foundation
http://www.msdnbrasil.com.br/microsoft.MediaCenter/Default.aspx_x_CATEGORY_x_WCF.aspx

WF – Windows Workflow Foundation
http://www.msdnbrasil.com.br/microsoft.MediaCenter/Default.aspx_x_CATEGORY_x_Windows%20Workflow%20Foundation.aspx

Sem esquecer do material impresso, através de livros para o .NET 3.x (WCF, WF e ASP.NET).

17. PROJETO: Em relação ao processo de gerenciamento, o time não aplicou o SCRUM de forma rígida, mas manteve o PRODUCT BACKLOG, assim como o papel do SCRUM MASTER, SPRINTs de 3 a 4 semanas e as SCRUM Meetings diárias.

18. COMPLEXIDADE: Avalio o projeto como de média para alta complexidade, considerando o potencial de crescimento e escalabilidade prevista. Apesar do aspecto multi-tenant (multi-inquilino), a integração com o legado, o controle de acesso, a integração transacional com serviços Jrava e a necessidade de crescimento de novas funcionalidades foram fatores também críticos. Para os mais rígidos, aplicar a Análise por Pontos de Função também ajuda.

19. FRAMEWORKS: Não foi construído um framework de desenvolvimento para o projeto. Ao invés, foram construídos bons templates para páginas CRUD e façades de serviços e workflows. Dessa maneira, a equipe conseguiu grande produtividade no desenvolvimento sem o custo adicional de manutenção de um framework doméstico. Fábricas de Software ou DSL’s não foram consideradas pela equipe por enquanto. :)

20. ALM – Application Lifecycle Management: como parte importante do projeto, foram considerados os vários papeis e processos previstos no ALM aplicado sobre MSF for Agile (MSF for Agile Software Development Process Guidance). O uso de VSTS – Visual Studio Team System como ferramenta de apoio ao processo de desenvolvimento e projeto também foi importante para o sucesso do ALM adotado.

Assim, fizemos as seguintes considerações para a plataforma .NET:

capacidade de desacoplamento entre apresentação e serviços (via WCF);
suporte para a construção de serviços com transporte via HTTP, MSMQ e TCP (via WCF);
facilidade na construção de processo por workflows, realizando chamadas coordenadas para serviços (via WF);
integração do desenvolvimento e testes com a ferramenta de desenvolvimento principal, via Visual Studio 2008;
suporte a frameworks de sincronização, caching, xml, coleções, etc, além da possibilidade de se trabalhar com configuração desacoplada para a camada de apresentação e de negócios (via web.config);
disponibilidade de bons exemplos de código na web (via a Enterprise Library 3.1 e 4.1). Mais recentemente, o Hands On Lab da EntLib 4.1 trouxe bons exemplos para alguns cenários não avaliados originalmente;
facilidade de construção de Web Forms via RAD no Visual Studio;
suporte para integração futura com outros cenários de apresentação e canais de relacionamento, como o ambiente Mobile;

Passamos aqui por alguns aspectos de decisão do projeto e algumas justificativas que levaram a adoção da plataforma .NET no cenário acima.

A partir desse exemplo, podemos montar uma planilha de decisão mais ampla, para a comparação ou avaliação de outras tecnologias, considerando:

1. redução de custos de desenvolvimento;
2. redução de custos de manutenção;
3. agilidade no processo de desenvolvimento;
4. produtividade e ferramentas de automação no desenvolvimento;
5. facilidade de integração com sistemas legados;
6. interoperabilidade com outras plataformas;
7. segurança;
8. suporte transacional;
9. mobilidade;
10. capacitação da equipe;
11. conectividade com web services e padrão WS-I.org;
12. suporte a padrões W3C;
13. facilidade de depuração e ferramentas;
14. integração e rastreabilidade no ambiente de infra-estrutura;
15. custo total de infra-estrutura necessária, etc.

Para pensar…

Creio que um dos aspectos importantes na adoção da plataforma .NET no cenário acima foi a decisão pela boa engenharia de software. O projeto precisava considerar balanceamento de carga, crescimento e escalabilidade ao longo do tempo, integração com o legado e diferentes plataformas, múltiplos bancos, processos via workflows e interfaces de serviços, etc. Era uma solução Web multi-inquilino, com potencial de crescimento no ambiente corporativo, e que sinalizava evolução ao longo do tempo.

Veja que a equipe não avaliou outros recursos importantes, como Live Services ou Cloud Computing através da plataforma Azure. Considerando valores de pricing da plataforma, assim como o desenvolvimento e depuração integrados sobre o Visual Studio 2008, a nuvem passa a ser uma opção cada vez mais interessante para projetos semelhantes também de baixa e média complexidade. Avalie se sua aplicação SAAS sobre ASP.NET + Banco de Dados não é também aderente ao modelo elástico da nuvem.

Em cenários menores, a análise acima pode ser exagerada (exemplo, um site simples sobre 1 única máquina consumindo 1 único banco de dados, com equipe reduzida). Mas se sua aplicação tem potencial de crescimento ou aspectos SaaS / Web 2.0 mais corporativos, passa a ser importante considerar os componentes de arquitetura de forma mais completa. A lista abaixo foi retirada do App Arch Guide 2.0:

Veja o que você realmente precisa em sua solução e escolha a melhor tecnologia de forma racional e com boas memórias de cálculo justificando suas decisões.

Por enquanto é só! Até o próximo post :)

Waldemir.

Leitura Recomendada: The Architecture Journal #20 e o papel do arquiteto

wcamb — Mon, 06 Jul 2009 23:22:00 GMT

Olá pessoal, tudo certo?

A edição n.20 do “The Architecture Journal” em inglês já está disponível, na verdade desde junho :)

O tema desta edição foi “Arquitetura em Tempos Turbulentos”, bem atual.

Veja mais aqui: http://msdn.microsoft.com/en-us/architecture/bb410935.aspx

Nesse tema, gostaria de levantar um assunto: minhas últimas conversas com arquitetos e profissionais de TI envolveram diversos aspectos relacionados com a plataforma de aplicações, integração entre serviços .NET e serviços em Java, construção de serviços e cenários SOA/SOI, melhores práticas para WCF e WF, assim como direções para times de arquitetura e desenvolvimento. Porém, sempre que questionei os aspectos de negócio envolvidos na solução ou mesmo sobre o impacto de cada decisão de projeto no negócio da empresa, foram poucas as respostas. :(

De fato, tenho sentido uma falta constante de envolvimento de muitos arquitetos em relação aos motivadores de TI. Já falei um pouco desses motivadores num post maior, aqui.

Quando escolhemos entre Web Forms e MVC, por exemplo, o impacto não está relacionado apenas em aspectos de programação, maior controle sobre o código HTML ou a aplicação de funcionalidades RAD. Existe um impacto de médio e longo prazo em manutenção, composição, testabilidade, operação, etc. que resulta em maiores ou menores oportunidades de negócio para a empresa. Isso é mais forte em algumas indústrias, seja para cenários de ISV’s, pequenas e médias empresas ou corporações.

Sempre falamos que é responsabilidade do arquiteto estar envolvido com os aspectos de negócio que direcionam cada decisão técnica. Pensar em cenários de negócio ao invés de features ou funcionalidades de produto é parte obrigatória dessa visão. Porém, por que não temos observado isso no dia-a-dia de nossas empresas e arquitetos? Atualmente, tem sido mais fácil encontrar arquitetos operacionais do que estratégicos.

Será que este comportamento é consequência da crise deste primeiro semestre, que atingiu o mercado em diferentes níveis para cada indústria? Ou o papel do arquiteto (de soluções, infra-estrutura e enterprise) no Brasil continua em formação, abrangendo vários sabores de atuação? Falta maior capacitação para a visão de negócio na formação de nossos arquitetos hoje em dia?

O que vocês acham?

Waldemir.