BT

Frustração com Arquitetura: qual a função dos Arquitetos nos projetos de software?

por Richard Seroter , traduzido por Robison Tesini em 04 Mai 2012 |

Seria a Arquitetura de Software um aspecto negligenciado e mal realizado nos projetos de software? Esta é a posição defendida em um post recente de Simon Brown, consultor independente e fundador do site CodingTheArchitecture.com. Brown afirma que a escolha de arquitetos inadequados para o papel e a maneira informal de se lidar com arquitetura em projetos ágeis têm contribuído com a má situação da disciplina de Arquitetura.

Segundo Brown, arquitetos desconectados com a realidade do desenvolvimento, que ficam em uma "torre de marfim", continuam a danificar a reputação da arquitetura de software. Ao invés de trabalhar próximos às equipes de desenvolvimento e modelar uma solução prática e bem pensada, vários arquitetos trabalham de forma independente dos desenvolvedores, entregando apenas especificações complexas e abstratas. Quando os arquitetos de software falham em agregar valor a um projeto, o resultado pode ser uma marginalização da arquitetura formal, o que faz com que os programadores mais despreparados tenham que assumir o papel de modelagem. Brown vê isso como um enorme problema e argumenta que os projetos executados com metodologias ágeis agravam ainda mais a situação. Ele alega que os projetos Agile frequentemente negligenciam princípios sólidos de arquitetura em prol de maior rapidez nas entregas.

Muitas equipes de desenvolvimento parecem pensar que não precisam de um arquiteto, usando termos como "equipes auto-organizadas", "YAGNI"(do inglês "You Ain't Gonna Need It": você não vai precisar disso), "arquitetura evolucionária" e "último momento responsável". Se precisarem de um arquiteto, provavelmente irão procurar um "arquiteto ágil". Não sei bem o que isso significa, mas imagino que tenha a ver com a utilização de post-its ao invés de UML, e de fazer TDD em vez de desenhar figuras. Isso se não abandonarem inteiramente a ideia de uma descrição da arquitetura do sistema, e usarem "design emergente" como desculpa para esperar ingenuamente que nada vai dar errado.

Mas nem tudo está perdido: Brown afirma que há utilidade para princípios sólidos de arquitetura em todos os tipos de projetos, mas desafia a comunidade de arquitetura a fazer melhor, explicando os seus valores e investindo nos arquitetos do futuro. O InfoQ ouviu Brown sobre o estado da Arquitetura e como melhorar sua prática.

InfoQ: Para citar um dos comentários do seu post, "o que exatamente um verdadeiro arquiteto faz?"

Brown: Um dos grande problemas com o termo "arquiteto" é que cada pessoa, equipe e organização tem sua própria definição. Na minha opinião, o papel de um arquiteto de software é trazer liderança técnica a uma equipe de software. Eu acredito que um certo grau de "design" é necessário no início de todo projeto de software e a dica é aplicar "just enough" ( somente o mínimo necessário), o que em resumo é a criação de uma estrutura de alto nível, lidando com os maiores riscos da aplicação e criando uma visão sobre a qual o resto da equipe possa trabalhar. Fora o trabalho inicial, o papel do arquiteto é ser "o dono" e evoluir o "design" inicial durante os ciclos de entrega do software quando necessário. Vale salientar que eu estou falando sobre um papel e não um cargo, e uma ou várias pessoas podem assumí-lo. Recentemente eu organizei um seminário na conferência QCon Londres 2012 onde respondi várias perguntas relacionadas com o papel do arquiteto. É interessante que o papel que foi discutido é muito diferente do que se encontra em várias organizações.

InfoQ: Por que você acha que arquitetura de software ainda é uma disciplina tão incompreendida? O que contribuiria para um entendimento melhor deste papel?

Brown: Acho que arquitetura não é bem compreendida por ter ficado com má reputação na indústria de informática. Além disso, a maior parte do material didático sobre a disciplina é vista como sendo muito superficial ou acadêmica. Usar termos como "estrategista de tecnologia de negócios" e "proposição de valor" afasta os desenvolvedores da disciplina, ao invés de aproximá-los.

O motivo de termos criado o site Coding the Architecture (codificando a arquitetura) é de oferecer um visão da arquitetura pragmática e "pé no chão", da qual desenvolvedores possam se aproximar. Muitos projetos de software falham por razões básicas e eu gostaria muito de ver arquitetura como parte integrante de qualquer processo de desenvolvimento de software, e que todos os desenvolvedores tivessem conhecimento básico sobre ela. Tornar os programadores em arquitetos de software é certamente um passo na direção certa para as equipes auto-organizadas que queremos criar.

InfoQ: No seu post você faz uma pergunta retórica "Processos ágeis precisam de arquitetura ou é arquitetura que necessita de um processo ágil?". Como você responderia isto?

Brown: Todo projeto de software, não importando o quanto é ágil, precisa considerar "arquitetura" devido a requisitos não funcionais e outras restrições das quais não se pode escapar. Então a resposta é sim, projetos ágeis necessitam do papel de arquiteto. Mas infelizmente, na pressa de se adotar um processo ágil, várias equipes esquecem disso. Por outro lado, existe muito a ser aprendido quanto à aplicação de uma abordagem leve para a arquitetura de software em projetos tradicionais. Projetos ágeis demonstraram bem que não precisamos um design extenso e detalhado inicial para tudo.

InfoQ: Você acha que o papel de arquiteto é uma evolução natural para um desenvolvedor, ou vê os dois papéis como caminhos divergentes, cada qual exigindo um conjunto de habilidades diferente?

Brown: Esta é uma daquelas respostas do tipo "depende". Alguns desenvolvedores preferem escrever código e ser criativos neste nível, enquanto que outros gostam do desafio do design numa escala maior. Os melhores arquitetos que conheço possuem um conhecimento muito profundo de tecnologia e se mudaram para o papel de arquiteto depois de se tornarem "mestres em codificação". O entendimento da tecnologia com que se está lidando é essencial; mas também é importante se distanciar um pouco para entender quais forças estão por trás do software e do ambiente em que ele irá rodar. Um bom arquiteto precisa ser capaz de fazer ambos; este é o motivo porque se tornar arquiteto não é necessariamente o próximo passo na carreira de todos os desenvolvedores. E mais: tornar-se um arquiteto não significa que se deve parar de codificar.

InfoQ: Como se forma um arquiteto dentro de uma organização?

Brown: Isso é algo que infelizmente não acontece em muitas organizações, com os desenvolvedores sendo jogados no "lado fundo da piscina" e se debatendo sem receber nenhum suporte; ou então sendo empurrados para um cargo administrativo. Desenvolver as habilidades de arquitetura de software é simples se o papel for tratado como colaborativo, encorajando-se pessoas que já estão no papel a treinar e supervisionar aqueles que não estão. A equipe toda deve apoiar a arquitetura do software; então por que os desenvolvedores não se envolvem e ajudam a criar e dar forma à arquitetura? Além disso, organizações podem organizar "katas de arquitetura" (Kata é uma forma de treinamento deartes marciais japonesas, comojudô ecaratê, em que se repetem os movimentos fundamentais para o aprendizado da disciplina). Nesses katas, as pessoas podem praticar como projetar um software do zero. Quantos desenvolvedores têm a oportunidade de fazer isso regularmente?

Os leitores interessados em conhecer mais da visão de Simon Brown sobre Arquitetura de Software podem visitar o site "Coding the Architecture" para encontrar guias de como praticar a Arquitetura de Software.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Cachorro com mais de um dono morre de fome? by Andrei Tognolo

Muito legal o post.

Quando começou a "onda do agile", minha maior preocupação era com relação a dividir a responsabilidade entre os membros da equipe. A idéia de dividir é fazer com que todos fiquem responsáveis pela arquitetura do sistema, mas sempre tive o receito de que provocasse o efeito contrário, e ninguém ficasse responsável.

Porém, esse meu receio não foi concretizado (pelo menos na empresa em que trabalho). Hoje, não existe o papel explícito de arquiteto, mas as pessoas, naturalmente assumem essa posição e ajudam as outras a se preocuparem com a arquitetura.

Como conseguimos isso? Não sei exatamente, mas uma coisa interessante é o fato de que é possível cobrar (no bom sentido) as pessoas para exercerem o papel de arquiteto, mesmo que ele esteja implícito.

Obviamente, nem tudo é perfeito, e creio que temos que melhorar muito na formação dos "arquitetos".

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

1 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT