Um arquiteto de solução atua primariamente na construção de soluções baseadas nas necessidades do negócio, fazendo uso dos serviços e recursos tecnológicos já existentes na empresa. Outro objetivo é o de alinhar novas soluções aos princípios arquiteturais já definidos, respeitando os padrões e integrações da empresa.
Têm a responsabilidade de reutilizar funcionalidades e serviços, devem alinhar novas soluções aos princípios arquiteturais já definidos respeitando os padrões e integrações existentes. Devem buscar o balanceamento entre os requisitos funcionais e não funcionais com a priorização e compromissos necessários à empresa em que atuam.
Um arquiteto de solução precisa alcançar o sucesso dos projetos o qual está envolvido e ao mesmo tempo, procurar alinhar as expectativas da unidade de negócio responsável pelo projeto com os princípios arquiteturais e a reutilização das capacidades tecnológicas da empresa.
As habilidades gerais de um arquiteto de solução
O papel do arquiteto de solução é uma evolução natural do papel tradicional de um arquiteto de sistemas e que não envolve apenas software, mas administradores de rede, administradores de sistemas, especialistas em infraestrutura entre outros papéis na área de tecnologia. Quando empresas resolvem mudar de seus padrões tradicionais de construção de soluções buscando a criação de soluções cada vez mais integradas, o papel do arquiteto de solução se torna mais importante pois sua visão e experiência, tanto tecnológica quanto de negócios, pode somar e ajudar na construção de uma solução efetiva e mais alinhada com as expectativas da empresa. Este papel é mais claro em grandes projetos, particularmente quando muitos sistemas estão envolvidos.
As competências envolvem um amplo conhecimento técnico generalizado, bem como experiência abrangente em áreas como: computação em nuvem - cloud, infraestrutura, modelagem e armazenamento de dados, business inteligence, big data, analytics, aprendizado de máquina, deep learning, arquitetura orientada a serviços - SOA, microserviços e uma significativa compreensão da arquitetura corporativa o qual está atuando.
Atuar como um arquiteto de solução significa exercer um papel tático com o objetivo de garantir que as escolhas tecnológicas e a abordagem de integração entre sistemas a ser utilizada estão alinhadas e são compatíveis com a visão estratégica da arquitetura corporativa. Ele deve abordar cada novo desafio que lhe é proposto sem jamais deixar a unidade de negócio requisitante sem uma solução, propondo o que há de mais novo no menor tempo possível. É um requisito fundamental estar continuamente alinhado com a estratégia empresarial e oferecer soluções que serão devidamente mantidas e apoiadas pela alta gestão da empresa.
Como exemplo, considere um caso onde um novo sistema está sendo concebido e planejado e que irá exigir uma grande quantidade de relatórios e visibilidades. Nesse caso, primeiramente, é importante definir se esses indicadores são apenas uma visão estática sem muitos detalhes ou se há correlação de dados e análise aprofundada com várias visões, o que exigiria o estudo de uma solução de Business Intelligence robusta. Portanto, o papel de um arquiteto de solução começa por olhar para as decisões arquiteturais já existentes, identificar se já existe alguma decisão arquitetural que contemple a demanda e possa ser reutilizada, caso não exista nada definido, ele deverá identificar tecnologias que possam atender a necessidade, elaborar RFIs, realizar provas de conceito, envolver os usuários chave, e por fim, criar uma decisão arquitetural para esta nova solução.
Arquitetos de Solução devem sempre pensar globalmente e buscar por soluções que possam ser utilizadas por uma grande quantidade de necessidades e que sejam capazes de atender a maior quantidade possível de unidades de negócio.
Um arquiteto de solução, em um alto nível, é semelhante a um compositor que define uma visão para uma música e seus arranjos com base no pedido de um cliente (requisitos) - o gerente de projeto, os desenvolvedores e os demais integrantes da equipe são semelhantes ao maestro e a orquestra que executa esta visão para alcançar o objetivo, respectivamente.
As habilidades técnicas e não técnicas que devem ser destacadas
O arquiteto de solução é predominantemente focado na modelagem de componentes e na interação destes componentes, como se estivesse formando um grande castelo com peças de lego, ele é capaz de sugerir a solução de um problema por meio de sistemas e subsistemas que consideram os princípios de modelagem de software mais utilizados como isolamento, camadas, separação de conceitos entre outros.
A modelagem por meio de componentes não necessariamente cobre a construção de componentes funcionais, quaisquer dependências subjacentes sobre o modelo operacional lógico e componentes operacionais ou de requisitos não funcionais devem, idealmente, ser também descritos como parte da solução.
Esta é uma visão holística de todo o problema levando em conta todas as dimensões com o objetivo de fornecer a estrutura e o entendimento necessário para que a solução seja efetivamente construída.
Ser um arquiteto de solução requer conhecimento e habilidades que são ao mesmo tempo amplas e profundas. Para que possa ser efetivo, o arquiteto de solução precisa ter experiência tanto em hardware como em software, e estar confortável com ambientes de sistemas heterogêneos e complexos. Além disso, seu conhecimento em redes de dados, incluindo internet, serão necessários quando a solução necessitar comunicar com soluções em cloud ou integrar com parceiros.
Referências bibliográficas que podem ajudar
Phillip Calçado, atualmente diretor de tecnologia na DigitalOcean, publicou em 2010 uma lista contendo referências para livros importantes para qualquer profissional que busque conhecimento e informação. Esta lista de referência é importante para dar visão sobre assuntos variados e até então desconhecidos. Ainda hoje, esta lista de livros se mantém atual.
Outra referência literária que pode auxiliar no modo de ver as coisas e pensar diferente é Seth Godin. Autor de inúmeros sucessos literários como o livro "A Vaca Roxa", blogueiro e como ele mesmo se descreve, com muita experiência em projetos. Seth Godin escreve sobre assuntos de como pensar diferente para conceber algo que tenha valor, incluindo conselhos de como se portar diante de dificuldades ou em reuniões, e como se tornar o líder de uma tribo e provocar mudanças. Com uma linguagem clara e simples, seu texto ajuda quem é de tecnologia a se portar de forma mais amigável, fazendo com que possa ser visto como uma pessoa perspicaz e interessada em resolver problemas.
Outro destaque, assim como Seth Godin, que não está ligado diretamente a área de tecnologia e que auxilia na formação é o livro A Quinta Disciplina de Peter Senge. Este livro descreve como uma organização que sabe aprender pode ser formada e como a interação entre as diversas áreas é importante para a solidificação da empresa. Apresenta lições de comportamento e até mesmo ajuda a visualizar ambientes não tão propícios a se trabalhar e como podemos atuar para mudá-los. Ao final da leitura, ajuda a tomar o rumo de sua carreira e tomar boas decisões e acertadas para melhorar e ajudar a construir um mundo melhor. Pessoas provenientes de áreas exatas possuem pensamento sistêmico voltado para números e exatidão. As 5 disciplinas batizadas por Peter Senge de tecnologias competentes, ajudam a pensar nos seguintes tópicos:
- Pensamento sistêmico;
- Domínio pessoal;
- Modelos mentais;
- Construção de uma visão compartilhada;
- Aprendizagem em equipe.
Outros livros de referência com um perfil mais técnico e recomendados são:
|
|
|
|
O mundo é formado por visões e comportamentos diferentes. Com o passar do tempo e experiência, aprendemos a respeitar estes ambientes e comportamentos não tão comuns e a desempenhar um bom papel de arquiteto de solução em qualquer ambiente o qual estejamos inseridos. Para que isto ocorra, e esta experiência seja adquirida com o passar do tempo, muitas horas de leitura, projetos de sucesso ou não são importantes para seu amadurecimento.
A experiência enriquecida por meio de vivência
Na maioria das vezes, um arquiteto de solução é um tecnocrata sênior altamente experiente, que já conduziu vários projetos por meio de processos de desenvolvimento de software ou de Ciclo de Vida de Desenvolvimento de Sistemas (SDLC) utilizando os mais variados meios existentes para alcançar seus objetivos. Isto inclui por exemplo, o uso de processos do PMBoK, Scrum e Kanban. Este profissional experiente, geralmente já exerceu uma grande variedade de diferentes papéis em sua trajetória profissional.
O arquiteto de solução precisa ter a capacidade de compartilhar e comunicar ideias com clareza, tanto oralmente como por escrito, aos executivos, patrocinadores do negócio e recursos técnicos em uma linguagem clara e concisa, ou seja, na linguagem que cada grupo seja capaz de compreender. Suas atividades, entre outras, envolvem:
- Preparar apresentação de soluções compreensíveis a técnicos e gerentes de negócio;
- Habilidade para preparar e apresentar propostas técnicas de alta complexidade assim como uma visão da solução - Business Blue Print - e atuar na evangelização de como o produto endereça as necessidades críticas do usuário;
- Habilidade para se envolver tanto tecnicamente com os usuários como com gerentes de unidades de negócio para entender os requisitos dos usuários, mapeá-los e desenhar uma solução;
- Apoiar as demonstrações de soluções com provas de conceito, avaliações, demonstrações ou mesmo auxiliar na instalação de produtos quando necessário;
- Auxiliar na construção de protótipos baseado nos requisitos dos usuários com o objetivo de propor avaliações da solução apresentada.
Levante da cadeira, saia de sua estação de trabalho, vá até o local onde seu cliente e a demanda estão, converse sobre a demanda, peça explicações. É primordial que o arquiteto de solução compreenda o processo da área de negócio e quais os impactos que podem ser causados na escolha de uma determinada solução. Muitas vezes foca-se muito em tecnologia e ferramentas, operacionalizando algo manual ao invés de propor otimizações de processos e mudança de cultura através de soluções inovadoras. Quanto mais detalhes e informações forem coletadas, mais preciso e de melhor qualidade seu trabalho será e mais reconhecimento você terá por ter desempenhado um bom trabalho. Quando demonstramos que estamos inseridos no contexto, as partes percebem que possuem em sua equipe uma pessoa decidida e engajada em ajudar.
Ferramentas, documentação e frameworks que ajudam
Em nossa experiência, a apresentação de soluções de forma visual é a que mais alcança as expectativas dos usuários. Quando uma solução é descrita por meio de um gráfico simples e bem estruturado, com os fluxos bem definidos e que permite aos usuários compreender e visualizar seu processo naquele simples diagrama, é perceptível a sensação de empoderamento da relação de confiança que se forma, e com isto, é possível identificar que todo o trabalho poderá ser desenvolvido com uma parceria antes não imaginada. Ao aprender a desenvolver software por meio de métodos ágeis, uma das premissas é o envolvimento de todas as partes para que a demanda seja bem compreendida e bem construída do início ao fim.
Grandes empresas, necessariamente possuem processos que muitas vezes mesclam o gerenciamento de informações de um projeto baseado em processos do PMBoK e outras metodologias. Na atualidade, é comum depararmos com processos híbridos que fazem uso dos processos do PMBoK e métodos ágeis. Apresentar estes documentos e acompanhar os projetos são tarefas que os gerentes de projetos precisam para comprovar suas entregas. Um bom arquiteto de solução precisa apresentar bons diagramas e um documento de arquitetura bem estruturado que passe segurança ao gerente de projeto. O conselho neste ponto é de não tentar transformar ou mudar o processo já estabelecido, e sim adaptar-se e entregar o melhor documento possível dentro da metodologia que o gerente de projetos acordou que entregaria a demanda.
Um time de projeto é formado por vários papéis, com a experiência vivida, o arquiteto de solução aprende a ser o braço de apoio do gerente de projetos no esclarecimento de dúvidas técnicas que estão no entorno do projeto utilizando documentos claros e concisos como já descrito.
Anotações e primeiros esboços da solução
Tenha sempre um bloco de anotações, desenhos, esboços ou um diário de viagem a mão. Estas tecnologias muito antigas são fundamentais para criar as primeiras anotações, os primeiros esboços de seu desenho arquitetural, os seus primeiros entendimentos da solução o qual criará e trabalhará nos próximos meses. Acredite, desenhar suas primeiras impressões sobre uma demanda o ajudarão a fixar mentalmente o problema a ser solucionado e a partir disso, a escolha de tecnologias a serem utilizadas se tornará mais fácil.
Diário de Viagem para anotações
Diagramação
Draw.io é uma ferramenta de diagramação gratuita disponível para desktop como um plugin para o navegador da Google Chrome ou para uso de forma online desenvolvido pela JGraph. Com o draw.io é possível, de forma simples e rápida, criar uma grande variedade de diagramas, como por exemplo: diagramas de fluxo de dados, diagramas de rede, diagramas UML, mapas mentais, diagramas de BPMN entre outros. Outra facilidade que esta ferramenta possui é a de integração com Dropbox, OneDrive e Google Drive, para armazenamento dos diagramas criados. Além disso, o draw.io pode ser integrado com as ferramentas da Atlassian como Jira e Confluence. Existem vários tutoriais no site do draw.io para os primeiros passos.
Draw.io para criação de diagramas
Outras ferramentas com o mesmo propósito estão disponíveis, algumas gratuitas e outras com algum custo como o Cacoo.com por exemplo, que permite a edição simultânea e o compartilhamento de diagramas. Com o Cacoo.com, é possível criar até 25 diagramas privados gratuitamente.
Exemplo de diagrama para uma arquitetura de solução
O documento de decisão arquitetural (DA)
O documento de decisão arquitetural é o documento que será utilizado em todo o processo de construção da solução para balizar e fornecer um entendimento completo no projeto. Trata-se da descrição da estrutura, características e comportamentos da solução. É o meio pelo qual a solução é definida, como ela será entregue, gerenciada e operada.
Uma solução é a resposta para um problema de negócio que pode ou não incluir um componente tecnológico. A Arquitetura de solução busca identificar uma solução ou um conjunto de opções de soluções e seus respectivos componentes.
Este não é um documento que uma vez criado fica estagnado, muito pelo contrário, trata-se de um documento vivo, que inicialmente é desenvolvido com as primeiras recomendações sobre o que fazer para criar a solução. A medida que o projeto avança e as informações são coletadas e compreendidas, novas decisões podem ser incorporadas, e decisões já tomadas podem ser alteradas ou mesmo descartadas.
Como exemplo, recentemente em um dos projetos o qual participamos, inicialmente decidimos utilizar uma configuração de SSO federado seguindo um modelo de segurança e com o avanço do projeto constatamos que seria desnecessário pois incluiríamos uma camada a mais de segurança. Ao identificar que o desenho inicial traria uma camada extra de segurança desnecessária, analisamos um outro cenário já em uso e optamos por utilizar o mesmo. Diante disto, o documento de decisão arquitetural foi modificado para que contemplasse a nova arquitetura de solução para este módulo de autenticação anteriormente definido.
O que descrevemos neste ponto é que suas decisões arquiteturais não são absolutas e sim, podem mudar a medida que o projeto avança. Estas decisões são tomadas em conjunto por toda a equipe e o arquiteto de solução precisa estar seguro para declinar, arriscar ou sugerir uma nova estratégia durante o seu acompanhamento de projeto e por fim, alterar o documento de decisão arquitetural.
A medida que ganhamos experiência com as tecnologias que são permitidas a serem utilizadas na construção de soluções e que se encontram homologadas pela empresa e ao mesmo tempo nos inserimos no contexto do negócio, a tendência é de que este documento amadureça e sofra menos alterações a medida que é criado.
Em linhas gerais, um documento de solução arquitetural precisa conter pelo menos:
- Uma tabela de controle de versão do documento;
- A descrição da solução - Utilize a técnica do twitter, pense em 140 caracteres e seja sucinto e objetivo, mas escreva de tal forma que as pessoas consigam entender sobre o que o documento está tratando;
- Desenho macro estrutural da solução - Desenhe um diagrama completo que contemple toda a solução proposta, incluindo uma breve descrição de cada componente;
- Componentes que fazem parte da solução - Ferramenta de ETL, FTP server, Gateway de integração, Sistemas satélite que farão parte da solução como por exemplo. Diagrame todas as ferramentas a serem utilizadas na solução;
- Se a solução já existe e trata-se de um upgrade, descreva as novas tecnologias que serão inseridas;
- Qual a forma de autenticação a ser utilizada - SSO, LDAP por exemplo. Converse com o time de segurança da informação;
- Interfaces - Internas e externas, máquina para máquina e as interfaces do usuário. Converse com o time de middleware;
- Descrição do comportamento dinâmico - Desenhe um diagrama com os casos de uso macro, desenhe o entendimento que você adquiriu sobre o problema e que foi previamente discutido com os usuários;
- Breve descrição dos processos de negócio;
- Gráfico com as interligações entre a solução e outros sistemas - Desenhe um diagrama simples que indique outros sistemas onde informações são coletadas ou entregues. Sempre haverão outros sistemas a serem integrados;
- Decisões arquiteturais já existentes a serem reutilizadas - Grandes empresas possuem um dicionário de decisões arquiteturais, conheça o máximo de decisões já existentes possível e reaproveite a informação;
- On premises vs Cloud - Construa um quadro comparativo entre usar servidores locais ou utilizar um cloud caso esteja analisando um ambiente que será migrado para cloud;
- Conectividade - Descreva como se dará a conectividade entre a empresa e o cloud incluindo uma análise de como se dará a última milha - Last Mile;
- SLA de uptime e downtime - Grandes empresas precisam de ao menos 99.8 % de SLA. Descreva os SLAs acordados com o time de infraestrutura e com o seu fornecedor se for o caso;
- Proposta de arquitetura de hardware - Converse com o time de infraestrutura de servidores, detalhe o hardware que será utilizado na solução. Dependendo da empresa, a compra de um hardware pode levar meses e causar impactos no projeto;
- Proposta da arquitetura de integração - Grandes empresas normalmente possuem algum tipo de middleware de interação ou ESB, desenhe um diagrama que contemple este cenário;
- Abordagem de testes a ser utilizada - Descreva os tipos de teste a serem executados para garantia da qualidade da solução, os testes unitários, a automação de testes, etc.;
- Aspectos de segurança a serem considerados - A segurança da informação é parte fundamental na vida de um arquiteto de solução e precisa estar bem descrita para que os demais times envolvidos se sintam seguros ao implementar o que está sendo proposto;
- Outras soluções de mercado - Sempre há outras soluções de mercado que podem ser utilizadas para atender uma necessidade, algumas precisam de muitos ajustes ou adequações e outras se encaixam na necessidade do negócio de forma mais prática ou com poucas modificações. O arquiteto de solução precisa descrever estas possíveis soluções para auxiliar na justificativa de sua escolha. As outras soluções de mercado são balizadoras que apresentam aos solicitantes da demanda que uma pesquisa prévia foi realizada antes da tomada de decisão;
- TCO - Esta é uma das partes mais sensíveis do documento de decisão arquitetural, muitas vezes, o arquiteto de solução não possui acesso a valores e por este motivo o TCO é estimado e não uma certeza absoluta. Procure ser o mais coerente possível e caso necessário, solicite auxilio ao time responsável por compras.
Grandes empresas possuem áreas muito bem definidas e com isto, o arquiteto de solução precisa ter a habilidade de transitar por todas elas, conhecendo o máximo que puder para que possa então discutir com estas áreas e seus integrantes soluções que possam ser implementadas respeitando os processo já definidos. O arquiteto de solução no mínimo, precisa ter habilidades para conversar com as seguintes áreas:
- Segurança da informação;
- Banco de dados e infraestrutura de storage;
- Integrações (Middleware, Webservices, SOA);
- Servidores (Web, FTP, VPN);
- Suporte a aplicativos;
- Sistemas de informação.
O Technical Reference Model (TRM)
Todas as empresas (pequenas ou grandes), formalmente ou não, possuem algum tipo de TRM. O TRM é um documento que baliza todo o uso de tecnologia permitida em uma empresa. Este documento indica os produtos homologados que podem ser utilizados na construção de uma solução, desde a especificação de servidores web até a indicação de qual tipo de aplicação para controle de versão. Todos os componentes precisam estar claros e bem definidos neste documento, e os arquitetos de solução precisam sempre mantê-lo atualizado para que o mesmo possa ser utilizado como o documento de referência a que se propõe. Sem o uso de um documento formal como este, a construção de novas soluções fica fadada a escolha de tecnologias não homologadas pela empresa. Imagine um parque tecnológico onde a maioria das tecnologias utilizadas é Microsoft e uma nova solução é criada em Java ou outra linguagem. Certamente, o impacto para o time de segurança da informação e infraestrutura será muito alto e você não fará bons amigos.
Existem vários modelos de TRM que podem ser utilizados como referência, desde aqueles que são detalhados e que descrevem o tipo de tecnologia que pode ser utilizada , incluindo a versão homologada para uso até os mais macros e orientados a negócio. Veja os exemplos de TRM do governo da Arabia Saudita , do FEAPMO (Federal Enterprise Architecture Program Management Office), da agencia de promoção de tecnologia da informação do Japão (IPA) e o modelo online da Universidade de Birmingham no Reino Unido.
Frameworks que tratam de Arquitetura de Solução e Arquitetura Corporativa
Existem vários caminhos para se tomar durante uma caminhada, pode-se optar por qualquer um, mas a experiência aponta que ao obter qualquer informação que seja sobre um determinado trajeto, é ele que será seguido.
O TOGAF é um framework gerenciado pelo Open Group e que assim como outros procura apresentar a experiência de profissionais ao criar suas arquiteturas. Atualmente ele conta com o suporte de grandes empresas como: IBM, HP e Oracle. O TOGAF possui grande aceitação na área de tecnologia e a cada ano conquista novos simpatizantes devido a sua forma estruturada de se apresentar.
O TOGAF é dividido em 9 processos nomeados de Architecture Development Method (ADM), porém, em arquitetura de solução, o foco é principalmente direcionado em apenas três destes processos:
- Business Architecture;
- Information Systems Architecture;
- Technology Architecture.
Como arquiteto de solução, é preciso conhecer alguns destes frameworks para que possamos aplicar as técnicas propostas na construção de uma solução. É importante destacar que não há a necessidade de seguir a proposta do framework como ela foi definida. O framework deverá ser apenas uma referência para produzir documentação em um padrão largamente aceito no mercado. A documentação online do ADM destaca que:
O ADM é um método genérico para desenvolvimento de arquitetura, projetado para lidar com a maior parte dos sistemas e requisitos organizacionais. No entanto, muitas vezes, será necessário modificar ou estender o ADM para atender a necessidades específicas. Uma das tarefas fundamentais antes de aplicar as técnicas descritas no ADM é a de rever seus componentes para a aplicabilidade em questão, e depois adaptá-los conforme às circunstâncias individuais de cada empresa. Esta atividade pode ter como consequência a criação de um ADM específico da empresa.
Outros frameworks compatíveis com o TOGAF e que buscam atender o mesmo objetivo encontram-se referenciados no site do Open Group. É necessário ao menos ler a descrição resumida de cada um deles. É importante destacar que os mais utilizados são o TOGAF e o Zachman. Há na internet muito material descrevendo os frameworks mais importantes como por exemplo o material disponibilizado no site da Microsoft.
Google Trends para TOGAF, Zachman e C4ISR respectivamente em Jun/2016
O Roadmap
Como documento final que fará parte da apresentação da solução, é necessário construir um roadmap que apresente, de forma simples e objetiva, a evolução esperada para a solução em um determinado período de tempo. Este período de tempo varia de empresa para empresa e é baseado nos processos de obsolescência, no crescimento e na atualização que cada empresa estabelece. Uma prática de mercado comum entre as empresas considera que esta visão seja válida por até 5 anos após a implantação da solução.
Um modelo de roadmap simples e objetivo que podemos referenciar é o apresentado pelo Facebook em abril deste ano o qual apresenta a evolução do produto para os próximos 10 anos.
Observe que este modelo é simples porém destaca todos os produtos que compõem o ecossistema e as tecnologias a serem utilizadas com o passar dos anos.
O "não" como resposta
Ninguém gosta de receber não como resposta. Já vivemos situações onde parte de um time tinha como padrão começar sua resposta aos usuários com
"não..." sem ao menos analisar o problema e identificar a necessidade do usuário.
Este tipo de comportamento lamentável deve ser evitado pelo arquiteto de solução, ou caso contrário, ele se tornará uma pessoa mal vista na empresa e no lugar de ser um provedor de soluções, será considerado um embromador de solução odiado e evitado a todo custo.
Todo usuário que busca ajuda em uma empresa, incluindo o pessoal de TI não tão técnico como analistas de requisito, arquitetos de negócio ou mesmo lideres técnicos, quando procuram um arquiteto de solução buscam sempre por alguém que mesmo sem uma resposta pronta, pelo menos se comprometa a estudar sobre o assunto para lhe propor uma solução.
Estudar mais um assunto e buscar por mais informações continuamente é uma das mais importantes habilidades que um arquiteto de solução precisa ter. A expressão "Me dê 2 dias para pensar" mostra ao seu requisitante que você buscará uma solução e lhe apresentará uma saída, e o deixará confortável para saber que sempre poderá contar com sua ajuda.
Lembre-se, uma pessoa se considera bem recebida mesmo quando tem o não como resposta se você:
- Ouve o que ela tem a dizer;
- Explica o motivo da resposta negativa;
- Trata com delicadeza e respeito;
- Encaminha para a área indicada a resolver seu problema;
- Justifica o não atendimento e se coloca a disposição para atendê-la em uma outra ocasião.
Conclusão
Desempenhar o papel de arquiteto de solução requer experiência, um bom grau de conhecimento, leituras constantes e enfrentamento de riscos.
Desenhar soluções não significa apenas juntar blocos sem sentido e sem fundamentos técnicos, requer a vivência que só o passar dos anos é capaz de fornecer. Quando assumimos este papel, carregamos responsabilidades que podem representar impactos financeiros de milhões quando não bem executadas. A recomendação é a de uma linha constante de leituras e estudos, a realização de testes e discussões intensivas com as partes envolvidas para validação da solução não levando em conta apenas os aspectos técnicos mas também os processos.
Como dica de leitura e fonte de conhecimento adicional, além do blog de Phillip Calçado e dos livros indicados, Guilherme Chapiewisk, atualmente na Tile App, possui um blog antigo com boas recomendações de leitura. Outro site interessante é o Hacker News, o qual possui uma grande variedade de notícias sobre muitos assuntos da atualidade e suas evoluções.
Como editor, não poderia deixar de citar o InfoQ como fonte de referência, já faz seis anos que Marcelo Costa atua como editor voluntário neste site, traduzindo, revisando e escrevendo notícias e artigos originais.
O trabalho de escrita, tradução e revisão de artigos e notícias particularmente ajuda a me manter informado com o que há de mais novo na área de tecnologia e além disso, ajuda a enriquecer minhas habilidades técnicas. Como ganho adicional, meu inglês e português são a todo momento avaliados pelos demais contribuidores do site o que também ajuda profissionalmente.
Ambos os sites - Hacker News e InfoQ - são de leitura diária obrigatória pelo menos 2 vezes ao dia em nossa experiência.
Por fim, citando Sheryl Sandberg:
Você não nasce com uma quantidade fixa de resiliência. Ela é como um músculo o qual você pode exercitá-lo para se tornar forte e em seguida utilizá-lo quando precisar.
Sobre os autores
Marcelo Costa (LinkedIn, Twitter) é pós-graduado em Engenharia de Software pela UNICAMP. Atua em sistemas de alta complexidade desde 2002, coordenando equipes multidisciplinares no desenvolvimento de soluções de software nas áreas de educação, saúde, finanças, logística rodoviária e aeroespacial. Especializa-se na coleta inteligente de informações na internet e de conteúdo eletronicamente disponível; atualmente é consultor em Arquitetura de Solução para o setor de Aviação Comercial da EMBRAER.
Jorge Chagas realiza estágio como Arquiteto de Soluções no setor de Planejamento Estratégico da Embraer. É graduando em Engenharia da Computação na Escola de Engenharia Industrial em São José dos Campos e com extensão na Lawrence Technological University/EUA. Participou de competições mundiais de robótica como a IGVC (Intelligent Ground Vehicle Competition), Robofest world championship e a Michigan I-corps pela Universidade de Michigan/EUA e estagiou como Engenheiro de Sistemas na Engenharia Avançada da Magna Electronics, Michigan/EUA. Pode ser contatado em seu LinkedIn e email: jbarbosad at ltu.edu