{"id":4095,"date":"2022-05-03T09:45:41","date_gmt":"2022-05-03T12:45:41","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=4095"},"modified":"2024-01-12T11:26:02","modified_gmt":"2024-01-12T14:26:02","slug":"documentacao-arquitetural-na-medida-certa","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/documentacao-arquitetural-na-medida-certa\/","title":{"rendered":"Cap 1.3 Documenta\u00e7\u00e3o arquitetural na medida certa"},"content":{"rendered":"Muitos times qualificados e profissionais experientes s\u00e3o resistentes a ideia de documentar arquitetura de software.\u00a0<\/strong>A raiz dessa resist\u00eancia costuma estar em um passado cheio de burocracia exagerada e processos\u00a0up-front\u00a0<\/em>para design. H\u00e1 tamb\u00e9m quem fa\u00e7a associa\u00e7\u00e3o de documenta\u00e7\u00e3o com “arquitetos de torre de marfim”, que consomem tempo e outros recursos preciosos de projetos elaborando diagramas que ningu\u00e9m consulta ou mesmo se importa. Entretanto, negar a utilidade de boa documenta\u00e7\u00e3o arquitetural pode ser um problema grande, principalmente em projetos mais complexos.<\/strong>\n
\n

Se\u00a0 o prop\u00f3sito das pr\u00e1ticas de arquitetura de software \u00e9 aumentar as chances de que os objetivos do neg\u00f3cio sejam atingidos – respeitando restri\u00e7\u00f5es e atributos de qualidade – \u00e9 importante disseminar esses par\u00e2metros, com o m\u00ednimo de ambiguidade e subjetividade, durante todo o ciclo de vida do software que, ali\u00e1s, pode durar d\u00e9cadas come\u00e7ando muito antes da primeira linha de c\u00f3digo ser escrita.<\/p>\nSeja por motivos nobres, como aumentar o alinhamento de prop\u00f3sito que autoriza autonomia de atua\u00e7\u00e3o, ou tristes, como gerar evid\u00eancias de trabalho ou de acordos passados, documenta\u00e7\u00e3o arquitetural exerce papel importante e \u00e9 \u00fatil desde que feita na medida certa e focada para quem a ir\u00e1 utilizar.<\/strong>\n

Considera\u00e7\u00f5es sobre Gest\u00e3o do Conhecimento<\/h2>\n

\u00c9 comum, quando discute-se gest\u00e3o do conhecimento, tratar da elabora\u00e7\u00e3o e manuten\u00e7\u00e3o de documenta\u00e7\u00f5es. A falha, entretanto, est\u00e1 em assumir que gerenciar conhecimento implica em “apenas” elaborar documenta\u00e7\u00f5es. Na verdade, o processo \u00e9 consideravelmente mais complexo que isso.<\/strong><\/p>\n

H\u00e1 dois tipos de conhecimento: t\u00e1cito e expl\u00edcito.<\/strong> O conhecimento t\u00e1cito \u00e9 aquele que “sabemos por fazer”, mas que n\u00e3o necessariamente conseguimos explicar. J\u00e1 o conhecimento expl\u00edcito \u00e9 aquele que est\u00e1 codificado, geralmente em documenta\u00e7\u00f5es. A dissemina\u00e7\u00e3o do conhecimento, logo, sua perpetua\u00e7\u00e3o, acontece pela transi\u00e7\u00e3o cont\u00ednua do conhecimento de t\u00e1cito para expl\u00edcito e, no outro sentido, de expl\u00edcito para t\u00e1cito.<\/p>\n

\"\"<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" A socializa\u00e7\u00e3o do conhecimento \u00e9 fundamental, mas insuficiente quando se deseja atingir escala.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Documenta\u00e7\u00e3o arquitetural \u00e9 a explicita\u00e7\u00e3o do conhecimento e deve emergir como resultado dos eventos de socializa\u00e7\u00e3o. Mais tarde, deve ser utilizada para treinar pessoas facilitando novos eventos de socializa\u00e7\u00e3o.<\/p>\n

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

Gest\u00e3o do conhecimento<\/p>\r\nVivemos hoje na sociedade do conhecimento, sociedade essa que n\u00e3o usa m\u00e1quinas, linhas de montagens ou rob\u00f4s como \u201cmeios de produ\u00e7\u00e3o\u201d. Seus meios de produ\u00e7\u00e3o est\u00e3o na cabe\u00e7a e nas m\u00e3os das pessoas que nela trabalham. Este livro \u00e9 uma corajosa tentativa de repensar a gest\u00e3o a partir da perspectiva do conhecimento. Como devemos pensar sobre estrat\u00e9gia, organiza\u00e7\u00e3o, branding, competi\u00e7\u00e3o global ou TI do ponto de vista do conhecimento? \r\n

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

Suporte a lideran\u00e7a situacional<\/h2>\n

Naturalmente, pessoas envolvidas com atividades relacionadas a arquitetura exercem alguma forma de lideran\u00e7a nos times em que atuam.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" L\u00edder \u00e9 todo aquele que possui seguidores.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Lideran\u00e7a \u00e9 um exerc\u00edcio din\u00e2mico e contextual. O comportamento do l\u00edder acaba se adaptando ao n\u00edvel de prontid\u00e3o (entendo maturidade) para fazer o trabalho daqueles que s\u00e3o liderados. As mudan\u00e7as de comportamento tem rela\u00e7\u00e3o com o n\u00edvel de dire\u00e7\u00e3o e apoio.<\/p>\n

\"\"<\/p>\n

Quando o arquiteto precisa exercer lideran\u00e7a mais diretiva, sobretudo por estar atuando com um time com menor senioridade, se beneficiar\u00e1 da documenta\u00e7\u00e3o para dar mais clareza sobre o que precisa ser feito.<\/p>\n

Quando o arquiteto atua como\u00a0coaching, <\/em>desenvolvendo o time, se beneficiar\u00e1 da documenta\u00e7\u00e3o tanto para fornecer quanto para receber insights\u00a0<\/em>do time.<\/p>\n

Quando o arquiteto atua como “consultor”, apoiando o time do desenvolvimento de solu\u00e7\u00f5es, opinando, se beneficiar\u00e1 da documenta\u00e7\u00e3o como registro e mecanismo para “simplificar” sua vis\u00e3o para o time.<\/p>\n

Finalmente, quando o arquiteto atua como “delegador”, se beneficiar\u00e1 da documenta\u00e7\u00e3o como mecanismo de propagar os resultados que o time consegue atingir.<\/p>\n

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

Psicologia para administradores<\/p>\r\nPsicologia para Administradores se destina a todos os que trabalham em \u00e1reas em que \u00e9 preciso tomar decis\u00f5es. O livro concentra a aten\u00e7\u00e3o na intera\u00e7\u00e3o entre as pessoas, na motiva\u00e7\u00e3o e na lideran\u00e7a. \u00c9 o livro que apresentou para o mundo o conceito de lideran\u00e7a situacional.\r\n

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

Documenta\u00e7\u00e3o arquitetural em processos \u00e1geis<\/h2>\n
\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

Atrav\u00e9s desse trabalho, passamos a valorizar [..] Software em funcionamento mais que documenta\u00e7\u00e3o abrangente;<\/em><\/p>\n

\r\n

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

Os processos \u00e1geis de desenvolvimento de software s\u00e3o uma rea\u00e7\u00e3o a m\u00e9todos pesados que eram comuns no passado (com resqu\u00edcios fortes dentro de muitas empresas ainda hoje, infelizmente).<\/p>\n

Por causa de um rigor dif\u00edcil de justificar hoje em dia, era comum que se consumisse semanas elaborando documenta\u00e7\u00f5es detalhadas, n\u00e3o apenas em n\u00edvel arquitetural mas bem “perto do c\u00f3digo”, para um esfor\u00e7o de implementa\u00e7\u00e3o que iria durar apenas dias. A justificativa era uma pretensa garantia de qualidade que nunca se confirmava na pr\u00e1tica. Felizmente, essa j\u00e1 n\u00e3o \u00e9 mais a realidade, embora, talvez, hoje pequemos pelo contr\u00e1rio.<\/p>\n

\n

Na \u00e2nsia de eliminar etapas desnecess\u00e1rias para o desenvolvimento de sistemas de software, muitos “agilistas” resistem n\u00e3o apenas a documenta\u00e7\u00e3o arquitetural mas a tudo que esteja relacionado com t\u00e9cnicas para a pr\u00e1tica da arquitetura. Importante, entretanto, destacar que essa posi\u00e7\u00e3o n\u00e3o \u00e9 universal. Muitos expoentes das pr\u00e1ticas \u00e1geis – incluindo Martin Fowler, Robert Martin, Scott Ambler – reconhecem que essa conduta \u00e9 perigosa.<\/p>\n

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

Os m\u00e9todos \u00e1geis n\u00e3o se op\u00f5em \u00e0 documenta\u00e7\u00e3o, apenas \u00e0 documenta\u00e7\u00e3o sem valor. Documentos que auxiliam a pr\u00f3pria equipe podem ter valor, mas somente se forem mantidos atualizados.<\/em><\/p>\n

\r\n

Nygard<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nAtividades de refatora\u00e7\u00e3o para corrigir escolhas ruins de arquitetura s\u00e3o, muitas vezes, caras demais para serem colocadas em pr\u00e1tica.<\/strong> Por isso, \u00e9 importante que decis\u00f5es razo\u00e1veis sejam adotadas cedo e, para que isso aconte\u00e7a, s\u00e3o necess\u00e1rias aplica\u00e7\u00e3o de algumas t\u00e9cnicas incluindo, acredito, elabora\u00e7\u00e3o e manuten\u00e7\u00e3o de boa documenta\u00e7\u00e3o arquitetural. Resistir a pr\u00e1ticas arquiteturais, inclusive documenta\u00e7\u00e3o na medida certa, tem pouco haver com agilidade, mas com teimosia, falta de conhecimento profundo ou imaturidade.<\/strong>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Boa documenta\u00e7\u00e3o \u00e9 fundamento para a agilidade.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

O que a documenta\u00e7\u00e3o arquitetural N\u00c3O \u00e9<\/h2>\n

A documenta\u00e7\u00e3o arquitetural trata das decis\u00f5es de design<\/em> com impacto determinante para o atendimento dos objetivos de neg\u00f3cio, respeito a restri\u00e7\u00f5es e atributos de qualidade. <\/strong><\/p>\nRaramente, uma decis\u00e3o arquitetural, estar\u00e1 associada a uma feature\u00a0<\/em>especificamente.<\/strong> Dessa forma “System Engineering Documents<\/em>” – documentos que detalham prop\u00f3sitos e implica\u00e7\u00f5es do desenvolvimento de funcionalidades, muitas vezes, afetando a arquitetura -, embora importantes, n\u00e3o s\u00e3o documentos arquiteturais.\u00a0\n

\nEspecifica\u00e7\u00f5es exaustivas de requisitos funcionais ou n\u00e3o funcionais, embora importantes para a elabora\u00e7\u00e3o da arquitetura, tamb\u00e9m n\u00e3o s\u00e3o documentos arquiteturais.<\/strong> Tais documentos, ali\u00e1s, s\u00e3o\u00a0inputs\u00a0<\/em>para as atividades de arquitetura, mas n\u00e3o s\u00e3o necessariamente formulados, tampouco mantidos, por arquitetos.\n
\n

Documenta\u00e7\u00e3o arquitetural, finalmente, tamb\u00e9m n\u00e3o \u00e9 documenta\u00e7\u00e3o para usu\u00e1rios finais.<\/p>\n

Documenta\u00e7\u00e3o arquitetural e a comunica\u00e7\u00e3o<\/h2>\nComunica\u00e7\u00e3o \u00e9 parte fundamental de qualquer atividade relacionada \u00e0 engenharia de software<\/b>. Quanto melhor (n\u00e3o necessariamente ampla) a comunica\u00e7\u00e3o, maiores as chances de que exista alinhamento de prop\u00f3sito e que autonomia de atua\u00e7\u00e3o seja poss\u00edvel. A documenta\u00e7\u00e3o arquitetural \u00e9 ferramenta para a comunica\u00e7\u00e3o em projetos de sistemas de software.\n
\n
\r\n

Comunica\u00e7\u00e3o nem sempre \u00e9 uma coisa boa<\/p>\r\n<\/p>\n

Skelton e Pais fazem uma advert\u00eancia importante:<\/p>\n

Se a organiza\u00e7\u00e3o tem uma expectativa de que \u201ctodos devem ver todas as mensagens do chat\u201d ou \u201ctodos precisam comparecer \u00e0s massivas reuni\u00f5es standup\u201d ou \u201ctodos precisam estar presentes nas reuni\u00f5es\u201d para aprovar as decis\u00f5es, ent\u00e3o temos um problema de design da organiza\u00e7\u00e3o. A lei de Conway sugere que este tipo de comunica\u00e7\u00e3o muitos-para-muitos tende a produzir sistemas monol\u00edticos, emaranhados, altamente acoplados e interdependentes que n\u00e3o suportam fluxo r\u00e1pido. Mais comunica\u00e7\u00e3o n\u00e3o \u00e9 necessariamente uma coisa boa.<\/strong><\/em><\/p>\n

<\/div>\n

Os componentes de um software, evidentes em sua arquitetura, interagem e s\u00e3o desenvolvidos por times que tamb\u00e9m precisam interagir.<\/strong> Ambos, componentes e times, precisam de interfaces qualificadas, sem revelar seus funcionamentos internos, para que comunica\u00e7\u00e3o eficiente aconte\u00e7a.<\/p>\n

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

Arquitetura de software \u00e9 a divis\u00e3o prudente de um todo em partes, com rela\u00e7\u00f5es espec\u00edficas entre essas partes. Esse particionamento \u00e9 o que permite que grupos de pessoas – geralmente separados por limites organizacionais, geogr\u00e1ficos e at\u00e9 mesmo de fusos hor\u00e1rios – trabalhem em conjunto de forma cooperativa e produtiva para resolver um problema muito maior do que qualquer um deles resolve individualmente.<\/i><\/p>\n

\r\n

Clements et al.<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nDocumenta\u00e7\u00e3o arquitetural bem-feita exerce papel importante na comunica\u00e7\u00e3o. <\/b>H\u00e1 quem defenda que o c\u00f3digo, testes, scripts <\/i>para automa\u00e7\u00e3o de deploy<\/i> e gr\u00e1ficos din\u00e2micos gerados por ferramentas APM s\u00e3o suficientes. Pessoalmente, n\u00e3o concordo com essa vis\u00e3o pois todos esses artefatos, embora fundamentais para a comunica\u00e7\u00e3o, revelam apenas o “como” e dificilmente o “porqu\u00ea” das coisas.\n

\nMesmo o melhor projeto de arquitetura de um software ser\u00e1 in\u00fatil se as pessoas n\u00e3o forem capazes de entend\u00ea-lo direito, ao longo do tempo, para coloc\u00e1-lo em pr\u00e1tica ou, pior, entend\u00ea-lo errado implantando-o incorretamente.<\/strong> A documenta\u00e7\u00e3o bem-feita da arquitetura registra e explica os “porqu\u00eas” das decis\u00f5es e deve facilitar o entendimento do projeto de software, reduzindo chances de\u00a0 equ\u00edvocos de entendimento.\nDocumenta\u00e7\u00e3o arquitetural fala sobre a arquitetura hoje, liberando o arquiteto para que ele seja mais produtivo, tirando d\u00favidas dos envolvidos e, principalmente, fala sobre a arquitetura “amanh\u00e3”, quando outras pessoas, fora do time original, forem respons\u00e1veis por manter o sistema. Documenta\u00e7\u00e3o insuficiente ou ruim aumenta as chances de eros\u00e3o arquitetural!<\/b>\n
\n

(Documenta\u00e7\u00e3o da) arquitetura de software e a complexidade<\/h2>\nProjetos de software t\u00eam se tornado maiores e mais complexos com o passar dos anos.<\/strong> Esse aumento da complexidade dos sistemas tem sido compensada, de alguma forma com o surgimento de IDEs inteligentes, compiladores sofisticados, linguagens de programa\u00e7\u00e3o mais expressivas, frameworks <\/i>e componentes prontos. A complexidade dos projetos de software tamb\u00e9m pode ser mitigada pela ado\u00e7\u00e3o de pr\u00e1ticas eficientes de arquitetura de software.<\/strong>\n
\n

H\u00e1 pelo menos tr\u00eas contribui\u00e7\u00f5es not\u00e1veis da arquitetura de software para o combate da complexidade:<\/p>\n

    \n
  1. Divis\u00e3o do problema <\/b>– estruturando software em componentes que possam ser mantidos por times pequenos e que, depois, podem ser combinados, formando um sistema maior, a arquitetura autoriza, pelo menos por um tempo, a desenvolver partes de um software sem conhecer detalhes sobre como as outras funcionam. A \u00eanfase passa ser nas intera\u00e7\u00f5es.<\/li>\n
  2. Aproveitamento do conhecimento dos times <\/b>– facilitando, a partir de componentes pequenos e desacoplados, o reaproveitamento do conhecimento dos desenvolvedores na implementa\u00e7\u00e3o do projeto (ex: algu\u00e9m que j\u00e1 implementou um mecanismo de cobran\u00e7a, ter\u00e1 uma boa ideia de como implementar essa solu\u00e7\u00e3o). Tamb\u00e9m crescem as chances de encontrar boas fontes de conhecimento em livros, palestras, descri\u00e7\u00e3o de padr\u00f5es, projetos de c\u00f3digo aberto e mais.<\/li>\n
  3. Ado\u00e7\u00e3o de abstra\u00e7\u00f5es <\/b>– facilitando, ao ignorar detalhes menos significativos, os esfor\u00e7os para desenvolver solu\u00e7\u00f5es.<\/b><\/li>\n<\/ol>\n
    \nTanto os crit\u00e9rios utilizados na “divis\u00e3o do problema” como as abstra\u00e7\u00f5es utilizadas para desenvolver solu\u00e7\u00f5es se perdem facilmente em detalhes de implementa\u00e7\u00e3o e ficam melhor representados em boas documenta\u00e7\u00f5es fora do c\u00f3digo.\n

    Atividades suportadas pela documenta\u00e7\u00e3o arquitetural<\/h2>\n

    Falar que a documenta\u00e7\u00e3o ajuda a melhorar a arquitetura e facilita a comunica\u00e7\u00e3o \u00e9 importante, mas um tanto abstrato. Dando “um passo \u00e0 frente”, ficam evidentes tr\u00eas usos comuns para a documenta\u00e7\u00e3o:<\/p>\n

      \n
    1. Educa\u00e7\u00e3o, seja para novos membros do time, analistas externos ou at\u00e9 mesmo um novo arquiteto.<\/li>\n
    2. Alinhamento com stakeholders<\/i><\/li>\n
    3. Base para a continuidade da constru\u00e7\u00e3o e an\u00e1lise do software.<\/li>\n<\/ol>\n
      \nEm termos econ\u00f4micos, a documenta\u00e7\u00e3o da arquitetura \u00e9 essencial porque ela reduz o custo total de propriedade do software. Ali\u00e1s, a medida certa de quanto documentar \u00e9 determinada pela a capacidade de “c\u00f3digo+documenta\u00e7\u00e3o” custar menos do que “apenas c\u00f3digo”. Ou seja, precisa ser mais barato e menos arriscado adicionar features ou fazer ajustes quando h\u00e1 boa documenta\u00e7\u00e3o arquitetural dispon\u00edvel.<\/b>\u00a0\n
      \r\n\r\n\r\n\r\n
      \"\"<\/td>\r\n\"\" O esfor\u00e7o precisa ser compat\u00edvel com o risco de falha no projeto. Cada projeto enfrenta diferentes riscos e n\u00e3o h\u00e1 uma \u00fanica forma de fazer de arquitetura de software.<\/strong><\/em>\r\n

      Fairbanks<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nA utilidade de um documento arquitetural \u00e9 aquele onde o custo para sua produ\u00e7\u00e3o \u00e9 menor do que as economias que este ir\u00e1 gerar em outras atividades, ou ainda, por sua contribui\u00e7\u00e3o para mitiga\u00e7\u00e3o de riscos. <\/b>Documento \u00e9 \u00fatil se \u00e9 consultado, em algum momento. Se um documento n\u00e3o for utilizado ativamente, valer\u00e1 menos do que os bytes <\/i>comprometidos com ele.\n

      \n

      <\/p>\n

      Em minha atua\u00e7\u00e3o como consultor \u00e9 comum encontrar software, principalmente em empresas menores, sem qualquer tipo de documenta\u00e7\u00e3o. Por outro lado, tamb\u00e9m n\u00e3o \u00e9 incomum, principalmente em empresas maiores, encontrar documenta\u00e7\u00e3o t\u00e3o \u201cabstrata\u201d e desatualizada que n\u00e3o resolve d\u00favida alguma. H\u00e1 tanta burocracia envolvida que toda informa\u00e7\u00e3o relevante, quando h\u00e1, fica escondida atr\u00e1s de formatos e normas. Muitas vezes, as \u201cdores\u201d que geram a necessidade de consultoria s\u00e3o provenientes da falta de alinhamento do time sob aspectos b\u00e1sicos da arquitetura. Quase sempre, os problemas \u201cse resolvem sozinhos\u201d assim que se inicia o esfor\u00e7o para gerar documenta\u00e7\u00e3o b\u00e1sica, por\u00e9m de qualidade.<\/b><\/p>\n

      O que (geralmente) precisa ser documentado<\/h2>\n

      Se a documenta\u00e7\u00e3o \u00e9 boa quando o custo de sua elabora\u00e7\u00e3o \u00e9 compensado pela redu\u00e7\u00e3o de custos em outras atividades ou pela mitiga\u00e7\u00e3o de riscos, ent\u00e3o, sua manuten\u00e7\u00e3o precisa custar o m\u00ednimo poss\u00edvel. De forma objetiva, a documenta\u00e7\u00e3o de arquitetura \u00fatil para os projetos demanda atualiza\u00e7\u00f5es menos frequentes.<\/p>\n

      A documenta\u00e7\u00e3o arquitetural deve registrar, primeiro, aspectos que v\u00e3o permanecer verdadeiros por mais tempo.<\/b> Sem d\u00favidas, se encaixam nessa caracter\u00edstica algum detalhamento das restri\u00e7\u00f5es e dos atributos de qualidade.<\/p>\n

      A documenta\u00e7\u00e3o arquitetural tamb\u00e9m precisa dar \u00eanfase na estrat\u00e9gia – padr\u00e3o coerente para tomada de decis\u00f5es – que ir\u00e1 autorizar mudan\u00e7as. <\/b>Ou seja, que crit\u00e9rios devem ser observados para determinar a necessidade de adicionar, remover ou substituir a implementa\u00e7\u00e3o dos componentes.<\/p>\n

      Finalmente, a documenta\u00e7\u00e3o tamb\u00e9m deve expor a estrutura atual e suas propriedades. <\/b>Entretanto, quanto maior for a fragmenta\u00e7\u00e3o de componentes de um software, por exemplo, em arquiteturas baseadas em microsservi\u00e7os – extremamente din\u00e2micos e auto organizados, com estrat\u00e9gias de descoberta sofisticadas – menor ser\u00e1 o incentivo para documentar suas intera\u00e7\u00f5es. Nesses casos, ferramentas que permitam a “captura” da arquitetura-do-momento automaticamente, como, por exemplo, solu\u00e7\u00f5es APM s\u00e3o essenciais.<\/p>\n

      Considera\u00e7\u00f5es sobre “Architecture Haiku”<\/h2>\n

      George Fairbanks<\/a> prop\u00f4s a ideia do Architecture Haiku – uma descri\u00e7\u00e3o de design super concisa de uma p\u00e1gina, r\u00e1pida de construir.<\/p>\n

      A provoca\u00e7\u00e3o \u00e9 colocar um\u00a0overview\u00a0<\/em>da arquitetura em uma \u00fanica folha de papel A4. Assim, com menos espa\u00e7os para indecis\u00f5es ou prolongamentos. Eventualmente, pode n\u00e3o haver espa\u00e7o para diagramas – o que \u00e0 primeira vista parece loucura, mas talvez seja muito brilhante!<\/p>\n

      Com t\u00e3o pouco espa\u00e7o, escolher as informa\u00e7\u00f5es certas a serem inclu\u00eddas \u00e9 extremamente importante. Aqui est\u00e1 o que Fairbanks recomenda:<\/p>\n