SlideShare una empresa de Scribd logo
1 de 11
Descargar para leer sin conexión
Arquitectura empresarial para Ingenieros de Sistemas -
                      Resumen

Introducción
  ● En muchas ocasiones los Ingenieros de Sistemas se olvidan de detalles tan importantes
    como la interoperabilidad con sistemas existentes dentro de la organización o fuera de
    ella.
  ● En este resumen se podrán encontrar puntos importantes que ayudarán a los ingenieros
    de sistemas a comprender mejor cómo sus esfuerzos en los proyectos que crean
    o modifican sistemas pueden verse limitados por, y pueden a su vez modificar la
    arquitectura de la empresa a la cual soportan dichos sistemas.
  ● Hoy por hoy, se reconoce que hay una relación entre la funcionalidad que proveen
    proveen los proyectos y la capacidad de los negocios de la empresa.



El cambiante panorama del desarrollo de sistemas




  ● Las empresas necesitan sistemas integrados, esto es resultado de que las mismas
    empresas están haciendo a un lado a aquellos sistemas que ofrecen funcionalidad
    aislada. Con lo anterior en mente, el objetivo principal es ofrecer operaciones robustas y
    eficientes.
  ● En el momento de modificar un sistema, el ingeniero de sistemas debe evitar focalizarse
    sólo en los casos del sistema en modificación, sino ser consciente de cómo interactúan
    con otros sistemas dentro de la empresa.

  ●   La Figura 1 presenta una descripción general de cómo se diferencian focos en distintos
      épocas:
Definiciones
  ● Para entrar en detalles es importante resaltar algunos términos que nos conduzcan a
    tener un contexto claro sobre Sistemas.

  ●   Empresa

         ○   Es una organización de negocios.
         ○   Una compañía podría ser parte de un conglomerado de compañías.
         ○   Una compañía se la puede considerar como un sistema a gran escala.
         ○   Características:
                ■ Razón de ser.
                ■ Posee una financiación que le permite operar.
                ■ Lleva a cabo algunas acciones para cumplir su objetivo.
                 ■ Integrada por sistemas de menor nivel, componentes, trabajadores que
                    actúan conjuntamente para alcanzar su funcionalidad.

  ●   Arquitectura Empresarial

         ○ Descripción de la arquitectura de la empresa en cuestión.
         ○ La disciplina de la Arquitectura Empresarial aúna negocio, estrategia, proceso,
           método y componentes desde una cantidad de perspectivas diferentes.
○     Las Arquitecturas Empresariales están definidas por Arquitectos Empresariales.

       ○     La actividad de un Arquitecto Empresarial, es describir los componentes de una
             empresa, sus relaciones, cómo colaboran e interactúan entre sí con el “mundo
             exterior.
           ○ Una Arquitectura Empresarial ofrece la orientación para implantar los
             componentes de la empresa. Una vez implantados, produce un cambio en la
             empresa.

●   Sistema

       ○ Un sistema es un grupo de elementos que forman un todo unificado y cumplen
         un fin común.
       ○ Todo sistema tiene un fin, y es el de satisfacer las necesidades de los
         involucrados, es decir los requisitos del sistema.
       ○ Los requisitos definen qué funcionalidad se muestra, y cómo se debe mostrar la
         funcionalidad dadas las cualidades requeridas.
       ○ A la funcionalidad se le puede imponer unas restricciones o limitaciones (es
         decir, requisitos no funcionales o atributos de calidad).
       ○ Para satisfacer las necesidades de los involucrados, los componentes ejecutan
         unas acciones para alcanzar los objetivos establecidos.

       ○ Vale la pena mencionar, que un componente puede ser:
            ■ Software
            ■ Hardware
            ■ Personas o trabajadores
       ○ Es posible considerar a un componente como un sistema, dada su complejidad,
         tamaño o funcionalidad ofrecida. También se pueden mencionar como
         subsistemas.

