97 Cosas que Todo Arquitecto de Software Debe Conocer

Anotações:

• El libro “Las 97 cosas que debe saber un Arquitecto de Software” recolecta los comentarios de arquitectos lideres en la industria del software, ofreciéndonos importantes principios en aspectos fundamentales del desarrollo. Sus consejos que nos ayudarán a liderar con éxito nuestros proyectos.

1. Clientes Satisfechos por hacer lo correcto
   1. No complicarte, elimina problemas accidentales
      1. Un buen líder tiene buenos elementos
         1. Comunicación no es solo con clientes el quipo también aporta
            1. El balance en lo técnico y el negocio son importantes
               1. En una sola reunión no se tiene todo el panorama
                  1. El Diseño es importante pero el código es primordial
                     1. CUANDO SE HABLE DE LA CALIDAD, ESTA NO ES NEGOCIABLE
                        1. Los arquitectos debemos ser cuidadosos pues las herramientas automaticas no son una salida
                           1. Yo con yo no aplica por eso existe un equipo
                              1. AHORA A PROGRAMAS
                                 1. DISEÑAR, LA FABRICACION DEL SOFTWARE SE PUEDE AUTOMATIZAR
                                    1. ESTO ES UN ARTE Y COMO ARTE CONLLEVA A: DISCIPLINA, PRACTICA, EXITO.
                                       1. CUIDADO CON EL ROI, ENTREGAS CONTINUAS
                                          1. EL TRIANGULO DE HIERRO Alcance, tiempo costo
                                             1. OJO LA ARQUITECTURA DE SOTWARE TIENE CONSECUENCIAS ETICAS
                                                1. AntiPatrones y Patrones,
                                                   1. El Rey, elfos, magos roles para todos
                                                      1. La realidad no puede superar la vision
                                                         1. El soporte y el mantenimiento nunca deben ser pensamientos tardíos
                                                            1. "Perfecto" es el Enemigo de "Suficientemente Bueno"
                                                               1. Los usuarios no siempre estarán contentos con los nuevos sistemas o las mejoras
                                                                  1. Hay que mostrar el valor de la arquitectura como elemento fuerte de negocio.
                                                                     1. * Buscar el momento correcto *Reconocer cuando detenernos * Herramientas para cuantificar *pasar la propuesta del valor
                                                                        1. No podemos pretender que el documento de requimientos es un palno ni tampoco que el software es INTOCABLE, este es cambiante
                                                                           1. Las soluciones se deben establecer a tiempo real no a supuestos futuros
                                                                              1. Esxisten desventajas, asi como ventajas. DIVULGARLAS ES LO INDICADO
                                                                                 1. Si al trabajar el software el usuario no esta satisfecho, dicha satisfacción será negativa
                                                                                    1. Evitemos a toda costa el tratar de diseñar "TODO EL SOFTWARE DE UNA VEZ
                                                                                       1. G R A C I A S.....
                                                   2. Arquitectura (alto nivel (Ej: EDA, SOA, ROA)
                                                   3. Interprise : Diseñar las aplicaciones Empresas mas grandes, DataMapper, DTO
                                                   4. Diseño: implementar funcionalidades comunesSingleton, Visitor, Factory
                                                   5. Investigación: diseño y la comunicación de conceptos