Arquitetura de Software e o Arquiteto - Secomp Londrina - Vinicius Quaiato

955 views
839 views

Published on

Palestra explicando a o que é e a importância da arquitetura de software. Mostrando além disso as características, habilidades e skills do arquiteto de software e os motivos das brigas entre arquiteto x desenvolvedores.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
955
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Arquitetura de Software e o Arquiteto - Secomp Londrina - Vinicius Quaiato

  1. 1. Arquitetura de Software um pouco sobre arquitetura e o arquiteto Vinicius QuaiatoWednesday, September 14, 11
  2. 2. Arquitetura de Software um pouco sobre arquitetura e o arquiteto Vinicius QuaiatoWednesday, September 14, 11
  3. 3. @vquaiato (vinicius quaiato) programador palestrante pai santista entusiasta consultor etc, etc, etcWednesday, September 14, 11
  4. 4. @vquaiato (vinicius quaiato) http://viniciusquaiato.com http://crafters.com.br vinicius.quaiato@gmail.comWednesday, September 14, 11
  5. 5. um blogWednesday, September 14, 11
  6. 6. um podcastWednesday, September 14, 11
  7. 7. uma comunidadeWednesday, September 14, 11
  8. 8. um(ns) eventoWednesday, September 14, 11
  9. 9. um(ns) eventoWednesday, September 14, 11
  10. 10. começandoWednesday, September 14, 11
  11. 11. fazer software não é fácilWednesday, September 14, 11
  12. 12. bons projetos de software, reutilizáveis, são ainda mais difíceisWednesday, September 14, 11
  13. 13. solução spaguettiWednesday, September 14, 11
  14. 14. difícil de manterWednesday, September 14, 11
  15. 15. difícil de evoluirWednesday, September 14, 11
  16. 16. difícil de trabalharWednesday, September 14, 11
  17. 17. e a vida fica tristeWednesday, September 14, 11
  18. 18. um dos grandes problemas em softwareWednesday, September 14, 11
  19. 19. incrível vontade de sair fazendoWednesday, September 14, 11
  20. 20. confiamos muito em nosso conhecimentoWednesday, September 14, 11
  21. 21. mas nossa visão é limitadaWednesday, September 14, 11
  22. 22. isso não é um defeito, apenas um fatoWednesday, September 14, 11
  23. 23. alguns problemas emergem neste cenárioWednesday, September 14, 11
  24. 24. há enorme fragilidadeWednesday, September 14, 11
  25. 25. o software passa a quebrar com frequênciaWednesday, September 14, 11
  26. 26. a menor alteração causa efeitos catastróficosWednesday, September 14, 11
  27. 27. <filosofando>Wednesday, September 14, 11
  28. 28. “ o bater de asas de uma borboleta em Tóquio pode provocar um furacão em Nova IorqueWednesday, September 14, 11
  29. 29. </filosofando>Wednesday, September 14, 11
  30. 30. o software não é sólido, não passa confiançaWednesday, September 14, 11
  31. 31. o time e principalmente o cliente têm medoWednesday, September 14, 11
  32. 32. as coisas são confusasWednesday, September 14, 11
  33. 33. não existe coerência lógica e/ou físicaWednesday, September 14, 11
  34. 34. gasta-se tempo tentando entender o que faz o que(e onde)Wednesday, September 14, 11
  35. 35. a bagunça não é organizadaWednesday, September 14, 11
  36. 36. não se sabe o que está em uso e o que é lixoWednesday, September 14, 11
  37. 37. <fato>Wednesday, September 14, 11
  38. 38. em software o que não está em uso é lixoWednesday, September 14, 11
  39. 39. </fato>Wednesday, September 14, 11
  40. 40. aquilo que você jura fazer X faz YWednesday, September 14, 11
  41. 41. tudo é incerto neste cenárioWednesday, September 14, 11
  42. 42. corrigir um problema é outro problemaWednesday, September 14, 11
  43. 43. adicionar uma funcionalidade é um problemaWednesday, September 14, 11
  44. 44. não há previsibilidade de tempo e/ou esforçoWednesday, September 14, 11
  45. 45. estamos sempre tateando no escuroWednesday, September 14, 11
  46. 46. o que deveria ser simples é muito complexoWednesday, September 14, 11
  47. 47. o muito complexo é impossívelWednesday, September 14, 11
  48. 48. tudo isso somado resulta em uma enorme falta de flexibilidadeWednesday, September 14, 11
  49. 49. as bases sobre as quais criamos o software não são sólidasWednesday, September 14, 11
  50. 50. mas quais bases?Wednesday, September 14, 11
  51. 51. é preciso pensar na fundação do nosso sistemaWednesday, September 14, 11
  52. 52. pensar suas basesWednesday, September 14, 11
  53. 53. compreender estas basesWednesday, September 14, 11
  54. 54. organizar o sistemaWednesday, September 14, 11
  55. 55. trabalhar com abstraçõesWednesday, September 14, 11
  56. 56. separação de responsabilidadesWednesday, September 14, 11
  57. 57. traçar um ‘road map’ do que é necessárioWednesday, September 14, 11
  58. 58. existem muitas outras características mas podemos dizer que estas definem um pouco o que éWednesday, September 14, 11
  59. 59. arquitetura de softwareWednesday, September 14, 11
  60. 60. ou de uma maneira mais formalWednesday, September 14, 11
  61. 61. “ organização fundamental de um sistema incorporada em seus componentes, suas relações entre si e entre o ambiente e os princípios guiando seu design e evolução - IEEEWednesday, September 14, 11
  62. 62. ou de uma maneira menos formalWednesday, September 14, 11
  63. 63. “ arquitetura é aquela coisa que é difícil mudarWednesday, September 14, 11
  64. 64. os significados e definições(de arquitetura) são um pouco nebulososWednesday, September 14, 11
  65. 65. algumas pessoas não acreditam que ela existaWednesday, September 14, 11
  66. 66. o fato é que ela sempre está presenteWednesday, September 14, 11
  67. 67. pode não ter sido definida, ou bem definida, mas ela existeWednesday, September 14, 11
  68. 68. até mesmo na forma de uma péssima arquiteturaWednesday, September 14, 11
  69. 69. quais benefícios existem em pensar na arquitetura?Wednesday, September 14, 11
  70. 70. conhecimentoWednesday, September 14, 11
  71. 71. clareza e organizaçãoWednesday, September 14, 11
  72. 72. solidez / robustezWednesday, September 14, 11
  73. 73. certezasWednesday, September 14, 11
  74. 74. firmeza na tomada de decisões e cálculo de tradeoffsWednesday, September 14, 11
  75. 75. decisões tomadas de forma mais racionalWednesday, September 14, 11
  76. 76. previsão e mitigação de riscosWednesday, September 14, 11
  77. 77. analisar, gerenciar e planejar mudançasWednesday, September 14, 11
  78. 78. mas essa tal arquitetura não cai do céuWednesday, September 14, 11
  79. 79. para que ela exista de forma eficiente alguém precisa criá-laWednesday, September 14, 11
  80. 80. alguém precisa pensar em tudo issoWednesday, September 14, 11
  81. 81. arquiteto de softwareWednesday, September 14, 11
  82. 82. <palavra aqui> mais mal compreendida em TI profissão, papel, cargo, habilidade, títuloWednesday, September 14, 11
  83. 83. além disso o termo gera algum <palavra aqui> stress, desejo, conflito, rixaWednesday, September 14, 11
  84. 84. mas o que é o arquiteto?Wednesday, September 14, 11
  85. 85. “ o papel arquiteto de TI é resolver um problema definindo um sistema que possa ser implmentado usando tecnologia.Wednesday, September 14, 11
  86. 86. “ um bom arquiteto define sistemas utilizando abstrações e métodos provados para um conjunto de tecnologias criando uma solução extensível e manutenível.Wednesday, September 14, 11
  87. 87. quais conhecimentos um arquiteto possui?Wednesday, September 14, 11
  88. 88. um bom entendimento do domínio do problemaWednesday, September 14, 11
  89. 89. o problema é específico de um segmento?Wednesday, September 14, 11
  90. 90. quais desafios um segmento possui com relação aos outros?Wednesday, September 14, 11
  91. 91. perspicácia técnicaWednesday, September 14, 11
  92. 92. não há como conhecer profundamente toda e cada tecnologiaWednesday, September 14, 11
  93. 93. mas é necessário conhecer o propósito por detrás de seu usoWednesday, September 14, 11
  94. 94. o arquiteto deve entender a quais requisitos a tecnologia atendeWednesday, September 14, 11
  95. 95. conceitualizarWednesday, September 14, 11
  96. 96. comunicar a parte técnica e a não técnicaWednesday, September 14, 11
  97. 97. capaz de explicar para o time de negócios e o time de desenvolvimentoWednesday, September 14, 11
  98. 98. mais que explicar: dar visibilidade e clarezaWednesday, September 14, 11
  99. 99. conhecimento de padrõesWednesday, September 14, 11
  100. 100. criam um vocabulário e entendimento concisosWednesday, September 14, 11
  101. 101. possibilita o uso de soluções provadas para o cenárioWednesday, September 14, 11
  102. 102. <alerta>Wednesday, September 14, 11
  103. 103. o uso indiscriminado e aleatório de padrões causa doenças graves e pode levar o projeto à morteWednesday, September 14, 11
  104. 104. </alerta>Wednesday, September 14, 11
  105. 105. Wednesday, September 14, 11
  106. 106. quais competências um arquiteto possui?Wednesday, September 14, 11
  107. 107. liderançaWednesday, September 14, 11
  108. 108. o arquiteto define a fundação dos sitemasWednesday, September 14, 11
  109. 109. possibilita que os outros enxerguem o que precisa ser feito para atingir o objetivoWednesday, September 14, 11
  110. 110. cabe ao arquiteto tomadas de decisões e assumir estas decisõesWednesday, September 14, 11
  111. 111. em muitas vezes não são simplesWednesday, September 14, 11
  112. 112. em muitas vezes não são as melhores escolhas técnicasWednesday, September 14, 11
  113. 113. visão estratégicaWednesday, September 14, 11
  114. 114. deve conseguir observar as coisas como um todoWednesday, September 14, 11
  115. 115. transformar o todo em partes simples de alcançarWednesday, September 14, 11
  116. 116. fazer escolhas que maximizem ROIWednesday, September 14, 11
  117. 117. gestão de relações humanasWednesday, September 14, 11
  118. 118. lida com pessoas de negócio não somente internasWednesday, September 14, 11
  119. 119. precisa compreender implicações políticas para as decisõesWednesday, September 14, 11
  120. 120. deve ser acessívelWednesday, September 14, 11
  121. 121. boa comunicaçãoWednesday, September 14, 11
  122. 122. deve ser capaz de ouvir as áreas de negócio, gerenciais e técnicasWednesday, September 14, 11
  123. 123. deve ser capaz de explicar modelos para a área de negócios, as necessidades à gerenência e a arquitetura aos técnicosWednesday, September 14, 11
  124. 124. deve saber utilizar um vocabulário próprio para cada situaçãoWednesday, September 14, 11
  125. 125. todos os arquitetos são iguas?Wednesday, September 14, 11
  126. 126. nãoWednesday, September 14, 11
  127. 127. arquitetos podem atuar com: <cargo aqui> CIO, gerentes, analistas de negócio, programadoresWednesday, September 14, 11
  128. 128. Wednesday, September 14, 11
  129. 129. enterprise architectWednesday, September 14, 11
  130. 130. garante que os investimentos de TI estão alinhados com a estratégia de negócios da empresaWednesday, September 14, 11
  131. 131. implementa a visão e estratégia do CIO em TIWednesday, September 14, 11
  132. 132. solution architectWednesday, September 14, 11
  133. 133. implementa programas estratégicos de TIWednesday, September 14, 11
  134. 134. possui conhecimentos técnicos em diversas plataformasWednesday, September 14, 11
  135. 135. lida com times técnicos e de negóciosWednesday, September 14, 11
  136. 136. technical architectWednesday, September 14, 11
  137. 137. profundo conhecimento técnico em uma tecnologia/plataformaWednesday, September 14, 11
  138. 138. conhece e entende seus pontos fortes e fracosWednesday, September 14, 11
  139. 139. define a melhor arquitetura possível com a tecnologia em questãoWednesday, September 14, 11
  140. 140. mas de fato precisamos de um arquiteto?Wednesday, September 14, 11
  141. 141. alguém precisa assumir este papelWednesday, September 14, 11
  142. 142. ainda que formalmente ninguém o tenha assumido, alguém o desempenhaWednesday, September 14, 11
  143. 143. talvez não seja alguém com todas as características de um arquitetoWednesday, September 14, 11
  144. 144. muitas vezes não são necessárias todas estas característicasWednesday, September 14, 11
  145. 145. em muitos cenários um líder técnico com bom conhecimento do domínio assume este papelWednesday, September 14, 11
  146. 146. em alguns cenários o papel é compartilhado entre membros do timeWednesday, September 14, 11
  147. 147. é preciso atentar aos pontos que fogem ao domínio do conhecimento técnicoWednesday, September 14, 11
  148. 148. liderança, relações interpessoais, conceitualização, comunicação: fogem às linhas de códigoWednesday, September 14, 11
  149. 149. por que programadores não gostam de arquitetos?Wednesday, September 14, 11
  150. 150. experiências frustradasWednesday, September 14, 11
  151. 151. arquitetos que não possuíam além da parte técnicaWednesday, September 14, 11
  152. 152. arquitetos tecnicamente defasadosWednesday, September 14, 11
  153. 153. ocupação de cargo por tempo de casaWednesday, September 14, 11
  154. 154. um programador medíocre pode projetar um desejo de “crescimento”Wednesday, September 14, 11
  155. 155. programadores podem ser arquitetosWednesday, September 14, 11
  156. 156. é preciso compreender que são dois papéis distintos para uma mesma pessoaWednesday, September 14, 11
  157. 157. mesmo que se ocupe os dois papéis simultaneamente, eles ainda são distintosWednesday, September 14, 11
  158. 158. o papel de arquiteto não é o futuro de um desenvolvedorWednesday, September 14, 11
  159. 159. programadores brincam com editores de código fonteWednesday, September 14, 11
  160. 160. arquitetos brincam com quadros, desenhos, idéiasWednesday, September 14, 11
  161. 161. @vquaiato (vinicius quaiato) http://viniciusquaiato.com http://crafters.com.br vinicius.quaiato@gmail.comWednesday, September 14, 11
  162. 162. Wednesday, September 14, 11
  163. 163. • http://en.wikipedia.org/wiki/Software_architecture M ais • http://www.computer.org/portal/web/guest/home • http://viniciusquaiato.com/blog/efeito-borboleta-e-o-software/ • http://www.ibm.com/developerworks/rational/library/feb06/eeles/ • http://cnx.org/content/m17524/latest/ • http://www.bredemeyer.com/whatis.htm • http://www.sei.cmu.edu/architecture/ • http://msdn.microsoft.com/en-us/architecture/aa699358 • http://www.opengroup.org/togaf/ • http://www.ieee.org/index.htmlWednesday, September 14, 11

×