A prática de arquitetura

November 9th, 2009 § 9 comments

O Lucas Húngaro, que trabalhou comigo na WebCo, escreveu há poucos dias um artigo muito bom sobre a dificuldade de dissociar nomes e funções em projetos de software e sobre sua visão do processo de desenvolvimento e arquitetura. Desnecessário dizer, concordo essencialmente com tudo o que ele diz, com algumas pequenas ressalvas.

O leitor atento do blog deve estar se perguntando agora: mas, há menos de uma semana, você não disse que lidera uma equipe separada de arquitetura onde trabalha agora–isso não é uma contradição? Na verdade, não. Antes de responder a questão, porém, peço que o leitor me acompanhe por algumas considerações.

Como o Lucas menciona eu seu texto, o tópico de arquitetura de software é bastante controverso. De fato, ao longo das quase sete décadas desde que existe algum processo de desenvolvimento, nunca se chegou a um consenso sobre o que esse termo realmente significa. Ano após ano, novos artigos e livros são escritos para explicar o que se entende pela prática e metáforas abundam.

Eu não vou dizer que tenho a palavra final sobre o assunto, é claro. Nos últimos anos, entretanto, eu tenho pensado continuamente sobre o tema, especialmente como uma reflexão sobre o meu trabalho e cheguei a uma conclusão de que minha visão é bastante similar à advogada por Fred Brooks, com algumas pequenas diferenças que refletem minha experiência própria.

Brooks, na palestra que assisti, propôs o seguinte postulado: “Não há tecnologias ingênuas no Ocidente”. O que ele quis dizer com isso é que em qualquer domínio de conhecimento, a faixa de conhecimento e habilidades exigidas é maior do que uma única pessoa pode dominar em um dado projeto.

Ele usou como exemplo o caso de fabricantes de shampoo que usam simulações do fluxo de fluidos viscosos para garantir que as lâminas misturadoras não separem a emulsão de camadas triplas do produto final; adicionalmente, ele também comentou sobre uma fábrica de bolos em que a receita do dia é modificada pela análise química dos ingredientes que chegam a cada dia na planta.

O fato é que esse tipo de especialização de engenharia é uma constante reconhecida mesmo por metodologias ágeis em que a multi-disciplinaridade das equipes é exigida como uma das premissas para o funcionamento do processo.

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.

Em seu livro Computer Architecture: Concepts and Evolution (escrito em parceria com Gerrit A. Blaauw), Brooks define arquitetura de sistemas computacionais da seguinte forma:

The architecture of a computer system we define as the minimal set of properties that determine what programs will run and what results they will produce. The architecture is thus the system’s functional appearance to its immediate user, the conceptual structure and functional behavior as seen by one who programs in machine language.

Eu ressaltei the minimal set of properties porque isso representa uma dos grandes desentendimentos sobre o que arquitetura de software realmente significa e quais são os entregáveis da mesma. Como Brooks e Blaauw apontam, se arquitetura é o conjunto mínimo de propriedades de um sistema, existem outras coisas que, por definição não são arquiteturais e que ainda assim precisam existir para que a implementação suceda.

Nesse sentido, podemos fazer uma distinção bem clara entre a arquitetura e o design de um sistema para entender o desdobramento do projeto de um sistema qualquer. Enquanto a arquitetura existe mais no nível do mapeamento e organização fundamental de um sistema, como entendida através de seus componentes, os relacionamentos entre esses e sua distribuição em domínios de tempo, economia (sim, porque dinheiro também é arquitetura) e escala, o design está mais centrado no domínio de resolução de problemas e planejamento para implementação da solução.

Em outras palavras, a arquitetura é voltada a atingir necessidades de negócio através de blocos maiores de construção do sistema enquanto o design é a disseminação técnica desses objetivos em algoritmos, sub-sistemas e escolhas de implementação.

