Post on 02-Jun-2020
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
1
Mejora de Proceso en Proyectos de Desarrollo de Soluciones de Arquitectura Tecnológica de Middleware Oracle mediante la
Aplicación de Framework OEAF
Denny R. Alquinta Donders1
Huechuraba, Región Metropolitana de Santiago
denny.alquinta@sansano.usm.cl +56940135014
Resumen: En el contexto de venta y ejecución de servicios de consultoría, se consideran una serie de etapas las cuales están orientadas a capturar la necesidad tecnológica del cliente la cual finalmente es resumida en la individualización de productos y sus correspondientes requerimientos de licencias y servicios para implementarlas. Sin embargo, existe una falta de cohesión entre el proceso de venta de servicios y licencias con la implementación del proyecto en los clientes al sólo estimar los esfuerzos requeridos individualizados en jornadas-ingeniero pero en ninguna de éstas etapas se realiza una especificación técnica detallada del cómo se llevará a cabo la entrega del servicio. Como consecuencia, ésta brecha detectada en los procesos ocasiona pérdida de eficiencia y por ende, incremento en el costo e impacto en el margen de los proyectos. A partir de la aplicación de Oracle Enterprise Architecture Framework (basado en TOGAF) se propone realizar una serie de artefactos de arquitectura los cuales eliminarán o reducirán significativamente la brecha descrita. Se espera que ésta propuesta logre impactar positivamente en el margen neto de cada proyecto, eliminando los problemas de ejecución de estos al ahorrar tiempo en dictar la especificación técnica de implementación. Como método de validación, se compararán proyectos desarrollados con y sin ésta propuesta metodológica, estableciendo medidas objetivas que permitan comparar el impacto de ésta y comprobar si se producen mejoras. Palabras Clave: Soluciones de middleware, Arquitectura tecnológica, OEAF de Oracle, Estimación de esfuerzo y costos.
1 Introducción
Las compañías de consultoría poseen una vasta cantidad de oferta de servicios orientados a proveer soluciones técnicas de software y hardware que satisfagan las necesidades de negocio de sus clientes. Por ello, distintas áreas de las organizaciones internas de la compañía deben trabajar en cadena con el objetivo de lograr realizar el desarrollo y entrega de los proyectos relacionados a cubrir una problemática específica planteada por el mandante y satisfacer sus requerimientos. Luego de que el autor participara en una serie de proyectos en los cuales se han enfrentado dificultades, mayormente debidas al re-trabajo producto de la falta de definición y especificación en soluciones inicialmente propuestas, se detecta una falta de cohesión entre el proceso de venta de servicios, licencias y la implementación del proyecto tecnológico ya que sólo se estiman los esfuerzos requeridos individualizados en jornadas-ingeniero, sin embargo en ninguna de éstas etapas se realiza una especificación técnica detallada del cómo se llevará a cabo la entrega del servicio. Consecuentemente, ésta brecha detectada en los procesos ocasiona pérdida de eficiencia y por ende incremento en el costo e impacto en el margen de utilidad de los proyectos. Para solucionar este problema en este proyecto de tesina se propone la aplicación de Oracle Enterprise Architecture Framework, con el fin de definir y construir Artefactos de Arquitectura orientados a optimizar los esfuerzos y costos de entrega de proyectos de Middleware Oracle. Ésta tesina comienza por explicar el marco teórico y estado del arte, para luego plantear la hipótesis y la forma de comprobarla. Luego se analiza el estado actual, presentar la validación de propuesta para finalizar con el análisis de resultados y sus respectivas conclusiones.
1 Ingeniero Civil en Computación e Informática. Licenciado en Ciencias de la Ingeniería
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
2
2 Marco Teórico y Estado del Arte
2.1 Marco Teórico
Según Marianne Rønnebæk [1], el concepto básico de una buena arquitectura es que esté orientada a los principios. Ésto significa que primero son analizados los requerimientos de negocio, para luego en base a un diseño conceptual, establecer una base de trabajo fundamentada en principios para la organización y selección de componentes técnicos. El trabajo arquitectónico debe asegurar coherencia entre los requerimientos planteados y los principios definidos, con el fin de garantizar que la solución implementada será en base a la necesidad detectada y que los principios identificados siempre tienen base en los requerimientos de negocio (trazabilidad de los requisitos). Por ello, el objetivo de cualquier metodología de diseño de una arquitectura es asegurar que la visión y objetivos requeridos son cumplidos a cabalidad.
Los diferentes frameworks de arquitectura, en general presentan en común los siguientes 5 principios [1]:
- Interoperabilidad: La habilidad de los sistemas computarizados o de software de poder intercambiar y hacer uso de información.
- Seguridad: La capacidad de proteger el software ante cualquier ataque o intervención maliciosa, o cualquier otro peligro que ponga en riesgo la continuidad operacional de una solución de software.
- Apertura: La capacidad de un software de operar con estándares, interfaces, especificaciones y códigos abiertos y conocidos.
- Flexibilidad: El atributo mediante el cual un software puede adaptarse a cambios externos. - Escalabilidad: La característica de un sistema, modelo o función que describe la capacidad de soportar y
desempeñarse ante un constante incremento de su carga de trabajo. - Junto con ello, un sexto principio no documentado por [1], denominado Alta Disponibilidad, definida como la
capacidad de un sistema de garantizar un cierto nivel de servicio operacional, ante situaciones adversas.
De acuerdo a la definición entregada por Wikipedia [2]:
“La Arquitectura TI está dada por el proceso metodológico de especificaciones de tecnologías de la información, modelos y guías de implementación, utilizando una serie de notaciones, por ejemplo UML, dentro de un framework TI coherente, dando por resultado una solución de tecnología empresarial”.
Dentro del contexto de coherencia y con el fin de cumplir los 6 principios nombrados con anterioridad, se define el concepto de Building Block el cual especifica la manera en la cual se categorizan los componentes para definir una arquitectura de referencia. En 2004, Ramesh y Rakesh Radhakrishnan [3] definen los Building Blocks como Entidades de Arquitectura conocidas y modelos específicos de diseño, las cuales dan sustento al uso de patrones y frameworks de arquitectura. Por otra parte, en 2017 para Sjaak Laan [4] la infraestructura TI está basada en “Building Blocks” dados por la siguiente Figura 1.
Figura 1. Building Blocks Arquitectura TI.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
3
Ésta define atributos no funcionales transversales a las soluciones entregadas, dadas en las dimensiones de Disponibilidad, Performance y Seguridad.
Con ello, se puede deducir que los Building Blocks son parte fundamental en los Frameworks de Arquitectura modernos.
En la actualidad, según la revista Forbes [5] TOGAF es el Framework de Arquitectura Empresarial que goza de mayor popularidad en la industria, definido por la estructura base expuesta en la Figura 2. [6].
Figura 2. Diagrama de Componentes de TOGAF ADM.
En la ejecución de los proyectos TI, el foco de este trabajo está en la etapa D del ciclo de TOGAF ADM. El modelo TOGAF define en ésta etapa los siguientes Building Blocks en dos niveles [7]:
- Architecture Building Block (ABB): Típicamente describe la capacidad requerida y define la forma de la especificación que está dada por un SBB. Este punto es equivalente con la definición de Laan [4]. - Solution Building Block (SBB): Representa el componente que será implementado para cubrir la capacidad
requerida. Este punto es equivalente con la definición de los hermanos Radhakrishnan [3].
Para la ejecución de un proyecto se requiere del uso de un framework coherente, el cual sea capaz de decantar en artefactos orientados a ser seguidos por el equipo de ejecución y respetados con el fin de minimizar el re-trabajo. Para el presente trabajo, se selecciona una variación propietaria de TOGAF, denominada Oracle Enterprise Architecture Framework (OEAF). Este es un Framework de Arquitectura el cual define artefactos específicos a producir en cada etapa de iteración. La Figura 3, define los Building Blocks de OEAF.
Figura 3. OEAF Building Blocks.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
4
Como fue definido anteriormente, el proceso descrito en el Punto D del modelo TOGAF es el foco de este trabajo. Para OEAF, este punto se define dentro del Building Block denominado Technology Architecture [8]. Este define la producción de SBB en 4 capas de iteración consecutivas entre sí, en forma de vistas, las cuales están orientadas a documentar la solución a implementar, realizando el diseño de especificaciones de acuerdo a la necesidad del cliente. Este modelo itera basada en una Oracle Reference Architecture (ORA) [9], el cual define las referencias necesarias para establecer los conceptos de Modelo de Referencia, Arquitectura de Referencia y Arquitectura de Detalle. - Vista Conceptual: Realiza un mapeo lógico de capacidades requeridas por el cliente, típicamente en un documento
RFP [10] y las funcionalidades que buscan ser cubiertas en un macro-concepto tecnológico. Usualmente ayuda con la contextualización de la solución en una etapa temprana de desarrollo.
- Vista Lógica: Realiza una vista de componentes técnicos, traslapando el escenario anteriormente descrito y definiendo las interacciones entre dichos componentes. Ésta realiza una definición de los estándares de tecnología que se utilizarán en la implementación de la solución. Ésta se basa en la correspondiente arquitectura de referencia.
- Vista de Product Mapping: Realiza un traslape entre la etapa anterior y el producto o tecnología especifica mediante la cual Oracle cubre la necesidad detectada.
- Vista de Deployment: Realiza un diseño detallado de cómo se despliegan las tecnologías de la solución identificadas en el punto anterior, conformando una especificación para la ejecución del proyecto.
OEAF propone la creación de distintos SBB, con el fin de cubrir las dimensiones descritas de los cuales se implementaran los siguientes:
- Documento de Arquitectura de Delivery: Documento formal que detalla las 4 vistas anteriormente descritas, especificando cómo será desplegada la solución basada en las definiciones de OEAF, además cumpliendo con los 6 principios previamente definidos por Rønnebæk.
- Enterprise Deployment Workbook: Planilla de cálculo que especifica el detalle de la solución a implementar, con el fin que el ejecutor del proyecto dedique su trabajo a la entrega y no al diseño. Ésta planilla está parcialmente basada en lo que se entrega de manera oficial mediante la documentación disponible en [11]
- Artefactos de Automatización de Deployment: Artefactos de código orientados a la automatización de la post-configuración de ambientes.
2.2 Estado del Arte
Al momento de realizar una estimación de esfuerzos por parte de las áreas de ventas de la organización en estudio, ésta se hace en base a Software Delivery Kits, los cuales son cálculos estimativos en base a la complejidad de instalación y configuración de cada componente estimado en las etapas iniciales de cubicación de licencias. Éstas son puestas en una matriz de estimación, la cual termina por dar un total de Jornadas-Ingeniero que son negociadas en la etapa de venta con el cliente y luego son administradas por el jefe de proyecto. Ésta estimación no comunica ningún tipo de especificación de arquitectura tecnológica ni lineamientos de implementación, sino que solamente acota el tiempo de ejecución del proyecto. Por efectos de confidencialidad los valores descritos en este punto serán ofuscados.
Como fue investigado en el marco teórico de ésta propuesta, la implementación de proyectos de tecnología basados en Frameworks de Arquitectura, está orientada principalmente a optimizar el uso de recursos. En empresas del mismo calibre que Oracle, existen distintas propuestas de arquitecturas derivadas de TOGAF, las cuales buscan objetivos similares a los descritos recientemente.
La totalidad de las ofertas revisadas proponen soluciones en base a una arquitectura de referencia con respecto a algún tipo de tecnología en particular, como lo hace Microsoft [12] en su documento de IoT. Aquí se describen conceptos similares a los definidos por Rønnebæk.en [1]; además, agrega conceptos como heterogeneidad, definiéndolo de manera similar a la flexibilidad por Rønnebæk.
IBM [13] por otra parte, desde hace más de 10 años ha declarado principios similares, además de agregar los tipos de stakeholders requeridos para un diseño exitoso. Estos son divididos en dos tipos de arquitectos. Un Enterprise Level Architect, el cual planea la infraestructura a nivel general que dará cobertura a las necesidades planteadas por el cliente; mientras que un Application Technical Architect entiende a bajo nivel las tecnologías que soportarán los diseños preliminares, soportando cada Building Block de la manera más efectiva, dando soporte al rendimiento, conectividad y seguridad requerida.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
5
Por otra parte, AWS [14] mediante su publicación de Well Architected Services también incurre en nombrar principios de arquitectura basales como los mencionados por Rønnebæk [1], agregando la variable de optimización de costos y definiéndola como la habilidad de evitar o eliminar costos innecesarios o recursos sub-óptimos. Sin embargo en contraposición a lo implicado por Oracle, IBM y Microsoft, AWS realiza una organización clásica del cómo se debe organizar un equipo de arquitectura, no dividiéndolos por funciones, sino que diluyendo su responsabilidad en equipos no expertos. Recogiendo los 6 principios de arquitectura, más las definiciones sobre una arquitectura de referencia, los diferentes roles y tipos de arquitectos que influyen en el diseño de una solución y la optimización de costos que pretende la solución final, el presente trabajo propone entregar un diseño técnico end-to-end de una solución de Middleware para una organización en particular, la cual medirá la eficiencia de su aplicación mediante el estudio real de esfuerzo utilizado en la implementación del proyecto versus el tiempo estimado en sus etapas de preventa, el cual podrá demostrar su eficacia y validar la hipótesis trazada.
3 Propuesta de Investigación
3.1 Propuesta de Solución
Se aplicará OEAF en la producción de una serie de artefactos de arquitectura, los cuales luego de su implementación comprobarán empíricamente la reducción de uso de jornadas en la implementación del proyecto.
3.2 Hipótesis
La presente tesina propone que la aplicación de un Framework de referencia como OEAF, mejorará la entrega de soluciones consultivas de tecnología, impactando positivamente en la rentabilidad obtenida en el proyecto disminuyendo las jornadas ocupadas en un set de actividades detectadas como consumidores extremos de tiempo. Se selecciona además ésta metodología al estar altamente adaptada a productos Oracle, específicamente en soluciones de Oracle Fusion Middleware.
3.3 Metodología para validar la Hipótesis
La validación de la efectividad que propone la metodología de trabajo será mediante la evaluación de su aplicación a tres proyectos tecnológicos de consultoría de similares características, comparando los esfuerzos estimados inicialmente por parte de Preventas de Servicios y lo realmente utilizado en la implementación. Los resultados se medirán en función de la eficiencia económica del ahorro, calculado en monedas referenciales ficticias y realizando comparaciones porcentuales de éstas. Se considerará un caso de control, donde no se aplique la metodología y dos escenarios donde sí se haga, donde el primero es aplicación desde cero y el segundo escenario reutilizan los colaterales producidos en el caso anterior.
3.4 Objetivos Específicos.
Los siguientes son los objetivos específicos considerados en el desarrollo de este trabajo:
Identificación de artefactos de arquitectura a ser considerados en el diseño de la propuesta metodológica, usando como referencia OEAF.
- Definición de indicadores que se considerarán en la validación. - Aplicación de la metodología a tres casos de prueba de concepto y medición de los tiempos de implementación e
impacto en margen. - Análisis e interpretación de los resultados.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
6
4 Análisis de la Situación Actual en el Caso de Estudio
4.1 Contexto
Advanced Customer Services (ACS) es una organización de consultoría dentro de Oracle Corporation, la cual entrega servicios expertos de implementación, integración e instalación de productos Oracle a clientes del sector privado y público. El proceso de interacción con el cliente, comienza cuando se detecta una necesidad por parte del área de ventas de licencias, que vía procesos de levantamiento, cubica la venta de productos específicos adecuados para resolver la necesidad planteada. En este proceso inicial, solo se realiza un diseño arquitectónico conceptual, contemplando un mapeo 1:1 entre la necesidad expuesta por el cliente y el producto Oracle que la satisface, realizando la individualización de licencias relacionadas a éste. Este proceso finaliza con la venta de un conjunto de licencias a ser utilizadas por el cliente, ya sea en un ambiente on-premise o cloud. Según [15], Oracle Advanced Customer Services (ACS) es una organización altamente especializada en tecnologías Oracle, la cual provee desde hace más de 20 años servicios globales personalizados a las necesidades de sus clientes. En el contexto de este trabajo de tesina, los servicios prestados por ACS se focalizarán en la rama de Oracle On-Site Support la cual provee de los siguientes servicios:
- Technical Account Manager (TAM) [16]: Proporciona de la experiencia y orientación técnica durante la ejecución de un proyecto y luego el soporte para una adopción más rápida de la tecnología que se implementó. Un TAM trabaja con el cliente en cada paso del proyecto, brindando la planificación y gobierno basado en las mejores prácticas y la optimización de procesos, sin perder de vista los requisitos tecnológicos y los objetivos comerciales trazados en etapas tempranas.
- Advanced Support Engineers (ASE) [17]: Aseguran que las tecnologías Oracle implementadas en el proyecto se instalen y configuren de forma correcta y optimizada de acuerdo a las mejores prácticas de Oracle. Son ingenieros experimentados que aprovechan la experiencia de Global Customer Support y los equipos de desarrollo de Oracle para proveer soluciones integradas que se adapten a las necesidades del cliente. Luego de implementado el proyecto, se aseguran de utilizar herramientas de diagnóstico y monitoreo para anticipar, identificar y remediar problemas para todos los sistemas de misión crítica ofrecidos por Oracle.
- Datacenter Engineers (DCE): Ingenieros especializados en la instalación y configuración de Servidores y Storage, optimización de recursos y sistemas localizados en Datacenter de terceros, entre otros.
4.2 Definición del Problema
En la empresa donde se realizará el estudio de ésta propuesta de investigación, existen ocasiones en que el cliente requiere de la ayuda experta para la implementación de los productos adquiridos. En estos casos, el cliente solicita frecuentemente los servicios de ACS con el fin de realizar la implementación, donde el área de Venta de Servicios cumple el objetivo de realizar un cálculo exhaustivo para estimar el esfuerzo requerido para implementar la solución definida en el paso anterior. El resultado de ésta estimación consiste en definir las horas hombre (definidas como Jornadas-Ingeniero) requeridas para ejecutar la implementación del proyecto, dando inicio a un proceso denominado Sales to Delivery Handover (S2DH). Este segundo proceso tiene por objetivo entregar a la organización de ACS el alcance del proyecto, los productos y licencias a instalar y la cantidad de horas vendidas para su ejecución. Como puede verse en la Figura 4, cuando se completa el segundo proceso, el correspondiente TAM asignado debe iniciar la ejecución del proyecto, buscando recursos de Ingeniería (ASE) en los pilares técnicos disponibles, finalizando el proceso con la entrega de la solución. Los tres procesos anteriormente descritos tienen una falla fundamental. El autor luego de participar y observar la ejecución de numerosos proyectos, ha llegado a la conclusión de que la falta de una definición arquitectónica a bajo nivel, la que será implementada por ACS Ingenieria afecta directamente el tiempo de ejecución y, como consecuencia, en la rentabilidad real del proyecto. Ninguno de estos procesos realiza una especificación técnica detallada y precisa para realizar la implementación del proyecto, lo que genera retrasos en el inicio y ejecución de éste. Por lo tanto, el equipo técnico tiene solo una clara definición del qué, pero no del cómo realizar la ejecución del proyecto.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
7
Figura 4. Procesos Centrales de un Proyecto en el Ciclo de Vida del Desarrollo de una Solución.
4.3 Estimación de Licenciamiento Relacionada a Implementación
El cálculo de licenciamiento es un proceso clave para realizar una instalación correcta y que quede en concordancia con las reglas de licenciamiento especificadas por Oracle. Éstas se realizan en base a tres factores distintos, según lo consultado en [18] [19] y [20] el cálculo se realiza de la siguiente manera:
Para Ambientes Productivos (PRD, QA)
Tabla 1. Calculo de Licenciamiento para Ambientes Productivos y Quality Assurance.
Processor Perpetual Core vCPU
� 2� 4�
Para Ambientes Pre-Productivos (DEV)
Tabla 2. Calculo de Licenciamiento para Ambientes de Desarrollo.
NUP Core vCPU
�
��: �� ���:�� → � � 2�
��
��: �� ���: ��������������� → � � 2�
�
2�
Este cálculo debe realizarse al momento de la implementación, cuando el licenciamiento ya se encuentra otorgado y se comienza a realizar la instalación del software relacionado.
4.4 Estimación de Esfuerzos y Desagregación de Costos
Cada tipo de proyecto cuenta con una pre-cubicación de esfuerzos dada por un Software Delivery Kit la cual describirá unidades de dinero estándar para este trabajo. Este estima los esfuerzos estándar (en jornadas laborales de 8 horas) y las correspondientes tarifas que corresponden a éste. Éstas son estimadas en dos rangos: Ingeniero Estándar e Ingeniero Senior. Por efectos de mantener confidencialidad en el caso de estudio, se define una Unidad Monetaria de Trabajo ($UMT) orientada a mostrar las relaciones económicas y mantener la consistencia de este trabajo. Estas unidades no tienen ninguna relación con los valores reales ni guardan ninguna proporción con ellas. La siguiente tabla establece la relación de una jornada, separada por Ingeniero Estándar e Ingeniero Senior:
Arquitectura de Licencias
• Orientado a aplicar un marco conceptual de solucion y detectar la problematica especifica del cliente para luego realizar un mappeo 1:1 entre el problema y el software Oracle a utilizar para resolverlo
• Produce como resultado la venta de licencias de software para el uso on-premise o cloud de softwares de Oracle
Arquitectura de Servicios
• Orientado a diseñar el esfuerzo y prizing del proyecto en relacion a la ejecucion de las licencias detectadas en el proceso anterior. Se apoya por ingenieros de preventa tecnicos, los que tienen conocimientos de mediana profundidad en los productos a implementar
• Produce como resultado un contrato de servicios para el cliente, con el fin de implementar la solucion donde el cliente requiera hacerlo
Delivery de Proyecto
• Orientado a realizar la implementacion (Delivery) del proyecto diseñado en los procesos anteriores. El area Tecnica de ACS, Liderado por un Project Manager, Instala, configura y documenta la solucion, en los parametros establecidos en pasos anteriores (sizing de acuerdo a licenciamiento, esfuerzo cubicado por Venta de Servicios)
• Produce como resultado la instalacion y configuracion del software adquirido, basado en el licenciamiento disponible con el fin de disponiblizar la infraestructura requerida por el cliente para cubrir la necesidad detectada.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
8
Tabla 3. Relación de Perfil de Ingeniero vs Tarifa por Jornada ($UMT)
Tipo de Ingeniero Costo ($UMT)/Jornada Tarifa ($UMT)/Jornada
Ingeniero Estándar $100 $190 Ingeniero Senior $160 $320
Para efectos de ésta tesina, se define el Software Delivery Kit el cual permite realizar la desagregación de costos y tarifas en función de $UMT, para el producto de Oracle Fusion Middleware, Oracle Service Bus (OSB). Éste tipo de implementación es una de las más comunes dentro del trabajo realizado por la organización, por lo que se selecciona como caso de prueba, en función de su estimación estándar de esfuerzos. Este Kit estima los esfuerzos relacionados a realizar la instalación y configuración de OSB teniendo los siguientes supuestos:
- La instalación será adecuada a la necesidad del cliente. - Solo se realizarán instalaciones certificadas al momento de realizar el proyecto. - Se aplicarán los últimos parches recomendados disponibles a la fecha de finalizar el proyecto. - Se aplicarán donde fuere posible, las mejores prácticas de software. - Se incluyen 6 instancias dentro de un cluster para la instalación del software. - Se deben tener al menos 3 ambientes disponibles para efectos de Producción (PRD), Quality Assurance (QA) y
Desarrollo (DEV). - Este set de esfuerzos no incluye la estimación de Instalación y Configuración de Base de Datos, por no ser un
producto de Middleware. - Se provisiona un total de 10% adicional de costo y tarifa por imprevistos y riesgo.
Con los puntos antes definidos, se establece el siguiente Software Delivery Kit, que establece la relación entre actividades, esfuerzos y perfil de ingeniero por ambiente:
Tabla 4. Des-agregación de costos en función de Tareas y Entregables vs Perfil requerido, Costo, Tarifa en $UMT AS-IS.
Descripción de Tarea Perfil Ingeniero
Costo Jornadas
Costo Ingeniero ($UMT)
Tarifa ($UMT)
Coordinación con Jefe de Proyecto Senior 0,5 $ 80 $ 160 Realizar reunión preliminar de orientación y contexto
Senior 0,5 $ 80 $ 160
Revisar documentación disponible Estándar 0,5 $ 50 $ 95 Creación de Máquinas Virtuales requeridas
Senior 1 $ 160 $ 320
Creación de Puntos de Montaje y Configuración en OS
Senior 1 $ 160 $ 320
Ejecutar Repository Creation Utility e Instalar binarios de productos relacionados
Estándar 2 $ 200 $ 380
Aplicar parches mandatorios y realizar si se aplica, configuraciones post-instalación
Estándar 1 $ 100 $ 190
Configurar Sistema (6 instancias) Senior 15 $ 2.400 $ 4.800 Realizar validación de configuración Estándar 1 $ 100 $ 190 Preparar documentación relacionada Senior 2 $ 320 $ 640 Realizar reunión final de revisión de documentación de instalación y recomendaciones
Senior 1 $ 160 $ 320
Total 25,5 $ 3.810 $ 7.575 Total, más Riesgo Estándar (10%) 28,05 $ 4.191 $ 8.333
Las actividades descritas están diseñadas para alcanzar un margen esperado del 50%.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
9
4.5 Proceso de Implementación de Proyecto
En el actual contexto de ejecución de proyectos de tecnología, el TAM procede a ejecutar los siguientes pasos mostrados en la Figura 5.
Figura 5. Proceso de Partida de Proyecto AS-IS.
Según el Software Delivery Kit definido, el trabajo asociado ahora debería seguir el siguiente flujo:
Figura 6. Proceso de Delivery de Proyecto de Software AS-IS.
Sales to Delivery
Handover
• El area de ventas de servicio, puntualiza los servicios vendidos al cliente y entrega el scope acordado via contratos, detallando los entregables acordados y los plazos determinados para la ejecucion total de el proyecto, entregando el esfuerzo cubicado.
Busqueda de recursos
ASE
• En funcion de la especialidad requerida para el proyecto, el TAM procede a buscar recursos en forma global, para ejecutar el proyecto. Estos recursos son asignados de forma manual via un Resource Manager, el cual de acuerdo a la utilizacion del ingeniero y al nivel de seniority y expertise requerida asigna al recurso para el trabajo
Ejecucion del Proyecto
• El ingeniero asignado, comienza la ejecucion del proyecto, basado solo en lo determinado por el set de actividades identificadasen el Kit de Entrega de Software, sin embargo no cuenta con estandares de instalacion ni guia de implementacion.
• Etapa preliminar donde el Jefe de Proyecto se reune con el equipo asignado al proyecto con el fin de explicar el alcance, tareas y entregables del proyecto a ejecutar1. Coordinacion con Jefe de Proyecto
• Reunion inicial con el cliente, conocida como Kick-Off. 2. Reunion Preliminar de Contexto
• Los ingenieros asociados al proyecto, revisan la documentacion relacionada a los productos a instalar y configurar con el fin de iniciar la ejecucion del proyecto3. Revision de Documentacion Disponible
• Se inicia la creacion de las maquinas virtuales asociadas al proyecto a configurar. Estas deben contener la cantidad correcta de vCPU y los puntos de montaje requieridos para iniciar la instalacion de binarios
4. Creacion de Maquinas Virtuales
• Creacion de los correspondientes puntos de montaje en la unidad de storage, con la quota de disco correspondiente y la presentacion de estos a las maquinas donde se
realizara la implementacion del software
5. Creacion de Puntos de Montaje y Configuración en OS
• Se inicia la instalacion de binarios de la solucion adquirida. Ademas se realiza la configuracion de los esquemas de base de datos requeridos para la configuracion del OSB
6. Ejecucion de RCU e Instalacion de Binarios
• Se realiza la configuracion e instalacion de los ultimos parches disponibles en My Oracle Support, con efecto de dejar la plataforma cubierta contra los ultimos y mas comunes problemas reportados globalmente. Esto tipicamente implica implementar los ultimos PSU disponibles para la plataforma
7. Aplicacion de Ultimos Parches
• Conlleva la creacion y configuracion de los dominios asociados a Oracle Service Bus. Realizar la configuracion inicial de los 6 servidores mas la instancia de administracion, luego la configuracion completa del dominio para utilizar MAA/OFA/EDG y luego la configuracion de automatizacion de manejo de ciclo de vida de este.
8. Configuracion de Sistema
• Validacion basica del funcionamiento del dominio y la correspondiente recoleccion de evidencias necesarias para realizar la documentacion de la instalacion y configuracion.
9. Validacion de Instalacion
• Preparacion de la documentacion asociada al proyecto, conocida como SiteLog. Esta es la evidencia requerida para finalizar el hito de facturacion del proyecto10. Preparacion de Documentacion
• Reunion de entrega y clarificacion de dudas por parte del cliente. 11. Reunion de Finalizacion
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
10
4.6 Identificación y Diagnóstico de Áreas de Impacto utilizando OEAF
En función de las sucesivas experiencias de implementación de proyectos tecnológicos, se determina que los puntos que se encuentran en el alcance inmediato es conseguir mediante la aplicación de la metodología la reducción de los costos asociados a la instalación y configuración del software con el fin de incrementar el margen de utilidad del proyecto. Estos costos se encuentran asociados a los puntos descritos en la Tabla 4 y Figura 6 respectivamente. Después de la aplicación de criterio experto (por parte de los TAM asociados a los proyectos evaluados y los ASE asociados a éstos) sobre estas actividades, se definen que los siguientes puntos son foco común de re-trabajo durante la implementación debido a la falta de definición para la implementación:
- Coordinación con Jefe de Proyecto: Definido en el punto 1 de la Figura 6, este proceso está mayormente afectado por el hecho de que los jefes de proyecto no cuentan como parte de función tener un perfil técnico profundo, lo cual genera una serie de retrasos en la definición inicial del proyecto. Ésta etapa suele tener muchas iteraciones sin tener una definición técnica clara para comenzar la implementación.
- Creación de Máquinas Virtuales y puntos de Montaje requeridos: Definido en el punto 4 de la Figura 6, este punto es típicamente afectado por la inexistencia de un cálculo correcto de licenciamiento lo que se traduce a la creación de infraestructura con la cantidad incorrecta de vCPU y puntos de montaje requeridos para que la solución funcione correctamente, segregando la instalación en puntos factibles de respaldo en caso de desastre. Para efectos de des-agregación, como fue definido en la Tabla 4, este punto significa una estimación base de 2 Jornadas de Perfil Ingeniero Senior, por cada ambiente configurado.
- Configurar Sistema: Definido en el punto 7 de la Figura 6, este punto es afectado por la inexistencia de un estándar de implementación, lo que causa errores en la instalación y configuración de los productos, teniendo que realizarlos nuevamente de forma frecuente. Éste punto en particular funciona como variable dependiente de la cantidad de instancias a configurar, por lo que en la mayoría de los casos es el punto que tiene mayor impacto en el adelanto o retraso del proyecto. Para efectos de des-agregación, como fue definido en la Tabla 4, este punto significa una estimación base de 15 Jornadas de Perfil Ingeniero Senior y verifica que es el punto más sensible de la instalación y configuración de la solución entregada.
Mediante los SBB y ABB definidos por OEAF, se construirán los artefactos requeridos para que éstas áreas sufran de menor impacto al reducir la incertidumbre de implementación. Con ello se espera reducir las jornadas invertidas en dichos puntos y como consecuencia reducir los costos asociados.
5 Propuesta de Solución
5.1 Resumen de propuesta
La solución propuesta se enfoca a reducir la brecha de incertidumbre que existe en la estimación de esfuerzos que se produce entre el segundo proceso de venta del servicio y el tercer proceso donde se realiza la implementación real, agregando una fase facturable de Arquitectura de Delivery, orientada mediante OEAF al diseño y construcción de especificaciones más precisas, que redunde finalmente en reducción de gasto de jornada y por ende ahorro de costos, evitando el re-trabajo debido a implementaciones erróneas. Éstas especificaciones permitirán diseñar todos los puntos de error detectados por el autor en las implementaciones on-site y reutilizar la mayor cantidad de artefactos producidos con el fin de disminuir los tiempos de ejecución y aumentar el margen de cada proyecto. Con ello, se propone la inclusión de la etapa denominada Delivery Architecture entre los pasos 2 y 3 definidos en la Figura 6, transformándolo en el Proceso de Delivery de Proyecto TO-BE.
5.2 Descripción de Casos donde se aplicará metodología
La metodología se aplicará en tres proyectos de similares características, donde se tomará como variable de control un proyecto donde no se aplique y luego dos más donde sí se aplique OEAF. Estos tendrán como objetivo implementar una arquitectura estándar de Oracle Service Bus, como fue introducido en el punto 4.6, aplicando estándares de Máxima Disponibilidad, Enterprise Deployment Guide y Oracle Flexible Architecture. Los tres casos descritos constan de un despliegue en cluster de Alta Disponibilidad, de similares características para mantener la fidelidad de la comparación.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
11
5.3 Definición de Indicadores de Medición de Mejora (IMM)
Con el fin de comparar los resultados entre los escenarios evaluados, se adoptan las siguientes convenciones de nombre: - Jornadas Senior Realmente Utilizadas: Js
Estimador relacionado a las Jornadas de Ingeniero Senior Realmente usadas dentro de la implementación - Jornadas Estándar Realmente Utilizadas:!�
Estimador relacionado a las Jornadas de Ingeniero Estándar Realmente usadas dentro de la implementación - Costo Senior Utilizado:"#
Costo asociado a las jornadas de Ingeniero Senior, realmente usadas en la implementación del proyecto - Costo Estándar Utilizado:"�
Costo asociado a las jornadas de Ingeniero Senior, realmente usadas en la implementación del proyecto - Ambiente: �
Definición de Ambiente, el cual varía entre DEV, QA y PRD. Luego se definen los siguientes IMM:
IMM Totales:
- $#�!�����#%&'( � ∑ !# + ∑ !� - "�#��%&'( � ∑"# + ∑"� - ��#�������+#��,�����-./0'1'2 � !�����#32456'1'2 − (∑ !# + ∑ !�) - ��#�������"�#�� � "�#��32456'1'2 − (∑"# + ∑"�)
- :�;�� �<'/5='>?.24.@ABC
<'/5='∙100
- E,�����F'/G&0 � H�;��F'/G&0 −:�;��
IMM Por Ambiente:
- $#�!�����#%&'((�) � ∑ !#(�) + ∑ !�(�) - "�#��%&'((�) � ∑"#(�) + ∑"�(�) - ��#�������+#��,�����-./0'1'2(�) � !�����#32456'1'2(�) − (∑ !#(�) + ∑ !�(�)) - ��#�������"�#��(�) � "�#��32456'1'2(�) − (∑"#(�) + ∑"�(�))
- :�;��(�) �<'/5='(I)>?.24.@ABC(I)
<'/5='∙ 100
- E,�����F'/G&0(�) � H�;��F'/G&0(�) − :�;��(�)
5.4 Identificación y Justificación de Artefactos de Arquitectura
Aplicando OEAF y con el fin de impactar directamente el desempeño de las áreas individualizadas en el punto 4.6 se requieren construir los siguientes artefactos: Documento de Arquitectura de Delivery: Este documento contiene los siguientes SBB: Vista Conceptual: Consiste en explicar diagramáticamente, la manera en la cual la solución se pone en contexto, las correspondientes capas de arquitectura que tendrá y cuáles son los principios descritos por Marianne Rønnebæk [1] a cubrir. Ésta vista no afectará directamente el desempeño en las áreas identificadas en el punto 4.6, sin embargo es necesaria para comenzar la iteración de la metodología. La Figura 7, muestra ésta vista desde el punto de vista de Integración de Servicios:
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
12
Figura 7. Vista Conceptual de Solución de Integración y Mediación de Servicios
Vista Lógica: Ésta vista realiza una relación entre los escenarios a cubrir y que fueron puestos en contexto en el punto anterior, con los componentes técnicos y las relaciones entre sí. Éste artefacto se construye a manera de presentar a alto nivel cuáles son los componentes lógicos de la solución. Éste artefacto cumple una función fundamental para proveer de un contexto tangible al TAM, de cuáles son los componentes y cómo interactúan en el ecosistema tecnológico del cliente, con el fin de reducir en mayor medida las precisiones realizadas en el primer ciclo del proyecto (Ver: Coordinación con Jefe de Proyecto). Para el caso de ésta tesina, la implementación de OSB, se encuentra en la capa de mediación mencionada en la Figura 8.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
13
Vista de Mappeo de Productos: Ésta vista se construye sobre la anterior y se mapea en capacidades, identificadas con anterioridad, con los productos a implementar. Esto provee también de contexto técnico al TAM, para realizar el pareo con el contrato de servicios el cual especifica los productos a instalar y configurar y cómo éstos se ubican en el
ecosistema tecnológico de la compañía y del cliente. Una muestra de este artefacto, es expuesta en la Figura 9.
Figura 9. Vista de Mappeo de Productos de Solución de Integración y Mediación de Servicios.
Vista de Deployment: Ésta vista muestra el despliegue técnico final, el cual debe ser implementado por el ASE involucrado en el proyecto. Este artefacto es fundamental para la construcción de la especificación de detalle denominada Enterprise Deployment Workbook, mediante el cual se pretende impactar el área de creación de máquinas, puntos de montaje y configuración de dominios Middleware para OSB. Por ende, este artefacto es el más relevante en función de evaluación de reducción de costos de implementación. Una muestra de este artefacto, es expuesta en la Figura 10.
Figura 8. Vista Lógica de Solución de Integración y Mediación de Servicios
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
14
Figura 10. Vista de Deployment de Productos de Solución de Integración y Mediación de Servicios.
Junto con las vistas descritas en los puntos anteriores, el artefacto de Arquitectura de Delivery, además debe incluir:
- Diseño de Ambiente, incluyendo la infraestructura donde se implementará. - Convenciones de Nombre a utilizar en la implementación. - Cálculo de Licenciamiento según [18] [19] y [20]. - Definición de Máquinas Virtuales a crear. - Definición de Shared File Systems y Puntos de Montaje. Enterprise Deployment Workbook: Denominado EDW, de aquí en adelante; este artefacto definido inicialmente en [11], consiste en una planilla de cálculo orientada a entregar el diseño técnico detallado para la implementación de la solución. Para mayores detalles en la arquitectura de referencia de WebLogic Server [21] y Oracle Service Bus [22], consultar las documentaciones citadas. Al ser una planilla, ésta puede ser integrada con cualquier artefacto de automatización vía herramientas de scripting, como Python. Los contenidos de este Workbook son los siguientes:
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
15
- Diseño Arquitectónico: Diseño general ya realizado en el Documento de Arquitectura de Despliegue. - Información y Cálculo de Licenciamiento: Orientado a automatizar el cálculo de licenciamiento en función de lo
adquirido por el cliente. - Especificaciones de Creación de Maquinas: Especificaciones detalladas de creaciones de máquinas virtuales, las
cuales incluyen nombre, IP asignada, cantidad de vCPU y RAM, además del stack al cual pertenece. - Especificaciones de Creación de Dominios: Especificaciones detalladas de cómo deben crearse los dominios de
Middleware asociados a la solución. Estos incluyen detalles como: Host, IP, Nombre de Servidor, Nombre de Cluster (si aplica), puerto a utilizar, Rango de puerto de Coherence, Puerto de Node Manager, Dirección de Cluster, Asignación de Memoria a JVM.
- Especificaciones de Creación de FileSystems: Especificaciones detalladas del cómo debe ejecutarse la creación de los proyectos dentro del storage asociado a la solución, incluyendo detalles como el nombre de la unidad, su punto de montaje y las quotas asignadas además de la distribución creada, para seguir los estándares Oracle Flexible Architecture [23] y Maximum Availability Architecture [24].
Este artefacto, al igual que el Documento de Arquitectura de Delivery, impacta de manera directa los puntos de Creación de Máquinas Virtuales, Puntos de Montaje y Configuración de Sistema Una muestra de este documento es la mostrada en la Figura 11.
Artefactos de Automatización de Despliegue: Mediante la creación de una planilla de cálculo estandarizada, se procede a crear un artefacto de automatización vía Python, el cual simplifica gran parte de la configuración post-creación del dominio con el fin de reducir el error humano y afectar directamente sobre el puntos de Creación de Máquinas Virtuales, Puntos de Montaje y Configuración de Sistema. La Figura 12, muestra un extracto del script de automatización creado.
Figura 11. Muestra de Enterprise Deployment Guide Workbook.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
16
Figura 12. Muestra de Script de Automatización Post-Configuración.
6 Validación de la Propuesta
6.1 Metodología de Validación
Para efectos de validación, se actualiza el Software Delivery Kit para ampliar la capacidad de lo definido en la Tabla 4, incluyendo el proceso de Arquitectura de Delivery, utilizando OEAF. Para más Detalles, ver Anexo 11.1
En ésta nueva definición se incluye un costo de UMT $800, extra por cada ambiente, con el fin de realizar los artefactos definidos en el punto 5.4. Con ésta información, se define el costo y tarifa para los tres ambientes definidos en el punto 4.4, en la Tabla 5. Se calcularán los estimadores definidos en el punto 6.3, basado en los tiempos reales utilizados proporcionados por los TAM asociados a los proyectos tomados como referencia. Para efectos de la evaluación, se definen tres escenarios, los cuales se detallan a continuación:
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
17
- Escenario 1: Escenario de Control, sin la utilización de OEAF. - Escenario 2: Escenario Inicial de uso de OEAF. - Escenario 3: Escenario donde se reutilizan artefactos de OEAF.
Mediante el cálculo de indicadores se realizará la evaluación de impacto sobre la implementación del proyecto.
Tabla 5. Des-agregación de costos en función de Tareas y Entregables vs Perfil requerido, Costo, Tarifa para 1 y 3 ambientes (TO-BE).
Costo/Tarifa unitario Ambiente Costo/Tarifa por 3 Ambientes DEV - QA - PRD
Descripción de Tarea Perfil Ingeniero
Costo Jornadas
Costo Ingeniero ($UMT)
Tarifa ($UMT)
Costo Jornadas
Costo Ingeniero ($UMT)
Tarifa ($UMT)
Coordinación con Jefe de Proyecto
Senior 0,5 $ 80 $ 160 1,5 $ 240 $ 480
Realizar reunión preliminar de orientación y contexto
Senior 0,5 $ 80 $ 160 1,5 $ 240 $ 480
Arquitectura de Delivery Senior 5 $ 800 $ 1.600 15,0 $ 2.400 $ 4.800
Revisar documentación disponible
Estándar 0,5 $ 50 $ 95 1,5 $ 150 $ 285
Creación de Máquinas Virtuales requeridas
Senior 1 $ 160 $ 320 3,0 $ 480 $ 960
Creación de Puntos de Montaje y Configuración
en OS
Senior 1 $ 160 $ 320 3,0 $ 480 $ 960
Ejecutar Repository Creation Utility e Instalar
binarios de productos relacionados
Estándar 2 $ 200 $ 380 6,0 $ 600 $ 1.140
Aplicar parches mandatorios y realizar si se aplica, configuraciones
post-instalación
Estándar 1 $ 100 $ 190 3,0 $ 300 $ 570
Configurar Sistema (6 instancias)
Senior 15 $ 2.400 $ 4.800 45,0 $ 7.200 $ 14.400
Realizar validación de configuración
Estándar 1 $ 100 $ 190 3,0 $ 300 $ 570
Preparar documentación relacionada
Senior 2 $ 320 $ 640 6,0 $ 960 $ 1.920
Realizar reunión final de revisión de documentación
de instalación y recomendaciones
Senior 1 $ 160 $ 320 3,0 $ 480 $ 960
Total 30,5 $ 4.610 $ 9.175 91,5 $ 13.830 $ 27.525
Total, más Riesgo Estándar (10%)
33,55 $ 5.071 $ 10.093 100,65 $ 15.213 $ 30.278
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
18
7 Análisis de Resultados
7.1 Escenarios Recolectados
Escenario 1: Escenario de Control, sin la utilización de OEAF
La Tabla 6 muestra los indicadores calculados para el Escenario de Control.
Tabla 6. Tabla resumen IMM Escenario 1.
IMM Total DEV QA PRD
Uso de Jornadas Real 148 48,5 52,5 47
Costo Real $ 22.570 $ 7.430 $ 8.010 $ 7.130
Desviación en Estimación de Jornadas
-73 -23,5 -27,5 -22
Desviación de Costo $ -11.140 $ -3.620 $ -4.200 $ -3320
Margen 1% 2% -6% 6%
Impacto en Margen -49% -48% -55% -44%
Escenario 2: Escenario Inicial de uso de OEAF
La Tabla 7, muestra los indicadores calculados para el Escenario 2, primero donde se aplicó OEAF:
Tabla 7. Escenario 2. Tabla resumen IMM Escenario 2
IMM Total DEV QA PRD
Uso de Jornadas Real 73 30,5 23 19,5
Costo Real $ 10.960 $ 4.640 $ 3.440 $ 2.880
Desviación en Estimación de Jornadas
2 -5,5 2 5,5
Desviación de Costo $ 470 $ -830 $ 370 $ 930
Margen 52% 39% 55% 62%
Impacto en Margen 2% -11% 5% 12%
Escenario 3: Escenario donde se reutilizan artefactos de OEAF La Tabla 8, muestra los indicadores calculados para el Escenario 3, donde se reutilizan los artefactos realizados para el Escenario 2:
Tabla 8. Escenario 3. Tabla resumen IMM Escenario 3
IMM Total DEV QA PRD
Uso de Jornadas Real 56 21 19 16
Costo Real $ 8.300 $ 3.180 $ 2.800 $ 2.320
Desviación en Estimación de Jornadas
19 4 6 9
Desviación de Costo $ 3.130 $ 630 $ 1.010 $ 1.490
Margen 63% 58% 63% 69%
Impacto en Margen 14% 8% 13% 20%
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
19
7.2 Análisis de Indicadores
Reducción de Jornadas Reales Utilizadas
La siguiente gráfica, construida en base a los IMM de la sección anterior, muestra el desempeño a la baja de la Utilización de Jornadas:
Gráfica 1. Impacto en Jornadas Total.
Como muestra la regresión polinomial aplicada, la baja de utilización de jornadas se observa profundamente desde el escenario de control, hacia el escenario 2, bajando de 148 a 73 jornadas, mostrando un decremento de 51%. Para la transición desde el Escenario 2 al Escenario 3, se muestra una bajada de 73 a 56 jornadas, mostrando un decremento de 23%. Si realizamos la comparación del Escenario 1 de control versus el escenario final, mostramos un decremento del 62% lo cual se traduce en impacto directo en el margen de los proyectos, a evaluar en puntos siguientes. Esto implica necesariamente que la inversión de 15 jornadas extra, implica un ahorro neto de 92 jornadas. Con esto se puede inferir que la introducción del proceso de Arquitectura de Delivery impactó positivamente en la ejecución total del proyecto.
Gráfica 2. Impacto en uso de Jornadas, Comparación por Ambiente.
Al analizar comparando el desempeño por ambientes, podemos ver que sin aplicar OEAF, el comportamiento de utilización de jornadas en el escenario de control es errático, sin embargo una vez aplicado OEAF, se observa un patrón en el cual el primer ambiente construido, sin realizar reutilización de SBB, está ligeramente por sobre el target, sin embargo conforme avanza el proyecto, los siguientes ambientes están siempre bajo el target esperado. Ésta observación se puede extrapolar hacia las subsecuentes implementaciones reutilizando los artefactos construidos, exponiendo una tendencia hacia la baja.
148
73
56
76,5
91,5 91,5
R² = 1
0
20
40
60
80
100
120
140
160
Escenario 1 (Control) Escenario 2 Escenario 3
Impacto en Jornadas Total
Jornadas Target Polinómica (Jornadas)
48,5
30,5
21
52,5
2319
47
19,516
0
10
20
30
40
50
60
Escenario 1 (Control) Escenario 2 Escenario 3
Impacto en Uso de Jornadas, Comparación por Ambient e
DEV QA PRD
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
20
Aumento de Margen de Proyectos Evaluados La siguiente grafica construida en base a los IMM definidos en las secciones anteriores, muestra el desempeño al alza como consecuencia directa de la reducción de uso de jornadas descrita en el punto inmediatamente anterior:
Gráfica 3. Impacto en Margen Total.
Como se muestra en la gráfica, el impacto entre el Escenario de control y el Escenario 2, genera las garantías de alcance de margen de forma inmediata, superando el target de 50%, teniendo cero reutilización de SBB. Por otra parte, conforme los artefactos se van re-utilizando, el margen se ve impactado en un 11%. La regresión polinomial aplicada a la gráfica muestra la tendencia al alza de manera creciente. El aumento de margen entra en resonancia directa como es demostrado en el punto anterior, con el decremento de uso de jornadas, en los puntos detectados como críticos en el punto 4.6.
Gráfica 4. Impacto en Margen Comparación por Ambiente.
La gráfica anterior, muestra que sin la aplicación de OEAF, la gran cantidad de traspiés detectados en las etapas de instalación y configuración, afectan profundamente al margen del proyecto. El solo hecho de utilizar inicialmente las 15 jornadas cubicadas para arquitectura, eliminan el factor de incertidumbre. Además, se evidencia que el primer ambiente construido siempre es afectado desempeñándose de peor manera, sin embargo, desde el segundo en adelante, las instalaciones y configuraciones superan el target en un mínimo de un 5% y un máximo de 19%.
1%
52%
63%
50% 50% 50%
R² = 10%
10%
20%
30%
40%
50%
60%
70%
Escenario 1 (Control) Escenario 2 Escenario 3
Impacto en Margen Total
Margen Target Polinómica (Margen)
2%
39%
58%
-6%
55%
63%
6%
62%69%
-10%
0%
10%
20%
30%
40%
50%
60%
70%
80%
Escenario 1 (Control) Escenario 2 Escenario 3
Impacto en Margen Comparación por Ambiente
DEV QA PRD
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
21
Impacto General y efecto en áreas de Impacto utilizando OEAF
Gráfica 5. Costos y Jornadas vs Targets.
Como muestra la gráfica, las tendencias a la mejora quedan demostradas, exponiendo bajas en costos y usos de jornadas, lo que demuestra que el uso de la metodología es acertado. Por otra parte, con el fin de evaluar el efecto en las áreas de impacto identificadas en el punto 5.6, se realiza la des-agregación de estos ítems, con el fin de entender porcentualmente cuál es el área mayormente impactada por la aplicación de OEAF. Para ello se define la siguiente tabla, definiendo el cálculo con los siguientes cambios:
-Escenario N: Suma total de jornadas del ítem relacionado. - ∆: Diferencia entre lo cubicado menos lo utilizado dividido por lo cubicado. - Promedio 2 y 3: Promedio de Jornadas utilizadas en los escenarios 2 y 3, para el ítem relacionado. - Impacto Porcentual: Diferencia entre promedio de los escenarios 2 y 3 menos el valor del Escenario 1 dividido por el promedio de 2 y 3.
Tabla 13. Comparación de Escenarios.
Actividad Escenario 1
∆ Escenario 2
∆ Escenario 3
∆ Cubicado Promedio 2 y 3 Impacto Porcentual
Coordinación con Jefe
de Proyecto
24 -
1500%
3 -100% 4 -
167%
1,5 4 -586%
Creación de Máquinas
Virtuales requeridas
12 -300% 3 0% 2 50% 3,0 2 -433%
Creación de Puntos de
Montaje y
Configuración en OS
7 -133% 2 50% 2 50% 3,0 2 -367%
Configurar Sistema (6
instancias)
66 -47% 26 42% 20 56% 45,0 23 -187%
Con ello, podemos ver que el mayor impacto es causado en las reuniones de coordinación del jefe de proyecto, seguido de la creación de máquinas virtuales y puntos de montaje, relacionados al cálculo de licenciamiento y en último lugar la configuración de las instancias.
$ 22.570
$ 10.960 $ 8.300
$ 11.430
$ 13.830 $ 13.830
148
7356
76,5
91,5
91,5
$ -
$ 5.000
$ 10.000
$ 15.000
$ 20.000
$ 25.000
0
20
40
60
80
100
120
140
160
Escenario 1 (Control) Escenario 2 Escenario 3
Costos y Jornadas vs Targets
Costo Real Target Costo Uso Jornadas Real Target Jornadas
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
22
8 Conclusiones Finales y Trabajo Futuro
Luego de la realización del análisis de los Indicadores de Medición de Mejora (IMM), se concluye que la aplicación de OEAF tiene un impacto positivo en el uso de jornadas y el margen del proyecto, siendo recomendada su aplicación. Se concluye que la metodología impacta altamente el desempeño del TAM, al ahorrar significativamente en los tiempos relacionados a la coordinación inicial del proyecto definiendo el alcance derivado de la implementación de la tecnología a implementar. Se concluye por ello que este ítem a pesar de tener una baja estimación de esfuerzo, afecta ampliamente en el margen del proyecto y se infiere lo importante que es contar con una definición técnica clara al momento de iniciar la implementación de tecnología.
Se concluye además que la reutilización de SBB en proyectos subsecuentes, tiene un impacto positivo en la reducción de esfuerzos de arquitectura, significando ahorros a mediano-largo plazo.
Al aplicar la metodología, se concluye que como mínimo se garantiza el margen modelado inicialmente para el proyecto. Además, se evidencia que consecuentemente ambientes de similares características conforme se reutilizan los artefactos comienzan a realizarse en menos tiempo, sin embargo, el primer ambiente entregado siempre usará una mayor cantidad de jornadas de manera fija y en proporción decreciente.
La información capturada, además muestra que el impacto del uso de la metodología tiene menor efecto en el primer ambiente configurado, lo que tiene relación con la falta de familiaridad para con la metodología por parte de los ingenieros. Esto se propone como área de mejora, al introducir en etapas futuras entrenamiento de cómo usar los artefactos antes de comenzar las implementaciones, con el fin de disminuir los tiempos muertos a su mínima expresión.
Se puede observar además que el expertise técnico del ingeniero, directamente relacionado a su tarifa, tiene un impacto positivo en la ejecución de tareas complejas. Sin embargo, no es factible ejecutar todo con el nivel más alto de experiencia, debido a su impacto negativo en el costo. Este punto se comporta como variable independiente.
Se propone como trabajo futuro, el trabajo en implementación de servicios Infrastructure as Code (IaC), basado en DevOps, con el fin de tomar como entrada los SBB producidos en este trabajo y automatizar el despliegue y creación de máquinas, puntos de montaje y dominios, con el fin de reducir al mínimo la intervención humana y orientar la participación del ingeniero a las áreas consultivas del producto, esto es realizar troubleshooting y consultoría sobre el uso de ésta.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
23
9 Referencias
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
24
[1] M. Rønnebæk, «White Paper on Enterprise Architecture,» Working Grouo on IT Architecture within the Coordinating Information Comittee - Ministry of Science, Technology and Innovation, Copenhaggen, pp. 40 - 45, 2003.
[2] Wikipedia, "Information technology architecture," 27 07 2017. [Online]. Available: https://en.wikipedia.org/wiki/Information_technology_architecture. [Accessed 06 01 2018].
[3] R. R. Ramesh Radhakrishnan, «IT Infrastructure Architecture,» Sun Professional Services (Now Oracle Advanced Customer Services), 01 05 2004. [En línea]. Available: https://www.opengroup.org/architecture/0404brus/papers/rakesh/abb-1.pdf.
[4] S. Laan, IT Infrastructure Architecture - Infrastructure Building Blocks and Concepts, Lulu.com, 2017.
[5] F. Magazine, «Forbes Magazine,» 07 08 2014. [En línea]. Available: https://www.forbes.com/sites/jasonbloomberg/2014/ 08/07/enterprise-architecture-dont-be-a-fool-with-a-tool/#45914d3a7860. [Último acceso: 04 06 2018].
[6] T. O. G. A. F. (TOGAF), «TOGAF®, an Open Group standard,» [En línea]. Available: http://www.opengroup.org/subjectareas/enterprise/togaf. [Último acceso: 06 01 2018].
[7] The Open Group, «TOGAF Online > Part I: Introduction > Core Concepts,» The Open Group, 2009. [En línea]. Available: http://www.togaf.info/togaf9/chap02.html. [Último acceso: 06 01 2018].
[8] Oracle Corporation via Robert Covington, Hamza Jahangir, "The Oracle Enterprise Architecture Framework," pp. 1-12, 01 01 2009.
[9] O. Corporation, «IT Strategies from Oracle,» [En línea]. Available:https://community.oracle.com/community/fusion_middleware/architecture/it-strategies-from-oracle/content?filter ID=contentstatus[published]~category[oracle-reference-architectures]&customTheme=otn. [Último acceso: 01 04 2018].
[10] Wikipedia, «Request for Proposal,» 02 01 2018. [En línea]. Available: https://en.wikipedia.org/wiki/Request_for_proposal. [Último acceso: 07 01 2018].
[11] Oracle Corporation, "Oracle Enterprise Deployment Guide," 01 01 2015. [Online]. Available: https://docs.oracle.com/middleware/1213/soasuite/SOEDG/edg_workbook.htm#BABDFJGH. [Accessed 18 04 2018].
[12] Microsoft Corporation, «Microsoft Azure IoT Reference Architecture,» Microsoft Corporation, 01 01 2016. [En línea]. Available:http://download.microsoft.com/download/A/4/D/A4DAD253-BC21-41D3-B9D9-87D2AE6F0719/Microsoft_ Azure_IoT_Reference_Architecture.pdf. [Último acceso: 11 01 2018].
[13] IBM Corporation, «Developing a Technical Architecture for Web-Based Enterprise Software,» IBM Corporation, 01 06 2002. [En línea]. Available: https://www.ibm.com/developerworks/library/wa-techarch/index.html. [Último acceso: 18 12 2017].
[14] Amazon Web Services (AWS), «Well-Architected Framework,» Amazon, 2017. [En línea]. Available: https://d0.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf.
[15] Oracle Corporation, "Advanced Customer Services Home Page," Oracle Corporation, 01 01 2015. [Online]. Available: https://www.oracle.com/support/advanced-customer-support/index.html. [Accessed 14 04 2018].
[16] Oracle Corporation, "Oracle TAM DataSheet," 01 01 2017. [Online]. Available: http://www.oracle.com/us/support/advanced-customer-services/resource-library/technical-account-manager-4006120.pdf. [Accessed 14 04 2018].
[17] Oracle Corporation, «Oracle ASE Datasheet,» 01 01 2015. [En línea]. Available: https://www.oracle.com/us/assets/oracle-support-engineer-3662258.pdf. [Último acceso: 14 04 2018].
[18] Oracle Corporation, «License Definitions and Rules,» Oracle Corporation, 22 04 2018. [En línea]. Available: http://www.oracle.com/us/corporate/pricing/olsadef-ire-v122304-070549.pdf . [Último acceso: 22 04 2018].
[19] Oracle Corporation, "Core Factor Calculation," Oracle Corporation, 01 01 2017. [Online]. Available: http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf. [Accessed 22 04 2018].
[20] Oracle Corporation, «Partitioning Policy,» Oracle Corporation, 01 01 2017. [En línea]. Available: http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf. [Último acceso: 22 04 2018].
[21] Oracle Corporation, «Oracle WebLogic Server Documentation,» Oracle Corporation, 01 01 2017. [En línea]. Available: https://docs.oracle.com/middleware/12213/wls/index.html. [Último acceso: 02 05 2018].
[22] Oracle Corporation, «Oracle Service Bus Documentation,» Oracle Corporation, 01 01 2017. [En línea]. Available: https://docs.oracle.com/middleware/12213/lcm/INOSB/index.html. [Último acceso: 02 05 2018].
[23] Oracle Corporation, «Oracle Flexible Architecture,» Oracle Corporation, 01 01 2017. [En línea]. Available: https://docs.oracle.com/database/121/LADBI/appendix_ofa.htm#LADBI7916. [Último acceso: 02 05 2018].
[24] Oracle Corporation, «Maximum Availability Architecture,» Oracle Corporation, 01 01 2017. [En línea]. Available: http://www.oracle.com/technetwork/database/features/availability/maa-096107.html. [Último acceso: 02 05 2018].
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
25
10 Glosario
Término Definición
OEAF Oracle Enterprise Architecture Framework. Framework utilizado para el desarrollo de esta tesina.
ABB Capacidad Requerida dentro de un ambiente arquitectado.
SBB Componente implementado para cubrir la capacidad definida dentro de un ABB.
UML Unified Modeling Language.
Middleware Capa media de interacción de software, orientada a abstraer el funcionamiento y comunicación entre el cliente y la capa de datos.
TOGAF The Open Group Architecture Framework. Framework de Arquitectura ampliamente usado en la Industria.
ORA Oracle Reference Architecture. Arquitectura de Referencia utilizada para la implementación de tecnología Oracle.
ACS Advanced Customer Services. Organización de Consultoría perteneciente a Oracle Corporation.
TAM Technical Account Manager. Jefe De Proyectos a cargo de la ejecución de uno o más proyectos tecnológicos dentro de la organización de ACS.
ASE Advanced Support Engineer. Ingeniero a cargo de la implementación de uno o más proyectos tecnológicos dentro de la organización de ACS.
DCE DataCenter Engineer. Ingeniero a Cargo de la instalación y configuración de los servidores físicos dentro de soluciones de Datacenter.
S2DH Sales to Delivery Handover. Proceso en el cual el area de arquitectura de servicios presenta el proyecto vendido al area de ACS.
PRD Producción.
QA Quality Assurance.
DEV Desarrollo.
UMT Unidad Monetaria de Trabajo. Unidad monetaria ficticia creada para efectos de estandarización de costos en esta tesina.
IMM Indicador de Medicion de Mejora. Indicadores clave de medición de mejora para esta tesina.
Js Jornadas de Ingeniero Senior Realmente Utilizadas.
Je Jornadas de Ingeniero Estándar Realmente Utilizadas.
Cs Costo de Ingeniero Senior.
Ce Costo de Ingeniero Estándar.
OSB Oracle Service Bus. Software de Integración propiedad de Oracle Corporation. Sirve para integrar y converger tecnologías de distinto tipo en una arquitectura orientada a servicios.
EDW Enterprise Deployment Workbook. SBB creado para diseñar las soluciones de middleware cubiertas en esta tesina.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
26
OFA Oracle Flexible Architecture. Modelo de implementación arquitectónico adaptado a la escalabilidad y resiliencia de ambientes bajo tecnología Oracle.
MAA Maximum Availability Architecture. Arquitectura orientada a ofrecer la máxima disponibilidad posible, en función de los recursos adquiridos y licenciados.
SDK Software Delivery Kit. Lista de tareas lógicas requeridas para la ejecución de un proyecto tecnológico.
11 Anexos 11.1 Tablas de Desagregación de Costos y Tarifas Ambiente Único Tabla Anexa. Des-agregación de costos en función de Tareas y Entregables vs Perfil requerido, Costo, Tarifa en $UMT TO-BE
Descripción de Tarea Perfil Ingeniero
Costo Jornadas
Costo Ingeniero ($UMT)
Tarifa ($UMT)
Coordinación con Jefe de Proyecto
Senior 0,5 $ 80 $ 160
Realizar reunión preliminar de orientación y contexto
Senior 0,5 $ 80 $ 160
Arquitectura de Delivery Senior 5 $ 800 $ 1.600 Revisar documentación
disponible Estándar 0,5 $ 50 $ 95
Creación de Máquinas Virtuales requeridas
Senior 1 $ 160 $ 320
Creación de Puntos de Montaje y Configuración en OS
Senior 1 $ 160 $ 320
Ejecutar Repository Creation Utility e Instalar binarios de
productos relacionados
Estándar 2 $ 200 $ 380
Aplicar parches mandatorios y realizar si se aplica,
configuraciones post-instalación
Estándar 1 $ 100 $ 190
Configurar Sistema (6 instancias)
Senior 15 $ 2.400 $ 4.800
Realizar validación de configuración
Estándar 1 $ 100 $ 190
Preparar documentación relacionada
Senior 2 $ 320 $ 640
Realizar reunión final de revisión de documentación de instalación y recomendaciones
Senior 1 $ 160 $ 320
Total 30,5 $ 4.610 $ 9.175 Total, más Riesgo Estándar
(10%) 33,55 $ 5.071 $ 10.093
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
27
11.2 Detalle Muestra de Comportamiento Escenario de Control
Uso Real Jornadas Costo Total ($UMT)
Descripción de Tarea Costo Cubicado Jornadas
Perfil Ingeniero
DEV QA PRD DEV QA PRD
Coordinación con Jefe de Proyecto 0,5 Senior 8 6 10 $ 1.280 $ 960 $ 1.600 Arquitectura de Delivery - Senior - - - $ - $ - $ - Realizar reunión preliminar de orientación y contexto
0,5 Senior 1 1 0,5 $ 160 $ 160 $ 80
Revisar documentación disponible 0,5 Estándar 0,5 0,5 0,5 $ 50 $ 50 $ 50
Creación de Máquinas Virtuales requeridas
1 Senior 4 5 3 $ 640 $ 800 $ 480
Creación de Puntos de Montaje y Configuración en OS
1 Senior 2 3 2 $ 320 $ 480 $ 320
Ejecutar Repository Creation Utility e Instalar binarios de productos relacionados
2 Estándar 2 2 2 $ 200 $ 200 $ 200
Aplicar parches mandatorios y realizar si se aplica, configuraciones post-instalación
1 Estándar 1 1 1 $ 100 $ 100 $ 100
Configurar Sistema (6 instancias) 15 Senior 22 25 19 $ 3.520 $ 4.000 $ 3.040 Realizar validación de configuración 1 Estándar 2 3 3 $ 200 $ 300 $ 300 Preparar documentación relacionada 2 Senior 5 5 5 $ 800 $ 800 $ 800 Realizar reunión final de revisión de documentación de instalación y recomendaciones
1 Senior 1 1 1 $ 160 $ 160 $ 160
Uso Total Jornadas 25 148 49 52,5 47 Costo Total Real $ 22.570 $ 7.430 $ 8.010 $ 7.130 Desviación de Estimación -73 -24 -27,5 -22 Desviación de Costo -$ 11.140 -$ 3.620 -$ 4.200 -$ 3.320 Margen por Ambiente 2% -6% 6% Impacto en Margen (Target 50%) -49% -48% -55% -44% Margen Total Proyecto 1%
11.3 Detalle Muestra Escenario 2. Utilización de Artefactos OEAF inicial
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
28
Uso Real Jornadas Costo Total ($UMT)
Descripción de Tarea Costo Cubicado Jornadas
Perfil Ingeniero
DEV QA PRD DEV QA PRD
Coordinación con Jefe de Proyecto 0,5 Senior 2 0,5 0,5 $ 320 $ 80 $ 80 Arquitectura de Delivery 15 Senior 5 5 5 $ 800 $ 800 $ 800 Realizar reunión preliminar de orientación y contexto
0,5 Senior 1 1 0,5 $ 160 $ 160 $ 80
Revisar documentación disponible 0,5 Estándar 1 1 1 $ 100 $ 100 $ 100
Creación de Máquinas Virtuales requeridas
1 Senior 1 1 1 $ 160 $ 160 $ 160
Creación de Puntos de Montaje y Configuración en OS
1 Senior 0,5 0,5 0,5 $ 80 $ 80 $ 80
Ejecutar Repository Creation Utility e Instalar binarios de productos relacionados
2 Estándar 1 1 1 $ 100 $ 100 $ 100
Aplicar parches mandatorios y realizar si se aplica, configuraciones post-instalación
1 Estándar 1 1 1 $ 100 $ 100 $ 100
Configurar Sistema (6 instancias) 15 Senior 12 8 6 $ 1.920 $ 1.280 $ 960 Realizar validación de configuración 1 Estándar 1 1 1 $ 100 $ 100 $ 100 Preparar documentación relacionada 2 Senior 4 2 1 $ 640 $ 320 $ 160 Realizar reunión final de revisión de documentación de instalación y recomendaciones
1 Senior 1 1 1 $ 160 $ 160 $ 160
Total Estimación Proyecto 25 73 31 23 20 Costo Total $ 10.960 $ 4.640 $ 3.440 $ 2.880 Desviación de Estimación 2 -5,5 2 5,5 Desviación de Costo $ 470 -$ 830 $ 370 $ 930 Margen por Ambiente 39% 55% 62% Impacto en Margen (Target 50%) 2% -11% 5% 12% Margen Total Proyecto 52%
11.4 Detalle Muestra Escenario 3. Re-utilización de Artefactos OEAF.
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
29
Uso Real Jornadas Costo Total ($UMT)
Descripción de Tarea Costo Cubicado Jornadas
Perfil Ingeniero
DEV QA PRD DEV QA PRD
Coordinación con Jefe de Proyecto 0,5 Senior 2 1 1 $ 320 $ 160 $ 160
Arquitectura de Delivery 10 Senior 3 3 2 $ 480 $ 480 $ 320 Realizar reunión preliminar de orientación y contexto
0,5 Senior 1 1 1 $ 160 $ 160 $ 160
Revisar documentación disponible 0,5 Estándar $ - $ - $ - Creación de Máquinas Virtuales requeridas
1 Senior 0,5 0,5 0,5 $ 80 $ 80 $ 80
Creación de Puntos de Montaje y Configuración en OS
1 Senior 0,5 0,5 0,5 $ 80 $ 80 $ 80
Ejecutar Repository Creation Utility e Instalar binarios de productos relacionados
2 Estándar 1 1 1 $ 100 $ 100 $ 100
Aplicar parches mandatorios y realizar si se aplica, configuraciones post-instalación
1 Estándar 1 1 1 $ 100 $ 100 $ 100
Configurar Sistema (6 instancias) 15 Senior 8 7 5 $ 1.280 $ 1.120 $ 800
Realizar validación de configuración 1 Estándar 1 2 2 $ 100 $ 200 $ 200 Preparar documentación relacionada 2 Senior 2 1 1 $ 320 $ 160 $ 160
Realizar reunión final de revisión de documentación de instalación y recomendaciones
1 Senior 1 1 1 $ 160 $ 160 $ 160
Total Estimación Proyecto 25 56 21 19 16 Costo Total $ 8.300 $ 3.180 $ 2.800 $ 2.320 Desviación de Estimación 19 4 6 9 Desviación de Costo $ 3.130 $ 630 $ 1.010 $ 1.490 Margen por Ambiente 58% 63% 69% Impacto en Margen (Target 50%) 14% 8% 13% 20% Margen Total Proyecto 63%
11.5 Script de automatización import sys import os import datetime def create_dir(path): if not os.path.exists(path): os.makedirs(path) # Global Variables print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Setting Global Variables' ofa='/u01' domain_name='prd_osb_domain' dserver=ofa+'/app/oracle/admin/domains/'+domain_nam e log_dir=ofa+'/app/oracle/admin/logs/'+domain_name jms_dir=ofa+'/app/oracle/admin/jms/'+domain_name+'/ stores' sep='/' cookie_name='ADMINCONSOLE_'+domain_name usr='weblogic' pwd='foobarpasword' as_host="foprd01adminin" as_host_priv=as_host+'-priv' as_port="10000" as_socket='t3://'+as_host_priv+':'+as_port as_name='AdminServer' # Connect
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
30
print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Connecting to Admin Server' connect(usr,pwd,as_socket) edit() startEdit() # Domain Global Config # Exalogic Optimizations print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Setting Exalogic Optimizations' cd('/') cmo.setExalogicOptimizationsEnabled(true) print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Setting Console logs and cookie' cd('/') pwd() cd('/Log/'+domain_name) cmo.setFileName(log_dir+'/'+domain_name+'.log') cmo.setFileCount(30) cmo.setNumberOfFilesLimited(true) cmo.setRotationType('byTime') cd('/') cmo.setArchiveConfigurationCount(15) cmo.setConfigBackupEnabled(true) cmo.setClusterConstraintsEnabled(false) cd('/AdminConsole/'+domain_name) cmo.setCookieName(cookie_name) print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Setting Cluster to Unicast' cd('/Clusters/') # List of Servers clusters=cmo.getClusters() for cluster in clusters: myclus=cluster.getName() cd('/Clusters/'+myclus) cmo.setClusterMessagingMode('unicast') print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Setting Log redirection, Server System Properties' cd('/Servers/') # List of Servers servers=cmo.getServers() for server in servers: mysrv=server.getName() create_dir(log_dir+sep+mysrv) create_dir(log_dir+sep+mysrv+sep+'dump') cd('/Servers/'+mysrv+'/Log/'+mysrv) cmo.setFileName(log_dir+sep+mysrv+sep+mysrv+'.log' ) cmo.setNumberOfFilesLimited(true) cmo.setFileCount(30) cmo.setRotationType('byTime') cmo.setRedirectStderrToServerLogEnabled(true) cmo.setRedirectStdoutToServerLogEnabled(true) cd('/Servers/'+mysrv+'/WebServer/'+mysrv+'/WebServ erLog/'+mysrv) cmo.setFileName(log_dir+sep+mysrv+sep+'access.log' ) cmo.setFileCount(30) cmo.setNumberOfFilesLimited(true) cd('/Servers/'+mysrv+'/DataSource/'+mysrv+'/DataSo urceLogFile/'+mysrv) cmo.setFileName(log_dir+sep+mysrv+sep+'datasource. log') cmo.setNumberOfFilesLimited(true) cmo.setRotateLogOnStartup(true) cmo.setFileCount(30) cd('/Servers/'+mysrv+'/DefaultFileStore/'+mysrv)
Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
31
create_dir(jms_dir+sep+mysrv+sep+'tlogs') cmo.setDirectory(jms_dir+sep+mysrv+sep+'tlogs') if mysrv == as_name: print '['+ str(datetime.datetime.now().strftime(" %Y-%m-%d %H:%M:%S")) + '] Configuring AdminServer' cd('/Servers/'+mysrv) cmo.setAcceptBacklog(500) cd('/Servers/'+mysrv+'/ServerStart/'+mysrv) cmo.setArguments('-Xms3g -Xmx3g -Djava.security .egd=file:/dev/./urandom -Dweblogic.data.canTransferAnyFile=true -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:'+log_dir+sep+mysrv+sep+' gc.log -Djava.net.preferIPv4Stack=true -Dweblogic.nodemanager.ServiceEnabled=true -XX:+Heap DumpOnOutOfMemoryError -XX:HeapDumpPath='+log_dir+sep+mysrv+sep+'dump -Dweblogic.Stdout='+log_dir+sep+mysrv+sep+mysrv+'.ou t') cd('/Servers/'+mysrv+'/SSL/'+mysrv) cmo.setEnabled(false) cmo.setLoginTimeoutMillis(25000) if mysrv != as_name: print '['+ str(datetime.datetime.now().strftime(" %Y-%m-%d %H:%M:%S")) + '] Configuring Managed Servers' cd('/Servers/'+mysrv) cmo.setAcceptBacklog(500) cd('/Servers/'+mysrv+'/ServerStart/'+mysrv) cmo.setArguments('-Xms4g -Xmx4g -Djava.security.e gd=file:/dev/./urandom -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+Prin tHeapAtGC -Xloggc:'+log_dir+sep+mysrv+sep+'gc.log -Djava.net.p referIPv4Stack=true -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath='+l og_dir+sep+mysrv+sep+'dump -Dweblogic.Stdout='+log_dir+sep+mysrv+sep+mysrv+'.ou t' ) cd('/Servers/'+mysrv+'/SSL/'+mysrv) cmo.setEnabled(false) cmo.setLoginTimeoutMillis(25000)
11.6 Enterprise Deployment Workbook