Em Portugal não são necessários Arquitectos de Software?

Fora de Portugal principalmente nos países mais info-literados, aos quais nós tanto queremos pertencer, a função é bastante conhecida e requisitada. Em Portugal nunca vi um anúncio de emprego a pedir Arquitectos de Software!

Podem dizer que não estou atento a todos os anúncios que se publicam em Portugal. Sim, é verdade, mas tive o cuidado de perguntar ao departamento de recursos humanos da empresa onde trabalho e também procurei nos site’s de emprego disponíveis, os genéricos e os de empresas de recrutamento especializadas em TI.

Então, qual é o problema?

Opção 1: Será que realmente não precisamos de arquitectos de software?

Opção 2: Será que não sabemos para que serve um arquitecto de software?

Opção 3: Será que o entendimento que se tem, do papel reservado a um arquitecto de software é tão vago e ambíguo que, pedir um arquitecto de software equivale a receber uma quantidade enorme de respostas, de pessoas com perfis completamente díspares?

Se tivesse que decidir qual das opções está mais perto da realidade, acho que escolheria a terceira embora a segunda também não esteja longe da realidade. A diferença entre a segunda e a terceira é o tipo de pessoas de quem estamos a falar. Na segunda estou a assumir que as pessoas que recrutam não sabem para que serve um arquitecto de software, não sentem falta dessa função nas suas organizações e assim não a pedem. Não é completamente mentira. Existe ainda alguma necessidade de coaching ou consultoria ao mais alto nível, de forma a chamar a atenção da importância crescente da função. Mesmo assim acho que não é essa a maior questão. Acredito que a função não é correctamente percebida e entendida pela maioria das pessoas menos experientes da área de TI.

O que se entende por Arquitectura de Software

Uma procura rápida na Internet leva-nos de imediato ao encontro de dezenas de definições. No site do Software Engineering Institute existe até uma página  cujo objectivo é receber e coleccionar definições.

De todas as que encontrei, transcrevo algumas que gostei mais:

“Architecture is about the important stuff. Whatever that is.”

Ralph Johnson, quoted by Martin Fowler in Who Needs an Architect?

 “Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.”

Eoin Woods, software architect, co-author of Software Systems Architecture : Working With Stakeholders Using Viewpoints and Perspectives ISBN:0321112296

“The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. The term also refers to documentation of a system’s software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.”

Bass, Len; Paul Clements, Rick Kazman (2003). Software Architecture In Practice, Second Edition. Boston: Addison-Wesley, p. 21-24. ISBN 0-321-15495-9 

Gosto particularmente da definição do Ralph Johnson porque resume numa frase muito pequena todo o entendimento acerca da arquitectura de software. A arquitectura deve preocupar-se com o desenho dos aspectos importantes do software. São estes que vão decidir o sucesso ou o insucesso do projecto.

Os componentes que são fundamentais e importantes num projecto podem não o ser para outro projecto. Se tivermos um projecto que consiste no desenvolvimento de um site de comércio electrónico as preocupações vão para assuntos como a velocidade, a escalabilidade dos mecanismos de CRUD, a rapidez das consultas e, assim sendo, os aspectos importantes são a base de dados a utilizar, a escolha dos componentes de middleware, a forma da acesso à base de dados, o sistema de log e tracking de operações. Por outro lado, se o projecto consistir no desenvolvimento de uma aplicação para um laboratório médico o importante serão as tecnologias para tratamento de imagem, os algoritmos e rotinas  3D, as ligações aos periféricos.

Neste último exemplo também será necessário utilizar uma base de dados para guardar as fichas dos pacientes. No entanto,  é claro que a sua importância para o sucesso do projecto é bastante menor comparativamente ao projecto do site de comércio electrónico.

As funções do Arquitecto de Software

A função principal de um arquitecto de software é perceber o que é importante.

Só depois de perceber o que é realmente importante para os objectivos do projecto é que o arquitecto pode tomar decisões acerca da arquitectura a adoptar. Apesar de achar que esta afirmação é consensual, normalmente não é isto que acontece.

Quase sempre é necessário apresentar a arquitectura do software a desenvolver numa fase bastante precoce do projecto. Porque é necessário apresentar uma proposta, fazer um RFP, estimar investimentos, ou outra razão qualquer.

Então o que é que se deve fazer? Na minha opinião não há nada a fazer. Espera-se que o feeling do arquitecto, baseado na experiência que tem na área funcional do projecto e nos requisitos conhecidos,  esteja correcto e que, depois do levantamento de requisitos e da análise funcional, ou seja, depois de ter percebido o que é verdadeiramente importante, continue certa. Como facilmente se depreende quanto maior for a experiência e o conchecimento na área maior será a percentagem de acertos.

E… se a visão inicial da arquitectura não se confirmar?

