Olá pessoal, tudo certo?

Recentemente, estive conversando com um cliente da área de seguros. O mercado de seguros e corretoras é realmente desafiador e contempla uma série de aspectos de arquitetura que precisam ser considerados na definição de uma solução de sucesso. E como era de se esperar, muitos desses aspectos são semelhantes para projetos em outras indústrias como finanças, bens e consumo, óleo e gás, telco, etc.

No fundo, estamos selecionando requisitos de software, funcionalidades e questões de performance para o negócio alvo. Após a seleção desses requisitos, fazemos o mapeamento de tecnologias que atendam da melhor maneira cada aspecto. Tudo isso pensando em questões como investimentos já realizados, manutenabilidade, capacitação de equipes, modelo de desenvolvimento, fornecedores de tecnologia, plataformas, tendências e evolução tecnológica futura.

Vejamos um exemplo. Imagine que em nosso cenário na indústria de seguros e corretoras, queremos construir um novo sistema para entrada de propostas de seguros, que será disponibilizado para corretoras. Uma primeira coleção de cenários sobre essa solução seria:

• são esperados diversos tipos de clientes e configurações diversas, com um parque de hardware e sistema operacional heterogêneo;
• deve existir a necessidade de atualizações remotas de regras de negócio, configurações e informações dinâmicas na estação;
• deve existir algum tipo de controle de acesso, credenciais de usuário, certificados digitais, autenticação e autorização de uma forma segura e eficiente;
• modularidade e isolamento de regras de negócio são importantes para uma arquitetura flexível e escalável e devem ser consideradas;
• user experience facilitado, com foco em data entry, navegabilidade otimizada e performance são importantes;
• possibilidade de acesso através de diferentes dispositivos, como desktop, pda's, celulares, etc;
• possibilidade de análises de negócio e estatísticas a partir das informações trafegadas pela arquitetura, elemento crítico para um maior acompanhamento da evolução do negócio, sobre a solução de TI;
• suporte a mecanismos de monitoração, auditoria e logging sobre a saúde da arquitetura;
• possibilidade de operação online e offline, considerando cenários onde a conectividade à internet não é constante;
• isolamento e convivência da solução diante de outras aplicações terceiras e/ou concorrentes, instaladas na mesma estação;

Enfim, já deu para notar que a lista de requisitos acima pode ser aplicada em outras soluções. São aspectos comuns, pois envolvem questões de disponibilidade, performance, interface, atualização, modularidade, etc.

Neste ponto, quais atividades um arquiteto deve realizar afim de discutir as considerações acima, buscando a correta definição de tecnologia para cada cenário?

Um bom começo é o uso de uma metodologia de desenvolvimento ou um framework de disciplinas para a construção de software, que descreva entregáveis, blueprints, padrões de documento e principalmente, uma relação de atividades guia previstas para o arquiteto.

Já bem conhecido do mercado é o MSF - Microsoft Solutions Framework. O MSF não é um processo de software ou metodologia, mas sim um conjunto de boas práticas provadas em projetos da Microsoft em seus parceiros e clientes. De fato, o MSF é agnóstico ao uso de técnicas de análise essencial ou análise orientada por objetos ou do uso de UML ou outra linguagem de notação, por exemplo.

Atualmente na versão 4.0, o MSF conta com duas configurações: o MSF for Agile e o MSF for CMMI Process Improvement. Entre os principais elementos do MSF encontramos um modelo de time, um modelo de processos e uma disciplina de risco, atividades, etc. Em posts futuros, vamos falar um pouco mais sobre o movimento ágil de desenvolvimmento de software, que é a base da configuração do MSF for Agile.

Assim, aproveitando o modelo MSF for Agile, as atividades previstas para um arquiteto que podem ser um ótimo guia na discussão de arquitetura são:

1. Particionamento do sistema, que envolve a escolha de padrões de arquitetura e a construção de diagramas de aplicação;
2. 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;
3. 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;
4. 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;
5. Criação de Protótipo de Arquitetura, que deve perseguir os risco de arquitetura, para uma prova em ambiente controlado;
6. Criação da Arquitetura de Infraestrutura da solução, que deve mapear as questões para o correto deployment da solução;

Percorrendo essas atividades, o arquiteto terá uma visão consistente para o estudo e mapeamento de tecnologias de cada requisito de software previsto na arquitetura alvo. Esse é um exercício que pode ser interessante para um processo bem documentado de decisões de arquitetura.

Finalmente, em posts futuros, vamos discutir as tecnologias que atendem alguns dos requisitos acima, enquanto estudamos o uso de padrões de arquitetura e mecanismos para um correto mapeamento entre requisitos de software e tecnologias aplicáveis.

Enquanto isso, deixo aqui alguns links interessantes:

MSF for Agile Software Development Process Guidance
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=9F3EA426-C2B2-4264-BA0F-35A021D85234&displaylang=en

E sobre as questões do movimento ágil, veja a seguir:

Agile Alliance
Ref.: http://www.agilealliance.org/

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

Waldemir.