●   Ingeniero de Sistemas

       ○     Se ha observado que los «Ingenieros de Sistemas» ser responsables de todo:
                ■ Planeamiento
                ■ Obtención de requisitos
                ■ Captura de arquitectura
                ■ Integración
                ■ Testeo

        ○ Muchas de las actividades desempeñadas por un Ingeniero de Sistemas
          trascienden la disciplina tradicional de la Ingeniería de Sistemas.
       ○ En el contexto de artículo, el Ingeniero de Sistemas es responsable de crear o
          actualizar la arquitectura del sistema, cumpliendo con todas las restricciones por
          la empresa en general.

●   Programa

       ○     Cuando se adopta un programa se pretende cambiar el estado de la empresa:
                ■ Proporcionar alguna capacidad nueva o mejorada.

       ○     Un programa se integra en una empresa para agregar o modificar componentes.
○ Los programas apoyan las actividades de la empresa en cierta medida.
            Generalmente están por debajo del alcance de la empresa.

  ●   Proyecto

         ○ Un proyecto es un conjunto de actividades que poseen un inicio y un único fin o
           propósito.
         ○ De un proyecto se espera una nueva capacidad medible.
         ○ Es muy común que un proyecto se focalice o centre en la introducción de
           un sistema nuevo en la empresa, o inclusive, en la modificación de uno ya
           existente.

         ○   Todo proyecto tiene:
                ■ Objetivos, y
                ■ Presupuestos.

         ○   Normalmente se combinan con otros proyectos formando parte de un programa.

          ○ En la Figura 2, se muestra cómo los programas y los proyectos afectan a la
            empresa.




Descripción del nivel actual de la empresa
  ●   Una empresa tiene una serie de requisitos que debe cumplir.
  ●   Es normal encontrarse con arquitecturas empresariales no documentadas. Cuando todo
      lo contrario, es decir, la empresa cuenta con la descripción formal de la arquitectura,
      encontramos los siguientes elementos:
○   componentes (sus relaciones y colaboraciones),
        ○   diagramas,
        ○   dibujos,
        ○   documentos,
        ○   modelos,
        ○   etc.

  ● Un componente es puesto a prueba con el propósito de verificar que cumpla con sus
    requisitos.
  ● Las pruebas existentes ayudan a identificar incompatibilidades, posibles daños que
    pudiera causar el componente, daño de funcionalidad de mayor nivel por la forma en
    que interactúa con otros componentes.

  ● Cuando se combinan los artefactos ya mencionados, forman una descripción completa
    de elementos clave de la situación actual de la empresa. Ver Figura 3:




Los programas cambian a la empresa
 ● No hay que olvidar que un programa mueve a una empresa de un estado actual a un
   estado futuro.
 ● Para describir el estado futuro, es necesario la creación artefactos.
● Cuando se introducen modificaciones, es necesario documentarlas, ya que facilitan la
  descripción del estado futuro. (También se pueden conocer como deltas documentales).

● Cuando no se captura correctamente el estado actual, lo más seguro es llegar a
  conclusiones erróneas sobre el estado futuro.

● Los programas pueden modificar un aspecto concreto de la empresa, y en ciertas
   ocasiones todo el negocio de la misma.
● La posibilidad de poder modificar artefactos actuales permite prepararse para cambios
   futuros radicales. Además, de evitar la espera de cualquier programa de cambio.
 ● Para tener una representación completa y coherente de la empresa, todos los
   programas empresariales deben usar convenciones estándares para reprentar:
       ○ Artefactos actuales, y
       ○ Artefactos futuros
● Los artefactos actuales deben conservarse como un repositorio único homogéneo.
       ○ Coherente
       ○ Consistente
       ○ Seguro
       ○ Representación legible

● Si actualmente se poseen artefactos es posible emprender la búsqueda nuevos
  artefactos para la introducción de futuros cambios en la empresa.

       ○   Para lo anterior se requiere los deltas de:
              ■ requisitos,
              ■ actualizaciones a la arquitectura, y
              ■ modificaciones en las pruebas acordes a los cambios de requisitos.

● Los deltas de los requisitos capturan los cambios deseados en el comportamiento
  esperado.
● La satisfacción de los deltas de los requisitos, impulsan los deltas de la arquitectura.

● Las pruebas permiten reconocer si los requisitos han sido cumplidos y para detectar
  cualquier defecto en la implantación, los requisitos, o las pruebas propiamente dichas.
