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 informático (es decir, un sistema compuesto de software y hardware) con el fin de cumplir con 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 procurar evitar problemas de implementación y permitir fácilmente extensiones o 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 un conocimiento sustancial, pero general, de hardware, software y sistemas (de usuario) similares. 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áfico aéreo debe estar más que superficialmente familiarizado con todas las tareas de un sistema de tráfico aéreo, incluidas las de todos los niveles de usuarios.
El título de arquitecto de sistemas connota responsabilidades de diseño de nivel superior a las de un ingeniero de sistemas , un ingeniero de software o un programador , aunque las actividades diarias 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 previsto. 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, facilidad de uso, confiabilidad, capacidad de mantenimiento, disponibilidad y otras "capacidades" ) y seleccionar las opciones más adecuadas para el diseño posterior. El resultado de dicho trabajo establece las propiedades básicas del sistema y las que son más difíciles de cambiar más adelante.
En sistemas pequeños, la arquitectura suele estar definida directamente por los desarrolladores. Sin embargo, en sistemas más grandes, se debe designar un arquitecto de sistemas para que describa el sistema general y sirva de 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 varios arquitectos, en cuyo caso los arquitectos trabajan juntos para integrar sus subsistemas o aspectos y responden ante un arquitecto jefe responsable de todo el sistema. En general, el papel del arquitecto es actuar como mediador entre los usuarios y los ingenieros, conciliando 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 de gran tamaño se desarrolló como una forma de manejar sistemas demasiado grandes para que una sola persona los pueda concebir, y mucho menos diseñar. 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 o 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 comprensibles individualmente, 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 que sean funcionales y estéticamente agradables. Un buen arquitecto es también el principal guardián de la visión que los usuarios tienen del producto final y del proceso de derivación de los requisitos a partir de esa visión y de su implementación.
Los arquitectos no siguen procedimientos exactos. Se comunican con los usuarios y patrocinadores de una manera muy interactiva y relativamente informal; juntos extraen los verdaderos requisitos necesarios para el sistema (final) diseñado. El arquitecto debe permanecer en constante 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 requisitos de 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 es probable que se pueda lograr dentro de los límites de costo, tiempo y otras limitaciones. 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 esa manera, los usuarios tendrán absolutamente claro lo que están obteniendo. También es una protección contra requisitos que no se pueden probar, malentendidos y la proliferación de requisitos.
El desarrollo del primer nivel de requisitos de ingeniería no es un ejercicio puramente analítico y debe involucrar tanto al arquitecto como al ingeniero. Si se deben hacer concesiones para cumplir con las restricciones, el arquitecto debe asegurarse de que el producto final y el aspecto general no se alejen demasiado de las intenciones de los usuarios. El ingeniero debe centrarse en desarrollar un diseño que optimice las restricciones pero que garantice un producto funcional, confiable, extensible y robusto. La verdadera función de un sistema diseñado es la prestación de los servicios necesarios a los usuarios. 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 componentes simples de hardware y software, se ha descubierto que la aplicación estrecha de los principios tradicionales de desarrollo de sistemas es insuficiente; se considera que es necesaria la aplicación de principios más generales de arquitectura de sistemas, hardware y software al diseño de (sub)sistemas. La arquitectura también puede considerarse como un modelo simplificado del producto final terminado: su función principal es definir las partes y sus relaciones entre sí, de modo que el conjunto pueda verse como una representación coherente, completa y correcta de lo que los usuarios tenían en mente, especialmente para la interfaz entre el ordenador y el ser humano. También se utiliza para garantizar que las partes encajen entre sí y se relacionen de la forma deseada.
Es necesario distinguir entre la arquitectura del mundo de los usuarios y la arquitectura de sistemas de ingeniería. La primera representa y aborda problemas y soluciones en el mundo de los usuarios . Se captura principalmente en las interfaces hombre-computadora (CHI) del sistema de ingeniería. 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 la 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 una cantidad razonable de tiempo y con un gasto razonable de energía, o de obtener la información necesaria para los clientes y el 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 potencialmente útiles) . La primera es una actividad conjunta con los usuarios; la segunda 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 sistema sea aceptado por el usuario: el arquitecto se asegura de que todos los cambios e interpretaciones realizados durante el curso del desarrollo no comprometan el punto de vista de los usuarios.
Los arquitectos son generalistas. No se espera que sean expertos en ninguna tecnología en particular, pero sí que conozcan 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 los costos y beneficios de varias soluciones utilizando diferentes tecnologías, por ejemplo, hardware versus software versus manual, y se aseguran de que el sistema en su conjunto funcione de acuerdo con las expectativas de los usuarios.
Muchos componentes de hardware y software comerciales o ya desarrollados pueden seleccionarse de forma independiente según restricciones como el costo, la respuesta, el rendimiento, etc. En algunos casos, el arquitecto ya puede ensamblar el sistema final (casi) sin ayuda. O bien, puede necesitar 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 solicitar la ayuda de otros especialistas: en seguridad , protección , comunicaciones , hardware de propósito especial, gráficos , factores humanos , prueba y evaluación , control de calidad , confiabilidad , capacidad de mantenimiento , disponibilidad , gestión de interfaz , 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 sea agradable y útil para sus habitantes. Si bien un solo arquitecto puede ser suficiente para construir una casa unifamiliar, pueden necesitarse, además, muchos ingenieros para resolver los problemas de detalle que surgen cuando se diseña un nuevo 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 complejo de viviendas, podemos tener un arquitecto para el complejo y uno para cada tipo de edificio, como parte de un equipo arquitectónico.
Los sistemas de automatización de gran tamaño 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 delegar en un arquitecto de hardware o de software algunas tareas, aunque todos ellos pueden ser miembros de un equipo arquitectónico conjunto.
El arquitecto debe asignar los requisitos del sistema a los componentes o subsistemas principales que están dentro del alcance de un solo ingeniero de hardware o software, o de un gerente y equipo de ingeniería. Pero nunca se debe considerar al arquitecto como un supervisor de ingeniería. (Si el elemento es lo suficientemente grande y/o complejo, el arquitecto jefe asignará partes a arquitectos más especializados). Lo ideal es que cada uno de esos componentes o subsistemas sea un objeto lo suficientemente independiente como para que pueda probarse como un componente completo, separado del todo, utilizando únicamente un banco de pruebas simple para suministrar entradas simuladas y registrar las salidas. Es decir, no es necesario saber cómo funciona un sistema de control de tráfico aéreo para diseñar y construir un subsistema de gestión de datos para él. Solo es necesario conocer las restricciones bajo las cuales se espera que funcione el subsistema.
Un buen arquitecto se asegura de que el sistema, por complejo que sea, esté construido sobre conceptos relativamente simples y "limpios" para cada (sub)sistema o capa y sea fácilmente comprensible para todos, especialmente para los usuarios, sin necesidad de 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 confusos y excepciones. A medida que evolucionan las necesidades de los usuarios (una vez que el sistema está en funcionamiento), es mucho más fácil desarrollar posteriormente un concepto simple que uno cargado de excepciones, casos especiales y mucha "letra pequeña".
La superposición de capas en la arquitectura es importante para que cada una de ellas sea lo suficientemente simple como para que resulte comprensible para una sola mente. A medida que se asciende por las capas, los sistemas completos de las capas inferiores se convierten en componentes simples de las capas superiores y pueden desaparecer por completo en las capas superiores.
La prueba de aceptación es una responsabilidad principal del arquitecto de sistemas. Es el principal medio por el cual el líder del programa demostrará a los usuarios que el sistema es tal como se planeó originalmente y que todos los arquitectos e ingenieros involucrados han cumplido con 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 en borrador del manual del usuario es invaluable, especialmente junto con un prototipo. Sin embargo, es importante crear un conjunto de requisitos o especificaciones que funcionen y estén bien redactados y que sean razonablemente comprensibles para el cliente (para que puedan firmarlo correctamente, pero los requisitos principales de los usuarios deben estar reflejados en un manual de usuario preliminar para que sean inteligibles). Pero debe utilizar un lenguaje preciso e inequívoco para que los diseñadores y otros implementadores no tengan dudas sobre los significados o las intenciones. En particular, todos los requisitos deben ser comprobables y el borrador inicial del plan de pruebas debe desarrollarse simultáneamente con los requisitos. Todas las partes interesadas deben aprobar las descripciones de las pruebas de aceptación , o equivalentes, como el único determinante del cumplimiento de los requisitos, al comienzo del programa.
El uso de cualquier forma de la palabra "arquitecto" está regulado por "leyes de títulos" en muchos estados de los EE. UU., y una persona debe tener licencia como arquitecto de edificios 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]