El arquitecto de sistemas es un profesional de las tecnologías de la información y las comunicaciones . Los arquitectos de sistemas definen la arquitectura de un sistema computarizado (es decir, un sistema compuesto de software y hardware) para cumplir ciertos requisitos . Dichas definiciones incluyen: un desglose del sistema en componentes, las interacciones e interfaces de los componentes (incluso con el entorno, especialmente el usuario), y las tecnologías y recursos que se utilizarán en su diseño e implementación.
El trabajo del arquitecto de sistemas debe buscar evitar problemas de implementación y permitir fácilmente extensiones/modificaciones imprevistas en etapas futuras. Debido a la amplia experiencia requerida para esto, el arquitecto de sistemas suele ser un tecnólogo de alto nivel con conocimientos sustanciales, pero generales, de hardware, software y sistemas similares (de usuario). Por encima de todo, el arquitecto de sistemas debe tener un conocimiento razonable del dominio de experiencia de los usuarios. Por ejemplo, el arquitecto de un sistema de tránsito aéreo necesita estar más que superficialmente familiarizado con todas las tareas de un sistema de tránsito aéreo, incluidas las de todos los niveles de usuarios.
El título de arquitecto de sistemas connota responsabilidades de diseño de mayor nivel que un ingeniero de software o programador , aunque las actividades del día a día pueden superponerse.
Los arquitectos de sistemas interactúan con múltiples partes interesadas en una organización para comprender los distintos niveles de requisitos, el dominio, las tecnologías viables y el proceso de desarrollo anticipado. Su trabajo incluye determinar múltiples alternativas de diseño e implementación, evaluar dichas alternativas en función de todas las limitaciones identificadas (como costo, cronograma, espacio, energía, seguridad, usabilidad, confiabilidad, mantenibilidad, disponibilidad y otras "ilidades" ) y seleccionar las más opciones adecuadas para un mayor diseño. El resultado de dicho trabajo establece las propiedades centrales del sistema y aquellas que son más difíciles de cambiar más adelante.
En sistemas pequeños, la arquitectura normalmente la definen directamente los desarrolladores. Sin embargo, en sistemas más grandes, se debe nombrar un arquitecto de sistemas para delinear el sistema general y actuar como interfaz entre los usuarios, patrocinadores y otras partes interesadas, por un lado, y los ingenieros, por el otro. Los sistemas muy grandes y altamente complejos pueden incluir múltiples arquitectos, en cuyo caso los arquitectos trabajan juntos para integrar sus subsistemas o aspectos y responden a un arquitecto jefe responsable de todo el sistema. En general, el papel del arquitecto es actuar como mediador entre los usuarios y los ingenieros, reconciliando las necesidades y requisitos de los usuarios con lo que los ingenieros han determinado que es factible dentro de las limitaciones (de ingeniería) dadas.
En el diseño de sistemas , los arquitectos (e ingenieros) son responsables de:
La arquitectura de sistemas grandes se desarrolló como una forma de manejar sistemas demasiado grandes para que una sola persona pueda concebirlos, y mucho menos diseñarlos. Los sistemas de este tamaño se están convirtiendo rápidamente en la norma, por lo que cada vez se necesitan más enfoques arquitectónicos y arquitectos para resolver los problemas de sistemas grandes a muy grandes. En general, los sistemas cada vez más grandes se reducen a proporciones "humanas" mediante un enfoque de capas, donde cada capa se compone de una serie de subcapas individualmente comprensibles, cada una con su propio ingeniero y/o arquitecto principal. Una capa completa en un nivel se mostrará como un "componente" funcional de una capa superior (y puede desaparecer por completo en las capas más altas).
Se espera que los arquitectos comprendan las necesidades humanas y desarrollen productos humanamente funcionales y estéticamente agradables. Un buen arquitecto es también el principal guardián de la visión de los usuarios sobre el producto final y del proceso de derivar requisitos a partir de esa visión e implementarla.
Los arquitectos no siguen procedimientos exactos. Se comunican con los usuarios/patrocinadores de una manera altamente interactiva y relativamente informal; juntos extraen los verdaderos requisitos necesarios para el sistema (final) diseñado. El arquitecto debe permanecer constantemente en comunicación con los usuarios finales y con los ingenieros de sistemas (principales). Por lo tanto, el arquitecto debe estar íntimamente familiarizado con el entorno y el problema de los usuarios, y con el entorno de ingeniería de los posibles espacios de solución.
La especificación de los requisitos del usuario debe ser un producto conjunto de los usuarios y el arquitecto: los usuarios aportan sus necesidades y su lista de deseos, el arquitecto aporta el conocimiento de lo que probablemente resulte factible dentro de las limitaciones de coste, tiempo y otras. Cuando las necesidades de los usuarios se traducen en un conjunto de requisitos de alto nivel, también es el mejor momento para escribir la primera versión de la prueba de aceptación , que, a partir de entonces, debe mantenerse religiosamente actualizada con los requisitos. De esta forma, los usuarios tendrán absolutamente claro lo que obtienen. También es una salvaguardia contra requisitos no comprobables, malentendidos y requisitos progresivos.
El desarrollo del primer nivel de requisitos de ingeniería no es un ejercicio puramente analítico y también debe involucrar tanto al arquitecto como al ingeniero. Si se deben hacer concesiones (para cumplir con las limitaciones), el arquitecto debe asegurarse de que el producto final y la apariencia general no se desvíen mucho de la intención de los usuarios. El ingeniero debe centrarse en desarrollar un diseño que optimice las restricciones pero que garantice un producto viable, confiable, extensible y robusto. La prestación de los servicios necesarios a los usuarios es la verdadera función de un sistema de ingeniería. Sin embargo, a medida que los sistemas se vuelven cada vez más grandes y complejos, y a medida que su énfasis se aleja de los simples componentes de hardware y software, se ha descubierto que la aplicación estricta de los principios tradicionales de desarrollo de sistemas es insuficiente: la aplicación de principios más generales de sistemas, hardware, y se considera necesaria una arquitectura de software para el diseño de (sub)sistemas. La arquitectura también puede verse como un modelo simplificado del producto final terminado: su función principal es definir las partes y sus relaciones entre sí para que el todo pueda verse como una representación consistente, completa y correcta de lo que los usuarios hacen. ' tenía en mente, especialmente para la interfaz computadora-humano. También se utiliza para garantizar que las piezas encajen y se relacionen de la forma deseada.
Es necesario distinguir entre la arquitectura del mundo de los usuarios y la arquitectura de sistemas diseñados. El primero representa y aborda problemas y soluciones en el mundo del usuario . Se captura principalmente en las interfaces computadora-humano (CHI) del sistema diseñado. El sistema de ingeniería representa las soluciones de ingeniería : cómo el ingeniero propone desarrollar y/o seleccionar y combinar los componentes de la infraestructura técnica para respaldar el CHI. En ausencia de un arquitecto experimentado, existe una desafortunada tendencia a confundir las dos arquitecturas. Pero el ingeniero piensa en términos de hardware y software y el espacio de solución técnica, mientras que los usuarios pueden estar pensando en términos de resolver un problema de llevar a la gente del punto A al punto B en un tiempo razonable y con un gasto razonable de energía, o de hacer llegar la información necesaria a los clientes y al personal. Se espera que un arquitecto de sistemas combine el conocimiento tanto de la arquitectura del mundo de los usuarios como de las arquitecturas de sistemas de ingeniería (todas las potencialmente útiles) . La primera es una actividad conjunta con los usuarios; esta última es una actividad conjunta con los ingenieros. El producto es un conjunto de requisitos de alto nivel que reflejan los requisitos de los usuarios y que los ingenieros pueden utilizar para desarrollar requisitos de diseño de sistemas.
Debido a que los requisitos evolucionan a lo largo de un proyecto, especialmente uno largo, se necesita un arquitecto hasta que el usuario acepte el sistema: el arquitecto se asegura de que todos los cambios e interpretaciones realizados durante el desarrollo no comprometan el punto de vista de los usuarios.
Los arquitectos son generalistas. No se espera que sean expertos en ninguna tecnología, pero se espera que tengan conocimientos de muchas tecnologías y sean capaces de juzgar su aplicabilidad a situaciones específicas. También aplican sus conocimientos a situaciones prácticas, pero evalúan el costo/beneficio de varias soluciones utilizando diferentes tecnologías, por ejemplo, hardware versus software versus manual, y aseguran que el sistema en su conjunto funcione de acuerdo con las expectativas de los usuarios.
Muchos componentes de hardware y software disponibles comercialmente o ya desarrollados se pueden seleccionar de forma independiente según limitaciones como costo, respuesta, rendimiento, etc. En algunos casos, el arquitecto ya puede ensamblar el sistema final (casi) sin ayuda. O bien, es posible que aún necesite la ayuda de un ingeniero de hardware o software para seleccionar componentes y diseñar y construir cualquier función de propósito especial. Los arquitectos (o ingenieros) también pueden contar con la ayuda de otros especialistas: en seguridad , protección , comunicaciones , hardware para fines especiales, gráficos , factores humanos , pruebas y evaluación , control de calidad , confiabilidad , mantenibilidad , disponibilidad , gestión de interfaces , etc. Un equipo de arquitectura de sistemas eficaz debe tener acceso a especialistas en especialidades críticas según sea necesario.
Un arquitecto que planifica un edificio trabaja en el diseño general, asegurándose de que será agradable y útil para sus habitantes. Si bien un solo arquitecto puede ser suficiente para construir una casa unifamiliar, es posible que se necesiten muchos ingenieros, además, para resolver los problemas detallados que surgen cuando se diseña un novedoso edificio de gran altura. Si el trabajo es lo suficientemente grande y complejo, partes de la arquitectura pueden diseñarse como componentes independientes. Es decir, si estamos construyendo un conjunto de viviendas, podremos tener un arquitecto para el conjunto, y uno para cada tipo de edificio, como parte de un equipo de arquitectos.
Los grandes sistemas de automatización también requieren un arquitecto y mucho talento en ingeniería. Si el sistema diseñado es lo suficientemente grande y complejo, el arquitecto de sistemas puede ceder partes del trabajo a un arquitecto de hardware y/o a un arquitecto de software, aunque todos ellos pueden ser miembros de un equipo de arquitectura conjunto.
El arquitecto debe subasignar los requisitos del sistema a los componentes o subsistemas principales que estén dentro del alcance de un único ingeniero de hardware o software, o de un gerente y equipo de ingeniería. Pero el arquitecto nunca debe ser visto como un supervisor de ingeniería. (Si el elemento es lo suficientemente grande y/o complejo, el arquitecto jefe subasignará partes a arquitectos más especializados). Lo ideal es que cada componente/subsistema sea un objeto lo suficientemente independiente como para poder probarlo como un componente completo. separado del todo, utilizando sólo un banco de pruebas simple para proporcionar entradas simuladas y registrar salidas. Es decir, no es necesario saber cómo funciona un sistema de control de tráfico aéreo para poder diseñar y construir un subsistema de gestión de datos para el mismo. Sólo es necesario conocer las restricciones bajo las cuales se espera que funcione el subsistema.
Un buen arquitecto garantiza que el sistema, por complejo que sea, se base en conceptos relativamente simples y "limpios" para cada (sub)sistema o capa y que sea fácilmente comprensible para todos, especialmente los usuarios, sin una formación especial. El arquitecto utilizará un mínimo de heurística para garantizar que cada partición esté bien definida y libre de errores , soluciones alternativas , atajos o detalles y excepciones confusos. A medida que las necesidades de los usuarios evolucionan (una vez que el sistema está implementado y en uso), es mucho más fácil desarrollar un concepto simple que uno cargado de excepciones, casos especiales y mucha "letra pequeña".
La estratificación de la arquitectura es importante para mantener la arquitectura lo suficientemente simple en cada capa para que siga siendo comprensible para una sola mente. A medida que se ascienden capas, sistemas completos en las capas inferiores se convierten en componentes simples en las capas superiores y pueden desaparecer por completo en las capas más altas.
La prueba de aceptación es responsabilidad principal del arquitecto de sistemas. Es el medio principal por el cual el líder del programa demostrará a los usuarios que el sistema es como se planeó originalmente y que todos los arquitectos e ingenieros involucrados han cumplido sus objetivos.
Un arquitecto de edificios utiliza bocetos, modelos y dibujos. Un arquitecto de sistemas de automatización (o software o hardware) debe utilizar bocetos, modelos y prototipos para discutir diferentes soluciones y resultados con usuarios, ingenieros y otros arquitectos. Una versión preliminar del manual del usuario es de un valor incalculable, especialmente si se combina con un prototipo. Sin embargo, es importante crear un conjunto de requisitos o especificaciones viables y bien escritos que sean razonablemente comprensibles para el cliente (para que puedan aprobarlo adecuadamente, pero los requisitos de los usuarios principales deben capturarse en un informe preliminar). manual de usuario para la inteligibilidad). Pero debe utilizar un lenguaje preciso e inequívoco para que los diseñadores y otros implementadores no tengan dudas sobre los significados o intenciones. En particular, todos los requisitos deben ser comprobables y el borrador inicial del plan de prueba debe desarrollarse simultáneamente con los requisitos. Todas las partes interesadas deben aprobar las descripciones de las pruebas de aceptación , o equivalentes, como único determinante del cumplimiento de los requisitos, al inicio del programa.
El uso de cualquier forma de la palabra "arquitecto" está regulado por "leyes de títulos" en muchos estados de EE. UU., y una persona debe tener una licencia como arquitecto de construcción para utilizarla. [1]
En el Reino Unido, la junta de registro de arquitectos excluye el uso de arquitecto (cuando se utiliza en el contexto de software y TI) de su uso restringido. [2]