En los sistemas de información , la arquitectura de aplicaciones o la arquitectura de aplicaciones es uno de los varios dominios de arquitectura que forman los pilares de una arquitectura empresarial (EA). [1] [2]
Una arquitectura de aplicaciones describe el comportamiento de las aplicaciones utilizadas en una empresa, centrándose en cómo interactúan entre sí y con los usuarios. Se centra en los datos consumidos y producidos por las aplicaciones más que en su estructura interna. En la gestión de la cartera de aplicaciones , las aplicaciones se asignan a las funciones y procesos comerciales, así como a los costos, la calidad funcional y la calidad técnica para evaluar el valor proporcionado.
La arquitectura de las aplicaciones se especifica sobre la base de los requisitos funcionales y comerciales . Esto implica definir la interacción entre paquetes de aplicaciones, bases de datos y sistemas de middleware en términos de cobertura funcional. Esto ayuda a identificar cualquier problema de integración o brechas en la cobertura funcional. A continuación, se puede elaborar un plan de migración para los sistemas que se encuentran al final del ciclo de vida del software o que tienen riesgos tecnológicos inherentes.
La arquitectura de aplicaciones intenta garantizar que el conjunto de aplicaciones que utiliza una organización para crear la arquitectura compuesta sea escalable , confiable , disponible y manejable.
La arquitectura de aplicaciones define cómo varias aplicaciones están preparadas para trabajar juntas. Es diferente de la arquitectura de software , que se ocupa de los diseños técnicos de cómo se construye un sistema. [ cita requerida ]
No solo es necesario comprender y administrar la dinámica de las funcionalidades que está implementando la arquitectura compuesta, sino también ayudar a formular la estrategia de implementación y estar atento a los riesgos tecnológicos que podrían poner en peligro el crecimiento y / o las operaciones de la organización. [ cita requerida ]
Estrategia
La estrategia de arquitectura de aplicaciones implica asegurar que las aplicaciones y las integraciones se alineen con la estrategia de crecimiento de la organización. Si una organización es una organización de fabricación con planes de crecimiento rápido a través de adquisiciones, la arquitectura de las aplicaciones debe ser lo suficientemente ágil como para abarcar los sistemas heredados heredados, así como otros grandes sistemas competidores.
Patrones
Las aplicaciones se pueden clasificar en varios tipos según el patrón de arquitectura de aplicaciones que siguen.
Un "patrón" se ha definido como: "una idea que ha sido útil en un contexto práctico y probablemente será útil en otros".
Para crear patrones, se necesitan bloques de construcción. Los bloques de construcción son componentes de software, en su mayoría reutilizables, que se pueden utilizar para crear ciertas funciones. Los patrones son una forma de poner los bloques de construcción en contexto y describen cómo usar los bloques de construcción para abordar una o varias inquietudes arquitectónicas.
Una aplicación es una compilación de varias funcionalidades, todas típicamente siguiendo el mismo patrón. Este patrón define el patrón de la aplicación.
Los patrones de aplicación pueden describir características estructurales (relacionadas con la implementación / distribución) o de comportamiento (flujo de proceso o relacionadas con la interacción / integración) y una arquitectura de aplicación puede aprovechar uno o una combinación de patrones. La idea de patrones ha existido casi desde el comienzo de las ciencias de la computación, pero fue popularmente popularizada por la "Banda de los Cuatro" (GoF), aunque muchos de sus patrones son patrones de "arquitectura de software" en lugar de patrones de "arquitectura de aplicaciones". Además del GoF, Thomas Erl es un conocido autor de varios tipos de patrones, y la mayoría de los grandes proveedores de herramientas de software, como Microsoft, han publicado extensas bibliotecas de patrones.
A pesar de la gran cantidad de patrones que se han publicado, hay relativamente pocos patrones que puedan considerarse "estándar de la industria". Algunos de los más conocidos incluyen:
- Aplicación de escritorio / cliente grueso / de un solo nivel (patrón estructural): una aplicación que existe solo en una sola computadora, generalmente una computadora de escritorio. Por supuesto, se puede tener la misma aplicación de escritorio en muchas computadoras, pero no interactúan entre sí (con raras excepciones).
- cliente-servidor / 2 niveles (patrón estructural): una aplicación que consta de una capa de front-end (de cara al usuario) que se ejecuta como un cliente enriquecido que se comunica con un back-end (servidor) que proporciona lógica empresarial, flujo de trabajo e integración y servicios de datos. A diferencia de las aplicaciones de escritorio (que son de un solo usuario), las aplicaciones cliente-servidor son casi siempre aplicaciones multiusuario.
- n-tier (patrón estructural): una extensión del patrón cliente-servidor, donde las funciones del servidor se dividen en múltiples capas, que se distribuyen en diferentes computadoras a través de una red de área local (LAN).
- distribuido (patrón estructural): una extensión del patrón de n niveles donde las funciones del servidor se distribuyen en una red de área amplia (WAN) o en la nube. Este patrón también incluye algunos atributos de patrón de comportamiento porque las funciones del servidor deben diseñarse para ser más autónomas y funcionar en un diálogo asincrónico con las otras funciones para lidiar con la latencia potencialmente significativa que puede ocurrir en escenarios de implementación de WAN y en la nube.
- escalabilidad horizontal (patrón estructural): un patrón para ejecutar múltiples copias de funciones de servidor en múltiples computadoras de tal manera que el aumento de la carga de procesamiento se puede distribuir en un número creciente de instancias de las funciones en lugar de tener que volver a implementar las funciones en más grandes, ordenadores más potentes. Las aplicaciones nativas de la nube se basan fundamentalmente en la escalabilidad horizontal.
- Arquitectura impulsada por eventos (patrón de comportamiento): eventos de datos (que pueden haberse originado inicialmente en un dispositivo, aplicación, usuario, almacén de datos o reloj) y lógica de detección de eventos que puede descartar condicionalmente el evento, iniciar un proceso relacionado con el evento, alertar a un usuario o administrador de dispositivos, o actualizar un almacén de datos. El patrón controlado por eventos es fundamental para el procesamiento asincrónico requerido por el patrón de arquitectura distribuida.
- ETL (patrón de comportamiento): un patrón de proceso de aplicación para extraer datos de una fuente de origen, transformar esos datos de acuerdo con algunas reglas comerciales y luego cargar esos datos en un destino. Las variaciones en el patrón ETL incluyen ELT y ETLT.
- Solicitud-respuesta (patrón de comportamiento): un patrón de integración de aplicaciones para el intercambio de datos en el que la aplicación solicita datos de otra aplicación y espera una respuesta que contenga los datos solicitados. Este es el ejemplo más destacado de un patrón sincrónico, en contraste con el procesamiento asincrónico al que se hace referencia en las descripciones de patrones anteriores.
El patrón de aplicaciones correcto depende de la industria de la organización y del uso de las aplicaciones de los componentes. Una organización podría tener una combinación de múltiples patrones si ha crecido tanto orgánicamente como a través de adquisiciones.
Arquitecto de aplicaciones
TOGAF describe tanto las habilidades como las expectativas de rol de un arquitecto de aplicaciones . Estas habilidades incluyen una comprensión de la modularización / distribución de aplicaciones, integración, alta disponibilidad y patrones de escalabilidad, tecnología y tendencias. Cada vez más, la comprensión de los contenedores de aplicaciones, la computación sin servidor, el almacenamiento, los datos y el análisis, y otras tecnologías y servicios relacionados con la nube, son habilidades necesarias para los arquitectos de aplicaciones. Si bien una experiencia en software es una gran base para un arquitecto de aplicaciones, la programación y el diseño de software no son habilidades que se requieren de un arquitecto de aplicaciones (en realidad, son habilidades para un arquitecto de software, que es un líder en el equipo de programación de computadoras ).
Dominios del conocimiento
- Modelado de aplicaciones
- Emplea el modelado como marco para la implementación e integración de aplicaciones nuevas o mejoradas, usa el modelado para encontrar problemas, reducir el riesgo, mejorar la previsibilidad, reducir el costo y el tiempo de comercialización, prueba varios escenarios de productos, incorporando las necesidades / requisitos no funcionales de los clientes, agrega decisiones de diseño de prueba al proceso de desarrollo según sea necesario, evalúa los problemas de diseño del producto.
- Inteligencia competitiva , modelado de negocios , análisis estratégico
- Comprensión del mercado global, consumidores, industrias y competencia, y cómo se interrelacionan los modelos, estrategias, finanzas, operaciones y estructuras de negocios globales. Comprensión del entorno competitivo, incluida la tendencia actual en el mercado, la industria, la competencia y el entorno regulatorio, así como la comprensión de cómo los componentes del modelo comercial (es decir, estrategia, finanzas, operaciones) se interrelacionan para hacer que la organización sea competitiva en el mercado. Comprensión de los procesos comerciales , los sistemas, las herramientas, las regulaciones y la estructura de la organización y cómo se interrelacionan para proporcionar productos y servicios que crean valor para los clientes, consumidores y partes interesadas clave. La comprensión de cómo el valor crea para los clientes, consumidores y partes interesadas clave se alinea con la visión, el negocio, la cultura, la propuesta de valor, la promesa de marca y los imperativos estratégicos de la organización. Comprensión de los logros y deficiencias pasados y presentes de la organización para evaluar las fortalezas, debilidades, oportunidades y riesgos en relación con el entorno competitivo.
- Tecnología
- Comprensión de la estrategia de TI , el ciclo de vida del desarrollo y el mantenimiento de la infraestructura / aplicaciones; Comprensión de los procesos de soporte y servicio de TI para promover una ventaja competitiva, crear eficiencias y agregar valor al negocio.
- Estándares tecnológicos
- Demuestra una comprensión profunda de las tecnologías clave que forman la infraestructura necesaria para respaldar de manera efectiva los requisitos comerciales actuales y futuros , garantiza que todo el hardware y el software cumplan con los requisitos y estándares básicos antes de integrarse en el entorno comercial, comprende y puede desarrollar estándares técnicos y procedimientos para facilitar el uso de nuevas tecnologías, desarrolla pautas útiles para el uso y aplicación de nuevas tecnologías.
Tareas
Un arquitecto de aplicaciones es un maestro de todo lo específico de la aplicación en una organización. Un arquitecto de aplicaciones proporciona pautas estratégicas a los equipos de mantenimiento de aplicaciones al comprender todas las aplicaciones desde las siguientes perspectivas:
- Capacidad de interoperabilidad
- Rendimiento y escalabilidad
- Fiabilidad y disponibilidad
- Etapa del ciclo de vida de la aplicación
- Riesgos tecnológicos
- Numero de instancias
El análisis anterior señalará las aplicaciones que necesitan una variedad de cambios, desde un cambio en la estrategia de implementación para aplicaciones fragmentadas hasta un reemplazo total de aplicaciones al final de su ciclo de vida de tecnología o funcionalidad.
Huella de funcionalidad
Comprender el flujo de procesos del sistema de los procesos comerciales primarios. Ofrece una imagen clara del mapa de funciones y la huella de las aplicaciones de varias aplicaciones en el mapa.
Muchas organizaciones no tienen disciplina en la documentación y, por lo tanto, carecen de flujos de procesos de negocio detallados y flujos de procesos del sistema. Uno puede tener que iniciar una iniciativa para ponerlos en su lugar primero.
Crear pautas de arquitectura de soluciones
Cada organización tiene un conjunto básico de aplicaciones que se utilizan en varias divisiones, ya sea como una sola instancia o como una instancia diferente por división. Cree una plantilla de arquitectura de solución para todas las aplicaciones principales, de modo que todos los proyectos tengan un punto de partida común para diseñar implementaciones.
Los estándares en el mundo de la arquitectura se definen en TOGAF, The Open Group Architecture Framework describe los cuatro componentes de EA como BDAT ( Arquitectura empresarial , Arquitectura de datos , Arquitectura de aplicaciones y Arquitectura técnica ,
También hay otros estándares a considerar, dependiendo del nivel de complejidad de la organización:
- El marco de Zachman para EA
- Arquitectura empresarial federal (FEA)
- Gartner [3]
Ver también
- ISO / IEC 42010 Ingeniería de sistemas y software: la descripción de la arquitectura es un estándar internacional para las descripciones de la arquitectura de los sistemas y el software.
- IEEE 1471 un estándar IEEE reemplazado para describir la arquitectura de un "sistema intensivo en software", también conocido como arquitectura de software .
- Arquitectura de aplicaciones de sistemas IBM
- Planificación de la arquitectura empresarial
- Arquitectura de aplicaciones de alta disponibilidad
Referencias
- ^ Steven Spewak ; SC Hill (1992). Planificación de la arquitectura empresarial: desarrollo de un plan para datos, aplicaciones y tecnología . Boston, Pub QED. Grupo. ISBN 978-0-471-59985-2.
- ^ "Modelo de referencia para certificados ISEB en arquitectura empresarial y de soluciones versión 3.0" (PDF) . bcs. 2010.
- ^ "Arquitectura de aplicaciones" . Glosario de TI de Gartner . 2012-02-09 . Consultado el 26 de julio de 2017 .
- "Fase C: Arquitecturas de sistemas de información - Arquitectura de aplicaciones" . TOGAF 9.1 . Consultado el 26 de julio de 2017 .
- Hunter, Roy; Rasmussen, Brian. "Arquitectura de Aplicaciones" . Oracle . Consultado el 26 de julio de 2017 .