Atividades do Arquiteto de Software

Postado em Atualizado em

Hoje eu gostaria de publicar o meu resumo bem objetivo das principais atividades de um arquiteto de software no qual eu entendo até aqui que deveria ser. Vale lembrar que o post esta aberto para comentários e opiniões, uma vez que a atuação desse cargo sofre varianças nas empresas.

Objetivo principal de um arquiteto de software é projetar uma solução compatível com os requisitos atuais da corporação empregadora, que tenha flexibilidade suficiente para comportar mudanças futuras ou novos requisitos resultantes de sua evolução ao longo do tempo. Ou seja, o Arquiteto de software é aquele que:

  • visualiza os comportamentos da automação com um todo.
  • distingue requisitos funcionais e não funcionais do domínio.
  • reúne informações sobre os problemas, projetando soluções.
  • idealiza a planta (blueprint) que define os elementos partes da solução e como funcionaram em conjunto.
  • responsável por integrar os requisitos não funcionais na solução final.

Conhecimentos:

  • Dominar a(s) plataforma(s) adotada(s), bem como suas API’s.
  • Ter bons conhecimentos do “bussines” da corporação.

Coisas que um arquiteto deve fazer no desenvolvimento de uma solução:

1. Definição arquitetural:

  • Quantidade de camadas lógicas e físicas – (client, presentation, service, integration, persistence)
  • Definir as dependências entre as camadas existentes.
  • Definir tipo do protocolo de comunicação entre as camadas existentes.
  • Definir paradigma de protocolo de comunicação síncrono ou assíncrono entre as camadas existentes.
  • Levantar necessidades de integração com sistemas existentes e ou legados.
  • Definir a melhor forma de comunicação síncrono ou assíncrono com sistemas existentes e ou legados.
  • Levantar e considerar necessidades de I18N e I10N.

2. Arquitetura elaborada deve considerar e contemplar aspectos referentes a performance, confiabilidade,  extensibilidade, escalabilidade e segurança.
3. Definir um plano para escalar a arquitetura elaborada para suportar o volume crescente de acessos:

  • Escalabilidade Vertical (Hardware).
  •  Escalabilidade Horizontal (Clustering).

4. Definir um plano que garanta disponibilidade da solução (Clustering e Fail-over).
5. Definir um plano que garanta segurança das informações armazenadas (Hide sensitive datas).
6. Definir um plano que garanta segurança das informações trafegadas entre as camadas distribuídas da arquitetura elaborada (Encrypted communication e Tamper Proof)
7. Defini um plano anti-vulnerabilidades na arquitetura em nivel de aplicação.
8. Trabalho em conjunto com outras equipes da corporação com objetivo de estabelecer outros níveis de segurança – física, network e host.
9. Trabalhar em conjunto com o profissional GUI Designer na elaboração e construção dos padrões de GUI adotados.
10. Trabalhar em conjunto com o profissional DBA na elaboração, construção e utilização de banco de dados.
11. Seleção, aquisição, criação e configuração de produtos tecnológicos partes da solução (IDE, componentes, frameworks, servidores, banco de dados, ferramentas gerais etc) a serem utilizados na solução.

12. Ambiente de Desenvolvimento:

  • Montagem do ambiente de desenvolvimento.
  • Implementação, validação e documentação da solução arquitetural.
  • Escrever o documento arquitetural apresentando as “best pratics” e “Guideline” adotadas e suas devidas justificativas.
  • Treinamento da equipe de desenvolvimento nos produtos tecnológicos (componentes, frameworks, servidores etc) adotados.
  • Treinamento da equipe de desenvolvimento na arquitetura elaborada.
  • Acompanhamento e validação da implementação durante as versões, evitando a “erosão arquitetural”.
  • Manter feedback constante com a equipe de desenvolvimento durante as versões entregues, validando pros e contras objetivando levantar melhorias na arquitetura ou ambiente de desenvolvimento.

13. Ambiente de Produção:

  • Instalação do ambiente de produção.
  • Configuração e montagem da solução.
  • Monitoramento da solução.

O texto abaixo foi retirado do Ricardo Ferreira’s Blog no qual o autor maravilhosamente descreveu as principais habilidades de um arquiteto de software.

“A arquiteto de software deve ter algumas habilidades especiais. Estas, em sua totalidade não estão relacionados a tecnologia ou TI em geral. Estão relacionados mais a aspectos humanos e comportamentais. Aqui vai uma lista básica sobre o perfil de um arquiteto, sob o meu ponto de vista e das demais fontes de referência que pesquisei.

Possuir aptidão para discussões.