● Es posible que un programa introduzca defectos adicionales a nivel de la empresa.
● La Figura 4 muestra el flujo de artefactos.
.




Los proyectos implementan el programa
   ● Los programas definen un conjunto de cambios que crean o modifican alguna
     capacidad de extremo a extremo.
  ● Desde luego para introducir una nueva capacidad al sistema general, es necesario la
     creación de sistemas nuevos o modificación de varios sistemas existentes, por medio
     de :
         ○ Adquisición de una aplicación nueva, o
         ○ cambiando algún proceso.
  ● Los programas introducen nueva funcionalidad.
  ● En la Figura 5 se ilustra cómo un requisito a nivel del programa se asigna directamente
     a un único sistema.
● Si el alcance del proyecto consiste en modificar un sistema existente, entonces el
  sistema tiene un estado actual.
      ○ Tiene requisitos que cumplir,
      ○ una arquitectura,
      ○ pruebas que han sido realizadas, y
      ○ probablemente algunos defectos abiertos.

 ● Se pueden crear artefactos futuros a partir de artefactos de sistemas/empresa
   existentes.
● El programa puede brindar actualizaciones tanto para artefactos de sistemas como
   también artefactos de la empresa.
● La Figura 6 muestra las relaciones existentes entre artefactos de sistemas actuales y
   artefactos de proyectos:
Unir todas las piezas
 ●  Los flujos de extremo a extremo permiten la evolución, crecimiento de la empresa y de
    los sistemas que ésta posee, a través de la ejecución de programas y proyectos.
  ● La Figura 7 muestra el flujo completo, de extremo a extremo, para esta visión
    simplificada.
Conclusión
 ● Las organizaciones se han puesto firmes en el proceso de crear buenas prácticas para
   la administración de sus artefactos, y esto, les está trayendo enormes beneficios para
   potenciar los artefactos.
 ● Para administrar eficientemente la evolución de la empresa, es necesario comprender
   sus requisitos y funcionalidad actuales y cómo se logra esa funcionalidad (su
   arquitectura).
 ● Las pruebas al desempeño permiten detectar defectos.
 ● Las organizaciones son capaces de de planificar eficientemente la evolución de la
   empresa, teniendo una visión clara del estado actual.
 ● Capturar la mayor parte de los artefactos de la empresa, permite obtener mejores
   beneficios en la implementación de un programa.
 ● Es necesario tener una visión precisa del estado actual de la empresa para su correcto
   funcionamiento.

 ●   Los beneficios de la reutilización se multiplican por la cantidad de sistemas.
● La complejidad de muchos sistemas ha superado ampliamente la capacidad de
  cualquier individuo para mantenerlo completamente en su mente.

● Se ha ilustrado cómo la arquitectura de la empresa brinda la base para su evolución
  mediante los programas.

Más contenido relacionado

La actualidad más candente

El ciclo de vida del desarrollo de los sistemas de información
El ciclo de vida del desarrollo de los sistemas de informaciónEl ciclo de vida del desarrollo de los sistemas de información
El ciclo de vida del desarrollo de los sistemas de información
Jose Daniel Pacheco Mejia
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
eros.viggiano
 
Prototipação de software
Prototipação de softwarePrototipação de software
Prototipação de software
leopp
 
Experiences with enterprise architecture using togaf and ibm rational system ...
Experiences with enterprise architecture using togaf and ibm rational system ...Experiences with enterprise architecture using togaf and ibm rational system ...
Experiences with enterprise architecture using togaf and ibm rational system ...
james_dzidek
 

La actualidad más candente (20)

Learn Togaf 9.1 in 100 slides!
Learn Togaf 9.1 in 100 slides!Learn Togaf 9.1 in 100 slides!
Learn Togaf 9.1 in 100 slides!
 
Togaf adm (face c)
Togaf   adm (face c)Togaf   adm (face c)
Togaf adm (face c)
 
Mejorando la Gestión de la gerencia de TI
Mejorando la Gestión de la gerencia de TIMejorando la Gestión de la gerencia de TI
Mejorando la Gestión de la gerencia de TI
 
