Algumas idéias para discutir uma arquitetura.
Olá pessoal, tudo certo?
A semana começou com uma boa discussão de arquitetura, envolvendo um sistema bem interessante (confere Ramerson?) :)
Uma abordagem que surgiu durante o bate-papo foi primeiro olhar os vários pilares de tecnologias e depois relacionar algumas frentes de implantação para o projeto, seguindo alguma metodologia.
Quando pensamos nos pilares de desenvolvimento, podemos utilizar algumas classificações para os vários recursos da plataforma Microsoft. Uma proposta de organização desses pilares poderia focar o ambiente de execução, por exemplo:
Cada cenário acima envolve diferentes recursos como API's, mecanismos de integração, ferramentas de desenvolvimento, tipos de clientes e serviços, etc. De fato, uma mesma solução pode contemplar recursos de vários pilares.
Um post que já detalhou um pouco mais esse assunto, com foco no S+S, foi:
"Recursos para a construção de soluções Software + Services."
Ref.: https://blogs.msdn.com/wcamb/archive/2008/06/10/recursos-para-a-constru-o-de-solu-es-software-services.aspx
Com essa visão, podemos reconhecer quais recursos serão necessários ou possíveis para nossa solução, permitindo dimensionar também as alternativas de implementação e integração entre seus vários componentes. A pergunta-alvo é : "quais pilares de desenvolvimento nossa solução necessita tratar hoje ou poderá tratar no futuro?".
Avançando na discussão, surgiu uma outra pergunta: "por onde começar nosso desenho de arquitetura?". A velha pergunta de sempre.
Nesse ponto, utilizar uma metodologia que defina papéis e oriente as atividades que serão executadas ao longo do projeto é uma grande ajuda. Por isso, acabei propondo para o time as disciplinas do MSF - Microsoft Solutions Framework, como ponto de partida para o projeto.
Aroveitando o modelo MSF for Agile, as atividades previstas para um arquiteto, que podem ser um ótimo guia para o desenho de uma solução, seguem:
- Particionamento do sistema, que envolve a escolha de padrões de arquitetura e a construção de diagramas de aplicação;
- Determinação de interfaces, que envolve o mapeamento de conexões com sistemas internos e externos, assim como requisitos de qualidade dos serviços envolvidos;
- Desenvolvimento de um Modelo de Segurança, onde deve-se avaliar autenticação, autorização, criptografia, logging, exceções, etc. Uma das ferramentas do modelo de segurança é a identificação de ameaças pelo chamado STRIDE - Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service e Evelation of privilege;
- Desenvolvimento de um Modelo de Desempenho, que deve considerar os requisitos de qualidade de serviço, o volume de processamento esperado e os objetivos de desempenho exigidos para o sistema, assim como o orçamento disponível para tais atividades;
- Criação de Protótipo de Arquitetura, que deve perseguir os risco de arquitetura, para uma prova em ambiente controlado;
- Criação da Arquitetura de Infraestrutura da solução, que deve mapear as questões para o processo de implantação da solução;
Com esse conjunto de atividades, conseguimos montar um desenho de solução, assim como uma organização para os vários componentes presentes na arquitetura e tecnologias envolvidas.
Para uma visão completa do MSF for Agile, confira o link:
MSF for Agile Software Development Process Guidance
Ref.: https://www.microsoft.com/downloads/details.aspx?familyid=9F3EA426-C2B2-4264-BA0F-35A021D85234&displaylang=en
Foi um belo começo de semana!
Por enquanto é só! Até o próximo post :)
Waldemir.
Comments
Anonymous
September 08, 2008
PingBack from http://hoursfunnywallpaper.cn/?p=5211Anonymous
September 08, 2008
Post bem interessante e gostaria de compartilhar que utilizamos uma abordagem bem parecida na empresa onde trabalho, categorizamos todas as ofertas em termos de legos e combos e os agrupamos em contextos de negócios onde: legos são os pilares da solução ex.:Arquitetura de interface, Sharepoint, etc combos são conjuntos de legos interrelacionados ex.: Implantação de portal moss contexto Esta organização permite que rapidamente nossas soluções sejam desenhadas e nas iterações seguintes os gaps entre legos preenchidos Isso acabou garantindo que desde o momento que a solução seja desenhada ate o momento da entrega ela mantenha uma coerência, alem de ser bem ludico pensar em termos de legos e como eles se encaixam :)