O que leva à conclusão, por parte de Brooks, e com a qual eu concordo, de que para que se consiga integridade conceitual e estrutural da arquitetura, a figura de um arquiteto-chefe é necessária. Isso é óbvio quando se pensa no negócio como um todo e seus desdobramentos em múltiplas responsabilidades, projetos, sistemas de sistemas e relacionamentos da construção do software em si.

Uma palavra-chave aqui que ajuda esclarecer a distinção aqui é grande porte. Por grande porte, eu quero dizer projetos com um escopo grande ou com grandes características de distribuição. Como Brooks mesmo elabora em seus textos e palestras, se o sistema é pequeno o suficiente, não é necessário que exista uma distinção entre arquitetura, design e implementação. Brooks, na verdade, vai além ao sugerir que o arquiteto e implementador sejam uma única pessoa. Para projetos de porte maior, entretanto, sem uma visão consistente é impossível conseguir a consistência necessária entre as partes.

O arquiteto de sistemas, em outras palavras, é alguém que é capaz de enxergar o projeto com um todo, necessariamente além do escopo de um time qualquer de implementação, mesmo quando o design que esse time está seguindo é auto-contido dentro das premissas daquele time e somente se comunica com externalidades através de protocolos e convenções arquiteturas definidas anteriormente.

Como um exemplo disso, em uma de suas palestras, Brooks menciona uma discussão que ele teve com a pessoal responsável pela arquitetura de sistemas do Global Positioning System (GPS). Esse arquiteto entendia que o sistema como um todo era baseada na interação complexa entre muitos componentes (satélites e outros) e que a moeda corrente entre esses sistema era tempo, dividido em micro-segundos. Ainda mais, o arquiteto via como sua responsabilidade garantir que cada processo conseguisse a fatia necessária de micro-segundos para sua operação–com, como Brooks colocou, bastante micro-segundos sobrando em seus bolsos para resgatar partes do sistema que estivessem em dificuldade.

E isso é o que realmente eu entendo por arquitetura de sistemas. Aos proponentes de arquitetura emergente–tão comum entre praticantes de metodologias ágeis–a implicação é clara: é simplesmente impossível que arquitetura nesse porte, dessa complexidade, venha algum dia a emergir de times separados, trabalhando em componentes próprios, com suas próprias necessidades. Primeiro, por conta da onipresente necessidade de integridade conceitual e, segundo, por conta da degradação de comunicação à medida que o sistema de torna mais complexo e decisões maiores são cristalizada em um conjunto de constraints e especificações–o que Brooks chama de style sheet do projeto.

Volto a Brooks aqui para afirmar o ponto de que um comitê não é um bom lugar para se buscar integridade arquitetural:

Textbook examples of design are almost always “way too simple,” said Brooks. In particular, they ignore the fact that complexity often forces designs to change halfway through, and these changes then involves many other changes. Finally, there is no substitute for “the dreariness of labour and the loneliness of thought”–even though it has been joked that committees are a place where people seek refuge from that.

O arquiteto de sistemas é, em última instância, como Brooks também coloca, um advogado do usuário. Ele advoga pelo usuário em termos funcionais, em termos econômicos, e em termos de escala. Como mostrado na citação acima, o arquiteto de sistemas representa a aparência funcional do sistema para seu usuário imediato, visto pela lente de alguém que programa em linguagem de máquina. E, sim, é um papel técnico.

Para citar Brooks mais uma vez:

Computer architecture, like other architecture, is the art of determining the needs of the user of a structure and then designing to meet those needs as effectively as possible within economic and technological constraints. Architecture must include engineering considerations, so that the design will be economical and feasible; but the emphasis in architecture is on the needs of the user, whereas in engineering the emphasis is on the needs of the fabricator.

Note a diferença em ênfase como colocada por Brooks: arquitetura enfatiza as necessidades do usuário enquanto engenharia enfatiza as necessidades do construtor.

