Olá pessoal, tudo certo?
O post de hoje mostra minhas considerações sobre os papéis de arquitetura e desenvolvimento. Nessa posição, sou extremista (embora acredite que toda verdade extremista é fraca): arquitetos são arquitetos, desenvolvedores são desenvolvedores.
Vamos aos fatos…
O que é arquitetura?
Todo software possui uma arquitetura. Boa ou ruim, ela está presente. Planejada ou não, ela se forma, consiste e persiste. Ela pode estar “escondida”, mal-entendida, corrompida, vilipendiada, ignorada ou, até mesmo, esquecida. Mas está ali.
A arquitetura de um software pode até não estar descrita em documentos formais, representada em diagramas ou quaisquer outros tipos de artefatos. Mesmo assim, se há um software, há uma arquitetura.
A arquitetura é a expressão máxima das principais decisões relacionadas a um software. Ela contempla o conjunto de propriedades e comportamentos essenciais do software. Ela explicita o escopo fundamental do sistema.
A arquitetura é a visão fundamental do sistema. Mais que isso, ela define o sistema.
Em software, não há “visão do todo” sem profunda compreensão da arquitetura. Arquiteturas ocultas ou mal evangelizadas implicam em sistemas ruins e cheios de partes “descartáveis”. Um sistema com arquitetura “oculta” é um Frankenstein, uma colcha de retalhos, um pesadelo para o time, um pesadelo para todos os interessados.
A arquitetura de um software consiste de sua estrutura mais fundamental que são, por razões evidentes, praticamente imutáveis. Todo sistema possui uma estrutura fundamental, logo, todo sistema possui uma arquitetura.
Ao observar qualquer software, podemos identificar seus componentes principais -comportamentos e papéis. Além disso, conseguimos enxergar como esses componentes se relacionam com os outros componentes. A esse conjunto rico de informações chamamos arquitetura.
Sumarizando, a arquitetura de um software é descrita através da elucidação de seus componentes fundamentais – seus comportamentos, papéis e relacionamentos. É essa “visão” do todo – sem detalhes, sem internals desses diversos componentes, comportamentos e dos seus relacionamentos – que representa as decisões fundamentais de um software.
Toda arquitetura de sistema pode ser explicitada
Explicitando a arquitetura de um sistema
Fica claro e evidente que a arquitetura está presente em qualquer sistema. Entretanto, como identifica-la. Em outras palavras, como tonar a arquitetura de um sistema evidente?
Façamos um exercício simples:
- Pense no sistema que está trabalhando agora;
- Enumere as partes/componentes fundamentais desse sistema.
-
- Primeiro em sentindo horizontal. Pense nos módulos de seu sistema (chamo-os, também, componentes);
- Depois, em sentido vertical. Considere todos componentes que dão “sustentação” aos módulos (persistência, interface com usuário, regras de negócio, monetização);
- Descreva, mesmo que superficialmente, as principais atribuições e comportamentos de cada componente;
- Identifique as relações entre esses módulos e componentes;
- Vá para um quadro branco…
- Desenhe uma caixa para cada componente, começado do alto para baixo, na seguinte sequência;
-
- Interface com o usuário ou sistemas externos;
- Serviços (server side) e APIs expostas;
- Módulos de seu sistema
- Componentes de negócio compartilhados entre os diversos módulos;
- Componentes de infraestrutura;
- Desenhe setas ligando essas caixas para representar as relações mais importantes;
- Elimine o que parece excesso. Generalize e não se prenda a especificidades de tecnologia.
De forma básica, garanta que sua estrutura tenha, pelo menos, uma descrição básica de componentes e relações semelhantes ao template que indico a seguir (explico esse template com detalhes nesse post):
Esse modelo é útil para arquiteturas que estejam fundamentadas em camadas. Sinta-se a vontade se precisar criar representações alternativas (há patterns diferentes para representar arquiteturas diferentes).
Uma arquitetura devidamente explicitada facilita a comunicação com o grupo. Pratique esse exercício, compartilhe com seu time o resultado e verifique seus feedbacks.
Toda arquitetura pode e deve ser planejada
Não podemos confundir arquitetura emergente com anarquia arquitetônica. Em qualquer momento, o time precisa ter condições de descrever sua visão da estrutura fundamental de um projeto. Uma boa arquitetura dificilmente será obra do acaso. Uma boa arquitetura é resultado de um planejamento cuidadoso.
Não há razão para repetir velhos enganos. Mesmo trabalhando em uma área de conhecimento relativamente recente, há milhares de exemplos e experiências de projetos bem-sucedidos que podem servir como modelo para formação de uma boa arquitetura. Se há design patterns, há também patterns arquiteturais.
Construir e consolidar uma boa arquitetura colabora com o talento do time de desenvolvimento para uma definição mais clara das tecnologias que serão empregadas em cada componente. Uma boa arquitetura permite que seja selecionada a melhor tecnologia para cada escopo.
A definição dos componentes – seus papéis, comportamentos e relacionamentos – permite que o time perceba, o mais cedo possível, as entradas e saídas esperadas por cada componente, bem como oportunidades de generalização e reaproveitamento.
A construção de frameworks corporativos (entenda-se: componentes com alta possibilidade de reuso em novos projetos) é consequência de uma visão arquitetônica coerente. É comum que projetos sendo desenvolvidos em paralelo em uma corporação necessitem de componentes semelhantes.
Arquitetura não está relacionada DIRETAMENTE a atividade de desenvolvimento
Arquitetura não está relacionada diretamente a desenvolvimento
Pelo descrito, a arquitetura de um sistema nasce junto com o plano de como implementar esse sistema.
Repare que falo todo o tempo em componentes – papéis, comportamentos e relacionamentos. Não falo de classes, instâncias ou gestão de dependências. Logo, patterns para arquitetura não estão relacionados diretamente com patterns de design.
Arquiteturas emergentes decorrem da necessidade de ajustar componentes ou seus relacionamentos. Novos componentes surgem, ou componentes inicialmente percebidos como importantes perdem relevância. Relacionamentos ficam evidentes (junto com suas demandas), ou perdem seu propósito devido a uma melhor compreensão do domínio. De qualquer forma, isso ocorre durante o desenvolvimento e não por causa do desenvolvimento.
Arquitetos, geralmente, são (ou foram) bons desenvolvedores
Desenvolvimento de software é uma atividade relativamente recente e, por consequência, imatura. Mesmo com toda a relevância da arquitetura de software, poucos são os projetos que têm um desenvolvimento arquitetônico conduzido de forma coerente.
Na maioria dos casos, conta-se com a expertise dos desenvolvedores mais experientes que, por feeling e arrogância, tomam para si algumas atividades arquitetônicas. Infelizmente, o que temos na prática, na maioria dos casos, é a aplicação do mais do mesmo (até quando o “mesmo” não é o mais adequado).
Alguns desenvolvedores, geralmente com maior senioridade, percebem e valorizam a importância do projeto arquitetônico. Esses mesmos desenvolvedores percebem e evidenciam a necessidade de desenvolver competências distintas daquelas que já possuem visando maior efetividade e retorno.
Esses mesmos desenvolvedores acabam participando ativamente dos trabalhos de implantação e identificam rapidamente eventuais desvios (deterioração ou erosão arquitetônica) fazendo os ajustes necessários. Entretanto, que fique evidente: são desenvolvedores que também são arquitetos. Competência para arquitetura é distinta e isolada da competência para desenvolvimento.
Bons desenvolvedores não são, necessariamente, arquitetos
Todo software têm uma arquitetura definida. Fato!
Arquitetura pode ser, ou não, planejada. Fato!
Nem todas as empresas têm arquitetos (não estou falando de cargo, estou falando de alguém com competência para a atividade). Fato!
Toda empresa que faz software, possui desenvolvedores (mais ou menos qualificados). Fato!
Desenvolvedores não têm, necessariamente, habilidade para trabalhar arquitetura. Fato!
Você pode ser um excelente desenvolvedor (sênior até) e, mesmo assim, ter enorme dificuldade para identificar e planejar componentes – seus papéis, comportamentos e relacionamentos. Por quê? Porque nem todo desenvolvedor tem as competências (conhecimentos + habilidades + atitudes) para “desenvolver” arquitetura. Simples assim!
Enfim…
Pode ser que você seja um bom arquiteto e também um bom desenvolvedor. Parabéns para você!
Pode ser que você seja um bom arquiteto e seja um desenvolvedor bem ruinzinho (é raro, mas acontece!). Parabéns para você, também!
Talvez você seja um ótimo desenvolvedor, e não seja um arquiteto. Parabéns para você (com todo o meu respeito)! Se for uma opção, então, fantástico! Você deverá ser feliz com sua decisão.
Arquitetos fazem arquitetura. Desenvolvedores, não! São atividades diferentes, importantes, e com competências necessárias distintas.
Quer ser um arquiteto, estude para ser arquiteto. Não é o mesmo que estudar desenvolvimento.
Por hoje, era isso!
Flavio Silva
18/02/2011
Ótimo Post!
fulano
18/02/2011
blá blá blá
Bruno Gross
18/02/2011
Excelente artigo, pra variar. Que tal um seguindo a linha do “o que estudar para ser um (melhor) arquiteto”.
George
18/02/2011
Excelente!!!!!!!
Muito bem colocado os pontos. Deixou bem claro a diferença entre o arquiteto e o desenvolvedor sem desmerecer nenhuma das partes.
Continue postando sobre o assunto.
Fernando
18/02/2011
É por essas e por outras que eu digo que o arquiteto é o novo analista de sistemas.
elemarjr
18/02/2011
Cara?! Acha mesmo? Não consigo ver essa evidência! O que acha de explicitar melhor sua posição?
+
18/02/2011
Máquina de encher linguiça 2.0
Alberto Chvaicer
18/02/2011
Parabéns! Você sempre consegue escrever de forma clara e com bons argumentos.
Raramente disconcordo do que você pensa!
@LuanCouto
18/02/2011
Olá Elemar, concordo com você em relação ao papel do arquiteto. Já li bastante sobre este assunto polêmico em vários blogs/groups e vejo que as pessoas não conseguem entender isso com facilidade, muitas pessoas da área de TI não têm conhecimento para diferenciar os papéis.
Parabéns pelo texto e pela didática, realmente muito bom.
Obs1: Html.Encode no texto que será compartilhado pelo JS do Twitter.
Abraços.
18/02/2011
Muito bom seu artigo campeão…
Realmente concordo, nem sempre bons desenvolvedores tem capacidade para serem bons arquitetos.
Você está se referindo a Arquiteto o que é algo “novo” mas não somente o arquiteto, o Eng. de Softw. também. Acredito que para ser um Arq./Eng. de SW é preciso de uma visão “além do alcance”, uma boa percepção para detalhes, e uma capacidade de abstração diferenciada dos demais. E não precisamos nem lembrar que estudar boas práticas e padrões é essencial!
Até + campeão!
Higor César Ramos
21/02/2011
Ótimo post elemar, que tal um post sobre disciplinas e referências técnicas para um arquiteto?
Marcio Luiz
22/02/2011
Ótimo post elemar, que tal um post sobre disciplinas e referências técnicas para um arquiteto? [1]
Ari C. Raimundo
23/02/2011
Ótimo post !
Concordo com o pessoal, talvez um post sobre o que estudar para se tornar arquiteto seria interessante.
Jonas
02/05/2011
Quais são essas competências místicas do arquiteto? Cadê a ciência nesse post? Parece mais mimimi de quem está perdendo espaço.
elemarjr
02/05/2011
Desculpe-me Jonas, se meu post não lhe agrada.
Escrevi outros posts falando especificamente de arquitetura. Talvez seja do seu agrado ler estes posts também.
Em caso oposto, recomendo que você procure bons livros sobre o tema. Eles podem ser mais felizes do que eu na iniciativa de mostrar algum conteúdo relevante.
Quanto ao #mimimi, estou bem empregado. Aliás, estou há 13 anos na mesma empresa. Participei da criação de produtos usados em mais de 36 países, inclusive. Talvez você tenha uma experiência mais interessante para compartilhar. Que tal dar o endereço de seu blog para que todos possamos apreciar a genialidade de sua ciência? Também vale algum projeto seu .. ou código seu .. ou ..
Gabriel
03/06/2011
O problema existe pela indefinição das atividades de um arquiteto e principalmente pela sobrecarga da palavra: arquiteto corporativo, arquiteto de informação, arquiteto de software… A comparação da criação de software com a engenharia civil nunca é benéfica para a área. Já transformou programadores em pedreiros que só implementam os “quadradinhos” que o “arquiteto” desenhou no Jude.
A figura de alguém que tem um conhecimento amplo (não detalhado) sobre o desenvolvimento do software, passando pela infraestrutura computacional, organização do código fonte e que conheça os requisitos funcionais e não funcionais e os negocie com o cliente é totalmente aceitável e desejável.
A figura do cara que desenha um monte de quadradinho UML, forçando um monte de design patterns e uma arquitetura cheia de siglas só para encher o próprio ego, esse deve ser esquecido.
Vítor
10/08/2011
Olá Elemar,
Eu acredito que arquitetos precisam ser bons desenvolvedores.
É ele que vai definir que um o CRUD Master/Detail vai ser definido com aqueles arquivos e aquele padrão de código. Para isto ele tem que ser um bom desenvolvedor. Por ‘bom desenvolvedor’, podemos citar vários critérios, mas uma qualidade importante de um bom desenvolvedor é ter uma visão crítica com relação as decisões tomadas. Se o arquiteto tem que definir o modelo, de código escrito, que será replicado em toda a aplicação, então ele tem que fazer o trabalho de um bom desenvolvedor.