Você acredita em arquiteturas de software evolutivas?

Respostas a este tópico

Permalink Responder até Adriano Tavares em 19 abril 2009 at 21:53

Tratando-se de uma prática ágil, para que não se torne caótica acredito que o arquiteto deva participar ativamente do projeto para garantir sua aplicação que ao contrário do que parece exige mais disciplina que abordagens convencionais.

- Uma coisa fundamental é trabalhar junto com a equipe e não empurrar um documento por baixo da porta.
- Dar visibilidade para todos os envolvidos. Uma abordagem de múltiplas visões neste ponto ajuda mas não se esquecer da comunicação face-a-face.
- Evitar documentação muito extensa trabalhando em amplitude para mitigar riscos.
- Concentrar não só nas principais decisões técnicas mas também nas razões para estas decisões.
- Validar a arquitetura a cada iteração com provas de conceito, testes e principalmente: Software funcionando.
- Modelar a arquitetura de forma que possa absorver as mudanças que certamente vão surgir ao longo do projeto.

de Pangea, Adriano.

▶ Responder esta

Permalink Responder até Timothy High em 13 julho 2009 at 19:33

É claro que não existe limite claro. Toda aplicação tem caos, tem complexidade desnecessária e tem inconsistências, mesmo quando novinha. As vezes fica difícil o próprio arquiteto enxergar como a aplicação está evoluindo, enquanto um novo usuário ou desenvolvedor consegue ver plenamente. É uma questão que claridade, consistência e coerência no design. Dá para o desenvolvedor adivinhar como uma parte da aplicação deve ser implementado baseado no que foi feito em outra parte do sistema? Tem como comunicar a idéia básica da arquitetura através de um número pequeno de conceitos, ou tem muitas exceções a serem explicadas?

Como diz no artigo que você referenciou, arquitetura é a coleção de "conhecimentos compartilhados" pelos principais designers do sistema. Então, uma boa medida do nível de caos no sistema é a quantidade de conhecimentos que precisem ser compartilhados para entender a arquitetura.

▶ Responder esta

Permalink Responder até Luiz Carlos Faria em 4 novembro 2009 at 20:21

A intenção da arquitetura ser evolutiva é exatamente criar um ponto de 'corte'. Uma forma de ponderar entre realidade e utopia. Muitas vezes o necessário não é o belo ou o melhor, mas para quem gosta é difícil encontrar essa fronteira.
A questão do caos, se dá na má concepção das premissas iniciais. Criar um ponto de corte significa que não vou ter o universo, mas preciso ter um mundo 'operacional' e bem coordenado. Criando uma analogia com uma empresa: Não é pelo tamanho dela que você mede sua qualidade, o mais importante é crescer de forma sadia. Com a arquitetura o processo é o mesmo e ainda assim, mesmo com um crescimento maduro você vai encontrar pontos para serem refeitos, pelo simples fato de que a tecnologia é evolutiva. Não adianta você achar que seu modo de executar determinada operação será o melhor sempre. Há milhares de pessoas estudando para prover alguma coisa que pode agregar ou subsituir algo em seu framework de código, processo ou desenvolvimento.

▶ Responder esta

Permalink Responder até David Lojudice Sobrinho em 8 fevereiro 2010 at 12:25

Olá pessoal,

Tudo bem?

Sou novo no pedaço e este é meu primeiro post...:)

Descobri esse tópico que vai de encontro com o que estou fazendo atualmente. Escrevi dois posts sobre isso no meu blog:

http://cquesabe.blogspot.com/2010/01/system-of-systems-e-os-sistema...

http://cquesabe.blogspot.com/2010/01/system-of-systems-rest-hyperme...

(sugestões e críticas são bem-vindas)

Só uma coisa que gostaria de colocar para ajudar na discussão: a teoria da complexidade não é o mesmo que a teoria do caos, apesar das duas compartilharem algumas características. Acho que quando falamos "sistemas caóticos" na verdade o correto seria em "sistemas complexos", pois o simples fato de algo estar no estado caótico, ele não pode ser um sistema... ;)

Bom, já dei meu pitaco... agora que descobri essa comunidade, espero voltar mais vezes... abs!

▶ Responder esta

Permalink Responder até Camilo Ribeiro em 13 fevereiro 2010 at 19:31