As implicações são bastante óbvias e essencialmente respondem à questão da minha concordância com o que o Lucas disse e com o fato de que eu lidero uma equipe de arquitetura: as necessidades de desenvolvimento são completamente diferentes.

Tirando um exemplo da minha própria experiência, quando eu trabalhava na WebCo, tínhamos apenas dois produtos: Brasigo e BlogBlogs. Por mais complexos que ambos sistemas fossem, suas necessidades arquiteturais eram comparativamente pequenas. Da mesma forma, por mais similares que ambos fossem (aplicações escritas em Rails, virtualizadas, com gargalo em banco de dados, etc), havia poucas conexões arquiteturais para que a figura de um arquiteto-chefe fosse necessária.

E, de fato, pelo tamanho dos projetos, podíamos ter, sem problemas, a figura de um arquiteto em cada time, servindo como líder técnico, ponto focal em discussões entre produtos, alguém como senioridade o suficiente para fazer um papel de mentor para membros mais novos da equipe.

Esse não é o caso em minha posição atual, na Abril Digital. Não só a complexidade dos sistemas é maior, tanto em escala como em distribuição, como a relação entre eles é mais porosa e necessitando de coordenação. Construir um sistema de sistemas constituído de dezenas de sub-sistemas, cada um com suas necessidades, escopo e papel é fundamentalmente diferente de construir um único produto, com limites e condições bem específicos. Não estamos construindo algo do tamanho de um sistema de GPS, claro, mas estamos construindo coisas que possuem necessidades maiores que simplesmente as de um único escopo.

Por conta disso, 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.

Isso é ainda mais fundamental em projetos terceirizados que, em um ponto ou outro, precisam se encaixar em nossa infra-estrutura e arquitetura em múltiplos times e instâncias de sistemas. Uma equipe dedicada serve para ajudar nessa coordenação, oferecendo visões do problema. O gap arquitetural é assim resolvido já que existe uma rodovia arquitetural contendo épicos que guiam a quebra de sistemas nas partes necessárias.

Dessa quebra nascem preocupações que podem ser traduzidas no design emergente em cada equipe, contribuindo ao final, para o retorno ao pool arquitetural de conceitos e implementações feitas no ato de descoberta que é o processo de desenvolvimento.

Eu acredito nessa colaboração de papéis como essencial para garantir a agilidade. Citando um dos artigos de Martin Fowler:

This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. When I see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in non-technical terms–such as development costs.

Nesse artigo, Fowler usa uma versão limitada do que Brooks diz para definir um tipo de arquiteto não desejável. E Fowler está correto: usar o argumento de Brooks simplesmente para suportar alguém que simplesmente “toma as decisões mais importantes” não faz sentido.

Isso tudo que foi dito anteriormente não significa, também, que essa arquitetura de sistemas não possa falhar. Ela falha, sim, e algumas vezes catastroficamente. E, na maioria das vezes, 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.

Para resumir toda a conversa, considerando que esse texto acabou quase se tornando um ensaio, eu concordo com o Lucas: cada time deve ter o seu arquiteto. Mas acredito também que, para projetos com maior escopo, deve existir um nível mais alto de arquitetura–e por mais alto aqui não quero dizer em termos de uma elite ou de conhecimento mas simplesmente um papel que defina o que é mais alto simplesmente porque tecnicamente, alguém define que esse é o nível mais alto necessário.

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, atuando em conjunto com um time de arquitetos de sistemas que está preocupado com o todo e que não tenta, de forma alguma, forçar decisões de implementação ou design, que busca embasar suas decisões pela velha métrica do running code and rough consensus, que pratica código diariamente pelos meios necessários.

O que significa, essencialmente, que a arquitetura não tem que ser fechada no começo e permanecer imutável depois disso. Ao contrário, precisa evoluir como qualquer outra parte do sistema na percepção do que funciona e do que não funciona. Como Kent Beck diz:

The process of building architecture should have lots of feedback built in and it should be kept simple, because extra elements in the architecture introduce instability and unpredictability. The big difference from current practice is that: “I would stop apologizing for architecting this way,” he says

Espero com esses monte de palavras ter clarificado um pouco a visão do que andei escrevendo aqui nos últimos tempos. Obrigado ao Lucas por fornecer a oportunidade de uma discussão boa como essa–espero que ela continue, por sinal.

Aos leitores que tiveram paciência de chegar até esse ponto, quais são suas visões e comentários sobre o assunto? A caixa de comentários lhes espera impacientemente. :-)

Tagged

§ 9 Responses to A prática de arquitetura"

  • Olá Ronaldo,

    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”?

  • Ronaldo says:

    Opa, Rodrigo! Tudo bom?

    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. :)

  • Roger Leite says:

    Olá Ronaldo!
    Li e reli seu post, e como me perdi várias vezes, tentei sintetizar ao máximo o que você quis dizer:

    “[…] 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!

  • Ronaldo says:

    Opa, Roger! Tudo bom?

    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!

  • David says:

    Excelente post. Colabora com a desmistificação da idéia de hierarquia entre devs e arquitetos. Afinal, estamos todos olhando para bolinhas e como elas se falam (trabalhamos com sistemas, certo? http://pt.wikipedia.org/wiki/Sistema). A diferença básica mora no corte de abstração que olhamos para o tal sistema.

    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.

  • Gostei do post!

    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)

  • Ronaldo says:

    Opa, David, obrigado! :)

    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. :)

  • Leocadio says:

    olá, paz e bem!

    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

  • Leonardo says:

    Processo de arquitetura em equipe, independente do escopo, do porte, das soluções técnicas, do cliente, depende a priori de uma única figura: O Arquiteto que lidera a equipe. É preciso clareza e decisão.
    Equipe desorganizada é resultado de uma liderança desorganizada. Digo isto porque participei por anos de uma equipe que possuia um enorme potencial de produção e que sofria inúmeros “ataques organizacionais” de um lider que não sabe entender a demanda com clareza e praticidade.
    Decisões devem ser claras e precisas de forma que todos os membros da equipe, e principalmente o cliente, entendam o andamento da coisa.
    Teorias e utopias são de suma importância, porém são ferramentas de uso restrito a arquitetos. Quando a idéia vira projeto ela saida teoria, da mente e é incorporada às realidades físicas, construtivas, financeiras, ambientais, dentre outras. Daí, ela demanda resoluções em partes, vinculada sempre ao processo Cartesiano do método. Cada profissional envolvido deve compreender o todo do projeto e dominar o todo de sua parte no desenvolvimento do processo.
    Softwares, computadores, pranchetas, canetas e afins, são ferramentas usadas na representação do projeto. Representação esta que deve ser simples, clara e o mais objetiva possível.
    Já pequei por fornecer menos detalhes que o necessário e também pequei por fornecer inúmeros detalhamentos que nem foram sujos na obra. Certa vez um cliente me alertou deste problema.
    O cliente e o pessoal da obra são os grandes indicadores de seu trabalho, portanto é importante ouvi-los e trocar idéias.
    Arquitetura é isto, sempre foi e sempre será. Ao observar o tratado de arquitetura do Paládio, podemos sentir que as descrições de sua obra, bem como seus desenhos possuem um teor construtivo impírico maravilhoso, além da grande e fantástica qualidade estática que possuem.
    O arquiteto deve ser humanista não sóna hora de discutir filosofia e fazer croquis com cara de gênio inovador. Ele deve ser humanista em seu dia-a-dia observando a realidade local, conhecendo melhor seus clientes e trocando idéias com o pessoal da obras. Ler livros de arquitetura é ótimo, bom demais, porém mais impolgante é escrever a sua história mesmo que pequena.

Leave a Reply

Your email address will not be published. Required fields are marked *

What's this?

You are currently reading A prática de arquitetura at Superfície Reflexiva.

meta