El arquitecto de sistemas es un profesional en tecnología 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 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.
Ocupación | |
---|---|
Nombres | Arquitecto de sistemas |
Tipo de ocupación | Profesión |
Sectores de actividad | Ingeniería de sistemas Ingeniería de diseño de sistemas |
Descripción | |
Competencias | Conocimiento del dominio del usuario , conocimiento científico, habilidades de ingeniería, planificación y gestión. |
Educación requerida | Ver educación |
El trabajo del arquitecto de sistemas debe evitar problemas de implementación y permitir fácilmente extensiones / modificaciones imprevistas en etapas futuras. Debido a la amplia experiencia que se requiere 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 similares (de usuario). Por encima de todo, el arquitecto de sistemas debe tener un conocimiento razonable del dominio de experiencia de los usuarios (es decir, el arquitecto de un sistema de tránsito aéreo debe estar más que superficialmente familiarizado con todas las tareas de un sistema de tránsito aéreo, incluidas las de todos). niveles de usuarios).
Descripción general
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 "enfermedades" ) y seleccionar las más opciones adecuadas para un diseño posterior. El resultado de dicho trabajo establece las propiedades centrales del sistema y aquellas que son más difíciles de cambiar posteriormente.
En sistemas pequeños, la arquitectura suele ser definida directamente por los desarrolladores. Sin embargo, en sistemas más grandes, se debe nombrar un arquitecto de sistemas para delinear el sistema general y para interactuar entre los usuarios, patrocinadores y otras partes interesadas por un lado y los ingenieros por el otro. Los sistemas muy grandes y muy complejos pueden incluir varios 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, conciliando las necesidades y los requisitos de los usuarios con lo que los ingenieros han determinado que es factible dentro de las restricciones (de ingeniería) dadas.
En el diseño de sistemas , los arquitectos (e ingenieros) son responsables de:
- Interfaz con el (los) usuario (s) y patrocinador (es) y todas las demás partes interesadas para determinar sus necesidades (en evolución).
- Generando el más alto nivel de requisitos del sistema, basado en las necesidades de los usuarios y otras limitaciones.
- Asegurarse de que este conjunto de requisitos de alto nivel sea coherente , completo, correcto y definido operativamente .
- Realizar análisis de costo-beneficio para determinar si los requisitos se cumplen mejor mediante funciones manuales, de software o de hardware ; aprovechando al máximo los componentes comerciales disponibles en el mercado o ya desarrollados .
- Desarrollar algoritmos de partición (y otros procesos ) para asignar todos los requisitos presentes y previsibles en particiones discretas de modo que se necesite un mínimo de comunicaciones entre las particiones y entre los usuarios y el sistema.
- Partición de grandes sistemas en (capas sucesivas de) subsistemas y componentes, cada uno de los cuales puede ser manejado por un solo ingeniero o equipo de ingenieros o arquitecto subordinado.
- Interactuar con los ingenieros y arquitectos de diseño e implementación, para que cualquier problema que surja durante el diseño o la implementación se pueda resolver de acuerdo con los conceptos de diseño fundamentales y las necesidades y limitaciones de los usuarios.
- Asegurar que se desarrolle un diseño máximamente robusto y extensible .
- Generar un conjunto de requisitos de prueba de aceptación , junto con los diseñadores, ingenieros de prueba y los usuarios, que determinan que se han cumplido todos los requisitos de alto nivel, especialmente para la interfaz computadora-humano .
- Generar productos como bocetos , modelos , una guía de usuario temprana y prototipos para mantener a los usuarios e ingenieros constantemente actualizados y de acuerdo sobre el sistema que se proporcionará a medida que evoluciona.
- Asegurar que todos los productos arquitectónicos y los productos con entrada arquitectónica se mantengan en el estado más actual y nunca se permita que se retrasen seriamente o se vuelvan obsoletos.
Arquitecto de sistemas: temas
La arquitectura de sistemas grandes se desarrolló como una forma de manejar sistemas demasiado grandes para que una persona los concibiera, y mucho menos el diseño. Los sistemas de este tamaño se están convirtiendo rápidamente en la norma, por lo que los enfoques arquitectónicos y los arquitectos son cada vez más necesarios para resolver los problemas de los 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 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).
Usuarios y patrocinadores
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 del producto final y del proceso de derivar requisitos e implementar esa visión.
Los arquitectos no siguen los procedimientos exactos. Se comunican con los usuarios / patrocinadores de una manera muy interactiva y relativamente informal; juntos extraen los verdaderos requisitos necesarios para el sistema diseñado (final). 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 (los) entorno (s) de ingeniería de los posibles espacios de solución.
Requisitos de alto nivel
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 la lista de deseos, el arquitecto aporta el conocimiento de lo que probablemente resulte factible dentro del costo, el 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 los requisitos no comprobables, los malentendidos y la propagación de requisitos.
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 va a hacer algún compromiso, para cumplir con las limitaciones, el arquitecto debe asegurarse de que el producto final y la apariencia general no se alejen mucho de la intención de los usuarios. El ingeniero debe enfocarse en desarrollar un diseño que optimice las restricciones pero garantice un producto viable, confiable, extensible y robusto. La provisión de los servicios necesarios a los usuarios es la verdadera función de un sistema diseñado. 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, la aplicación limitada de los principios de desarrollo de sistemas tradicionales se ha encontrado que es insuficiente: la aplicación de principios más generales de sistemas, hardware, y se considera necesaria la arquitectura de software para el diseño de (sub) sistemas. La arquitectura también se puede ver 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 '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 de ingeniería. 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 apoyar al 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 la 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 de 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 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 acepta el sistema: 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.
Análisis de costo / beneficio
Los arquitectos son generalistas. No se espera que sean expertos en ninguna tecnología, pero se espera que conozcan muchas tecnologías y puedan juzgar su aplicabilidad a situaciones específicas. También aplican su conocimiento 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 comercializados o ya desarrollados pueden seleccionarse de forma independiente de acuerdo con limitaciones como el costo, la respuesta, el rendimiento, etc. En algunos casos, el arquitecto ya puede ensamblar el sistema final (casi) sin ayuda. O 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 la seguridad , la seguridad , las comunicaciones , hardware de propósito especial, gráficos , los factores humanos , prueba y evaluación , control de calidad , fiabilidad , facilidad de mantenimiento , la disponibilidad , la interfaz de gestión, etc. Un El equipo de arquitectura de sistemas eficaz debe tener acceso a especialistas en especialidades críticas según sea necesario.
Particionamiento y estratificación
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, es posible que se necesiten muchos ingenieros, además, para resolver los problemas detallados que surgen cuando se diseña un edificio novedoso 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, es posible que tengamos un arquitecto para el conjunto, y uno para cada tipo de edificio, como parte de un equipo arquitectónico.
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 recurrir a un arquitecto de hardware y / o un arquitecto de software para algunas partes del trabajo, aunque todos 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 solo ingeniero de hardware o software, o gerente de ingeniería y equipo. 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). Idealmente, cada componente / subsistema de este tipo es un objeto suficientemente independiente que se puede probar como un componente completo. separados del todo, utilizando solo un banco de pruebas simple para suministrar entradas simuladas y registrar 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 limitaciones bajo las cuales se espera que opere el subsistema.
Un buen arquitecto asegura que el sistema, por complejo que sea, se basa en conceptos relativamente simples y "limpios" para cada (sub) sistema o capa y es fácilmente comprensible para todos, especialmente los usuarios, sin una formación especial. El arquitecto utilizará un mínimo de heurística para asegurarse de que cada partición esté bien definida y libre de errores , soluciones , atajos o detalles confusos y excepciones. A medida que evolucionan las necesidades de los usuarios (una vez que el sistema está en el campo y en uso), es mucho más fácil desarrollar posteriormente un concepto simple que uno cargado de excepciones, casos especiales y mucha "letra pequeña".
Colocar la arquitectura en capas 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 las capas, los 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.
Examen de ingreso
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 como se planeó originalmente y que todos los arquitectos e ingenieros involucrados han cumplido sus objetivos.
Comunicaciones con usuarios e ingenieros
Un arquitecto de edificios utiliza bocetos, modelos y dibujos. Un arquitecto de sistemas de automatización (o software o hardware) debe usar bocetos, modelos y prototipos para discutir diferentes soluciones y resultados con usuarios, ingenieros y otros arquitectos. Una versión preliminar preliminar del manual del usuario es invaluable, especialmente junto con un prototipo. No obstante, es importante que se cree un conjunto de requisitos o especificaciones viables y bien redactados que sean razonablemente comprensibles para el cliente (de modo que puedan aprobarlo adecuadamente, pero los requisitos de los principales usuarios deben capturarse en una etapa preliminar). manual del usuario para la inteligibilidad). Pero debe usar 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 probables y el borrador inicial del plan de prueba debe desarrollarse al mismo tiempo que los requisitos. Todas las partes interesadas deben firmar las descripciones de las pruebas de aceptación , o equivalentes, como el único determinante de la satisfacción de los requisitos, al comienzo del programa.
Metáfora del arquitecto
El uso de cualquier forma de la palabra "arquitecto" está regulado por "leyes de título" en muchos estados de los EE. UU., Y una persona debe tener una licencia como arquitecto de construcción para usarlo. [1]
En el Reino Unido, la junta de registro de arquitectos excluye el uso de arquitecto (cuando se usa en el contexto de software y TI) de su uso restringido. [2]
Ver también
- Arquitectura empresarial
- Arquitecto Empresarial
- Arquitectura de hardware
- Análisis de requerimientos
- Arquitectura de software
- Ingeniería de software
- Arquitectura de sistemas
- Modelado de sistemas
- Ingeniería de Sistemas
- Diseño de sistemas
- Analista de negocios
- Marco de modelado orientado a servicios (SOMF)
Referencias
- ^ El término "arquitecto" es un título profesional protegido por la ley y restringido, en la mayoría de las jurisdicciones del mundo, a quienes están capacitados en la planificación, diseño y supervisión de la construcción de edificios . En estas jurisdicciones, cualquier persona que no sea un arquitecto con licencia tiene prohibido usar este título de cualquier manera . En el estado de Nueva York y en otros estados de EE. UU., El uso no autorizado del título "arquitecto" es un delito y está sujeto a procedimientos penales . "Arquitectura: lo que es legal, lo que no" (PDF) . AIA Estado de Nueva York . Consultado el 9 de julio de 2012 ."Arquitectura del estado de Nueva York: leyes, normas y reglamentos: arquitectura del artículo 147" . Consultado el 9 de julio de 2012 .
- ^ "Qué hacemos para regular el uso del título 'arquitecto ' " . Junta de Registro de Arquitectos . Consultado el 8 de julio de 2019 .
Otras lecturas
- Donald Firesmith et al .: The Method Framework for Engineering System Architectures , (2008)
- Mark W. Maier y Rechtin, Eberhardt, El arte de la arquitectura de sistemas , tercera edición (2009)
- Gerrit Muller, "Arquitectura de sistemas: una perspectiva empresarial", CRC Press, (2012).
- Eberhardt Rechtin , Arquitectura de sistemas: Creación y construcción de sistemas complejos , 1991.
- JH Saltzer , MF Kaashoek, Principios del diseño de sistemas informáticos: Introducción , Morgan Kaufmann, 2009.
- Rob Williams, Arquitectura de sistemas informáticos: un enfoque de redes , segunda edición (diciembre de 2006).
enlaces externos
- Principios del diseño de sistemas informáticos: una introducción - MIT OpenCourseWare
- Arquitectura de sistemas: Canaxia incorpora un arquitecto , artículo