TOGAF
TOGAFTOGAF
TOGAF
 
Artefactos Arquitectura Empresarial Biblioteca Digital
Artefactos Arquitectura Empresarial Biblioteca DigitalArtefactos Arquitectura Empresarial Biblioteca Digital
Artefactos Arquitectura Empresarial Biblioteca Digital
 
El ciclo de vida del desarrollo de los sistemas de información
El ciclo de vida del desarrollo de los sistemas de informaciónEl ciclo de vida del desarrollo de los sistemas de información
El ciclo de vida del desarrollo de los sistemas de información
 
Togaf introduction and core concepts
Togaf introduction and core conceptsTogaf introduction and core concepts
Togaf introduction and core concepts
 
Arquitectura Empresarial - Enterprise Architecture
Arquitectura Empresarial - Enterprise ArchitectureArquitectura Empresarial - Enterprise Architecture
Arquitectura Empresarial - Enterprise Architecture
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Stepping-stones of enterprise-architecture: Process and practice in the real...
Stepping-stones of enterprise-architecture: Process and practice in the real...Stepping-stones of enterprise-architecture: Process and practice in the real...
Stepping-stones of enterprise-architecture: Process and practice in the real...
 
Prototipação de software
Prototipação de softwarePrototipação de software
Prototipação de software
 
Architecture Series 5-5 Effective Enterprise Architecture Action Plan
Architecture Series 5-5   Effective Enterprise Architecture Action PlanArchitecture Series 5-5   Effective Enterprise Architecture Action Plan
Architecture Series 5-5 Effective Enterprise Architecture Action Plan
 
Arquitectura de Empresa TOGAF
Arquitectura de Empresa TOGAFArquitectura de Empresa TOGAF
Arquitectura de Empresa TOGAF
 
Enterprise Architecture basics
Enterprise Architecture basicsEnterprise Architecture basics
Enterprise Architecture basics
 
Governança da Arquitetura Corporativa
Governança da Arquitetura CorporativaGovernança da Arquitetura Corporativa
Governança da Arquitetura Corporativa
 
Crystal Methodologies
Crystal MethodologiesCrystal Methodologies
Crystal Methodologies
 
Togaf introduction ver1 0
Togaf introduction ver1 0Togaf introduction ver1 0
Togaf introduction ver1 0
 
Sistemas operativos resumen
Sistemas operativos resumenSistemas operativos resumen
Sistemas operativos resumen
 
Enterprise Architecture
Enterprise ArchitectureEnterprise Architecture
Enterprise Architecture
 
Experiences with enterprise architecture using togaf and ibm rational system ...
Experiences with enterprise architecture using togaf and ibm rational system ...Experiences with enterprise architecture using togaf and ibm rational system ...
Experiences with enterprise architecture using togaf and ibm rational system ...
 

Similar a Arquitectura empresarial para ingenieros de sistemas - Resumen

Planificación y Modelado
Planificación y ModeladoPlanificación y Modelado
Planificación y Modelado
DiaNa González
 
1315 ignacio garcia orange 2013 10 17 plan director de sistemas (aaee)
1315 ignacio garcia orange 2013 10 17   plan director de sistemas (aaee)1315 ignacio garcia orange 2013 10 17   plan director de sistemas (aaee)
1315 ignacio garcia orange 2013 10 17 plan director de sistemas (aaee)
SpainAEA
 
Cómo abordar un Plan Director: lecciones aprendidas
Cómo abordar un Plan Director: lecciones aprendidasCómo abordar un Plan Director: lecciones aprendidas
Cómo abordar un Plan Director: lecciones aprendidas
Spain-AEA
 

Similar a Arquitectura empresarial para ingenieros de sistemas - Resumen (20)

Administracion de proyectos de sist infor
Administracion de proyectos de sist inforAdministracion de proyectos de sist infor
Administracion de proyectos de sist infor
 
Relación Sistemas-Proceso
Relación Sistemas-ProcesoRelación Sistemas-Proceso
Relación Sistemas-Proceso
 
ResCapitulo 6-Arquitectura_de_Integracion_Tecnica
ResCapitulo 6-Arquitectura_de_Integracion_TecnicaResCapitulo 6-Arquitectura_de_Integracion_Tecnica
ResCapitulo 6-Arquitectura_de_Integracion_Tecnica
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
 