Boa tarde,

Não sou arquiteto de software, mas já vi algumas arquiteturas evolutivas e outras "não tão evolutivas" na vida de "achar e evitar problemas" como testador. Por isso vou dar minha pequena contribuição mais teórica do que prática.

Uma das prioridades do SOA manifesto é exatamente essa, "Evolutionary refinement over pursuit of initial perfection", também é uma das preocupações de qualidade da ISO 9126, eu diria que em três das seis medidas (ou características) de qualidade (manutentabilidade, portabilidade e funcionalidade). Também está refletida com muita força em dois princípios de programação (Alta coesão e baixo acoplamento) como citado pelo grande professor Arndt Von Staa no seu livro "Programação Modular". Com certeza citado em muitos outros lvros e artigos assim como o indicado pelo Marcos Mendes na chamada essa ilha.

Acho que deve ser uma das preocupações do arquiteto, mas como citado pelo Marco Mendes, deve encontrar o ponto chave onde a arquitetura passa de flexível para desorganizada (missão para vocês, grandes arquitetos), o que varia de projeto para projeto e está muito mais ligado ao fator-negócio do que ao fator-técnico.

Boa parte disso foi resumida pelo comentário do Adriano Tavares: "Modelar a arquitetura de forma que possa absorver as mudanças que certamente vão surgir ao longo do projeto.".

Meio clichê o que vem a seguir, mas se pensarmos no mundo em constante mudança, com sistemas cada vez mais integrados, mercados mudando do dia para a noite, explosão da internet e dispositivos móveis e etc., não pensar em arquitetura de software evolutiva para um projeto de médio porte é assumir vários riscos.

Acredito que a tendência é a arquitetura corporativa e a arquitetura de software ficarem cada vez mais próximas e integradas (meio que uma arquitetura de sistemas), e uma das características mais fortes da arquitetura corporativa é o fator evolutivo.

É a "Teoria da Evolução Darwin" ultrapassando a fronteira da biologia e entrando no DNA das organizações.

Pessoal, desculpe por qualquer confusão no texto acima, espero não ter viajado muito.

Abraços.

▶ Responder esta

Permalink Responder até David Lojudice Sobrinho em 16 fevereiro 2010 at 12:50

Mais um link com informações sobre arquitetura evolutiva/emergente (agora do Gartner):

http://www.gartner.com/it/page.jsp?id=1124112

via InfoQ:

http://www.infoq.com/news/2009/08/Emergent-Architecture

▶ Responder esta

Permalink Responder até David Lojudice Sobrinho em 16 fevereiro 2010 at 13:06

E a propósito... acho que fica mais claro se fizermos uma distinção entre evolutiva e emergente...

Emerger: propriedades que não pertencem a nenhum dos sistemas emergem da combinação deles.

Evolução: a arquitetura muda durante o tempo confirme seus sistemas são substituídos.

▶ Responder esta

Permalink Responder até Juliano Nunes em 22 fevereiro 2010 at 16:10

Uma das coisas mais importantes é evitar que as solicitações "pra ontem" lhe faça alterar algo consistente para uma forma que consiga "quebrar um galho". É o famoso, "faz do jeito paliativo que depois a gente corrige."
Se você controla isto, a arquitetura evolutiva mantém a sua importância e sua vantagem (considerando que todo dia muita coisa nova surge e se sua arquitetura não pode evoluir, você perde oportunidade de melhorá-la).

▶ Responder esta

Permalink Responder até David Lojudice Sobrinho em 9 junho 2010 at 12:42

"Agility and Architecture: Can They Coexist?"

Achei muito interessante esse artigo (http://www.computer.org/portal/web/computingnow/0410/theme/software1 , resumo: http://www.infoq.com/news/2010/05/agile-architecture-partnership).

▶ Responder esta

Permalink Responder até David Lojudice Sobrinho em 28 julho 2010 at 16:01

Pessoal,

Vou fazer uma apresentação no Dev in Sampa sobre nosso case aqui na Abril e como usamos arquitetura emergente:

Case CMS Abril - System of Systems e Arquitetura (quase) Caótica
http://devinsampa.com.br/palestras#presentation-6

Fica ai o convite! :)

Abs!

David

▶ Responder esta

▶ Responder esta