O Papel do Arquiteto de Software
Quando falamos de um projeto desenvolvimento de software que se utilize Java como linguagem de programação é comum ouvir de alguém que você precisa de um arquiteto de software. Na verdade esta necessidade não é única de projeto Java, independente da tecnologia de implementação dependendo da magnitudede seu projeto você vai precisar tanto de um arquitetocomo você precisaria de um analista ou gerente de projetos.
Diferente do que muitos pensam arquitetura não significa escolher frameworks, a arquitetura de software vai muito além do que meramente decidir se no projeto vão utilizar Spring ou Hibernate, Struts ou JSF.
Mas qual o papel do Arquiteto de Software?
Em poucas palavras é dar suporte e participar de todas as decisões técnicas significativas em termos de design e implementação. Em outros termos estamos falando de riscos, a arquitetura serve para mitigar os principais riscos técnicos de um projeto, veja que eu disse os principais ao invés de todos.
Se você trabalha com riscos no seu projeto e trabalha com priorizarão de requisitos essa é uma tarefa relativamente simples, pois a arquitetura já sabe com o que deve se preocupar e com o que não deve dar muita atenção e deixar os desenvolvedores resolver.
Agora se você não trabalha com riscos e não possui priorizarão de requisitos isso pode se tornar em um grande problema e a arquitetura pode perder o foco e se preocupar e gastar energia de mais com questões de importância inferior.
Eis que existe a fronteira com requisitos...
Se você estiver utilizando um processo baseado em RUP, você irá fazer uma análise inicial de negocio focando 80% dos requisitos mais importantes do sistema e desses requisitos 20%+- serão os requisitos mais importantes para arquitetura. O arquiteto participa dessa priorizarão de requisitos por que ele sabe o que pode ser critico em termos técnicos e o que deve ser preocupação da arquitetura e o que não deve ser.
Arquiteto não precisa saber das regras de negócio?
Esse é um grande erro! Um arquiteto de verdade deve se preocupar muito com as regras de negócio, isso de que arquitetura é um coisa e requisitos e analise são outras não existe! O arquiteto de software precisa se preocupar com as regras e a cima de tudo entender e conhecer os requisitos do sistema!
A arquitetura também serve para atender os requisitos do sistema! Se a sua arquitetura Java não atende os requisitos do sistema para que ela serve? Usar frameworks por modismo não serve de nada, não podemos nos esquecer que o objetivo não é utilizar frameworks ou desenvolver código de arquitetura. O objetivo é solucionar os problemas do negócio com um sistema!
Sim, existem arquiteturas de referencias!
Por mais que alguns agilistas teimem isso existe. Quando estamos em um contexto corporativo, normalmente existe um domínio mais fechado e os sistemas não fogem muito de uma linha e você pode e deve reaproveitar componentes e acima de tudo reaproveitar sistemas e isso que é SOA!
Nem sempre a solução está somente no Java
Muitas vezes a solução é mais heterogênea! Não conseguimos resolver todos os problemas somente com Java. As vezes é necessário envolver código de banco como PL/SQL por exemplo ou até mesmo outras linguagens como Delphi, VB, C, etc...
Não é necessário conhecimento especifico!
Um bom arquiteto não é aquele que sabe tudo de Spring ou EJB, mas é aquele que conhece os principais componentes de uma solução e conhece outras coisa como banco de dados, requisitos, processos, metodologias, redes, protocolos, web, etc... Como já dizia ou Vitruvius:
A arquitetura fica pronta na fase de elaboração?
Outro erro! A fase de elaboração do RUP serve para mitigar riscos não para concluir a arquitetura. Ninguém quer fazer uma BIG Arquitetura Up to Front! Outro equivoco comun que vejo é a arquitetura de papel, você precisa desenvolver código da fase de elaboração, não precisa ser código em volume, mas é necessário ter desenvolvimento!
A prova de conceito arquitetural deve ser o mais real o quanto for possível. Se possível já utilize requisitos do usuário consolidados(Casos de uso)! Lembrando que se você fizer toda a arquitetura nessa fase você estara cacateando o projeto, e isso é muito ruim. :(
Diferente do que muitos pensam arquitetura não significa escolher frameworks, a arquitetura de software vai muito além do que meramente decidir se no projeto vão utilizar Spring ou Hibernate, Struts ou JSF.
Mas qual o papel do Arquiteto de Software?
Em poucas palavras é dar suporte e participar de todas as decisões técnicas significativas em termos de design e implementação. Em outros termos estamos falando de riscos, a arquitetura serve para mitigar os principais riscos técnicos de um projeto, veja que eu disse os principais ao invés de todos.
Se você trabalha com riscos no seu projeto e trabalha com priorizarão de requisitos essa é uma tarefa relativamente simples, pois a arquitetura já sabe com o que deve se preocupar e com o que não deve dar muita atenção e deixar os desenvolvedores resolver.
Agora se você não trabalha com riscos e não possui priorizarão de requisitos isso pode se tornar em um grande problema e a arquitetura pode perder o foco e se preocupar e gastar energia de mais com questões de importância inferior.
Eis que existe a fronteira com requisitos...
Se você estiver utilizando um processo baseado em RUP, você irá fazer uma análise inicial de negocio focando 80% dos requisitos mais importantes do sistema e desses requisitos 20%+- serão os requisitos mais importantes para arquitetura. O arquiteto participa dessa priorizarão de requisitos por que ele sabe o que pode ser critico em termos técnicos e o que deve ser preocupação da arquitetura e o que não deve ser.
Arquiteto não precisa saber das regras de negócio?
Esse é um grande erro! Um arquiteto de verdade deve se preocupar muito com as regras de negócio, isso de que arquitetura é um coisa e requisitos e analise são outras não existe! O arquiteto de software precisa se preocupar com as regras e a cima de tudo entender e conhecer os requisitos do sistema!
A arquitetura também serve para atender os requisitos do sistema! Se a sua arquitetura Java não atende os requisitos do sistema para que ela serve? Usar frameworks por modismo não serve de nada, não podemos nos esquecer que o objetivo não é utilizar frameworks ou desenvolver código de arquitetura. O objetivo é solucionar os problemas do negócio com um sistema!
Sim, existem arquiteturas de referencias!
Por mais que alguns agilistas teimem isso existe. Quando estamos em um contexto corporativo, normalmente existe um domínio mais fechado e os sistemas não fogem muito de uma linha e você pode e deve reaproveitar componentes e acima de tudo reaproveitar sistemas e isso que é SOA!
Nem sempre a solução está somente no Java
Muitas vezes a solução é mais heterogênea! Não conseguimos resolver todos os problemas somente com Java. As vezes é necessário envolver código de banco como PL/SQL por exemplo ou até mesmo outras linguagens como Delphi, VB, C, etc...
Não é necessário conhecimento especifico!
Um bom arquiteto não é aquele que sabe tudo de Spring ou EJB, mas é aquele que conhece os principais componentes de uma solução e conhece outras coisa como banco de dados, requisitos, processos, metodologias, redes, protocolos, web, etc... Como já dizia ou Vitruvius:
"O arquiteto ideal deve ser uma pessoa erudita, um matemático, familiarizado com estudos históricos, um estudioso aplicado de filosofia, conhecedor de música, que não desconheça medicina, detentor de saber jurídico e familiarizado com astronomia e cálculos astronômicos." - Vitruvius, circa 25 BCEm geral o arquiteto precisa muitos de alguns skills como: Liderança, comunicação, pro-atividade, com relacionamento com a equipe. Sem falar que o mesmo deve entender de Design de sistemas!
A arquitetura fica pronta na fase de elaboração?
Outro erro! A fase de elaboração do RUP serve para mitigar riscos não para concluir a arquitetura. Ninguém quer fazer uma BIG Arquitetura Up to Front! Outro equivoco comun que vejo é a arquitetura de papel, você precisa desenvolver código da fase de elaboração, não precisa ser código em volume, mas é necessário ter desenvolvimento!
A prova de conceito arquitetural deve ser o mais real o quanto for possível. Se possível já utilize requisitos do usuário consolidados(Casos de uso)! Lembrando que se você fizer toda a arquitetura nessa fase você estara cacateando o projeto, e isso é muito ruim. :(