isu1modelodenegocios-160918001452.pdf
isu1modelodenegocios-160918001452.pdfisu1modelodenegocios-160918001452.pdf
isu1modelodenegocios-160918001452.pdf
 
2 introduccion al pmbok
2 introduccion al pmbok2 introduccion al pmbok
2 introduccion al pmbok
 
Planificación de proyecto de software
Planificación de proyecto de softwarePlanificación de proyecto de software
Planificación de proyecto de software
 
Pym
PymPym
Pym
 
Planificación y Modelado
Planificación y ModeladoPlanificación y Modelado
Planificación y Modelado
 
Pym
PymPym
Pym
 
1315 ignacio garcia orange 2013 10 17 plan director de sistemas (aaee)
1315 ignacio garcia orange 2013 10 17   plan director de sistemas (aaee)1315 ignacio garcia orange 2013 10 17   plan director de sistemas (aaee)
1315 ignacio garcia orange 2013 10 17 plan director de sistemas (aaee)
 
Cómo abordar un Plan Director: lecciones aprendidas
Cómo abordar un Plan Director: lecciones aprendidasCómo abordar un Plan Director: lecciones aprendidas
Cómo abordar un Plan Director: lecciones aprendidas
 
¿El ERP implementado cubre sus expectativas? Las revisiones post implantación...
¿El ERP implementado cubre sus expectativas? Las revisiones post implantación...¿El ERP implementado cubre sus expectativas? Las revisiones post implantación...
¿El ERP implementado cubre sus expectativas? Las revisiones post implantación...
 
Ejemplo proyecto informatico.pptx
Ejemplo proyecto informatico.pptxEjemplo proyecto informatico.pptx
Ejemplo proyecto informatico.pptx
 
Proyecto de reingenieria de software
Proyecto de reingenieria  de softwareProyecto de reingenieria  de software
Proyecto de reingenieria de software
 
Administración de proyectos
Administración de proyectosAdministración de proyectos
Administración de proyectos
 
Administración de proyectos
Administración de proyectosAdministración de proyectos
Administración de proyectos
 
MODELAMIENTO DE NEGOCIO
MODELAMIENTO DE NEGOCIOMODELAMIENTO DE NEGOCIO
MODELAMIENTO DE NEGOCIO
 
RUP
RUPRUP
RUP
 
Enrique Cabello
Enrique CabelloEnrique Cabello
Enrique Cabello
 

Más de John Ortiz

Más de John Ortiz (17)

Axiomas de peano para nat
Axiomas de peano para natAxiomas de peano para nat
Axiomas de peano para nat
 
Características de la información valiosa
Características de la información valiosaCaracterísticas de la información valiosa
Características de la información valiosa
 
Ejemplo 1 - Propiedades de las Operaciones entre Conjuntos
Ejemplo 1  - Propiedades de las Operaciones entre ConjuntosEjemplo 1  - Propiedades de las Operaciones entre Conjuntos
Ejemplo 1 - Propiedades de las Operaciones entre Conjuntos
 
Operaciones sobre Conjuntos
Operaciones sobre ConjuntosOperaciones sobre Conjuntos
Operaciones sobre Conjuntos
 
The Observer Pattern (Definition using UML)
The Observer Pattern (Definition using UML)The Observer Pattern (Definition using UML)
The Observer Pattern (Definition using UML)
 
TI en Las Organizaciones - Cadena de Valor - Actividades de Soporte
TI en Las Organizaciones - Cadena de Valor - Actividades de SoporteTI en Las Organizaciones - Cadena de Valor - Actividades de Soporte
TI en Las Organizaciones - Cadena de Valor - Actividades de Soporte
 
Ti en las organizaciones cadena de valor
Ti en las organizaciones   cadena de valorTi en las organizaciones   cadena de valor
Ti en las organizaciones cadena de valor
 
TI en las Organizaciones - Objetivos Estratégicos de las TI
TI en las Organizaciones - Objetivos Estratégicos de las TITI en las Organizaciones - Objetivos Estratégicos de las TI
TI en las Organizaciones - Objetivos Estratégicos de las TI
 
