{"id":443,"date":"2020-07-16T20:48:49","date_gmt":"2020-07-16T20:48:49","guid":{"rendered":"https:\/\/arsum.cl\/?page_id=443"},"modified":"2020-07-17T17:24:26","modified_gmt":"2020-07-17T17:24:26","slug":"eres-arquitecto-de-software","status":"publish","type":"page","link":"https:\/\/arsum.cl\/?page_id=443","title":{"rendered":"\u00bfEres arquitecto de software?"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t

La l\u00ednea entre el desarrollo de software y la arquitectura de software es complicada. Algunas personas te dir\u00e1n que no existe y que la arquitectura es simplemente una extensi\u00f3n del proceso de dise\u00f1o realizado por los desarrolladores. Otros se dar\u00e1n cuenta de que es un abismo enorme que solo pueden cruzar los desarrolladores altaneros que creen que siempre debes abstraer tus abstracciones y no quedarte estancado por esos molestos detalles de implementaci\u00f3n. Como siempre, hay un equilibrio pragm\u00e1tico en alg\u00fan punto intermedio, pero plantea la interesante pregunta de c\u00f3mo te mueves de uno a otro.<\/strong><\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t

La experiencia es un buen indicador, pero debes mirar m\u00e1s profundamente<\/h1>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t

Convertirse en un arquitecto de software no es algo que simplemente sucede de la noche a la ma\u00f1ana o con una promoci\u00f3n. Es un papel, no un rango. Es un proceso evolutivo donde gradualmente ganar\u00e1 la experiencia y la confianza que necesita para asumir el papel.<\/p>

Hay varias cualidades diferentes que se pueden buscar en un arquitecto de software, y su experiencia pasada a menudo es un buen indicador de su capacidad para asumir el papel. Sin embargo, dado que el papel de un arquitecto de software es variado, debe profundizar para comprender el nivel de participaci\u00f3n, influencia, liderazgo y responsabilidad que se ha demostrado en varias \u00e1reas diferentes. En t\u00e9rminos generales, la arquitectura de software en la mayor\u00eda de los proyectos se puede dividir en dos fases: la arquitectura se define y luego se entrega.<\/span><\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t

Definici\u00f3n de la arquitectura del software<\/h1>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t

El proceso de definici\u00f3n de la arquitectura parece bastante sencillo. Todo lo que tienes que hacer es descubrir cu\u00e1les son los requisitos y dise\u00f1ar un sistema que los satisfaga. Pero en realidad no es tan simple y el rol de la arquitectura de software puede variar enormemente dependiendo de qu\u00e9 tan comprometido est\u00e9 y cu\u00e1n seriamente vea su rol. Como se muestra en el siguiente diagrama, la parte de definici\u00f3n de arquitectura en el rol se puede desglosar en varios elementos diferentes:<\/span><\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t
    \n \t
  1. Gesti\u00f3n de requisitos no funcionales<\/b>. Los proyectos de software a menudo se quedan atrapados preguntando a los usuarios qu\u00e9 caracter\u00edsticas desean, pero rara vez les preguntan qu\u00e9 requisitos no funcionales (o cualidades del sistema) necesitan. A veces los interesados nos dir\u00e1n que \u00abel sistema debe ser r\u00e1pido\u00bb, pero eso es demasiado subjetivo. Los requisitos no funcionales deben ser espec\u00edficos, medibles, alcanzables y comprobables si vamos a satisfacerlos. La mayor\u00eda de los requisitos no funcionales son de naturaleza t\u00e9cnica y a menudo tienen una gran influencia en la arquitectura del software. Comprender los requisitos no funcionales es una parte crucial del rol, pero hay una diferencia entre asumir cu\u00e1les son esos requisitos y desafiarlos. Despu\u00e9s de todo, \u00bfcu\u00e1ntos sistemas has visto que realmente necesitan estar operativos 24×7?\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t
    \n\t\t\t\t
      \n \t
    1. Definici\u00f3n de la arquitectura<\/b>. Con los requisitos no funcionales capturados, el siguiente paso es comenzar a pensar en c\u00f3mo vas a resolver los problemas establecidos por las partes interesadas y definir la arquitectura. Es justo decir que cada sistema de software tiene una arquitectura, pero no todos los sistemas de software tienen una arquitectura definida. Y ese es realmente el punto aqu\u00ed. El proceso de definici\u00f3n de arquitectura te permite pensar c\u00f3mo vas a tomar los requisitos junto con las restricciones impuestas y resolver el problema. La definici\u00f3n de arquitectura se trata de introducir estructura, pautas, principios y liderazgo en los aspectos t\u00e9cnicos de un proyecto de software. Definir la arquitectura es tu trabajo como arquitecto de software, pero hay una gran diferencia entre dise\u00f1ar un sistema de software desde cero y extender uno existente.\u00a0<\/b><\/li>\n<\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t
      \n\t\t\t\t
      1. Selecci\u00f3n de tecnolog\u00eda<\/b>. La selecci\u00f3n de tecnolog\u00eda suele ser un ejercicio divertido, pero tiene una serie de desaf\u00edos cuando se consideran los costos, las licencias, las relaciones con los proveedores, la estrategia tecnol\u00f3gica, la compatibilidad, la interoperabilidad, el soporte, la implementaci\u00f3n, las pol\u00edticas de actualizaci\u00f3n, los entornos de usuario final, etc. La suma de estos factores a menudo puede hacer que una tarea simple de elegir algo como una tecnolog\u00eda de cliente enriquecida sea una pesadilla completa. Y luego est\u00e1 la cuesti\u00f3n de si las tecnolog\u00edas realmente funcionan. La selecci\u00f3n de tecnolog\u00eda tiene que ver con la gesti\u00f3n del riesgo: reduciendo el riesgo donde hay alta complejidad o incertidumbre e introduciendo el riesgo donde hay beneficios para tener. Las decisiones tecnol\u00f3gicas deben tomarse teniendo en cuenta todos los factores, y todas las decisiones tecnol\u00f3gicas deben revisarse y evaluarse. Esto incluye los principales bloques de construcci\u00f3n para un proyecto de software hasta las bibliotecas y los frameworks que se introducen durante el desarrollo. Si est\u00e1s definiendo una arquitectura, tambi\u00e9n debes estar seguro que las elecciones de tecnolog\u00eda que se est\u00e1n haciendo son las correctas. Nuevamente, hay una gran diferencia entre evaluar la tecnolog\u00eda para un nuevo sistema y agregar tecnolog\u00eda a un sistema existente.<\/li><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t
        \n\t\t\t\t
        1. Evaluaci\u00f3n de la arquitectura<\/b>. Si est\u00e1s dise\u00f1ando software, debes preguntarte si tu arquitectura funcionar\u00e1. Para m\u00ed, una arquitectura funciona si satisface los requisitos no funcionales, proporciona la base necesaria para el resto del c\u00f3digo y proporciona una plataforma suficiente para resolver el problema comercial subyacente. Uno de los mayores problemas con el software es que es complejo y abstracto, lo que dificulta la visualizaci\u00f3n de las caracter\u00edsticas de tiempo de ejecuci\u00f3n de los diagramas UML o del c\u00f3digo en s\u00ed. Llevamos a cabo una serie de diferentes tipos de pruebas a lo largo del ciclo de vida de desarrollo de software para darnos la confianza de que el sistema que estamos entregando funcionar\u00e1 cuando se implemente. Entonces, \u00bfpor qu\u00e9 no hacemos lo mismo para nuestras arquitecturas? Si puedes probar su arquitectura, puedes probar que funciona. Y si puedes hacer esto lo antes posible, puedes reducir el riesgo del proyecto m\u00e1s que simplemente desear que ocurra lo mejor.<\/li><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
          \n\t\t\t\t
          \n\t\t\t\t\t\t\t\t
          \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
          \n\t\t\t\t
          \n\t\t\t\t\t\t\t\t
          \n\t\t\t\t
          1. Colaboraci\u00f3n de la arquitectura<\/b>. Es inusual que cualquier sistema de software viva de forma aislada y muchos tienen que entenderlo. Esto abarca desde el equipo de desarrollo inmediato que necesita comprender y aceptar la arquitectura, hasta otras partes interesadas que tienen un inter\u00e9s desde el punto de vista de seguridad, base de datos, operaciones, mantenimiento, soporte, etc. Para que un proyecto de software sea exitoso, debes colaborar estrechamente con todas las partes interesadas del sistema para garantizar que la arquitectura se integre con \u00e9xito con su entorno. Desafortunadamente, la colaboraci\u00f3n de arquitectura dentro del equipo de desarrollo rara vez ocurre, y mucho menos con las partes interesadas externas.<\/li><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
            \n\t\t\t\t
            \n\t\t\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
            \n\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t
            \n\t\t\t\t\t
            \n\t\t\t
            \n\t\t\t\t\t\t\t
            \n\t\t\t\t\t\t
            \n\t\t\t\t
            \n\t\t\t

            Entrega de la arquitectura del software<\/h1>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
            \n\t\t\t\t
            \n\t\t\t\t\t\t\t\t
            \n\t\t\t\t

            Es la misma historia con la entrega de arquitectura, donde el rol de la arquitectura de software puede variar dependiendo del nivel de compromiso entre los elementos que contribuyen a un proyecto de software exitoso.\u00a0<\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

            \n\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t
            \n\t\t\t\t\t
            \n\t\t\t
            \n\t\t\t\t\t\t\t
            \n\t\t\t\t\t\t
            \n\t\t\t\t
            \n\t\t\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
            \n\t\t\t\t
            \n\t\t\t\t\t\t\t\t
            \n\t\t\t\t
            1. Propiedad del panorama general<\/b>. Para llevar la arquitectura a una conclusi\u00f3n exitosa, es importante que alguien posea el panorama general y venda la visi\u00f3n durante todo el ciclo de vida del desarrollo de software, evolucionando a lo largo del proyecto si es necesario y asumiendo la responsabilidad de garantizar que se entregue con \u00e9xito . Si ha definido una arquitectura, tiene sentido permanecer continuamente involucrado y evolucionar su arquitectura en lugar de elegir entreg\u00e1rsela a un \u00abequipo de implementaci\u00f3n\u00bb.<\/li><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
              \n\t\t\t\t
              \n\t\t\t\t\t\t\t\t
              \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
              \n\t\t\t\t
              \n\t\t\t\t\t\t\t\t
              \n\t\t\t\t
              1. Liderazgo<\/b>. Tener una visi\u00f3n m\u00e1s amplia es un aspecto del liderazgo t\u00e9cnico, pero hay otras cosas que deben hacerse durante la fase de entrega de un proyecto de software. Estos incluyen asumir la responsabilidad, proporcionar orientaci\u00f3n t\u00e9cnica, tomar decisiones t\u00e9cnicas y tener la autoridad para tomar esas decisiones. Como arquitecto, debes asumir el liderazgo t\u00e9cnico para garantizar que todo est\u00e1 bajo cuidado y que el equipo se dirija en la direcci\u00f3n correcta de forma continua. La posici\u00f3n del arquitecto de software es inherentemente sobre el liderazgo y, aunque esto parece obvio, muchos equipos de proyecto no obtienen el liderazgo t\u00e9cnico que necesitan, y los arquitectos suponen que una entrega exitosa no es necesariamente su problema.<\/li><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                \n\t\t\t\t
                \n\t\t\t\t\t\t\t\t
                \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                \n\t\t\t\t
                \n\t\t\t\t\t\t\t\t
                \n\t\t\t\t
                  \n \t
                1. Orientaci\u00f3n y tutor\u00eda<\/b>. El asesoramiento y la tutor\u00eda es una actividad que se pasa por alto en la mayor\u00eda de los proyectos de desarrollo de software, ya que muchos miembros del equipo no obtienen el apoyo que necesitan. Si bien el liderazgo t\u00e9cnico se trata de dirigir el proyecto en su conjunto, hay momentos en que las personas necesitan asistencia. Adem\u00e1s de esto, el entrenamiento y la tutor\u00eda proporcionan una forma de mejorar las habilidades de las personas y ayudarlas a mejorar sus propias carreras. Esto es algo que deber\u00eda caer directamente dentro del \u00e1mbito del arquitecto de software, y claramente hay una gran diferencia entre entrenar a su equipo en arquitectura y dise\u00f1o versus ayudarlos con sus problemas de codificaci\u00f3n.<\/li>\n<\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t
                  \n\t\t\t\t
                    \n \t
                  1. Aseguramiento de la calidad<\/b>. Incluso con la mejor arquitectura y liderazgo del mundo, una entrega deficiente puede hacer que fracase un proyecto exitoso. El aseguramiento de la calidad es una gran parte del papel de un arquitecto, pero es m\u00e1s que solo hacer revisiones de c\u00f3digo. Por ejemplo, necesitas una l\u00ednea base contra la cual asegurarte, y esto significa la introducci\u00f3n de est\u00e1ndares y pr\u00e1cticas de trabajo. Desde una perspectiva de desarrollo de software, estos podr\u00edan incluir est\u00e1ndares de codificaci\u00f3n, principios de dise\u00f1o y herramientas de an\u00e1lisis de c\u00f3digo fuente hasta el uso de herramientas de integraci\u00f3n continua, pruebas unitarias automatizadas y cobertura de c\u00f3digo. Es seguro decir que la mayor\u00eda de los proyectos no aseguran la calidad lo suficiente y, por lo tanto, debes descubrir qu\u00e9 es importante y cerciorarte de que est\u00e9 lo suficientemente asegurado. Para m\u00ed, las partes importantes de un proyecto son cualquier cosa que sea arquitect\u00f3nicamente significativa, cr\u00edtica para el negocio, compleja o altamente visible. Solo necesitas ser pragm\u00e1tico y darte cuenta que no necesariamente puedes asegurar todo, haciendo algo en lugar de no hacer nada.<\/li>\n<\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                    \n\t\t\t\t
                    \n\t\t\t\t\t\t\t\t
                    \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                    \n\t\t\t\t
                    \n\t\t\t\t\t\t\t\t
                    \n\t\t\t\t
                    1. Dise\u00f1o, desarrollo y pruebas<\/b>. Lo \u00faltimo que cae directamente dentro del rol de un arquitecto de software es el dise\u00f1o, desarrollo y prueba. Ser un arquitecto \u00abmanos a la obra\u00bb no significa necesariamente que debas involucrarte en las tareas de codificaci\u00f3n del d\u00eda a d\u00eda, pero s\u00ed significa que est\u00e1s continuamente involucrado en el proyecto, ayudando activamente a darle forma y entregarlo. Dicho esto, \u00bfpor qu\u00e9 las actividades de codificaci\u00f3n del d\u00eda a d\u00eda no deber\u00edan ser parte del papel de un arquitecto? La mayor\u00eda de los arquitectos son codificadores experimentados, por lo que tiene sentido mantener esas habilidades actualizadas. Adem\u00e1s, el arquitecto puede experimentar el mismo dolor que todos los dem\u00e1s en el equipo, lo que a su vez los ayuda a comprender mejor c\u00f3mo se ve su arquitectura desde una perspectiva de desarrollo. Muchas compa\u00f1\u00edas tienen pol\u00edticas que impiden que los arquitectos de software participen en actividades de codificaci\u00f3n porque sus arquitectos son \u00abdemasiado valiosos para emprender ese trabajo b\u00e1sico\u00bb. Claramente, esta es la actitud equivocada. \u00bfPor qu\u00e9 dejar que sus arquitectos hagan todo ese esfuerzo para definir la arquitectura si no van a dejar que contribuyan a su entrega exitosa? Por supuesto, hay situaciones en las que no es pr\u00e1ctico involucrarse a nivel de c\u00f3digo. Por ejemplo, un proyecto grande generalmente significa un \u00abpanorama general\u00bb m\u00e1s general que cuidar, y puede haber momentos en los que simplemente no tengas tiempo. Pero en t\u00e9rminos generales, un arquitecto que codifica es m\u00e1s efectivo y m\u00e1s feliz que un arquitecto que observa desde el costado de la cancha.<\/li><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t\t\t\t\t\t
                      \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t\t\t\t
                      \n\t\t\t\t\t
                      \n\t\t\t
                      \n\t\t\t\t\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t

                      \u00bfEres arquitecto de software?<\/h1>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t\t\t\t\t\t
                      \n\t\t\t\t

                      Independientemente de si ves la l\u00ednea entre el desarrollo de software y la arquitectura como un abismo m\u00edtico o enorme, los elementos anteriores resaltan que el nivel de experiencia de las personas en el rol de la arquitectura de software var\u00eda considerablemente dependiendo de cu\u00e1n comprometidos est\u00e9n y cu\u00e1n seriamente vean su rol. La mayor\u00eda de los desarrolladores no se despiertan un lunes por la ma\u00f1ana y se declaran arquitectos de software. Ciertamente, yo no lo hice as\u00ed, y mi ruta hacia la arquitectura de software fue en gran medida un proceso evolutivo. Dicho esto, sin embargo, hay una alta probabilidad de que esos mismos desarrolladores ya est\u00e9n asumiendo partes de la funci\u00f3n de arquitectura de software, independientemente de su cargo.<\/p>

                      Hay una gran diferencia entre contribuir a la arquitectura de un sistema de software y ser responsable de definirlo t\u00fa mismo, con un continuo de habilidades, conocimiento y experiencia necesarios en las diferentes \u00e1reas que conforman el rol de la arquitectura de software. Depende de ti cruzar la l\u00ednea entre el desarrollador de software y el arquitecto de software, pero comprender tu propio nivel de experiencia es la primera parte del viaje.<\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

                      \n\t\t\t\t\t\t
                      \n\t\t\t\t\t\t\t
                      \n\t\t\t\t\t
                      \n\t\t\t
                      \n\t\t\t\t\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t\t\t
                      \n\t\t\t\n\t\t\t\t\t\t<\/span>\n\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t\t\t\t
                      \n\t\t\t\t\t
                      \n\t\t\t
                      \n\t\t\t\t\t\t\t
                      \n\t\t\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t

                      Sobre el Autor<\/h1>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t\t\t\t\t\t
                      \n\t\t\t\t

                      Dependiendo de su punto de vista, Simon Brown es un arquitecto de software que codifica o un desarrollador de software que comprende la arquitectura. Cuando no est\u00e1 desarrollando software con .NET o Java, a Simon generalmente se lo puede encontrar consultando, haciendo coaching o entrenando. Simon tambi\u00e9n ha escrito libros sobre Java, presentado en eventos de la industria y ha organizado un curso de capacitaci\u00f3n llamado Arquitectura de Software para Desarrolladores, que se basa en su escrito sobre arquitectura de software en Codificando la Arquitectura. Puedes ponerte en contacto con Simon por correo electr\u00f3nico o Twitter.<\/p>

                      Este art\u00edculo ha sido traducido desde su original en ingl\u00e9s, el que se encuentra en la siguiente direcci\u00f3n:
                      https:\/\/www.infoq.com\/articles\/brown-are-you-a-software-architect\/<\/a><\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

                      La l\u00ednea entre el desarrollo de software y la arquitectura de software es complicada. Algunas personas te dir\u00e1n que no existe y que la arquitectura es simplemente una extensi\u00f3n del proceso de dise\u00f1o realizado por los desarrolladores. Otros se dar\u00e1n cuenta de que es un abismo enorme que solo pueden cruzar los desarrolladores altaneros que […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":305,"menu_order":4,"comment_status":"closed","ping_status":"closed","template":"","meta":{"ocean_post_layout":"","ocean_both_sidebars_style":"","ocean_both_sidebars_content_width":0,"ocean_both_sidebars_sidebars_width":0,"ocean_sidebar":"0","ocean_second_sidebar":"0","ocean_disable_margins":"enable","ocean_add_body_class":"","ocean_shortcode_before_top_bar":"","ocean_shortcode_after_top_bar":"","ocean_shortcode_before_header":"","ocean_shortcode_after_header":"","ocean_has_shortcode":"","ocean_shortcode_after_title":"","ocean_shortcode_before_footer_widgets":"","ocean_shortcode_after_footer_widgets":"","ocean_shortcode_before_footer_bottom":"","ocean_shortcode_after_footer_bottom":"","ocean_display_top_bar":"default","ocean_display_header":"default","ocean_header_style":"","ocean_center_header_left_menu":"0","ocean_custom_header_template":"0","ocean_custom_logo":0,"ocean_custom_retina_logo":0,"ocean_custom_logo_max_width":0,"ocean_custom_logo_tablet_max_width":0,"ocean_custom_logo_mobile_max_width":0,"ocean_custom_logo_max_height":0,"ocean_custom_logo_tablet_max_height":0,"ocean_custom_logo_mobile_max_height":0,"ocean_header_custom_menu":"0","ocean_menu_typo_font_family":"0","ocean_menu_typo_font_subset":"","ocean_menu_typo_font_size":0,"ocean_menu_typo_font_size_tablet":0,"ocean_menu_typo_font_size_mobile":0,"ocean_menu_typo_font_size_unit":"px","ocean_menu_typo_font_weight":"","ocean_menu_typo_font_weight_tablet":"","ocean_menu_typo_font_weight_mobile":"","ocean_menu_typo_transform":"","ocean_menu_typo_transform_tablet":"","ocean_menu_typo_transform_mobile":"","ocean_menu_typo_line_height":0,"ocean_menu_typo_line_height_tablet":0,"ocean_menu_typo_line_height_mobile":0,"ocean_menu_typo_line_height_unit":"","ocean_menu_typo_spacing":0,"ocean_menu_typo_spacing_tablet":0,"ocean_menu_typo_spacing_mobile":0,"ocean_menu_typo_spacing_unit":"","ocean_menu_link_color":"","ocean_menu_link_color_hover":"","ocean_menu_link_color_active":"","ocean_menu_link_background":"","ocean_menu_link_hover_background":"","ocean_menu_link_active_background":"","ocean_menu_social_links_bg":"","ocean_menu_social_hover_links_bg":"","ocean_menu_social_links_color":"","ocean_menu_social_hover_links_color":"","ocean_disable_title":"default","ocean_disable_heading":"default","ocean_post_title":"","ocean_post_subheading":"","ocean_post_title_style":"background-image","ocean_post_title_background_color":"","ocean_post_title_background":444,"ocean_post_title_bg_image_position":"","ocean_post_title_bg_image_attachment":"","ocean_post_title_bg_image_repeat":"","ocean_post_title_bg_image_size":"","ocean_post_title_height":0,"ocean_post_title_bg_overlay":0.9,"ocean_post_title_bg_overlay_color":"#290451","ocean_disable_breadcrumbs":"default","ocean_breadcrumbs_color":"","ocean_breadcrumbs_separator_color":"","ocean_breadcrumbs_links_color":"","ocean_breadcrumbs_links_hover_color":"","ocean_display_footer_widgets":"default","ocean_display_footer_bottom":"default","ocean_custom_footer_template":"0"},"_links":{"self":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/443"}],"collection":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/arsum.cl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=443"}],"version-history":[{"count":9,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/443\/revisions"}],"predecessor-version":[{"id":475,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/443\/revisions\/475"}],"up":[{"embeddable":true,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/305"}],"wp:attachment":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=443"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}