1. CREACIÓN DE LA ARQUITECTURA DE UNA EMPRESA
1.1. DISEÑO DE LA ARQUITECTURA DE SISTEMAS
1.1.1. DISEÑAR LA ARQUITECTURA DE SISTEMAS DE UNA GRAN ORGANIZACIÓN ES UNA TAREA COMPLEJA
1.2. TECNOLOGÍAS ORIENTADAS POR OBJETOS
1.2.1. LA ORIENTACIÓN POR OBJETOS ES UN PARADIGMA IMPORTANTE EN LA INFORMÁTICA QUE PERMITE LA CREACIÓN DE COMPONENTES
1.3. PROMESAS DE LA ORIENTACIÓN POR OBJETOS
1.3.1. LA ORIENTACIÓN POR OBJETOS PROMETE FACILIDAD EN LA REUTILIZACIÓN DE CÓDIGO, PERO NO FUE CUMPLIDA HASTA LA LLEGADA DE LAS TECNOLOGÍAS DE EMPAQUETADO DE COMPONENTES
2. EMPAQUETADO DE COMPONENTES
2.1. EL SECRETO DEL EMPAQUETADO
2.1.1. EL EMPAQUETADO DE COMPONENTES ES POSIBLE GRACIAS A LA MADUREZ DE LAS TECNOLOGÍAS ACTUALES
2.2. TECNOLOGÍAS DE EMPAQUETADO
2.2.1. TRANSPARENCIA EN CUANTO A LA LOCALIZACIÓN
2.2.1.1. LOS COMPONENTES PUEDEN SER USADOS SIN PREOCUPARSE DE SU UBICACIÓN FÍSICA
2.2.2. INVOCACIÓN
2.2.2.1. LOS COMPONENTES PUEDEN SER CARGADOS Y EJECUTADOS CUANDO SEAN NECESARIOS, COMUNICÁNDOSE CON OTROS COMPONENTES Y LA APLICACIÓN A TRAVÉS DE LA RED
2.2.3. INTROSPECCIÓ
2.2.3.1. LOS COMPONENTES PUEDEN CENTRARSE EN SU FUNCIÓN SIN PREOCUPARSE DEL MUNDO EXTERIOR
2.2.4. DISTRIBUCIÓN
2.2.4.1. LOS COMPONENTES PUEDEN SER TRANSMITIDOS A TRAVÉS DE UNA RED
2.3. PROBLEMAS DEL EMPAQUETADO DE COMPONENTES
2.3.1. AUNQUE EL EMPAQUETADO DE COMPONENTES TIENE VENTAJAS, TAMBIÉN PUEDE AUMENTAR EL TAMAÑO DE LOS PROGRAMAS Y EMPEORAR SU RENDIMIENTO
3. TECNOLOGÍAS DE COMPONENTES
3.1. TECNOLOGÍAS RECIENTES
3.1.1. ACTIVES
3.1.1.1. ACTIVES POTENCIA LA DIVISIÓN EN COMPONENTES Y LA INTEROPERABILIDAD ENTRE DISTINTOS FABRICANTES
3.1.2. JAVA BEANS
3.1.2.1. JAVA BEANS PROPORCIONA UN CONTENEDOR PARA EL CÓDIGO, INDEPENDIENTEMENTE DEL LENGUAJE EN EL QUE ESTÉ ESCRITO
3.1.3. COMPONENTES DESARROLLADOS CON HERRAMIENTAS QUE CUMPLEN LAS ESPECIFICACIONES CORBA, SAP, ETC
3.1.3.1. ESTAS TECNOLOGÍAS PERMITEN LA ESPECIALIZACIÓN EN LA CREACIÓN DE OBJETOS COMPLEJOS Y DE MAYOR CALIDAD
4. LA LEY DE MOORE EN EL SOFTWARE
4.1. EJEMPLOS DE COMPONENTES ANTERIORES
4.1.1. VBX Y PLUG-INS
4.1.1.1. LOS VBX Y PLUG-INS FUERON COMPONENTES ANTERIORES QUE TENÍAN LIMITACIONES EN SU USO Y VALOR
4.2. DEFINICIÓN DE COMPONENTE DE SOFTWARES
4.2.1. UN COMPONENTE DE SOFTWARE ES UNA PIEZA CON FUNCIONES Y UNA INTERFAZ BIEN DEFINIDAS
4.3. MEJORAS EN LOS COMPONENTES ACTUALES
4.3.1. LOS COMPONENTES ACTUALES TIENEN MEJORAS EN SU USO Y VALOR EN COMPARACIÓN CON LOS ANTERIORES
5. LA TECNOLOGÍA DE COMPONENTES
5.1. FLEXIBILIDAD Y REUTILIZACIÓN DEL SOFTWARE
5.1.1. LA TECNOLOGÍA DE COMPONENTES PERMITE UNA MAYOR FLEXIBILIDAD Y REUTILIZACIÓN DEL SOFTWARE
5.2. ESPECIALIZACIÓN Y VENTAJAS EN LA INDUSTRIA DEL SOFTWARE
5.2.1. LA ESPECIALIZACIÓN EN LA INDUSTRIA DEL SOFTWARE ES SIMILAR A LA DE LA NATURALEZA
5.2.1.1. LA ESPECIALIZACIÓN EN LA INDUSTRIA DEL SOFTWARE PERMITE UNA PERSONALIZACIÓN MASIVA Y UNA REPLICACIÓN SIN PROBLEMAS
5.3. LIMITACIONES DE LOS COMPONENTES ANTERIORES
5.3.1. LOS COMPONENTES ANTERIORES TENÍAN LIMITACIONES EN CUANTO A SU USO Y VALOR
6. 3. CARACTERÍSTICAS DE UNA ARQUITECTURA DE SISTEMAS EFECTIVA
6.1. FLEXIBILIDAD PARA ADAPTARSE A CAMBIOS ORGANIZACIONALES
6.1.1. LA ARQUITECTURA DE SISTEMAS DEBE SER LO SUFICIENTEMENTE FLEXIBLE PARA ADAPTARSE A CAMBIOS EN LOS OBJETIVOS ORGANIZACIONALES
6.2. MEDICIÓN DE LA BONDAD DE UNA ARQUITECTURA
6.2.1. LA FORMA EN QUE UNA ARQUITECTURA SUSTENTA LAS APLICACIONES ES LA MEJOR FORMA DE MEDIR SU BONDAD
6.2.2. MEDICIÓN
6.3. ELEMENTOS CLAVE PARA FACILITAR EL DESARROLLO DE NUEVAS APLICACIONES
6.3.1. DIRECTIVAS CLARAS, APLICACIONES PERSONALIZABLES Y USO DE COMPONENTES Y PLUG-INS SON ELEMENTOS CLAVE PARA FACILITAR EL DESARROLLO DE NUEVAS APLICACIONES
7. OBSTÁCULOS DE LA ARQUITECTURA DE SISTEMAS
7.1. LA ARQUITECTURA ACTUAL COMO OBSTÁCULO
7.1.1. EN MUCHOS CASOS, LA ARQUITECTURA ACTUAL DE LOS SISTEMAS ES UN OBSTÁCULO PARA MEJORAR PROCESOS Y APLICACIONES
7.2. LIMITACIONES DE LA ARQUITECTURA DE SISTEMAS EN LOS AÑOS 90
7.2.1. EN LOS AÑOS 90, LA ARQUITECTURA DE SISTEMAS SE LIMITABA A LA PLANIFICACIÓN Y NO IBA MÁS ALLÁ
7.3. DEFINICIÓN DE UNA ARQUITECTURA OBJETIVO COMO ERROR
7.3.1. COMENZAR POR DEFINIR UNA ARQUITECTURA OBJETIVO ES UN ERROR EN LA PLANIFICACIÓN DE SISTEMAS
8. MEJORA DE PROCESOS Y APLICACIONES
8.1. RELACIÓN ENTRE MEJORA DE PROCESOS Y APLICACIONES
8.1.1. MEJORAR LOS PROCESOS Y APLICACIONES GENERA UN MEJOR RENDIMIENTO DE LA EMPRESA
8.2. NECESIDAD DE MEJORAR LOS SISTEMAS PARA MEJORAR LAS APLICACIONES
8.2.1. PARA MEJORAR LAS APLICACIONES ES NECESARIO MEJORAR LOS SISTEMAS
8.3. LA ARQUITECTURA DE SISTEMAS COMO VEHÍCULO DE DESARROLLO
8.3.1. LA ARQUITECTURA DE SISTEMAS DEBE SER EL VEHÍCULO DE DESARROLLO PARA MEJORAR PROCESOS Y APLICACIONES
9. ORGANIZACIONES CON ARQUITECTURAS EVOLUTITATIVAS
9.1. FERENCIA POR DIRECTIVAS EN LUGAR DE ESTÁNDARES
9.1.1. LAS ORGANIZACIONES CON ARQUITECTURAS EVOLUTIVAS PREFIEREN LAS DIRECTIVAS A LOS ESTÁNDARES
9.2. USO DE TECNOLOGÍA ORIENTADA A COMPONENTES
9.2.1. LAS ORGANIZACIONES CON ARQUITECTURAS EVOLUTIVAS UTILIZAN TECNOLOGÍA ORIENTADA A COMPONENTES
9.3. FLEXIBILIDAD COMO NECESIDAD FUNDAMENTAL
9.3.1. A FLEXIBILIDAD ES UNA NECESIDAD FUNDAMENTAL EN LAS ARQUITECTURAS DE SISTEMAS MODERNOS
10. ENFOQUE EVOLUTIVO EN LA ARQUITECTURA DE SISTEMAS
10.1. ADAPTACIÓN AL MODELO EVOLUTIVO
10.1.1. LA ARQUITECTURA DE SISTEMAS SE ADAPTA AL MODELO EVOLUTIVO, BASADO EN LA DEPENDENCIA Y LA SUPERVIVENCIA DE LOS MÁS FUERTES
10.2. USO DE MÉTODOS EVOLUTIVOS EN EL DESARROLLO DE SOFTWARE
10.2.1. LOS MÉTODOS EVOLUTIVOS SON POPULARES EN EL DESARROLLO DE SOFTWARE A MEDIDA, REDUCIENDO EL RIESGO DE FALLOS Y COSTOS
10.3. TECNODIVERSIDAD COMO CLAVE PARA LA SUPERVIVENCIA
10.3.1. LA TECNODIVERSIDAD ES FUNDAMENTAL PARA LA SUPERVIVENCIA DE LOS SISTEMAS, CREANDO UN ENTORNO QUE PROPICIE LA DIVERSIDAD TECNOLÓGICA