Arquiteto de software
Arquiteto de Software é um termo abrangente e pode se referir a uma grande variedade de papéis. Existem muitas definições aceitáveis. Consenso em terminologias independentes de empresas e certificações estão contribuindo para evoluir os conceitos em torno desse papel desde a última década.
História editar
Com o aumento da popularidade do desenvolvimento de aplicações em multi-camadas, as escolhas de como uma aplicação pode ser desenvolvida também aumentaram. Desenvolvedores se viam constantemente "reinventando a roda" na mesma empresa onde trabalhavam. Foi quando o novo papel 'Arquiteto de Software' tornou-se uma necessidade durante o desenvolvimento de software.
As principais responsabilidades desse novo profissional são:
- Limitar as escolhas durante o desenvolvimento em:
- escolher um padrão para a maneira de desenvolver aplicações
- definir/criar um framework para ser usado na aplicação
- Indicar pontos potenciais de reutilização na organização ou dentro da aplicação em
- enxergar de maneira mais abrangente
- adotar um design de componentização
- ter contato e conhecimento com outras aplicações na organização
Isso ocorreu no momento em que a programação orientada a objetos (POO) atingiu uma utilização em larga escala (final dos anos 90). Com a ajuda da POO, aplicações maiores e mais complexas foram construídas. Então deu-se a necessidade de enxergar essas aplicações por um ângulo de visão mais abrangente. Essa nova responsabilidade foi atribuída aos arquitetos de software que incluem:
- Durante o Design, quebrar a complexidade do desenvolvimento de aplicações e pedaços menores e melhores gerenciáveis.
- Entender as funções de cada componente
- Entender as interações e dependências entre os componentes de software
- Comunicar esses pontos com os desenvolvedores
Dessa forma, um arquiteto de software tem que ter no mínimo familiaridade com UML (Unified Modeling Language) e POO. UML é a linguagem de modelagem que se tornou importante para arquitetos de software para comunicarem os seus designs aos desenvolvedores e outros membros do time. É como se fosse o desenho arquitetural de uma construção civil. Porém essa não é a única maneira utilizada para comunicação.
Deveres editar
Mesmo com a falta de uma simples definição, há alguns aspectos no perfil que são compartilhados por todos os arquitetos:
Pensamento estratégico editar
Arquitetos tem o foco de resolver problemas relacionados ao negócio da empresa com uma visão estratégica. Por exemplo, decisões são tomadas visando a maneira de como elas irão proporcionar à empresa, ou um software, um crescimento sustentável e performance a longo prazo. Grande atenção é dada para criar e apontar oportunidades de reutilização.
Em decorrência do foco estratégico, as decisões que um arquiteto irá tomar muitas vezes vai se diferenciar das decisões dos desenvolvedores e gerentes de projetos. Em muitos casos, arquitetos irão agir como se os gestores de negócio agiriam caso tivessem conhecimentos técnicos.[1] Enquanto um desenvolvedor está trabalhando com o foco em criar componentes de software, não necessariamente enxergando como esses componentes interagem entre si, o arquiteto de software abstrai e define a interação entre os componentes.
Interação sistêmica editar
Arquitetos lidam com fronteiras, interfaces e interações sistêmicas. Isso pode ocorrer entre dois sistemas escritos em linguagens diferentes em locais diferentes, ou entre dois componentes do mesmo sistema, escritos na mesma linguagem de programação.
Arquitetura Orientada a Serviço (SOA) é uma recente evolução que tem como potencial, simplificar o trabalho dos arquitetos. Isso ocorre principalmente porque proporciona uma maneira de pensar em arquitetura que é mais próxima e alinhada com a necessidade do arquiteto para definir as APIs dos sistemas.
Design editar
O arquiteto faz várias escolhas de design de alto nível (e algumas vezes de baixo nível).
Além disso, o arquiteto deve ditar os vários tipos de padrões, incluindo padrões de código, ferramentas e plataformas. A razão para essas medidas é mais para ajudar a atingir o objetivo estratégico do que arbitrariamente restringir as escolhas feitas pelos desenvolvedores.
Comunicação editar
O aspecto final está ligado a comunicação, em um primeiro momento para entender as necessidades de negócio, e em seguida para comunicar a sua própria visão arquitetural.
Além da comunicação verbal, existem vários modelos de arquitetura de software especializados em comunicação arquitetural.
Tipos de arquitetos de Software editar
O arquiteto organizacional lida com decisões estratégicas de software (alinhando a TI com o negócio da empresa), geralmente integrando vários sistemas de software dentro da organização, através de vários times de desenvolvedores, e em alguns casos até em localidades diferentes. O arquiteto organizacional raramente vê ou interage com código.
Dentro do contexto de um projeto de software uma outra distinção pode ocorrer entre o arquiteto físico que lida com ambiente de hardware para aplicação, e o arquiteto de software, que lida com metodologias de design de código.
Um arquiteto de aplicação está relacionado com um único software. Esse arquiteto pode desempenhar esse papel em tempo integral ou parcial. O arquiteto de aplicação é na maioria dos casos um integrante do time de desenvolvimento.
Outros títulos de arquitetos que geralmente se usa, porém sem um consenso em relação ao seu significado real são:
- Arquiteto de Solução - geralmente destina-se ao profissional com foco em resolver um problema específico de negócio, o que gera a necessidade de interação entre aplicações diferentes. Também pode se referir a um arquiteto de aplicação.
- Arquiteto de Sistema (singular) - Usado como sinônimo para arquiteto de aplicação.
- Arquiteto de Sistemas (plural) - Usado como sinônimo para arquiteto organizacional ou arquiteto de solução.
A tabela abaixo pode ajudar a entender melhor as diferenças entre os arquitetos de software:
| Tipo de Arquiteto | Pensamento estratégico | Interação sistêmica | Comunicação | Design |
|---|---|---|---|---|
| Arquiteto Organizacional | Multi-projetos | Abstração alta | Organizacional | Minimo, alto nível |
| Arquiteto de Solução | Focado na interação das soluções | Abstração Média | Vários times | Detalhado |
| Arquiteto de Aplicação | Reutilização de componentes, manutenibilidade | Focado em uma única aplicação | Um time | Muito detalhado |
Na indústria de software, há uma grande quantidade de conflitos[2] entre arquitetos de aplicação, arquitetos de solução e arquitetos organizacionais. Olhando para a tabela acima, não é difícil descobrir o motivo. Por exemplo, arquitetos de aplicação e arquitetos organizacionais tem pontos de vista completamente opostos.
A Metáfora do Arquiteto editar
O termo arquiteto começou a ser utilizado porque o desenvolvimento de software foi associado ao desenvolvimento de prédios.[3] Realmente o papel que mais se aproxima na construção civil é o arquiteto.
O ganho de popularidade do uso do termo Arquiteto dentro do contexto de desenvolvimento de software deu-se a partir do dia que Bill Gates anunciou que ele estava abandonando o posto de Presidente e CIO da Microsoft e assumindo o papel de Chefe de Arquitetura de Software. Presumindo-se, este título foi dado para refletir o seu papel como um tipo de supervisor dos muitos projetos de desenvolvimento de software na Microsoft. Repentinamente, muitas pessoas decidiram que seus cargos deveriam conter a palavra arquiteto em seu título.
É comumente aceito que a metáfora da construção civil é falha[4] ao ser comparada ao desenvolvimento de software. De qualquer maneira, o termo ainda é significativo pois descreve o aspecto de design desse tipo de profissional.
Torre de Marfim editar
Quando arquitetos ficam muito distantes dos times que realmente estão desenvolvendo o software, eles são associados de maneira pejorativa ao termo "Torre de Marfim".[5] A imagem que se faz é a de Arquitetos criando definições arquitetônicas e então delegando para o time de desenvolvimento.
Esse é um dos motivos do equivoco da metáfora da construção civil (arquitetos desenhando e projetando a estrutura de prédios). De maneira geral, muitas empresas que se utilizam da metodologia de desenvolvimento em cascata, encorajam esse estilo de trabalho.
Controvérsias editar
Em decorrência do nível de detalhe que os arquitetos de aplicação e arquitetos de solução trabalham, é necessário que se envolvam com a codificação propriamente dita. Uma grande bagagem em desenvolvimento de software é necessária para esse tipo de profissional. Algumas organizações estendem esse pré-requisito também para os arquitetos organizacionais. O principal motivo para isso é que Arquitetos organizacionais sem uma certa experiência em desenvolvimento irão tendenciar-se à maneira da Torre de Marfim para realizarem seus trabalhos.
Ver também editar
Referências
- ↑ Business Improvement Through Better Software Architecture
- ↑ «Anedota sobre uma discussão entre um arquiteto de solução e um arquiteto organizacional». Consultado em 4 de novembro de 2008. Arquivado do original em 11 de outubro de 2007
- ↑ Filosofia WWISA
- ↑ Building Architect (Martin Fowler)
- ↑ Quem é o arquiteto de Software?