Melhor resposta
Não há definições formais dessas funções que são amplamente adotadas como padrão por organizações, então haverá muita variação e contexto localizado.
Como um guia geral, eu uso as seguintes definições:
- Arquiteto Técnico – Um especialista em áreas alinhadas para infraestrutura, rede e segurança.
- Arquiteto de soluções – Um generalista responsável por soluções baseadas em projetos que levam em consideração todos os aspectos de uma solução (por exemplo, impacto nos negócios, alterações de aplicativos, dados e considerações de informações e a tecnologia sustenta tudo isso) e, com sorte, as considerações do cliente também.
- Arquiteto principal – Alguém com um conjunto mais amplo de responsabilidades do que as funções acima. Isso pode ser focado em um domínio de negócios, um programa de trabalho maior ou toda uma empresa. Também é frequentemente usado por consultorias para sugerir um nível de superioridade (experiência) sobre outros arquitetos da equipe. Normalmente, eles têm preocupações generalistas em vez de se concentrar em um único domínio de arquitetura, como infraestrutura, mas nem sempre é esse o caso.
Espero que ajude. É importante lembrar que existem nenhum padrão aceito, portanto, os termos em si são específicos ao ambiente em que são usados.
Resposta
Primeiro, é importante diferenciar a arquitetura de software simplesmente das melhores práticas. Um bom engenheiro de software pode ser excelente em codificação, excelente e detalhado em sua abordagem e ter uma grande percepção do problema, mas ainda pode não ser um bom arquiteto.
No mínimo, um bom o arquiteto deve ter as seguintes habilidades:
Um arquiteto é excelente na decomposição de problemas . A decomposição do problema é a habilidade necessária para ver um problema em praticamente qualquer nível e dividi-lo nas etapas e partes necessárias para implementá-lo. Um bom arquiteto de software pode tomar uma declaração como “Nossos sistemas de controle de tráfego aéreo são inadequados e precisamos de um design melhor” e sabe as perguntas a fazer para começar a decompor o problema em componentes alcançáveis, para decompor essas metas de componentes em subprojetos alcançáveis e decompor esses subprojetos em tarefas de programação realizáveis. Um bom arquiteto pode fazer essas coisas em qualquer nível ou escala, desde a visão de um projeto de software de um bilhão de linhas até a compreensão da melhor maneira de implementar um algoritmo para lidar com links não confiáveis. A escala é irrelevante porque o processo é sempre o mesmo.
Um arquiteto entende as interfaces . As interfaces, seja na forma de protocolos, bibliotecas de funções, interfaces de classes ou esquemas, são as principais ferramentas necessárias para gerenciar a complexidade dos projetos quando há contratantes e implementadores independentes. Ao conhecer o processo de definição de interfaces nítidas e inequívocas que são logicamente completas, um arquiteto pode capacitar muitas pessoas a construir partes de sistemas que se conectam facilmente para atingir um objetivo maior.
Um arquiteto entende que a complexidade é o inimigo e tem domínio das ferramentas de programação e paradigmas necessários para reduzir a complexidade em todos os componentes, para reduzir a complexidade das interfaces e garantir o mínimo ou nenhuma redundância de implementação de função. Eles podem reconhecer rapidamente algoritmos e implementações que são muito específicos ou muito genéricos e guiar aqueles em desenvolvimento para criar componentes que executam a função certa. Freqüentemente, as ferramentas de gerenciamento da complexidade são coisas como ocultação de dados, programação orientada a objetos, sistemas de autovalidação e planos de teste abrangentes para interfaces padrão. Mas, um bom arquiteto não é dogmático sobre ferramentas e tecnologias porque tem uma compreensão acadêmica abrangente dos fundamentos e razões pelas quais a ocultação de dados funciona e porque certas linguagens suportam bons princípios de design e outras não.
Um arquiteto é um bom comunicador, um bom e prolífico escritor e documentador e é bom em falar a linguagem de programação, bem como a linguagem comum daqueles que são interessados no design do sistema. Junto com uma boa comunicação, um bom arquiteto pode dar razões concretas para práticas de programação ao invés de opiniões, e oferece insights para sua equipe ao invés de argumentos. Eles favorecem fortemente e buscam a opinião do usuário de adequação para seus próprios ou dos programadores envolvidos no projeto.
Um bom arquiteto é um bom líder e é excelente em ganhar o respeito de todo o pessoal técnico eles trabalham com .Normalmente, isso significa que eles têm um alto nível de habilidade, trabalharam em vários idiomas e foram arquitetos antes, ou demonstraram sua capacidade de criar projetos de sistemas que permaneceram flexíveis diante das mudanças.
Muitas definições incluem uma série de chavões, enfatizando metodologias como design orientado a dados, programação ágil, linguagens específicas, plataformas e kits de ferramentas. Essas coisas são rótulos atuais para várias técnicas cuja base precisa ser bem compreendida, não aceita porque é atualmente em voga. Portanto, de muitas maneiras, as principais habilidades de um arquiteto são experiência, inteligência, disposição para trabalhar duro e assumir uma função prática, boa intuição e a capacidade de analisar problemas usando a lógica para que, conforme as palavras da moda da indústria vão e vêm, seus designs permanecem úteis e relevantes.
Minha definição acima intencionalmente não inclui gerenciamento de projetos, programação e habilidades de gerenciamento. O papel do arquiteto é criar bons sistemas, não resolver problemas de equipe ou orçamentos. Na verdade, é melhor se aqueles com orçamentos e problemas de equipe são simplesmente partes interessadas que ajudam a definir uma das restrições com que o arquiteto deve lidar, assim como se fosse parte do problema de design deles.