http://www.bredemeyer.com/who.htm

Como conclução existen diferencia entre as ondas arquiteturais pero muitos arquitetos trabalhan en varias delas.

Brigado.

A “corrente agilista” acredita que bons times multidisciplinares são uma ótima estratégia para produzir bons softwares, de ponta a ponta, que realmente atendam às necessidades de seus clientes. Mas não significa que não acredite na divisão de papeis. FDD, por exemplo, define alguns papeis: Gerente de Projetos, Especilista de Negócio, Arquiteto, Gerente de Desenvolvimento, Programador Chefe e Programador. Mesmo em times XP há o papel do Líder Técnico, que é bem próximo ao papel do arquiteto de software que popularmente conhecemos (exceto talvez pelo fato de que ele normalmente envolve os outros programadores nas decisões; o que normalmente não acontece em abordagens fabris).

Agora, pelo que entendi deste post, Marco está falando sobre possíveis disciplinas de arquitetura que podem haver em corporações, o que está além de um projeto de software desenvolvido sob uma abordagem ágil ou não.

Por exemplo, um “arquiteto de software” está em um time que está desenvolvendo um projeto de softare. Este projeto, por sua vez, pode ou não estar sendo desenvolvido sob uma abordagem ágil. Se estiver, ótimo!

Já os outros arquitetos desempenham papeis que vão além de um projeto [que pode ou não ser desenvolvido sob uma abordagem ágil]. Aliás, em alguns casos, estes arquitetos (dependendo da posição na “onda”) vão atuar em projetos que nem mesmo de desenvolvimento de software são. A partir da segunda posição na onda, os papeis dizem mais respeito a dizer como as coisas funcionam e se relacionam em uma corporação – quardados os seus devidos escopos, claro.

(Só pra constar, há alguns anos andei dando uma olhada em TOGAF, por influência de um amigo. Mas não achei que seja a minha praia.)

[]s
Leandro
{leandrosilva.com.br}

Apesar disso, concordo com a visão ágil sobre o desenvolvimento de software e do trabalho colaborativo. No artigo citamos primordialmente papéis e podemos ter pessoas e times com interseção assumindo estes papéis. Inclusive, o Scott Ambler tem um trabalho interessante a respeito: “Agile Enterprise Architectures”, que postei em PANGEA. http://pangeanet.org/group/enterprisearchitecture/forum/topics/arquiteturas-empresariais

Legal o post. Esse tipo de assunto faz parte do meu cotidiano e embora (acredito eu) essas definições não sejam “politicamente corretas”, elas são reais e fazem parte do cenário atual de TI.

Digo que não são “politicamente corretas” no sentido da corrente agilista, que afirma que na verdade a melhor forma de se desenvolver um software é com um bom time e não com uma boa divisão departamental. De qualquer maneira procuro ser o menos tendencioso possível para assumir o que é certo e o que é errado e acredito que as duas abordagens possam coexistir. Entendo que uma boa divisão departamental seja crucial para um bom entendimento dos deveres e responsabilidades de cada área e é muito útil em discussões estratégicas de nível gerencial, de diretoria e até presidencial.

Porém quando o assunto é desenvolver software, essa divisão pode ser até meio prejudicial pois ela incentiva a passagem de bastão (jogo da batata quente) entre as áreas que fogem desesperadamente de suas SLA’s. Quem está em alguma posição de liderança, tem a obrigação de ter esse tipo de questionamento e de alguma forma tentar achar uma solução viável olhando sempre para o core business da empresa. Para os superficiais de plantão: Não existe solução enlatada! Você vai ter que fazer muita pesquisa e por o tico e o teco pra funcionar!

[]’s
-l30-

Muito interessante seu post. Quando li o quinto parágrafo falando sobre arquitetos de TI logo relacionei com o CTO e mais embaixo você confirmou isso. Nesse “nível” está correto afirmar que ITIL é outro exemplo de modelo?

Além disso, você acredita que existe o papel de “arquiteto de sistemas”? Pelo que entendi este profissional teria que conhecer muito bem de todas as áreas, então imagino que o cargo até possa existir, mas não sozinho, ou seja, ele depende de uma equipe (DBAs, Infra, etc) para auxiliá-lo nas decisões, tal como você escreveu.

Obrigado.