TI en las Organizaciones - C1 - Entorno y TI - ¿Cómo crea valor?
TI en las Organizaciones - C1 - Entorno y TI - ¿Cómo crea valor?TI en las Organizaciones - C1 - Entorno y TI - ¿Cómo crea valor?
TI en las Organizaciones - C1 - Entorno y TI - ¿Cómo crea valor?
 
TI en las Organizaciones - C1 - Entorno y TI - Dominio Organizacional
TI en las Organizaciones - C1 - Entorno y TI - Dominio OrganizacionalTI en las Organizaciones - C1 - Entorno y TI - Dominio Organizacional
TI en las Organizaciones - C1 - Entorno y TI - Dominio Organizacional
 
TI en las Organizaciones - C1 - Entorno y TI - Entorno Organizacional
TI en las Organizaciones - C1 - Entorno y TI - Entorno OrganizacionalTI en las Organizaciones - C1 - Entorno y TI - Entorno Organizacional
TI en las Organizaciones - C1 - Entorno y TI - Entorno Organizacional
 
Essential Software Architecture - Chapter 1 Understanding Software Architectu...
Essential Software Architecture - Chapter 1 Understanding Software Architectu...Essential Software Architecture - Chapter 1 Understanding Software Architectu...
Essential Software Architecture - Chapter 1 Understanding Software Architectu...
 
Manejo de excepciones en Java
Manejo de excepciones en JavaManejo de excepciones en Java
Manejo de excepciones en Java
 
An Introduction to Software Architecture - Summary
An Introduction to Software Architecture - SummaryAn Introduction to Software Architecture - Summary
An Introduction to Software Architecture - Summary
 
Arquitectura empresarial resumen
Arquitectura empresarial   resumenArquitectura empresarial   resumen
Arquitectura empresarial resumen
 
Lactancia materna
Lactancia maternaLactancia materna
Lactancia materna
 
Brigada de salud
Brigada de saludBrigada de salud
Brigada de salud
 

Arquitectura empresarial para ingenieros de sistemas - Resumen

  • 1. Arquitectura empresarial para Ingenieros de Sistemas - Resumen Introducción ● En muchas ocasiones los Ingenieros de Sistemas se olvidan de detalles tan importantes como la interoperabilidad con sistemas existentes dentro de la organización o fuera de ella. ● En este resumen se podrán encontrar puntos importantes que ayudarán a los ingenieros de sistemas a comprender mejor cómo sus esfuerzos en los proyectos que crean o modifican sistemas pueden verse limitados por, y pueden a su vez modificar la arquitectura de la empresa a la cual soportan dichos sistemas. ● Hoy por hoy, se reconoce que hay una relación entre la funcionalidad que proveen proveen los proyectos y la capacidad de los negocios de la empresa. El cambiante panorama del desarrollo de sistemas ● Las empresas necesitan sistemas integrados, esto es resultado de que las mismas empresas están haciendo a un lado a aquellos sistemas que ofrecen funcionalidad aislada. Con lo anterior en mente, el objetivo principal es ofrecer operaciones robustas y eficientes. ● En el momento de modificar un sistema, el ingeniero de sistemas debe evitar focalizarse sólo en los casos del sistema en modificación, sino ser consciente de cómo interactúan con otros sistemas dentro de la empresa. ● La Figura 1 presenta una descripción general de cómo se diferencian focos en distintos épocas:
  • 2. Definiciones ● Para entrar en detalles es importante resaltar algunos términos que nos conduzcan a tener un contexto claro sobre Sistemas. ● Empresa ○ Es una organización de negocios. ○ Una compañía podría ser parte de un conglomerado de compañías. ○ Una compañía se la puede considerar como un sistema a gran escala. ○ Características: ■ Razón de ser. ■ Posee una financiación que le permite operar. ■ Lleva a cabo algunas acciones para cumplir su objetivo. ■ Integrada por sistemas de menor nivel, componentes, trabajadores que actúan conjuntamente para alcanzar su funcionalidad. ● Arquitectura Empresarial ○ Descripción de la arquitectura de la empresa en cuestión. ○ La disciplina de la Arquitectura Empresarial aúna negocio, estrategia, proceso, método y componentes desde una cantidad de perspectivas diferentes.
  • 3. Las Arquitecturas Empresariales están definidas por Arquitectos Empresariales. ○ La actividad de un Arquitecto Empresarial, es describir los componentes de una empresa, sus relaciones, cómo colaboran e interactúan entre sí con el “mundo exterior. ○ Una Arquitectura Empresarial ofrece la orientación para implantar los componentes de la empresa. Una vez implantados, produce un cambio en la empresa. ● Sistema ○ Un sistema es un grupo de elementos que forman un todo unificado y cumplen un fin común. ○ Todo sistema tiene un fin, y es el de satisfacer las necesidades de los involucrados, es decir los requisitos del sistema. ○ Los requisitos definen qué funcionalidad se muestra, y cómo se debe mostrar la funcionalidad dadas las cualidades requeridas. ○ A la funcionalidad se le puede imponer unas restricciones o limitaciones (es decir, requisitos no funcionales o atributos de calidad). ○ Para satisfacer las necesidades de los involucrados, los componentes ejecutan unas acciones para alcanzar los objetivos establecidos. ○ Vale la pena mencionar, que un componente puede ser: ■ Software ■ Hardware ■ Personas o trabajadores ○ Es posible considerar a un componente como un sistema, dada su complejidad, tamaño o funcionalidad ofrecida. También se pueden mencionar como subsistemas. ● Ingeniero de Sistemas ○ Se ha observado que los «Ingenieros de Sistemas» ser responsables de todo: ■ Planeamiento ■ Obtención de requisitos ■ Captura de arquitectura ■ Integración ■ Testeo ○ Muchas de las actividades desempeñadas por un Ingeniero de Sistemas trascienden la disciplina tradicional de la Ingeniería de Sistemas. ○ En el contexto de artículo, el Ingeniero de Sistemas es responsable de crear o actualizar la arquitectura del sistema, cumpliendo con todas las restricciones por la empresa en general. ● Programa ○ Cuando se adopta un programa se pretende cambiar el estado de la empresa: ■ Proporcionar alguna capacidad nueva o mejorada. ○ Un programa se integra en una empresa para agregar o modificar componentes.
  • 4. ○ Los programas apoyan las actividades de la empresa en cierta medida. Generalmente están por debajo del alcance de la empresa. ● Proyecto ○ Un proyecto es un conjunto de actividades que poseen un inicio y un único fin o propósito. ○ De un proyecto se espera una nueva capacidad medible. ○ Es muy común que un proyecto se focalice o centre en la introducción de un sistema nuevo en la empresa, o inclusive, en la modificación de uno ya existente. ○ Todo proyecto tiene: ■ Objetivos, y ■ Presupuestos. ○ Normalmente se combinan con otros proyectos formando parte de un programa. ○ En la Figura 2, se muestra cómo los programas y los proyectos afectan a la empresa. Descripción del nivel actual de la empresa ● Una empresa tiene una serie de requisitos que debe cumplir. ● Es normal encontrarse con arquitecturas empresariales no documentadas. Cuando todo lo contrario, es decir, la empresa cuenta con la descripción formal de la arquitectura, encontramos los siguientes elementos:
  • 5. componentes (sus relaciones y colaboraciones), ○ diagramas, ○ dibujos, ○ documentos, ○ modelos, ○ etc. ● Un componente es puesto a prueba con el propósito de verificar que cumpla con sus requisitos. ● Las pruebas existentes ayudan a identificar incompatibilidades, posibles daños que pudiera causar el componente, daño de funcionalidad de mayor nivel por la forma en que interactúa con otros componentes. ● Cuando se combinan los artefactos ya mencionados, forman una descripción completa de elementos clave de la situación actual de la empresa. Ver Figura 3: Los programas cambian a la empresa ● No hay que olvidar que un programa mueve a una empresa de un estado actual a un estado futuro. ● Para describir el estado futuro, es necesario la creación artefactos.
  • 6. ● Cuando se introducen modificaciones, es necesario documentarlas, ya que facilitan la descripción del estado futuro. (También se pueden conocer como deltas documentales). ● Cuando no se captura correctamente el estado actual, lo más seguro es llegar a conclusiones erróneas sobre el estado futuro. ● Los programas pueden modificar un aspecto concreto de la empresa, y en ciertas ocasiones todo el negocio de la misma. ● La posibilidad de poder modificar artefactos actuales permite prepararse para cambios futuros radicales. Además, de evitar la espera de cualquier programa de cambio. ● Para tener una representación completa y coherente de la empresa, todos los programas empresariales deben usar convenciones estándares para reprentar: ○ Artefactos actuales, y ○ Artefactos futuros ● Los artefactos actuales deben conservarse como un repositorio único homogéneo. ○ Coherente ○ Consistente ○ Seguro ○ Representación legible ● Si actualmente se poseen artefactos es posible emprender la búsqueda nuevos artefactos para la introducción de futuros cambios en la empresa. ○ Para lo anterior se requiere los deltas de: ■ requisitos, ■ actualizaciones a la arquitectura, y ■ modificaciones en las pruebas acordes a los cambios de requisitos. ● Los deltas de los requisitos capturan los cambios deseados en el comportamiento esperado. ● La satisfacción de los deltas de los requisitos, impulsan los deltas de la arquitectura. ● Las pruebas permiten reconocer si los requisitos han sido cumplidos y para detectar cualquier defecto en la implantación, los requisitos, o las pruebas propiamente dichas. ● Es posible que un programa introduzca defectos adicionales a nivel de la empresa. ● La Figura 4 muestra el flujo de artefactos.
  • 7. . Los proyectos implementan el programa ● Los programas definen un conjunto de cambios que crean o modifican alguna capacidad de extremo a extremo. ● Desde luego para introducir una nueva capacidad al sistema general, es necesario la creación de sistemas nuevos o modificación de varios sistemas existentes, por medio de : ○ Adquisición de una aplicación nueva, o ○ cambiando algún proceso. ● Los programas introducen nueva funcionalidad. ● En la Figura 5 se ilustra cómo un requisito a nivel del programa se asigna directamente a un único sistema.
  • 8. ● Si el alcance del proyecto consiste en modificar un sistema existente, entonces el sistema tiene un estado actual. ○ Tiene requisitos que cumplir, ○ una arquitectura, ○ pruebas que han sido realizadas, y ○ probablemente algunos defectos abiertos. ● Se pueden crear artefactos futuros a partir de artefactos de sistemas/empresa existentes. ● El programa puede brindar actualizaciones tanto para artefactos de sistemas como también artefactos de la empresa. ● La Figura 6 muestra las relaciones existentes entre artefactos de sistemas actuales y artefactos de proyectos:
  • 9. Unir todas las piezas ● Los flujos de extremo a extremo permiten la evolución, crecimiento de la empresa y de los sistemas que ésta posee, a través de la ejecución de programas y proyectos. ● La Figura 7 muestra el flujo completo, de extremo a extremo, para esta visión simplificada.
  • 10. Conclusión ● Las organizaciones se han puesto firmes en el proceso de crear buenas prácticas para la administración de sus artefactos, y esto, les está trayendo enormes beneficios para potenciar los artefactos. ● Para administrar eficientemente la evolución de la empresa, es necesario comprender sus requisitos y funcionalidad actuales y cómo se logra esa funcionalidad (su arquitectura). ● Las pruebas al desempeño permiten detectar defectos. ● Las organizaciones son capaces de de planificar eficientemente la evolución de la empresa, teniendo una visión clara del estado actual. ● Capturar la mayor parte de los artefactos de la empresa, permite obtener mejores beneficios en la implementación de un programa. ● Es necesario tener una visión precisa del estado actual de la empresa para su correcto funcionamiento. ● Los beneficios de la reutilización se multiplican por la cantidad de sistemas.
  • 11. ● La complejidad de muchos sistemas ha superado ampliamente la capacidad de cualquier individuo para mantenerlo completamente en su mente. ● Se ha ilustrado cómo la arquitectura de la empresa brinda la base para su evolución mediante los programas.