Bem, aí a postura deve ser bastante pragmática e fria. Deve-se mudar! Custe o que custar. Mesmo que isso implique que todo o projecto seja renegociado, reequacionado e eventualmente cancelado. A ser cancelado, que o seja cedo!  Já assisti a alguns projectos que falharam, com prejuízos graves para todos os envolvidos porque em devido tempo não existiu coragem ou  sabedoria para mudar.

Politica

Por estranho que possa parecer a algumas pessoas, habituadas a olhar para os especialistas de software como uns “gajos” que percebem à brava de computadores, trabalham que se fartam e que às vezes falam uma linguagem ininteligível para o comum dos mortais, esta é uma das funções mais importantes que o arquitecto deve estar preparado para desempenhar. Ele deve ser capaz de negociar com os vários interlocutores do projecto, sejam eles do cliente ou da sua equipa, todas as decisões e opções técnicas que possam ser questionadas. Deve também ter a capacidade para fazer uma avaliação critica ao negócio e, se achar que devem existir mudanças, deve ter a capacidade de influenciar as pessoas que tem o poder de decisão. O que torna difícil a tarefa é ter que falar na mesma “língua” das várias pessoas com quem negoceia ou a quem tem que explicar alguma opção ou sugestão.

É preciso ter uma grande capacidade de persuasão e até paciência para explicar a uma pessoa com menores ou bastante menores conhecimentos técnicos e ainda menos de metodologias de desenvolvimento de software porque é que determinadas opções são cruciais. Então se essas opções mexerem directa ou indirectamente com dinheiro…

Mas atenção! Não quero dizer com isto que o arquitecto deve achar que a razão está sempre do seu lado e nunca deve ceder. Nada disso. Também é necessário ter a flexibilidade e a inteligência para ceder quando é necessário. Muitas vezes acontece o arquitecto não estar de posse de toda a informação e não sabe disso. Por razões de negócio, segurança ou outras. O bom-senso e o equilíbrio devem sempre prevalecer.

Liderança técnica

De uma forma natural o arquitecto deve ser reconhecido por todos como “O” líder técnico. Pode não conhecer profundamente todos os aspectos técnicos envolvidos mas deve dominar de uma forma geral – não confundir com superficial – todas as metodologias e tecnologias a usadas.

Durante o ciclo de desenvolvimento deve fiscalizar com periodicidade regular que o desenho está a ser respeitado e, as regras e metodologias previamente definidas, correctamente aplicadas. Estas acções de fiscalização nunca devem ficar para a parte final do projecto! Nesta altura o tempo para mudar já pode ser muito curto.

Gestão da equipa de programadores

Numa fase inicial compete ao arquitecto com a ajuda do gestor de projecto avaliar e seleccionar as pessoas que reúnam o conjunto de competências técnicas que garantam o sucesso do projecto. Depois, durante o decorrer do mesmo o arquitecto deverá estar disponível para ajudar a equipa nos vários aspectos técnicos assim como nos aspectos funcionais.

A gestão da equipa de projecto onde também se inclui toda a equipa de programadores é normalmente uma tarefa que compete ao gestor de projecto. O que se passa é que existem alguns programadores, normalmente os mais dotados, que tem um perfil psicológico especial. O arquitecto deve entender estas pessoas e ajudar o gestor de projecto nessa missão.

Conclusão

Todos os que estão na indústria do desenvolvimento de software concordam que o papel de arquitecto de software é absolutamente necessário e fundamental. Não sei se todos concordarão com todas as funções que eu enumero aqui. Concerteza com a maior parte acho que sim.

Para terminar deixo apenas uma pergunta para a qual, sinceramente, não sei a resposta:

O que será preciso para que em Portugal se comece a valorizar convenientemente o papel de Arquitecto de Software?


Referências:

Role of Software Architecture
http://www.wwisa.org/wwisamain/role.htm

Who Needs an Architect? artigo publicado na revista IEEE SOFTWARE de Julho/Agosto 2003
http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

Is Design Dead?
http://www.martinfowler.com/articles/designDead.html Maio,2004

Becoming an Architect. A Conversation with Luke Hohmann, Part IV by Bill Venners. Abril 5,2004
http://www.artima.com/intv/architect.html

Peter Eeles, Characteristics of a software architect. Março 15,2006
http://www.ibm.com/developerworks/rational/library/mar06/eeles/index.html

The role of the Software Architect by Fabrice Marguerie
http://madgeek.com/Articles/Architect/EN/architect.htm

Anúncios

