PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS

Arquitetura de Software
Estudo dirigido: Papel Arquiteto de Software
Prof: Pedro A. Oliveira

Este texto apresenta algumas visões e avaliações sobre a área de atuação e as principais
atividades desempenhadas por um arquiteto de software no que tange às características
essenciais para este profissional e suas responsabilidades no processo de desenvolvimento de
software.

1. Introdução
O que faz um Arquiteto de Software? Qual é o perfil desse profissional e quais são os papéis
que ele deve desempenhar? Segundo Torres, com a evolução da construção de software, aos
poucos foi surgindo uma nova profissão: Arquiteto de Software.
Ainda segundo Torres, mesmo sendo indispensáveis no processo de desenvolvimento de
grandes aplicações, os arquitetos de software ainda são muito pouco conhecidos. Isto se deve
ao fato de que uma empresa, ao iniciar o desenvolvimento de uma nova solução,
primeiramente pensa em contratar um analista de sistemas e alguns desenvolvedores para a
implementação da solução. Porém, durante o desenvolvimento do software, algumas questões
referentes à sua infraestrutura são levantadas, tais como:
A solução será Web, Windows ou mobile? Se for Windows, por exemplo:
• Como será distribuída, via setup nos clients, utilizando distribuição GPO no
domínio ou como smart clients?
• Como serão as futuras atualizações da solução?
• Como será feito o controle de segurança no ambiente do servidor?
• A solução será acessada externamente? Se sim, como será feita a conexão remota
com o banco de dados?
Se a solução for web:
• Estará em um Data Center próprio ou na nuvem?
• Como será o tratamento de sessão?
• Serão utilizados cookies? Haverá a necessidade de instalar plug-ins?
Se a solução for distribuída ou envolver mobile:
• Qual serão as tecnologias utilizadas?
• Será utilizada solução nativa ( para Android, iOS ou outro S.O. móvel)?
• Será elaborado um app multiplataforma ou híbrido? Se sim, para que plataformas?
• Haverá integração entre camadas ou tecnologias?
Todas estas questões são importantes, pois suas respostas servirão de base para definições
na construção de uma boa solução. A tarefa de fornecer respostas para estas questões deve
ser realizada por um profissional específico com características técnicas que o capacitem a
fazê-la. Esse profissional é conhecido como arquiteto de software.

2. Arquitetura de Software
Arquitetura de software é, simplesmente, um modelo conceitual que facilita a transição de
requisitos para a implementação (Merson). Formalmente, tem-se:
The software architecture of a program or computing system is the
structure or structures of the system, which comprise software
elements, the externally visible properties of those elements, and the
relationships among them.
(BASS at el. Apud SOFTWARE ENGINEERING INSTITUTE)

A arquitetura de software é também uma das sub-áreas da área de Projeto de Software, como
apresentada no SWEBOK (Corpo de Conhecimento em Engenharia de Software) e abrange
tópicos como: estruturas, pontos de vista, descrição de arquiteturas, estilos arquiteturais,
padrões.

3. O Arquiteto de Software
Arquiteto de Software é o especialista em soluções técnicas para o desenvolvimento de
sistemas, o que exige uma visão sistêmica madura e aguçada, e deve ficar responsável por
ações no nível decisório mais alto, seja corporativo ou de sistemas:
- análise e conhecimento de tecnologias para compor o espaço de soluções possíveis;

1
- projeto de sistemas no nível alto de abstração, sem detalhes, baseado em requisitos não
detalhados;
- identificação e gerência de riscos associados aos projetos;
- Assessoria aos gerentes/coordenadores de projeto.

3.1. O papel Arquiteto de Software

Segundo as definições obtidas no guia navegação do RUP, processo de desenvolvimento
criado pela Rational Software Corporation, o papel principal desempenhado por um arquiteto
de software é liderar e coordenar as atividades e os artefatos técnicos no decorrer do projeto.
O arquiteto de software estabelece a estrutura geral de cada visão de arquitetura: a
decomposição da visão, o agrupamento dos elementos e as interfaces entre esses principais
agrupamentos. Portanto, comparado aos outros papéis, a visão do arquiteto de software é
ampla, e não detalhada.
Em resumo, o arquiteto de software deve ter grande conhecimento geral, possuir maturidade,
visão e profunda experiência que permita identificar problemas rapidamente e dar opiniões
sensatas e criteriosas na falta de informações completas (RUP, 2007).

Segundo o blog InfoQ (https://www.infoq.com/br/news/2010/09/real-papel-arquiteto) Arquiteto

de Software é um dos cargos mais desejados por diversos profissionais da área de TI. Hoje em
dia é cada vez mais comum vivenciar situações onde o próprio time define a arquitetura do
projeto, frameworks, tecnologias, entre outros. Dado o cenário atual, onde o papel do Arquiteto
de software se enquadraria? Ele é o responsável por escolher as tecnologias e estruturas de
todos os projetos de uma empresa? O arquiteto deve ser um programador?
Foi com uma indagação desse tipo que se iniciou uma discussão sobre o que o arquiteto faz
hoje em dia. Guilherme Silveira, diretor técnico da Caelum e criador do Restfulie disse:
Historicamente, o arquiteto começou sendo aquele que definia quantas máquinas, quais as
tecnologias, etc, mas não colocava a mão no código – ou nos diagramas de sequência, na
época. A desvantagem dessa abordagem é a pessoa se distanciar cada vez mais dos
problemas e das soluções que cada estilo arquitetural e ferramenta implicam no dia a dia da
equipe, e começar a considerar somente aspectos facilmente visiveis de suas escolhas[...]
Ainda historicamente, o mercado viu a necessidade de ter alguém conectando os projetos de
uma empresa, afinal uma pessoa era responsável pela arquitetura de seu projeto, mas
ninguém alinhava arquiteturalmente a empresa. Daí surgiu o “enterprise architect”, alguém
com uma preocupação maior.
Guilherme complementa defendendo a idéia sobre a teoria do Ditador Benevolente, que é
aquela pessoa que tem o voto final e que muitos confundem com o "Arquiteto 2.0".
Com o XStream aprendi sobre o ditador benevolente, que é uma pessoa (ou duas) que tem a
decisão final. A arquitetura, o design, o código, o método podem evoluir pelo desejo da própria
equipe, mas por fim possuem uma pessoa guia; alguém que, com mais experiência, saiba
conectar melhor os planos da empresa, do produto, da equipe, da arquitetura e guiar todos
para o mínimo de conflitos técnicos. Esse é o líder da equipe (não arquiteto 2.0).
[...]
Resumindo, na minha visão, os arquitetos somos nós, mas sempre em contato com as outras
equipes dentro da empresa. E o líder é fundamental para manter o caminho em momentos de
discórdia.
David Lojudice tem um ponto de vista diferente, onde o papel do arquiteto é manter a coerência
entre as partes envolvidas em um projeto. Ele defende que a decisão de incluir ou não tal papel
depende do tamanho do time e do projeto.
O seu pet project (projeto de fim de semana com 1 pessoa) precisa manter coerência entre as
pessoas? Só tem uma pessoa pensando nas classes, suas responsabilidades, acoplamento e
comunicação. O arquiteto é o profissional que mantem a coerência entre essas classes. E é só
olhar o código que é possível encontrar um “estilo arquitetural”, ou seja, um jeitão de
implementação. Esse “jeito” é a coerência mantida pelo desenvolvedor.
Num time de 4 pessoas a arquitetura normalmente é colegiada. Precisa de arquiteto? Precisa.
Só que nesse caso todo mundo é arquiteto também. A coerência é mantida pelo time.
Já no sistema coorporativo, envolvendo muitas pessoas, muitos times, a solução do colegiado
fica difícil. Precisa de arquiteto? [...] Precisa! :) Manter a coerência de integração e
responsabilidades dos sistemas é o que o arquiteto vai tentar fazer. Existem várias maneiras
de fazer isso e depende muito do sistema sendo desenvolvido. A abordagem que usamos
atualmente é a criação de um ecossistema, com regras simples, onde cada time pode criar um
sistema para fazer parte desse ecossistema ao mesmo tempo que tem liberdade para usar a
melhor ferramenta e a melhor arquitetura daquele sistema para resolver o problema.

2
Uma das coisas mais importantes para o arquiteto é que ele deve, sempre que possível,
oferecer liberdade para os desenvolvedores escolherem suas tecnologias, frameworks, não
engessando totalmente o software, visto que isso faz com que seu time aprenda mais e fique
mais motivado. Uma outra atitude interessante é incluir os desenvolvedores em reuniões
arquiteturais, pois os mesmos podem agregar com experiências vivenciadas, entre outros
conhecimentos adquiridos.

3.2. Perfil de um Arquiteto de Software

O arquiteto de software ou os membros da equipe de arquitetura devem combinar as seguintes
habilidades (RUP, 2007):
• Experiência no domínio do problema, conhecendo totalmente os requisitos, e no
domínio de engenharia de software. Se há uma equipe, essas qualidades podem se
achar distribuídas entre os seus membros, mas deve existir pelo menos um arquiteto
de software que ofereça a visão global do projeto.
• Liderança para conduzir o esforço técnico entre as várias equipes, tomar decisões
importantes sob pressão e fazer com que essas decisões sejam cumpridas à risca.
Para melhor eficiência, o arquiteto de software e o gerente de projeto devem trabalhar
juntos, com o arquiteto de software responsável pelas questões técnicas e o gerente de
projeto cuidando dos assuntos administrativos. O arquiteto de software deve ter poder
para tomar decisões técnicas.
• Comunicação para conquistar confiança, persuadir, motivar e servir como mentor. O
arquiteto de software não pode liderar por decreto, mas somente com o consentimento
dos outros membros da equipe do projeto. Para desempenhar seu papel com
eficiência, o arquiteto de software deve conquistar o respeito da equipe do projeto, do
gerente do projeto, do cliente, da comunidade de usuários e da equipe de
gerenciamento.
• Orientação por metas e Pró-atividade com enfoque inexorável nos resultados. O
arquiteto de software é a força técnica orientadora existente por trás do projeto, não um
visionário ou sonhador. A carreira de um arquiteto de software bem-sucedido consiste
em uma longa série de decisões insatisfatórias, tomadas com incerteza e sob pressão.
Somente aqueles que se concentram em fazer o que deve ser feito terão êxito nesse
ambiente do projeto.

Do ponto de vista de habilidades, um arquiteto de software deve ter ainda as seguintes

características (RUP, 2007):
• sólidos conhecimentos práticos de:
o técnicas de modelagem;
o requisitos do sistema;
o técnicas de design de software, incluindo as técnicas de análise e design
orientados a objetos, e a Linguagem Unificada de Modelagem (UML),
tecnologias com as quais o sistema será implementado;
• conhecer a arquitetura do sistema;
• conhecer o papel dos testes de sistema;
• ter conhecimento prático dos princípios de gerenciamento de configuração em geral.

A seguir são apresentadas algumas inverdades sobre a profissão Arquiteto de Software.

3.3. Mitos sobre a profissão de arquiteto de software.

(Mendes, 2006) considera que o arquiteto de software é ainda um papel recente na
comunidade brasileira de software. Por consequência, existe muita confusão sobre o que este
papel realiza dentro das etapas de desenvolvimento de um software. Seguem alguns mitos:

1º. Mito: arquiteto = desenvolvedor sênior evoluído.

Diferentemente do senso comum, um arquiteto não é um desenvolvedor sênior que evoluiu em
sua carreira. Um desenvolvedor é especialista e tático. Um arquiteto de sistemas é um
generalista em sua essência e primordialmente estratégico (Mendes, 2006).

2º. Mito: o arquiteto trabalha em um ambiente isolado da realidade do processo de

desenvolvimento.
Um arquiteto deve trabalhar em intensa e forte colaboração com a equipe, apoiando o time na
investigação dos pontos de relevância técnica de um projeto. Um arquiteto deve atuar como um

3
coach, realizando a identificação dos mecanismos arquiteturais relevantes, motivando o time
para a investigação e resolução destes mecanismos e apoiando o time do início ao fim do
projeto (Mendes, 2006).

3º. Mito: para ser um arquiteto basta conhecer as técnicas de arquitetura de software.
Um arquiteto de sistemas deve conhecer também outras disciplinas (ex: Gerência de Projetos)
ou domínios (hardware, Dados ou Segurança), além da pura implementação J2EE ou. NET
(Mendes, 2006).

4º. Mito: um analista de sistemas ou um programador mais experiente pode fazer o

mesmo trabalho que um arquiteto de software faz.
Segundo Torres inicialmente poder-se-ia imaginar que o analista ou o programador poderiam
resolver isso, mas:
• A tarefa do analista de sistemas é fazer o levantamento de informações e modelar as
regras de negócio.
• A tarefa do programador é implementar as regras de negócio modeladas.
Se qualquer um dos dois, analista ou programador, ficar encarregado de definir as questões
que seriam tarefa do arquiteto de software uma de duas coisas vão ocorrer:
1. Ou por falta de especialização técnica as questões não serão bem definidas e haverá
perda de produtividade no desenvolvimento do software. Observe que tratam-se de
questões complexas que exigem profundo conhecimento tanto das ferramentas atuais
de desenvolvimento de software como também de infraestrutura, para que seja
possível definir o trabalho em conjunto do software com a infraestrutura disponível;
2. Um dos dois, analista ou programador, tem realmente o conhecimento técnico para
definir estas questões. Neste caso, estão superqualificados para a função,
provavelmente cobram muito mais do que um analista ou programador cobrariam e tem
seus conhecimentos sub-utilizados na tarefa de analise ou programação, gerando um
gasto maior que o necessário para o desenvolvimento do sistema.

4. O dia de trabalho típico de um Arquiteto de Software

Você talvez esteja pensando: espera aí... como é um dia de trabalho desse profissional tão
completo e bem formado?
Bom, vai depender um pouco do tipo de arquiteto que estamos falando. Se ele trabalha no
escopo corporativo então sua atividade passa muito por “arrumar a casa”, organizar e
padronizar tecnologias e fazer avaliações de arquiteturas, verificando sua viabilidade,
adequação, qualidade, etc.
Se estivermos falando do arquiteto no escopo de aplicação então sua atuação vai ser muito
mais de conversar com a equipe, fazer o time entender as partes do produto, suas
características e integração, na medida da necessidade. Isto pode se dar tanto em projetos de
desenvolvimento como de manutenção.
Uma outra possibilidade seria esse profissional atuar de forma mais “invisível”, sendo um
consultor para momentos em que se necessita dele. Assim ele não ficaria com uma atuação
destacada em cada projeto, mas agiria sob demanda, seja de forma preventiva, seja para
“apagar incêndios”. Neste último caso o sucesso já não seria tão garantido, por motivos óbvios.
Também existe uma relação forte entre o profissional de arquitetura e os diferentes times:
desenvolvimento, manutenção, produção. Seu trânsito entre essas equipes deve ser bom,
sendo respaldado pelos respectivos gestores das áreas envolvidas.
Resumindo: ele não pode ser visto como um “salvador da pátria”, pois sua atuação está mais
na elaboração/projeto da solução do que na correção de bugs. Visto desta forma, ele deve se
adequar à realidade do projeto e se inserir o quanto antes, para evitar transtornos futuros. Em
equipes que seguem abordagens de desenvolvimento tradicionais isto se traduz em uma
atuação com funções e um timing específico. Já no desenvolvimento segundo as abordagens
ágeis acontece uma de duas situações: 1 - o arquiteto não é caracterizado como uma só
pessoa destacada, sendo todos arquitetos em potencial; 2 – o arquiteto é caracterizado,
mesmo que informalmente, sendo aquele, dentre os grupo, que mais possui as características
esperadas desse papel. O segundo caso, a meu ver, tende a ser mais adequado, uma vez que
fica melhor caracterizada a função de tomada de decisão baseada em gabarito técnico.

5. Uma “receita de bolo” para documentação arquitetural na visão ágil

Atualmente observe-se um mercado de desenvolvimento de software fortemente voltado para
as abordagens ágeis. Esta mudança de paradigma reflete diretamente na arquitetura de
software.

4
No link https://www.infoq.com/br/articles/C4-architecture-model/ do blog InfoQ é possível
conhecer um modelo mais leve e ágil para documentação de arquiteturas, denominado “C4”.
Esta sigla indica as quatro etapas/formas de documentação a serem adotadas para atender a
uma documentação minimamente adequada, como segue:
• Nível 1: diagrama de contexto do sistema;
• Nível 2: diagrama de container;
• Nível 3: diagrama de componentes;
• Nível 4: código.
Procure entender esta proposta, avaliando sua adequação, vantagens e possíveis problemas.
Informações complementares sobre C4 podem ser encontradas aqui: https://c4model.com e
aqui: https://www.archimatetool.com/blog/2020/04/18/c4-model-architecture-viewpoint-and-
archi-4-7/.

5. Considerações Finais
Pode-se concluir que é essencial a presença de um arquiteto de software durante o processo
de desenvolvimento, especialmente, quando se trata de aplicações de grande porte, complexas
ou distribuídas. O bom trabalho desse profissional afeta não apenas um projeto, mas pode
afetar muitos outros projetos a serem desenvolvidos futuramente pela empresa, pois um
padrão de desenvolvimento bem definido obviamente poderá ser aplicado a vários projetos.
Assim, a definição de uma boa arquitetura acontece em cada um dos níveis: corporativo, de
domínio, de aplicação, de componente.
Assim, o arquiteto de software torna-se um profissional imprescindível. Por um lado, atua como
aliado dos gestores na redução de riscos e, consequentemente, no aumento das chances de
sucesso dos projetos; por outro lado, se coloca como referência técnica da equipe de projeto.

Referências
TORRES, DENNES. Arquitetos de Software. & lt;
http://www.bufaloinfo.com.br/artigos/coluna09.asp>. Acessado em: 26 set. 2016.
MERSON, PAULO.? Mini-curso: Como documentar arquitetura de software? & lt;
http://www.sbbd-sbes2005.ufu.br/arquivos/Merson05_minicurso_SBES1.pdf>. Acessado em:
26, set. 2017.
SOFTWARE ENGINEERING INSTITUTE, CarnegieMellon. & lt;
http://www.sei.cmu.edu/architecture/index.html> Acessado em: 26, set. 2017.
BASS, LEN; CLEMENTS, PAUL; & KAZMAN, RICK. Software Architecture in Practice, Second
Edition. Boston, MA: Addison-Wesley, 2016.
BRAGA, L. J. (2007). ?Carreira: Arquiteto de Software? & lt;
http://zeluisbraga.wordpress.com/2007/06/27/carreira-arquiteto-de-software/>. Acessado em:
26, set. 2007 RUP.? Papel: Arquiteto de Software? & lt;
http://www.wthreex.com/rup/process/workers/wk_archt.htm> Acessado em: 26, set. 2017.
INFOQ. https://c4model.com. Acesso em: 10/08/2020.
INFOQ. https://www.archimatetool.com/blog/2020/04/18/c4-model-architecture-viewpoint-and-
archi-4-7/. Acesso em: 10/08/2020.
MENDES, M. (2006).? Quem é o arquiteto de software?. & lt;
http://blog.marcomendes.com/2006/10/09/quem-e-o-arquiteto-de-software/> Acessado em:
26, set. 2017
https://www.infoq.com/br/news/2010/09/real-papel-arquiteto, Acesso em: 13/02/2019.

Questões:
1. Qual é a importância de um arquiteto de Software para uma empresa de TI que desenvolve
sistemas corporativos que devem ser integrados? Cite uma situação prática como exemplo.

2. Cite três atividades típicas que um arquiteto de software pode/deve desempenhar num
grande projeto de software conduzido por uma empresa para um cliente externo.

3. Qual é o principal diferencial propiciado pela atuação de um arquiteto de software, na

captação e atendimento à visão do cliente?

4. Cite um mito sobre o papel arquiteto de software e explique porque ele é falso.

5
5. Num projeto de desenvolvimento de software um arquiteto poderia atuar como (assinale
quantos itens julgar corretos):
( ) Assessor / consultor do gerente do projeto.
( ) Assessor / consultor dos analistas de sistemas.
( ) Líder técnico.
( ) Interface entre os times de projeto e de produção.
( ) Analista de qualidade.

6. Analise a relação entre o arquiteto de software e as disciplinas do RUP, como visto na

figura a seguir. Aponte em qual ou quais dela(s) ele deve atuar e como deve atuar
(atividades):

7. Considere o diagrama “4+1” mostrado em sala (ver figura) e explique a importância de

contemplar todas essas visões no projeto de uma arquitetura específica.

8. Cite uma situação concreta em que a atuação de um arquiteto de software foi determinante
para o sucesso de um projeto de desenvolvimento de software. Você pode se basear em
experiências pessoais ou em pesquisas sobre casos de sucesso reais.

9. Faça uma pesquisa de mercado visando encontrar cursos de graduação e/ou de pós-
graduação na área de arquitetura de software, no Brasil ou no exterior. Cite o nome, a
instituição que oferece, a duração e o foco/objetivo dos três cursos encontrados.

10. Com base no texto e nas atuais demandas do mercado de tecnologia descreva uma
situação (real ou hipotética) em que um arquiteto de software atuaria de forma a aumentar
as chances de sucesso de um projeto que segue a abordagem ágil. Você deve ser
convincente sobre a importância (ou não) deste papel para o projeto apresentado.