{"id":3640,"date":"2022-03-11T13:31:42","date_gmt":"2022-03-11T16:31:42","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=3640"},"modified":"2024-01-11T17:50:48","modified_gmt":"2024-01-11T20:50:48","slug":"definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/","title":{"rendered":"Definindo arquitetura de software e o papel do arquiteto \/ Introdu\u00e7\u00e3o v3.01"},"content":{"rendered":"

Desenvolvimento de software \u00e9 cada vez mais relevante. \u00c9 dif\u00edcil imaginar qualquer atividade, em qualquer empresa, em qualquer segmento, que n\u00e3o seja suportada, direta ou indiretamente, por algum tipo de sistema digital.<\/strong> Software bem-feito \u00e9, cada vez mais, premissa para a competitividade. Logo, mesmo empresas que n\u00e3o se declaram tecnol\u00f3gicas, tem a tecnologia como compet\u00eancia essencial. Nesse contexto, arquitetura de software ganha relev\u00e2ncia, bem como a atua\u00e7\u00e3o do arquiteto.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Como TI \u00e9 percebida em sua empresa?<\/p>\r\nTI passou, em poucos anos, de fonte de custo a fonte diferencial competitivo<\/strong>. Isso implicou em ajustes na forma como ela \u00e9 gerenciada, sobretudo por novos e crescentes objetivos estrat\u00e9gicos.<\/p>\n

\n

Nesse epis\u00f3dio, falamos sobre as v\u00e1rias percep\u00e7\u00f5es para a \u00e1rea de TI que encontramos em empresas de todos os portes. Tamb\u00e9m indicamos o que deveria estar sendo feito.\r\n

Acessar epis\u00f3dio<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nSoftware bem-feito atende os objetivos do neg\u00f3cio, respeitando restri\u00e7\u00f5es e atingindo atributos de qualidade. Al\u00e9m disso, por sua import\u00e2ncia, tem sua estrat\u00e9gia evolutiva bem definida.<\/strong> A arquitetura do software bem-feita \u00e9 premissa para software bem-feito e manuten\u00edvel.\n

\n

Todo software tem sua arquitetura. Algumas emergem de forma n\u00e3o supervisionada e, por isso, t\u00eam qualidade question\u00e1vel, implicando em software tamb\u00e9m de qualidade question\u00e1vel.<\/strong> Boas arquiteturas dificilmente acontecem sem a atua\u00e7\u00e3o de algu\u00e9m competente como respons\u00e1vel.<\/p>\nEventualmente, bons sistemas s\u00e3o desenvolvidos a partir das “cicatrizes” do time. Ou seja, utilizando arquiteturas de sistemas desenvolvidos com \u00eaxito no passado como refer\u00eancia para uma nova solu\u00e7\u00e3o. <\/strong>Entretanto, isso n\u00e3o \u00e9 indicativo de que conhecimentos relacionados a arquitetura sejam menos importantes, apenas indica que decis\u00f5es arquiteturais podem, eventualmente, ser “requentadas” para resolver cen\u00e1rios com problemas de neg\u00f3cio, restri\u00e7\u00f5es ou atributos de qualidade similares.\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Software n\u00e3o desgasta, mas deteriora. <\/em>\r\n

Pressman<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Empresas de varejo, com frequ\u00eancia, contratam pessoas t\u00e9cnicas que tenham experi\u00eancia atuando no varejo, por exemplo. Essa “prefer\u00eancia” se justifica pela intimidade com aspectos arquiteturais espec\u00edficos.<\/p>\nH\u00e1 tamb\u00e9m, sistemas que evoluem suas arquiteturas com base em modismos, influ\u00eancias de terceiros ou prefer\u00eancias dif\u00edceis de justificar.<\/strong> Nestes cen\u00e1rios, preju\u00edzos acabam sendo percebidos mais tarde e por muito tempo. Geralmente, no longo prazo, tais solu\u00e7\u00f5es se convertem em “colchas de retalhos” com custo crescente de manuten\u00e7\u00e3o.\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Como um projeto de software pode ter um “atraso” de mais de um ano? … Um dia de cada vez. \r\n

Frederick P. Brooks Jr.<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div><\/em><\/p>\nAs oportunidades s\u00e3o muitas e os riscos s\u00e3o cada vez maiores – neg\u00f3cios e tecnologia mudam e evoluem em ritmo cada vez mais acelerado. Ter ci\u00eancia da import\u00e2ncia de desenvolver sistemas com boas arquiteturas deve fazer parte, cada vez mais, da proposi\u00e7\u00e3o competitiva das organiza\u00e7\u00f5es. Profissionais com habilidades em conceber e implementar tais arquiteturas ser\u00e3o cada vez mais valorizados, independente do t\u00edtulo que se d\u00ea a posi\u00e7\u00e3o que ocupam.\n

O que \u00e9 arquitetura de software<\/h2>\nEmbora n\u00e3o exista consenso absoluto sobre o conceito, alguns aspectos s\u00e3o amplamente aceitos. Qualquer discuss\u00e3o madura sobre a arquitetura de um software aborda, de maneira mais ou menos qualificada, seus componentes, a responsabilidade destes e a forma como eles se relacionam.<\/strong> Ali\u00e1s, isto est\u00e1 alinhado com a defini\u00e7\u00e3o proposta pelo IEEE, que \u00e9 uma das mais mencionadas.\n
\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

Arquitetura de software pode ser definida como a organiza\u00e7\u00e3o fundamental de um sistema, seus componentes, as rela\u00e7\u00f5es entre eles e o ambiente que guia seu design e evolu\u00e7\u00e3o. <\/em>\r\n

IEEE Standard 1471<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nIndiretamente, a refer\u00eancia a componentes, relacionamentos e responsabilidades tamb\u00e9m est\u00e1 presente na defini\u00e7\u00e3o proposta no excelente “Software Architecture in Practice<\/strong><\/a>“.\u00a0\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Software Architecture in Practice, 4th edition<\/p>\r\n<\/p>\n

Um verdadeiro cl\u00e1ssico, agora revisado e ampliado. Trata-se de “leitura obrigat\u00f3ria” para quem deseja realizar uma abordagem s\u00e9ria e mais formal as pr\u00e1ticas de arquitetura de software.<\/p>\n

\r\n

Acessar livro<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

A arquitetura de software de um programa ou sistema computacional \u00e9 a estrutura ou estruturas do sistema que abrange os componentes de software, as propriedades externamente vis\u00edveis desses componentes e as rela\u00e7\u00f5es entre eles.<\/em><\/p>\n

\r\n

Bass, Clements e Kasman<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A arquitetura de um software n\u00e3o \u00e9 um conjunto de diagramas, produzidos por algu\u00e9m, frequentemente desatualizados.<\/strong> Os diagramas, ali\u00e1s, s\u00e3o apenas um modelo, uma representa\u00e7\u00e3o, da arquitetura real que est\u00e1 ou estar\u00e1 implementada no software.<\/p>\nAs melhores arquiteturas, geralmente, tem componentes com baixo acoplamento. Ou seja, que funcionam e evoluem de maneira independente, com pouco impacto nos demais, tanto na manuten\u00e7\u00e3o quanto na opera\u00e7\u00e3o, al\u00e9m do ganho em testabilidade (que \u00e9 um ganho mais amplo, de engenharia).<\/strong> Por outro lado, arquiteturas ruins geralmente tem componentes fracamente delimitados, com forte acoplamento, dif\u00edceis de manter e, sobretudo, caros para testar e evoluir.\n

\n

A rela\u00e7\u00e3o de arquitetura com design<\/em> de software<\/h2>\n

Quando falamos sobre arquitetura, invariavelmente falamos sobre design de software. Entretanto, o oposto n\u00e3o \u00e9 verdadeiro. <\/strong>As decis\u00f5es sobre design que s\u00e3o parte da arquitetura de um software s\u00e3o aquelas que tem rela\u00e7\u00e3o direta com o atendimento dos objetivos do neg\u00f3cio, respeito a restri\u00e7\u00f5es e atendimento dos atributos de qualidade.<\/p>\n

A decis\u00e3o de isolar acesso ao banco de dados em uma \u201cclasse reposit\u00f3rio\u201d, por exemplo, \u00e9 uma decis\u00e3o de design, mas, dificilmente ser\u00e1 uma decis\u00e3o de arquitetura. Afinal, dificilmente ser\u00e1 fundamento para atendimento dos objetivos de neg\u00f3cio, respeito a restri\u00e7\u00f5es e atributos de qualidade. Por outro lado, a ado\u00e7\u00e3o de um cache \u00e9, quase sempre, uma decis\u00e3o de arquitetura pois, este componente pode ser a resposta para atender atributos de qualidade como disponibilidade e performance.<\/p>\n

Construir um software cloud-ready<\/em> tamb\u00e9m \u00e9 uma decis\u00e3o de arquitetura, bem como adotar um ou outro fornecedor de nuvem. Ali\u00e1s, as escolhas do banco de dados, das linguagens de programa\u00e7\u00e3o, dos frameworks<\/em> tanto para frontend<\/em> quando backend<\/em> tamb\u00e9m s\u00e3o exemplos de resolu\u00e7\u00f5es arquiteturais pois, certamente, ter\u00e3o implica\u00e7\u00f5es relevantes para a continuidade do software, logo, condi\u00e7\u00f5es para atender o neg\u00f3cio e implica\u00e7\u00f5es sobre o or\u00e7amento (uma das restri\u00e7\u00f5es mais comuns).<\/p>\nEspecificidades sobre inje\u00e7\u00e3o de depend\u00eancias, composi\u00e7\u00e3o ou agrega\u00e7\u00e3o de classes, nomes de m\u00e9todos e vari\u00e1veis e, at\u00e9 mesmo princ\u00edpios SOLID, quando relacionados a aspectos diretamente ligados ao c\u00f3digo, s\u00e3o bons exemplos de design<\/em>, mas n\u00e3o de arquitetura.\n

\n

A maioria das decis\u00f5es de design<\/em> s\u00e3o individuais, em conformidade com os acordos estabelecidos pelo time de desenvolvimento e acontecem o tempo todo. Algumas decis\u00f5es de design<\/em> relacionadas com a arquitetura, por outro lado, t\u00eam impacto maior e s\u00e3o menos frequentes. Decis\u00f5es arquiteturais raramente s\u00e3o produtos do trabalho individual.<\/strong><\/p>\n

Finalmente, decis\u00f5es de arquitetura geralmente s\u00e3o mais dif\u00edceis e custosas de revisitar. <\/strong>Da\u00ed, talvez, venha a defini\u00e7\u00e3o vaga de Ralph Johnson que utilizei na cita\u00e7\u00e3o de abertura.<\/p>\n

A rela\u00e7\u00e3o de arquitetura com engenharia de software<\/h2>\n
\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

A disciplina de engenharia de software contempla n\u00e3o apenas a escrita de c\u00f3digo, mas todas as ferramentas e processos que uma organiza\u00e7\u00e3o usa para construir e manter o software ao longo do tempo.\u00a0<\/em><\/p>\n

\r\n

Winters, Manshreck e Wright<\/em><\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Arquitetura de software \u00e9 uma das disciplinas da engenharia. N\u00e3o mais, n\u00e3o menos!<\/strong><\/p>\nA engenharia de software n\u00e3o \u00e9 est\u00e1tica e trata do “ciclo de vida” do software. De forma an\u00e1loga, a arquitetura de software tampouco \u00e9 est\u00e1tica, ou seja, a arquitetura evolui na mesma medida em que os objetivos de neg\u00f3cio podem ser redefinidos, restri\u00e7\u00f5es s\u00e3o revisadas e atributos de qualidade determinados.\n

\nH\u00e1 sempre, pelo menos, duas vis\u00f5es a respeito da arquitetura. A primeira, trata da arquitetura como ela est\u00e1 (AS-IS). A segunda, projeta como a arquitetura dever\u00e1 ser (TO-BE). Seja, para adequar aos novos tempos, seja para compensar d\u00edvidas t\u00e9cnicas. \n
\n

Quanto mais expl\u00edcitas forem as condi\u00e7\u00f5es atuais (AS-IS) e mais expl\u00edcitas forem as expectativas para o futuro (TO-BE), mais f\u00e1cil ser\u00e1 planejar a evolu\u00e7\u00e3o arquitetural atrav\u00e9s de “arquiteturas intermedi\u00e1rias”.<\/p>\n

A arquitetura de software deve considerar e respeitar as outras disciplinas de engenharia ou, pelo menos, t\u00ea-las em considera\u00e7\u00e3o.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

O projeto da Torre de Babel falhou por falta de comunica\u00e7\u00e3o, e por causa dessa falta, a organiza\u00e7\u00e3o falhou.\u00a0<\/em><\/p>\n

\r\n

Frederick P. Brooks Jr.<\/em><\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A rela\u00e7\u00e3o da arquitetura de software com a estrutura organizacional<\/h2>\nTratar da arquitetura de um software implica, fatalmente, em tratar da estrutura da organiza\u00e7\u00e3o que o utiliza e vice-versa.\n
\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

Organiza\u00e7\u00f5es que desenvolvem sistemas de software tendem a produzir sistemas que s\u00e3o c\u00f3pia das estruturas de comunica\u00e7\u00e3o dessas empresas. (Melvin Conway)<\/em><\/p>\n

\r\n

Melvin Conway<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A estrutura dos componentes de um software impacta na forma\u00e7\u00e3o dos times que v\u00e3o desenvolver o software. N\u00e3o h\u00e1, por exemplo, chances de implementar arquiteturas baseadas em microsservi\u00e7os em estruturas organizacionais com times monol\u00edticos. Se o time for indivis\u00edvel, o software tamb\u00e9m o ser\u00e1!<\/strong><\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Team Topologies<\/p>\r\nUm “novo cl\u00e1ssico”! Team Topologies <\/em>aborda de maneira clara e direta as complica\u00e7\u00f5es e oportunidades resultantes da Lei de Conway.\r\n

Acessar livro<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nA arquitetura de software, por\u00e9m, excede a estrutura dos times de desenvolvimento. Na pr\u00e1tica, a estrutura de componentes de um software acaba impactando tamb\u00e9m a pr\u00f3pria estrutura corporativa da empresa que adotar\u00e1 o produto tecnol\u00f3gico.<\/strong> Isso leva, por exemplo, a profundas modifica\u00e7\u00f5es, mesmo em empresas s\u00f3lidas, quando h\u00e1 migra\u00e7\u00e3o de um sistema chave ou, ainda, resist\u00eancia acentuada a mudan\u00e7a e aumento dos custos.\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

A lei de Conway<\/p>\r\nQuais s\u00e3o os impactos da lei de Conway para a arquitetura de software? Essa \u00e9 a tem\u00e1tica desse v\u00eddeo – parte de uma playlist<\/em> que preparamos para apresentar fundamentos das pr\u00e1ticas arquiteturais.\r\n

Acessar v\u00eddeo<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

As pr\u00e1ticas da arquitetura de software<\/h2>\nAs decis\u00f5es de design<\/em> que tem rela\u00e7\u00e3o com a arquitetura s\u00e3o t\u00e3o importantes que, idealmente, devem ser tomadas obedecendo algumas boas pr\u00e1ticas.<\/strong> Ou seja, replicando os comportamentos comuns adotados por times eficientes que produzem software de boa qualidade, que atendem os objetivos do neg\u00f3cio, respeitando restri\u00e7\u00f5es a atingindo atributos de qualidade.\n
\n

As pr\u00e1ticas de arquitetura de software maximizam a produtividade. Ou seja, a rela\u00e7\u00e3o entre o valor obtido (desempenho) e o esfor\u00e7o dispensado (empenho). De maneira an\u00e1loga, boa arquitetura maximiza o resultado, otimizando o investimento. Em termos simples, boa arquitetura de software colabora para melhorar o ROI de iniciativas de desenvolvimento e reduzir o TCO.<\/strong><\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

A f\u00f3rmula da produtividade<\/p>\r\n<\/p>\n

No meio corporativo \u00e9 comum falar sobre o \u201cdesafio da produtividade\u201d.\u00a0Mas, voc\u00ea j\u00e1 parou para pensar no que ser mais produtivo, de fato, significa?\u00a0<\/b><\/p>\n

N\u00f3s costumamos explicar a produtividade utilizando uma f\u00f3rmula simples.\u00a0<\/b>Entendemos que produtividade \u00e9 definida pela propor\u00e7\u00e3o do desempenho (o resultado que se busca obter) e do empenho (o esfor\u00e7o ou custo necess\u00e1rio para gerar o desempenho).<\/p>\n

\r\n

Acessar epis\u00f3dio<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

As melhores pr\u00e1ticas de arquitetura de software invariavelmente acionam as partes interessadas (stakeholders<\/em>) para explicitar e atualizar os objetivos do neg\u00f3cio que precisam ser atingidos, focando nos resultados e n\u00e3o na forma.<\/strong> Elas tamb\u00e9m devem diagnosticar, at\u00e9 o \u00faltimo momento respons\u00e1vel, as restri\u00e7\u00f5es que devem ser observadas e assegurar que elas sejam respeitadas. Finalmente, tamb\u00e9m devem inferir os atributos de qualidade que garantem a efici\u00eancia no atendimento do neg\u00f3cio e das restri\u00e7\u00f5es.<\/p>\nAs melhores pr\u00e1ticas de arquitetura resolvem de maneira mais leve os principais trade-offs<\/em> – dire\u00e7\u00f5es conflitantes que precisam ser observadas – que emergem no levantamento dos objetivos e das restri\u00e7\u00f5es.<\/strong> Por exemplo, disponibilidade – um atributo de qualidade – conflita com seguran\u00e7a – uma restri\u00e7\u00e3o, afinal, disponibilidade implica em adi\u00e7\u00e3o de componentes que ampliam a \u201csuperf\u00edcie de ataque\u201d.\n

A abrang\u00eancia da arquitetura de software<\/h2>\n

As decis\u00f5es arquiteturais impactam, obviamente, nas atividades de desenvolvimento, mas tamb\u00e9m tem rela\u00e7\u00e3o com a manuten\u00e7\u00e3o, atualiza\u00e7\u00e3o, entrega (deploy<\/em>) e opera\u00e7\u00e3o do software. Por isso, arquitetura de software \u00e9 parte do esfor\u00e7o de engenharia, que \u00e9 mais amplo.<\/strong><\/p>\n

A boa engenharia de software, conforme a Google, contempla todas as atividades que habilitam um sistema a suportar as mudan\u00e7as de escala, ao longo do tempo, sem sacrificar a efici\u00eancia.<\/strong> Seguramente, as decis\u00f5es arquiteturais s\u00e3o parte crucial para o sucesso da engenharia.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Software Engineering at Google<\/p>\r\nComo a Google, uma das maiores empresas de tecnologia do mundo, trata engenharia de software? Quais foram as li\u00e7\u00f5es aprendidas pela companhia ao longo de sua jornada? Essa \u00e9 a tem\u00e1tica desse livro fant\u00e1stico.\r\n

Acessar livro<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A decis\u00e3o de adotar microsservi\u00e7os, por exemplo, transfere parte da complexidade de desenvolver um software para sua opera\u00e7\u00e3o. H\u00e1 mais o que operar e monitorar e obrigam a ado\u00e7\u00e3o de abordagens mais modernas e automatizadas. N\u00e3o raro, microsservi\u00e7os \u00e9 uma tentativa de resolver um problema criando outro pior!<\/strong><\/p>\n

A \u201cestrat\u00e9gia\u201d na arquitetura de software<\/h2>\n

Estrat\u00e9gia \u00e9 um padr\u00e3o coerente para tomada de decis\u00f5es.<\/strong> Ou seja, quando todas as pessoas de um grupo tomam decis\u00f5es seguindo um mesmo padr\u00e3o coerente, obedecendo um conjunto est\u00e1vel de crit\u00e9rios, diz-se que est\u00e3o alinhados a uma mesma estrat\u00e9gia – mesmo quando, eventualmente, as decis\u00f5es em si sejam diferentes.<\/p>\nQuando um time de desenvolvimento adota boas pr\u00e1ticas de arquitetura, seus membros seguem uma estrat\u00e9gia comum para suas escolhas e isso \u00e9 extremamente importante. Afinal, para cada problema tecnol\u00f3gico h\u00e1 uma continuidade crescente de respostas vi\u00e1veis – com pr\u00f3s e contras – que dificultam o consenso. A alternativa selecionada deve ser aquela que for mais aderente aos objetivos de neg\u00f3cio, restri\u00e7\u00f5es e atributos de qualidade.\n

\n

Na pr\u00e1tica, isso significa, por exemplo, que qual framework utilizar no frontend<\/em>, por exemplo, \u00e9 menos relevante, sob a perspectiva da arquitetura, que os crit\u00e9rios que foram utilizados para adotar tal tecnologia.<\/strong><\/p>\n

\r\n

Defini\u00e7\u00e3o: 'Arquitetura de Software' (Proposta)<\/p>\r\n

Arquitetura de software trata das decis\u00f5es relacionadas ao design<\/em> de um software – seus componentes, as responsabilidades destes componentes e como se relacionam –\u00a0 bem como a estrat\u00e9gia que governar\u00e1 sua evolu\u00e7\u00e3o, de forma a atender os objetivos do neg\u00f3cio, respeitando restri\u00e7\u00f5es t\u00e9cnicas e n\u00e3o t\u00e9cnicas, atendendo atributos de qualidade, sempre buscando minimizar custo ou risco.<\/p>\r\n<\/div>\n

O arquiteto de software<\/h2>\n

Todo software tem uma arquitetura. Nem sempre, entretanto, ela \u00e9 suportada por boas pr\u00e1ticas arquiteturais.<\/p>\n

H\u00e1 quem defenda que as boas pr\u00e1ticas arquiteturais devem ser refor\u00e7adas por todo o time de desenvolvimento e eu concordo com isso. Entretanto, tamb\u00e9m entendo que algo que \u00e9 responsabilidade de todos, acaba recebendo cuidados de ningu\u00e9m.<\/strong> O arquiteto de software, em um time de desenvolvedor de software, \u00e9 o respons\u00e1vel por garantir que boas pr\u00e1ticas de arquitetura sejam adotadas.<\/p>\n

O arquiteto apoia os esfor\u00e7os de engenharia de software, tomando decis\u00f5es que facilitem a gest\u00e3o do ciclo de vida de um produto tecnol\u00f3gico.<\/p>\n

Em um mundo onde especialistas sabem cada vez mais sobre cada vez menos, n\u00e3o se pode esperar que uma \u00fanica pessoa seja capaz de tomar todas as decis\u00f5es importantes relacionadas com a arquitetura.<\/strong> Entretanto, parece coerente ter algu\u00e9m preocupado e respons\u00e1vel por garantir que essas decis\u00f5es sejam tomadas – este \u00e9 o papel do arquiteto.<\/p>\n

O arquiteto de software \u00e9, idealmente, um orquestrador.<\/strong> Ele garante que todas as partes interessadas sejam ouvidas e suas pondera\u00e7\u00f5es sejam levadas em conta na formula\u00e7\u00e3o da arquitetura. Para isso, elabora e mant\u00e9m artefatos abrangentes que facilitam o engajamento.<\/p>\n

O arquiteto de software deve, de tempos em tempos, revisar a estrutura de componentes e suas rela\u00e7\u00f5es de um software para garantir que os objetivos do neg\u00f3cio ser\u00e3o atingidos, as restri\u00e7\u00f5es obedecidas e os atributos de qualidade atendidos. Al\u00e9m de tudo isso, o arquiteto deve adotar postura \u201cprovocativa\u201d para verificar se a entrega est\u00e1 maximizada frente ao melhor custo.<\/strong><\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

The Software Architect Elevator<\/p>\r\nQuais s\u00e3o as fun\u00e7\u00f5es e responsabilidades do arquiteto de software? O que muda conforme o tamanho das organiza\u00e7\u00f5es? Greg Hohpe apresenta uma vis\u00e3o madura e bem fundamentada para essas quest\u00f5es neste livro espetacular.\r\n

Acessar livro<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nH\u00e1, certamente, muitos times de tecnologia que tem sucesso em fazer entregas sem ningu\u00e9m ocupando, formalmente, a posi\u00e7\u00e3o de arquitetura. Entretanto, esses times s\u00e3o compostos ou, pelo menos, liderados por desenvolvedores muito experientes.<\/strong> Nesses casos, esses desenvolvedores tem cicatrizes relacionadas a decis\u00f5es arquiteturais semelhantes as que s\u00e3o necess\u00e1rias para o projeto em que est\u00e3o trabalhando, diminuindo o risco da aus\u00eancia do pensamento arquitetural mais especializado. H\u00e1 ainda, claro, pessoas executando o ‘papel de arquiteto’, sem o devido reconhecimento formal.\n

O arquiteto n\u00e3o \u00e9, necessariamente, um \u201cdev s\u00eanior-s\u00eanior\u201d<\/h2>\n

Em minha experi\u00eancia, n\u00e3o conheci nenhum arquiteto de software que n\u00e3o tenha sido, tamb\u00e9m, excelente desenvolvedor. Entretanto, embora exista correla\u00e7\u00e3o, n\u00e3o consigo identificar causalidade.<\/p>\nMuito da confus\u00e3o do arquiteto com um “dev s\u00eanior-senior” surge da incapacidade das empresas de ajustarem um plano de carreira adequado para times de tecnologia. N\u00e3o raro, a posi\u00e7\u00e3o do arquiteto de software \u00e9 ofertada como uma promo\u00e7\u00e3o (um pr\u00f3ximo passo natural) para um desenvolvedor e este n\u00e3o \u00e9 o caso.\n

\n

O arquiteto de software precisa de soft skills<\/em> suficientes para poder interagir com os diferentes stakeholders<\/em> de maneira qualificada<\/strong>. Al\u00e9m disso, deve ter capacidade de abstra\u00e7\u00e3o suficiente para representar componentes complexos de maneira compreens\u00edvel. Finalmente, precisa ter \u201csensibilidade t\u00e9cnica\u201d para identificar falhas arquiteturais e acionar as pessoas certas para que as decis\u00f5es sejam as mais assertivas.<\/p>\n

A aloca\u00e7\u00e3o de uma pessoa em atividades de arquitetura pode variar significativamente conforme a complexidade ou os riscos do software que est\u00e1 sendo desenvolvido. Em muitos cen\u00e1rios, o arquiteto tem tempo para escrever c\u00f3digo. Outras vezes, as atividades de orquestra\u00e7\u00e3o podem ser demandantes ao ponto de que n\u00e3o sobre tempo para escrever c\u00f3digo em quantidade relevante.<\/p>\nImportante, por\u00e9m, destacar que hard skills\u00a0<\/em>nunca ser\u00e3o um problema, muito pelo contr\u00e1rio!\n

\r\n

Defini\u00e7\u00e3o: 'Arquiteto de Software' (Proposta)<\/p>\r\n

O arquiteto de software \u00e9 o respons\u00e1vel por garantir (n\u00e3o necessariamente executar) que as pr\u00e1ticas de arquiteturais sejam executadas. Tem perfil “t\u00e9cnico” com excelentes essential skills, <\/em>capaz de discutir desde com “escovadores de bits<\/em>” at\u00e9 “altos executivos”.<\/p>\r\n<\/div>\n

Quatro configura\u00e7\u00f5es de trabalho para o “arquiteto”<\/h2>\n

Todo sistema de software possui uma arquitetura. Entretanto, ela nem sempre \u00e9 planejada, tampouco idealizada por algu\u00e9m que responde, pelo menos oficialmente, como arquiteto.<\/strong><\/p>\n

Gregory Hohpe<\/a> ensina que h\u00e1 pelo menos quatro configura\u00e7\u00f5es poss\u00edveis para a atividade de arquitetura.<\/p>\n

\"\"<\/p>\n

O arquiteto como “Ditador Benevolente”<\/h3>\n

Nessa configura\u00e7\u00e3o, cabe ao arquiteto definir o que precisa ser feito e ao time executar o que o arquiteto definir.<\/strong><\/p>\n

\"\"<\/p>\nEmbora aparentemente na contram\u00e3o de estruturas modernas e \u00e1geis, esta configura\u00e7\u00e3o pode ser necess\u00e1ria em times onde produzir o consenso \u00e9 dif\u00edcil. Geralmente, tais cen\u00e1rios s\u00e3o resultantes do excesso ou da falta absoluta da press\u00e3o por resultados. Ou ainda, por falta de equil\u00edbrio de senioridade.\n

\n

No m\u00e9dio-longo prazo, times com uma cabe\u00e7a, a do “ditador benevolente”, e diversos bra\u00e7os, o restante do time, s\u00e3o insustent\u00e1veis por promover comportamento med\u00edocre.<\/p>\n

Arquiteto como “membro do time”<\/h3>\n

Nessa configura\u00e7\u00e3o, o arquiteto assume a posi\u00e7\u00e3o de orquestrador para as decis\u00f5es mais importantes.<\/strong> Ele explicita e consolida op\u00e7\u00f5es com o time verificando sempre o atendimento dos objetivos do neg\u00f3cio, respeito a restri\u00e7\u00f5es e atendimento dos atributos de qualidade.<\/p>\n

\"\"<\/p>\nGeralmente, nessas configura\u00e7\u00f5es, h\u00e1 equil\u00edbrio percept\u00edvel de senioridade na maior parte do time. As decis\u00f5es nem sempre s\u00e3o tomadas rapidamente, mas, s\u00e3o sempre mais seguras.\n

\nO maior risco, nessa configura\u00e7\u00e3o, \u00e9 que o arquiteto passe a executar outras atividades, como escrever c\u00f3digo, em demasia, deixando de cumprir seu papel prim\u00e1rio.\n
\n

Arquitetura sem arquitetos<\/h3>\n

Nessa configura\u00e7\u00e3o, as atividades de arquitetura s\u00e3o dilu\u00eddas entre os diversos membros do time, que assumem responsabilidade compartilhada pelos resultados.<\/strong><\/p>\n

\"\"<\/p>\n

Esse tipo de configura\u00e7\u00e3o s\u00f3 \u00e9 poss\u00edvel em times com senioridade extremamente elevada, onde h\u00e1 consci\u00eancia da natureza e da import\u00e2ncia das atividades arquiteturais.<\/p>\nO maior risco, nessa configura\u00e7\u00e3o, \u00e9 que o time negligencie aspectos como comunica\u00e7\u00e3o eficaz com outros stakeholders<\/em>, migrando para outra configura\u00e7\u00e3o, “impl\u00edcita” onde pr\u00e1ticas arquiteturais simplesmente n\u00e3o s\u00e3o executadas.\n

\n

Arquitetura “impl\u00edcita”<\/h3>\n

Nessa configura\u00e7\u00e3o, as atividades de arquitetura simplesmente n\u00e3o s\u00e3o executadas e a mesma “emerge organicamente” durante o processo de desenvolvimento.\u00a0<\/strong>\u00c9 comum em times alegadamente \u00e1geis que acham pr\u00e1ticas arquiteturais desnecess\u00e1rias.<\/p>\n

\"\"<\/p>\n

O resultado comum desse tipo de configura\u00e7\u00e3o \u00e9 ver o time “fazendo outra fez” software que j\u00e1 fez no passado. Ou seja, reproduzindo solu\u00e7\u00f5es de projetos anteriores para problemas propostos no projeto atual.<\/p>\nEste tipo de configura\u00e7\u00e3o costuma ser o “gatilho” para ado\u00e7\u00e3o, em algum momento, do modelo com um “ditador benevolente”. Geralmente, quando o projeto sai dos trilhos.\n

\n

Qual \u00e9 o jeito certo?<\/h3>\n

N\u00e3o h\u00e1 jeito certo! Mas, com certeza, desenvolver software buscando arquiteturas impl\u00edcitas \u00e9 o jeito errado. A op\u00e7\u00e3o por ter um “ditador benevolente”, como um “igual” no time, ou ter as atividades dilu\u00eddas depende da senioridade e da orienta\u00e7\u00e3o do time.<\/p>\n

Este \u00e9 o in\u00edcio de uma longa jornada…<\/h2>\n

Gosto muito da ideia de dar passos consistentes na dire\u00e7\u00e3o certa, o tempo todo.<\/strong> Nesta introdu\u00e7\u00e3o, tentei consolidar impress\u00f5es sobre arquitetura de software, suas pr\u00e1ticas e as atribui\u00e7\u00f5es de um arquiteto. Nos pr\u00f3ximos cap\u00edtulos, vou apresentar algumas \u201cboas pr\u00e1ticas\u201d de arquitetura que tenho vivenciado como arquiteto e consultor.<\/p>\n

\/\/ TODO<\/h2>\n

Antes de avan\u00e7ar para o primeiro cap\u00edtulo, recomendo as seguintes atividades:<\/p>\n

    \n
  • Reflita sobre as pr\u00e1ticas de arquitetura de software<\/em> que voc\u00ea tem presenciado. O que tem funcionado? O que n\u00e3o tem gerado os resultados esperados?<\/li>\n
  • Voc\u00ea consegue relacionar os principais componentes do software que est\u00e1 desenvolvendo, suas responsabilidades e a forma como estes se relacionam?<\/li>\n
  • Voc\u00ea consegue relacionar os objetivos de neg\u00f3cio que precisam ser atingidos usando o software que est\u00e1 ajudando a desenvolver? Conhece as principais restri\u00e7\u00f5es? Saberia explicitar os atributos de qualidade?<\/li>\n<\/ul>\n","protected":false},"featured_media":366,"parent":0,"comment_status":"open","ping_status":"open","template":"","url":[],"sessoes":[57],"apendices":[],"capitulos":[15],"class_list":["post-3640","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","sessoes-secao-1","capitulos-capitulo-1-1"],"acf":[],"yoast_head":"\nDefinindo arquitetura de software e o papel do arquiteto \/ Introdu\u00e7\u00e3o v3.01 - Manual do Arquiteto de Software<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Definindo arquitetura de software e o papel do arquiteto \/ Introdu\u00e7\u00e3o v3.01 - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"Desenvolvimento de software \u00e9 cada vez mais relevante. \u00c9 dif\u00edcil imaginar qualquer atividade, em qualquer empresa, em qualquer segmento, que n\u00e3o seja suportada, direta ou indiretamente, por algum tipo de sistema digital. Software bem-feito \u00e9, cada vez mais, premissa para a competitividade. Logo, mesmo empresas que n\u00e3o se declaram tecnol\u00f3gicas, tem a tecnologia como compet\u00eancia […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/\" \/>\n<meta property=\"og:site_name\" content=\"Manual do Arquiteto de Software\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/eximiaco\" \/>\n<meta property=\"article:modified_time\" content=\"2024-01-11T20:50:48+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/02\/img-capitulo-3.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"600\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:site\" content=\"@eximiaco\" \/>\n<meta name=\"twitter:label1\" content=\"Est. tempo de leitura\" \/>\n\t<meta name=\"twitter:data1\" content=\"21 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/\",\"name\":\"Definindo arquitetura de software e o papel do arquiteto \/ Introdu\u00e7\u00e3o v3.01 - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/02\/img-capitulo-3.jpg\",\"datePublished\":\"2022-03-11T16:31:42+00:00\",\"dateModified\":\"2024-01-11T20:50:48+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/02\/img-capitulo-3.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/02\/img-capitulo-3.jpg\",\"width\":1200,\"height\":600},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Volume 1\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Definindo arquitetura de software e o papel do arquiteto \/ Introdu\u00e7\u00e3o v3.01\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"name\":\"Manual do Arquiteto de Software\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"pt-BR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\",\"name\":\"EximiaCo\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"width\":150,\"height\":150,\"caption\":\"EximiaCo\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/facebook.com\/eximiaco\",\"https:\/\/x.com\/eximiaco\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Definindo arquitetura de software e o papel do arquiteto \/ Introdu\u00e7\u00e3o v3.01 - Manual do Arquiteto de Software","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/","og_locale":"pt_BR","og_type":"article","og_title":"Definindo arquitetura de software e o papel do arquiteto \/ Introdu\u00e7\u00e3o v3.01 - Manual do Arquiteto de Software","og_description":"Desenvolvimento de software \u00e9 cada vez mais relevante. \u00c9 dif\u00edcil imaginar qualquer atividade, em qualquer empresa, em qualquer segmento, que n\u00e3o seja suportada, direta ou indiretamente, por algum tipo de sistema digital. Software bem-feito \u00e9, cada vez mais, premissa para a competitividade. Logo, mesmo empresas que n\u00e3o se declaram tecnol\u00f3gicas, tem a tecnologia como compet\u00eancia […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-11T20:50:48+00:00","og_image":[{"width":1200,"height":600,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/02\/img-capitulo-3.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"21 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/","name":"Definindo arquitetura de software e o papel do arquiteto \/ Introdu\u00e7\u00e3o v3.01 - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/02\/img-capitulo-3.jpg","datePublished":"2022-03-11T16:31:42+00:00","dateModified":"2024-01-11T20:50:48+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/02\/img-capitulo-3.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/02\/img-capitulo-3.jpg","width":1200,"height":600},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/definindo-arquitetura-de-software-e-o-papel-do-arquiteto-introducao-v3-01\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/"},{"@type":"ListItem","position":2,"name":"Volume 1","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/"},{"@type":"ListItem","position":3,"name":"Definindo arquitetura de software e o papel do arquiteto \/ Introdu\u00e7\u00e3o v3.01"}]},{"@type":"WebSite","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","name":"Manual do Arquiteto de Software","description":"","publisher":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"pt-BR"},{"@type":"Organization","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization","name":"EximiaCo","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","logo":{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","width":150,"height":150,"caption":"EximiaCo"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/eximiaco","https:\/\/x.com\/eximiaco"]}]}},"_links":{"self":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1\/3640","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1"}],"about":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/types\/volume-1"}],"replies":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/comments?post=3640"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/366"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=3640"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=3640"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=3640"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=3640"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=3640"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}