11 Respostas

  1. Vou tomar a liberdade de deixar pontas soltas da minha opinião.
    Em resposta à pergunta final, atrevo-me a dizer que a valorização efectiva de um Arquitecto de Software (AS) tem que partir de um facto assumido, onde? No seio da própria empresa, na qualidade de processos de desenvolvimento de software. Sendo esta uma realidade assumida, a questão da necessidade ou não de um AS, deixa de ser uma questão e passa a um facto.
    Um erro frequente que tenho verificado: um AS não pode nunca cair na teia ‘burocracia’ e por vezes perdem-se bons ASs e ganham-se não tão bons Gestores de Projectos (GP) – fruto da carreira de AS não ser uma realidade e também da não abundância de ASs com o perfil, que muito bem mencionas, na secção “Política”… originando a actual realidade: “GP + Team/Technical Leader” e não “GP/AS” (esta realidade está dependente da dimensão do projecto). Dependendo da dimensão da empresa poderá fazer sentido também o por mim denominado “O” AS Nómada 🙂

  2. André, o teu comentário é bastante pertinente e concordo em absoluto com o teor do mesmo.
    A falta de arquitectos de software com perfil politico como referes e bem, terá a ver com a falta de carrreira e formação …. é a estória do ovo e da galinha e de quem nasceu primeiro.

  3. Aqui vão os meus 2 centimos adicionais…

    Criatividade – Qualquer arquitecto deve ser por natureza criativo, mas um AS deve adicionalmente ‘beber’ de outros sectores de actividade para além do sector puramente técnico. Muitas boas ideias têm-se quando se está a fazer algo de diferente do trabalho. Na praia, na BTT, etc.

    Comunicação – a realização completa do AS está não só em saber o que é importante, mas sim em saber comunicar eficazmente o que é importante, em termos de negócio… e isto, nem sempre é claro dentro da empresa ou organismo

    Liderança – A liderança técnica (conhecimento técnico) a que te referes deve ser também estendida ao outro pilar da ponte, o da liderança no conhecimento “ad nauseum” do negócio. Só assim se pode ter uma perspectiva global do mesmo, e focar as energias na criação de uma solução eficiente… e aceite por todos.

    Parabéns pelo artigo e pelo blog, é bom haver algumas ondas de mudança.

    A nivel pessoal, já lá vai algum tempo que te tinha perdido do radar 🙂 , é bom reencontrar-te.

  4. Emilio, obrigado pelo cumprimento e pelos teus comentários, com os quais, obviamente não deixo de concordar por completo.

  5. Insiro-me no grupo dos que têm “conhecimento de informática na óptica da utilizador”, (provávelmente 98 por cento da população mundial) e como tal, sendo um não especialista, creio ter entendido para que serve (e se serve ou não) um Arquitecto de Software.

    Parabéns pelo Post, e até outras visitas…

  6. Zé, obrigado pelo cumprimento. Fico feliz de ter conseguido passar a mensagem … mesmo a um não informático 🙂

  7. Excelente tema. Concordo com o André Martins em relação à carreira de um software developer em Portugal, e acho que é precisamente aí que reside o problema, pois tipicamente temos a seguinte progressão: Programador Júnior -> Programador Sénior -> Gestor de Projecto. Onde se encaixa aqui o Analista (no sentido de levantamento de requisitos)? E o Arquitecto? E o responsável por QA? Os anúncios raramente pedem estas funções porque simplesmente não fazem parte dos planos de carreira das empresas. Na prática, o que acontece é que o Programador Sénior, se tiver alguma experiência, começa já a ter um papel na análise de requisitos ou na arquitectura da aplicação mas é quando chega a Gestor de Projecto que assume realmente essas responsabilidades. Essas e todas as outras, claro: gestão de recursos, planeamento e controlo, comunicação, reuniões com o cliente, gestão de expectativas, etc. No meio de tanta coisa, algo tem que se perder…

  8. Caro José Formiga, o tema mantém-se mas, nem de propósito, ao pesquisar por Arquitectos de Software encontei à cabeça o seguinte link:

    http://www.empregos.org/view_job.php?sb_id=7536

  9. Será que algo está a mudar…?

  10. Tiago, também é a minha percepção. As coisas estão a mudar. Lentamente, mas estão.

  11. O rol de um arquiteto de software é algo muito novo em comparação como otras diciplinas de Sistemas de Informacão, comensou com os famosos livros de patrones de disenho de Gamma é os patrones empresariais de Fowler.
    No Argentina, onde eu moro , tampouco existe o rol formal de arquitecto de software definido dentro dela empresa , su funcâo expecificos depende de cada emprega, tampouco se ensina en as maior parte delas universidades, em alguns só como aula aislada.
    Eu estuve investigando sobre os roles e porque é importante o arquitecto de software na emprega.
    Nossos como profesonais de arquitetura mais por expericencia que por titulo fomais devemos poder comunicar o valor que acrescenta o profissional de arquitectura de software no sistemas dela empresa.

    No siguente post eu trato de justificar porque e necessario o arquitecto de software.

    http://ssalanitri.blogspot.com/2009/05/por-que-es-necesario-un-arquitecto-de.html

    Obrigado.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

%d bloggers like this: