0.4 Stakeholders  (Page 8/9)

Clientes também se mostram interessados na justificativade resolução dos eventuais conflitos, principalmente se essa resoluçãotem impacto no negócio.

Arquiteto

Uma vez que é o principal responsável por projetara arquitetura, o arquiteto tem a obrigação de conhecer os stakeholdersenvolvidos no sistema. Isso permitirá que ele saiba o que os stakeholdersesperam do sistema e, por fim, seja capaz de projetar o sistemade acordo com os requisitos esperados. O arquiteto também é responsávelpor negociar os conflitos de interesses entre os stakeholders, o que resultaránuma arquitetura com atributos de qualidade que agradem a vários,mesmo que parcialmente.

A necessidade de conhecer e dialogar com os diversosstakeholders faz com que o arquiteto precise de habilidades tanto sociaisquanto técnicas. Em relação ao conhecimento técnico, ser experienteno domínio do problema o ajudará a identificar previamente as dificuldadese soluções a serem encontradas ao longo do desenvolvimento. Jáas habilidades sociais o ajudam tanto na descoberta de requisitos,quanto na negociação de divergências.

Desenvolvedor

O desenvolvedor vê a arquitetura como base paraconstruir o sistema. Há dois extremos de como a arquitetura pode serapresentada para ele. Ela pode ser apresentada como uma especificação,onde não há qualquer liberdade de design durante o desenvolvimento.Ou ela pode ser apresentada como um guia, que apresenta algumasrestrições essenciais para que o software alcance o sucesso, mastambém possui diversas liberdades para as decisões de implementaçãoe design de baixo-nível que ficam a cargo do time de desenvolvimento.Ao longo de todo o espectro, o desenvolvedor espera pela ideiageral do sistema, onde as funcionalidades serão implementadas, quem serãoos responsáveis por elas e quais as decisões de design de alto-nívelrelacionadas a elas.

Um desenvolvedor comumente espera que a arquiteturatambém seja viável e de acordo com suas habilidades, além de quepossua as decisões de design escritas de forma clara e objetiva. Eletambém espera que o documento de arquitetura possibilite a associaçãodos requisitos do sistema às partes que o compõem. Essa associaçãoé o que chamamos de rastreabilidade, que torna mais fácil tanto a manutençãoquanto o entendimento do sistema.