Grande parte do trabalho de um arquiteto, é estar em reuniões, seja com o cliente, com a equipe, com o grupo de coordenadores etc. Um bom arquiteto deve ter o dom de falar, ser comunicativo, saber passar idéias, propor soluções. Uma pessoa que não seja comunicativa ou não goste de falar em público (principalmente quando pressionada)  não é um bom candidato ao perfil de arquiteto.

Ser uma pessoa querida.

A área de arquitetura introduz as pessoas em posições delicadas. Hora você estará com a equipe de desenvolvimento, delegando tarefas, ouvindo, ajudando, questionando. Seja qual for o motivo, você estará sendo referência para a equipe e para isso deverá refletir confiança e credibilidade. Já vi muitos ‘arquitetos’ sendo julgados pela equipe como arrogantes, metidos ou impositores. A credibilidade e apatia não é imposta, é o resultado de um tratamento dócil e amistoso. Saber lidar com pessoas é chave para este quesito. Da mesma forma, quando estiver lidando com coordenadores, gerentes e clientes, deve-se possuir credibilidade para poder negociar estratégias, saber vender uma solução. Arquitetos sem credibilidade (por serem arrogantes ou impositores) nunca darão certo. Mais uma vez, outro talento humano.

Saber delegar tarefas

Delegar tarefas é uma coisa chata. Por questões de milésimos você tende a ser julgado como o chato e indesejado na equipe. Normalmente gerentes de projeto fazem esta tarefa, mas em equipes grandes, o arquiteto porventura tenha que cuidar da equipe. Ao delegar tarefas, é importante demonstrar preocupação com as pessoas. Elas não são apenas os que põem a mão na massa’ como muitos ditos arquitetos pensam. Elas são os especialistas que farão o trabalho do projeto. E é sua responsabilidade coordenar a equipe para que o trabalho seja feito. Foco inexorável nos resultados é a prioridade numero um do arquiteto, mas fazer isso sem prejudicar o bom relacionamento, é o diferencial de um bom arquiteto.

Saber questionar sem prejudicar

Devido a experiência acumulada, será fácil se deparar com situações em que você terá, como arquiteto, que reconhecer erros de sua equipe, e propor melhorias ou correções. Como um sábio já disse, pessoas são difíceis de lidar. Apontar um erro é uma oportunidade grande para você se tornar um metido ou petulante com sua equipe. Saber fazer isso, sem parecer arrogante, é a diferença entre um bom líder ou apenas uma pessoa que está onde está por delegação. Pessoas devem ser cativadas ao sucesso, e você deve ter o dom de fazer as pessoas melhorarem. Principalmente na área de software, onde facilmente encontran-se pessoas com egos exacerbados, é difícil manter um relacionamento incorruptível pela apatia. Seja exemplo, não motivo de rebelião.

Saber tomar decisões

Ser posto diariamente na parede, ser pressionado até a perfeição, ser cobrado por prazos e metas, são algumas das situações que um arquiteto vivencia. Grande parte do trabalho de um arquiteto de software é tomar decisões. Mas ao contrário do que muitos pensam, as decisões a serem tomadas não são apenas sobre o desenho da solução (aquele momento lindo onde se está de frente a ferramenta UML na fase de elaboração onde os riscos devem ser mitigados e a pressão ainda não existe). São decisões estratégicas sobre viabilidade e custo, analise de desempenho da equipe, melhorias no processo de software para o projeto, apontar quem está sendo gargalo na equipe (mesmo que seja seu próprio coordenador) ou mesmo decidir sobre qual será o número de servidores para o escalonamento da aplicação (que é o terror dos arquitetos pois se algo der errado, serão eles os responsáveis).

Ser um profundo pesquisador

Um bom arquiteto nunca para de pesquisar. Ele deve estar por dentro de todas as soluções arquiteturais existentes, para poder propor a mais adequada aos projetos. Normalmente, bons arquitetos devem ser pessoas da academia, que passaram por longos anos na faculdade e no mercado, lidando com soluções provenientes de analises, estudos e experiências. Necessariamente, um arquiteto não deve ser apenas um experimentador (ele deve ter pelo menos uma experiência prática).

Ter maturidade e serenidade

Para se tornar um arquiteto, deve-se ter uma boa base história de vivência em projetos. Seja no papel de um programador, um revisor, um analista ou testador, saber viver um projeto, conhecer as fases, os papeis, os problemas e os momentos, são cruciais para um perfil de arquiteto. Um arquiteto que só viveu projetos em livros ou tutoriais do tipo ‘Getting Started’ não deve ser considerado. Normalmente, consultores de empresas não são bons candidatos a serem arquitetos, porque nunca viveram o projeto por completo, apenas ajudaram a resolver algum problema de frameworks, linguagens ou ferramentas. Quem passou a vida inteira apenas na área de consultoria, deve viver projetos no dia a dia antes de se tornarem arquitetos. Senão, ficarão eternamente na ilha da fantasia, como gosto de exemplificar.

