confesso que não lí todo o post…

apesar e acima disto quero parabenizá-lo novamente pela seriedade e sagacidade ao expor este tema.

conforme foi lembrado por um dos colegas comentaristas, estamos nos referindo a sistemas e suas variantes, às vezes, linguística e conceituais: meta, supra, infra ou seja, sistemas geralmente compõem-se de sistemas.

em outro comentário citei o trabalho de Ludwig von Bertalanffy (http://pt.wikipedia.org/wiki/Ludwig_von_Bertalanffy) e sua contribuição para evolução do pensamento sistêmico.

eis o nome do jogo… desenvolvermos nossa habilidade em “ver” sistemas. daí a pertinência da discussão sobre arquitetura: é um misto de técnica e arte.

continue incitando-nos a aprender!

[]s livres,

Leo, Guarujá/SP-BR

Acho que a coisa é bem por aí mesmo. Talvez sejam os labels, rótulos que atrapalhem tanto na comunicação. De certa forma, acho que alguns deles deixaram um gosto amargo por conta da experiência particular do nosso campo nos últimos anos. É a sina da massificação, entretanto.

Desde que haja esse entendimento de que todos trabalhamos em sistemas, o problema deixa de existir pelo menos em um nível. Descasca-se o primeiro nível da cebola e que venha o próximo.

As bolinhas me fizeram lembrar de World of Goo, a propósito. Arquitetos, construtores, e tal

—

Opa, Lucas! Bom ver você por aqui.

Gostei do post!

Obrigado! Gostei igualmente do seu texto e achei que valia a pena o comentário para complementar a discussão–resgatar essa qualidade de blogs de espalhar a conversa

Acredito que, num nível fundamental, nós concordamos completamente. O que parece ser discordância, na verdade, é a expressão da opinião de dois pontos de vista diferentes: você como arquiteto-chefe e eu como desenvolvedor. Isso é natural.

No fim das contas, o que mais importa é não criar uma “aura sagrada” em torno do arquiteto (ou equipe de arquitetura), como se fosse superior e o grande sabe-tudo. Ele tem que participar junto com os desenvolvedores e ajudá-los no entendimento da solução e no amadurecimento profissional deles.

Sem sombra de dúvida. Eu tenho pensando muito nesse assunto e tentado entender as raízes disso. Acho que parte vem do que você mencionou em seu texto, do arquiteto como consultor, movido a PowerPoint que chega para “salvar” a situação em projetos quebrados. Devemos muito às metodologias ágeis por resgatar parte disso mas temos um bom caminho a andar antes que as coisas se ajeitem pelo menos em alguma medida.

Também não podemos fixar um pensamento apenas num determinado tipo de problema e solução. Como você bem disse, a necessidade (e utilidade) de uma equipe de arquitetura aumenta em proporção direta com o tamanho do problema. Nunca trabalhei em algo que eu considere “realmente grande”, então meu universo se restringe à soluções onde não vejo a necessidade, como escrevi no post.

Com certeza e essa é uma das coisas em que eu difiro do Brooks e volto-me ao lado ágil das coisas. Meio evitar o problema de achar que tudo é prego quando se tem um martelo.

O único “porém” que lanço aqui é que, em muitos casos, problemas grandes tem soluções pequenas e simples mas, em grandes corporações, o mindset acaba levando à criação de soluções gigantescas. Essas, geralmente, são as falhas catastróficas e, muitas vezes, são causadas por arquitetura excessiva: já que temos uma equipe de arquitetos, temos que justificar sua existência, logo todo problema passa a ter uma solução grande e complexa.

Infelizmente, esse parece ser o modelo mais comum de prática arquitetural. Meu texto reflete mais o desejo de fazer a coisa certa do que ter visto o cenário dar certo sempre, é a verdade. Acho que falta educação–aqui no sentido de ensino/experiência mesmo–tanto entre arquitetos quando entre desenvolvedores para que isso aconteça de maneira mais suave. Esse risco de afastamento está sempre presente e em nosso mercado sempre volátil, a falta de dar tempo para que as coisas tomem um rumo mais sólido só aumenta o problema. As próprias empresas sabotam sua arquitetura ao forçar deadlines impensadas, estabelecer condições impossíveis e por aí vai.

Resta pensar e tentar agir onde é possível.

Obrigado pela menção e pelas opiniões.

Eu é que agradeço, novamente.

(gostei do tema do blog também, ficou limpo e fácil de ler)

Esse foi um achado. Não é único, mas finalmente satisfez a minha necessidade de balanço. Apesar de que Google Analytics e Google Feed Burner diz que menos de 10% dos meus leitores usuais usam o site.

Acredito que, num nível fundamental, nós concordamos completamente. O que parece ser discordância, na verdade, é a expressão da opinião de dois pontos de vista diferentes: você como arquiteto-chefe e eu como desenvolvedor. Isso é natural.

No fim das contas, o que mais importa é não criar uma “aura sagrada” em torno do arquiteto (ou equipe de arquitetura), como se fosse superior e o grande sabe-tudo. Ele tem que participar junto com os desenvolvedores e ajudá-los no entendimento da solução e no amadurecimento profissional deles.

Também não podemos fixar um pensamento apenas num determinado tipo de problema e solução. Como você bem disse, a necessidade (e utilidade) de uma equipe de arquitetura aumenta em proporção direta com o tamanho do problema. Nunca trabalhei em algo que eu considere “realmente grande”, então meu universo se restringe à soluções onde não vejo a necessidade, como escrevi no post.

O único “porém” que lanço aqui é que, em muitos casos, problemas grandes tem soluções pequenas e simples mas, em grandes corporações, o mindset acaba levando à criação de soluções gigantescas. Essas, geralmente, são as falhas catastróficas e, muitas vezes, são causadas por arquitetura excessiva: já que temos uma equipe de arquitetos, temos que justificar sua existência, logo todo problema passa a ter uma solução grande e complexa.

Obrigado pela menção e pelas opiniões.

(gostei do tema do blog também, ficou limpo e fácil de ler)

E é característica do sistema que trabalhamos que os componentes de um determinado nível influencie no funcionamento das abstrações superiores (ou menos detalhadas) e por isso a colaboração dos responsáveis por cada nível de abstração (enterprise architect, system architect, software architect, tech leader, devs, etc.) é extremamente importante.

Parabéns novamente pelo post.

Bem, se você se perdeu acho que, infelizmente, não consegui passar bem minha opinião. Chega um momento em que multo texto realmente não vale a pena. Sorry.

Sobre o seu ponto, não discordo. Só acho que precisamos separar duas coisas. Sobre a questão de precisar saber, sim, foi exatamente o que respondi ao Rodrigo no comentário anterior. Ninguém consegue fazer o seu trabalho se não conseguir entender em que contexto se situa.

Mas, por outro lado, não acredito de que a arquitetura seja tão “fácil” de definir naturalmente assim em determinados contextos. Como disse no texto, depende muito do escopo. Digamos que estamos falando de um projeto que na verdade é a combinação de seis a dez outros projetos diferentes em um escopo de tempo variável. Qual seria a solução, colocar quarenta pessoas em uma sala e esperar que saia consenso disso? Eu acho que não mas sempre estou aberto a sugestões de como fazer a coisa melhor. Não acredito que conhecimento seja algo fechado.

Sobre a “visão além do alcance”, novamente, acho que isso é uma idealização simplista. Todo projeto possui riscos. Quanto maior o projeto, maior os riscos. Você pode olhar a questão toda, então, do ponto de vista de alguém que vai ter mais responsabilidade porque vai correr, proporcionalmente mais risco. Arquitetura ad hoc, que não leva em conta esses riscos, não se paga no final. É por isso que não dá para olhar para todos os casos com o mesmo prisma. Quem é que define quais são os impactos econômicos de determinadas decisões? Se eu usar esse tipo de comunicação ou não, meu custo de banda fica dez vezes maior: posso ou não fazer? Multiplique isso por cem usos e as respostas não são tão simples.

Finalmente, sim, se o objetivo “final/ideal” não está sendo definido por ninguém, há uma falha gritante a ser corrigida.

Abraços e obrigado pelo comentário!

“[...] Por conta disso, Brooks chega à conclusão de que a única maneira de atingir algum nível de consistência e integridade no desenho arquitetural de um sistema é obter uma visão única de como as estruturas devem se comportar no seu nível mais alto: em outras palavras, criar a arquitetura de um sistema.”

Na minha humilde opinião, arquiteto ou não, todo desenvolvedor tem obrigação de saber “como as estruturas devem se comportar no seu nível mais alto”. Quando todos sabem o “objetivo final/ideal” do seu software, a arquitetura é definida naturalmente pelo grupo, e não por um ser “com visão além do alcance”.

O que geralmente ocorre, é que este objetivo “final/ideal”, nunca é definido por ninguém, e sempre ficam em situações “E se …”

Sucesso!

Pelo que entendi do seu ponto de vista, a necessidade de uma equipe de arquitetura é justificável em projetos de grande porte, ou melhor “coisas que possuem necessidades maiores que simplesmente as de um único escopo”. E neste caso, um arquiteto é alguém que é capaz de enxergar o projeto com um todo, necessariamente além do escopo de um time qualquer de implementação,

Sim. Complementando o que eu disse no texto, eu acredito que arquitetura é meramente um papel–não uma parte de uma hierarquia de desenvolvimento. Dizer que um projeto precisa de um arquiteto, é, de muitas formas, similar a dizer que ele precisa de um especialista no tópico X, Y ou Z (por exemplo, um especialista em grafos para um projeto que precisa de usá-los para alguma coisa). Ou dizer que um projeto ágil precisa de um scrum master, para trazer uma situação mais próximo.

Cada um contribui para o projeto de acordo com a necessidade e de acordo com suas especialidades. Esse é o ponto de ter equipes multi-disciplinares, inclusive. Agora, é claro que todos envolvidos no projeto precisam ter pelo menos uma visão geral do todo para poder trabalhar em questões de implementação. Uma coisa não exclui a outra.

Se a “falha” é de todos envolvidos no processo, por que então centralizar “decisões arquiteturais” em um único ponto, aquele que “enxerga o projeto com um todo”?

Sabendo que esse tipo de “centralização” está susceptível à ruídos na comunicação que podem causar ainda mais “falhas”, não seria mais inteligente que “todos envolvidos no processo” participassem das “decisões arquiteturais”?

Eu acredito que uma coisa não tem a ver com a outra. Vou tentar separar as coisas para ver se consigo explicar melhor.

Primeiro, eu não acredito que o papel do arquiteto implique em centralização no sentido negativo. Acho que o texto tenta deixar isso claro ao dizer que a arquitetura e desenho são papéis colaborativos (há um link específico sobre isso para o blog Scaling Agility no texto). Mas o ponto é que, em alguns momentos, você precisa de centralização, sim. É o que Brooks fala sobre o fato de que desenho por comitê não funciona. Quem não participou de uma reunião com dezenas de pessoas em uma sala em que nada é produzido, ninguém consegue concordar com nada porque, simplesmente, com esse tanto de gente, comunicação de qualidade não ocorre? Como Brooks menciona em seu famoso livro, o número de canais aumenta com o quadrado do número de participantes: o dobro de pessoas gera quatro vezes mais canais com mais susceptibilidade a falha.

“Centralização”, nesse sentido, é uma redução desse problema–ou seja, isso não causa mais ruídos, causa menos. E volto ao ponto, para equipes pequenas, em projetos auto-contidos, arquitetura é igual a design que é igual a implementação. Além disso, se há um problema de comunicação, provavelmente é porque as “decisões” não estão sendo colaborativas, não estão trafegando corretamente entre as várias partes envolvidas.

O que volta ao caso de que, sim, a falha é de todos envolvidos porque, se o arquiteto não consegue conversar e simplesmente “hands down” decisões ou folhas de papel, isso está errado. E se o desenvolvedor também acha que qualquer coisa que vem do seu parceiro é inerentemente falha, o mesmo ocorre. Um problema aqui é que quase nunca percebemos que arquitetura geralmente é mais simples do que se pensa. Por exemplo, escolha de linguagem é arquitetura ou não?

Espero que isso tenha esclarecido um pouco mais. Caso contrário, fire away.

Gostaria de ressaltar alguns pontos do seu longo artigo:

(…) surge a necessidade de arquitetura como uma colaboração de papéis empregando arquitetos de sistemas e arquitetos de software (chamados de tech leaders internamente) para chegar a um design final coerente. (…)

Esse arquiteto, dentro do time, é um desenvolvedor sênior capaz de fazer decisões de design em colaboração com seus pares, praticar a mentoria, planejar e executar escolhas de implementação (…)

Pelo que entendi do seu ponto de vista, a necessidade de uma equipe de arquitetura é justificável em projetos de grande porte, ou melhor “coisas que possuem necessidades maiores que simplesmente as de um único escopo”. E neste caso, um arquiteto é alguém que é capaz de enxergar o projeto com um todo, necessariamente além do escopo de um time qualquer de implementação,

(…) a falha pode ser rastreada para decisões que foram tomadas em pontos errados do processo por problemas de comunicação ou de definição de escopo resultado em design inconsistente pelo qual ninguém quer tomar a responsabilidade. A falha, nesse caso, é de todos envolvidos no processo.

Se a “falha” é de todos envolvidos no processo, por que então centralizar “decisões arquiteturais” em um único ponto, aquele que “enxerga o projeto com um todo”?

Sabendo que esse tipo de “centralização” está susceptível à ruídos na comunicação que podem causar ainda mais “falhas”, não seria mais inteligente que “todos envolvidos no processo” participassem das “decisões arquiteturais”?