Conhecer pelo menos uma coisa em particular.

Mesmo sendo um generalista, um arquiteto deve ser especialista em pelo menos uma plataforma ou ambiente. A razão disso é que é necessário saber viver uma determinada área para poder opnar por melhorias. Quando uma plataforma é ruim? Quando uma linguagem não é recomendada? Para afirmar isso, deve-se pelo menos conhecer uma das plataformas ou linguagem, para ter uma referência de melhoria ou fracasso.

Ser um bom analista e projetista.

Conhecer técnicas de analise e desenho de software são imperativos num arquiteto. Saber identificar domínios, subsistemas, granularidade de objetos, compartilhamentos de dados, refinamento de mensagens, são qualidades de um bom arquiteto. Por isso, um super programador nunca pode ou deve ser tornar um arquiteto de cara (Isso se aplica aos aspirantes do SCEA). Parte do trabalho da arquitetura é analise do domínio, e deve-se ter experiência nesta área. Conhecer os cartões CRC é um dos ‘mínimos dos míminos’ para um arquiteto de software. Vejo, no JavaRanch, muitas pessoas tendo dificuldades com a criação dos diagramas de sequência da parte II. A que nível de detalhes tenho que ir? Como dividir as responsabilidades? Componentes arquiteturais devem aparecer no diagrama, ou simplesmente fronteiras, controladores e entidades? Se você têm dificuldades nestes aspectos, ainda não é a hora de se tornar um arquiteto. Mais ainda, bons arquitetos devem conhecer bem padrões de desenho. Padrões são reflexos de boas práticas de desenho, e eles são importantes para a criação de ecossistemas e frameworks de software.

Saber lidar com requisitos não funcionais

A quem diga que um arquiteto é um especialista em requisitos não funcionais. A grande verdade, é que um arquiteto é a pessoa que se importa com estes detalhes, e é responsável diretamente pelos riscos desta área. Notadamente, o arquiteto de software deve conhecer bem os principais requisitos não funcionais de todo projeto de software, e do projeto de software em particular. Conhecer técnicas de medição de performance, como ganhar escalabilidade horizontal e vertical, o grau de segurança a ser usado, qual a precisão das casas decimais de tipos numéricos, estas são questões que um arquiteto de software deve conhecer bem. Passar um tempo lidando com questões de infra-estrutura de soluções de software, como armazenamento, redes, canais de protocolos, pode ser uma boa experiência para aspirantes ao perfil de arquiteto.”

 “A memória deixada pelos justos será uma bênção, mas o nome dos ímpios apodrecerá.” Provérbios 10:7

7 comentários em “Atividades do Arquiteto de Software

    Sergio Ricardo disse:
    13/11/2011 às 20:27

    Parabéns pelo artigo!

    Uma informação que eu busco é uma bibliografia recomendada para os arquitetos.

      Fernando Franzini respondido:
      14/11/2011 às 07:36

      O papel é muito abrangente…não existe livros assim específicos. Na verdade o arquiteto é o cara que domina a maioria das coisas .Ele deve manjar o bussines, plataforma e arquitetura em geral. Segue a lista dos que não podem faltar:

      – Patterns of Enterprise Application Architecture – Martim Fowler – Bookman.
      – Sun Certified Enterprise Architect for Java EE Study Guide – Paul Allen, Joseph Bambara – Osborne.
      – Padrões de Projeto – Gamma / Helm / Johnson / Vlissides – Bookman.
      – Core J2EE Patterns: Best Practices and Design – Alur, Deepak / Crupi, John Malks, Dan – Pearson.
      – 97 things every software archiyect should know O’reilly

      E por ai vai…

    rascunhosdenovembro disse:
    26/06/2012 às 19:14

    Muito legal o post. Sabe como fazer o curso oficial da oracle no Brasil?

      Fernando Franzini respondido:
      09/07/2012 às 11:26

      Procure um centro de treinamento oracle mais perto da sua casa!

    […] Atividades do Arquiteto de Software […]

    Wellington disse:
    26/02/2013 às 11:35

    Frenando, você já retornou aos estudos. Alguma coisa mudou na certificação de lá pra cá ?

      Fernando Franzini respondido:
      26/02/2013 às 12:04

      Sim…dia 20 agora faço a ultima parte da prova.
      Nada mudou…a oracle só impôs um curso obrigatório…no resto ficou na mesma.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s