Errores comunes en modelado dimensional para BI/DWH: Estructuras y jerarquías normalizadas

El actual articulo esta orientado a ingenieros y arquitectos de datos(principalmente para personas encargadas del diseño y/o construcción de data warehouse siguiendo un modelado multi-dimensional) por lo cual se asume y recomienda familiaridad con la materia.

Existen en la industria buenas prácticas , tips y patrones de diseño comprobadas a lo largo del tiempo y con muchos casos de éxito , pero de igual forma existen malas practicas, errores y acciones a evitar cuando se aborda la tarea de diseñar un modelo de datos para apoyar a la toma de decisiones .

Dentro de estos errores , es muy común el que se presenta en este articulo y también se presentará el método recomendado para manejarlo. Ojo, las ideas propuestas acá(y por los expertos de la industria) entran en conflicto con las buenas prácticas de diseño de modelos de datos que se enseñan religiosamente en universidades y cursos de bases de datos, por lo cual se recomienda terminar de leer el post antes de dejarlo a medias pensando que lo que en el se dice es incorrecto.

El error es: modelar estructuras y jerarquías normalizadas. 

A lo largo de mi experiencia me he encontrado con este error en múltiples ocasiones ,incluso siendo realizado por arquitectos de datos experimentados , pero a que se debe? Principalmente a que como se menciono , esta práctica se evangeliza y se trata religiosamente en universidades y cursos de bases de datos y comúnmente los arquitectos de datos incursionan en el diseño de un modelo de datos de toma de decisiones sin tener en cuenta las diferencias(incluso sin un entrenamiento adecuado) en el enfoque y objetivos de un modelo de datos transaccional(comúnmente relacional) y un modelo analítico(toma de decisiones, descubrimiento de patrones y conocimiento).

En un modelo transaccional , el modelo se realiza pensando en objetivos tales como: captura de información,reducción de redundancia, integridad referencial , disminución de espacio de almacenamiento y para esto se recurre comúnmente a un modelo entidad/ relación normalizado, en el cual se modelan entidades del mundo(o negocio) y las relaciones entre las mismas.

Por otra parte en un modelo analítico , el diseño se realiza con objetivos tales como: consumo de información,toma de decisiones, análisis de indicadores del negocio, facilidad de consumo y entendimiento por parte de usuarios no técnicos, velocidad de acceso a la información ,aplicar pocos o ningún calculo y formulas durante el consumo(durante el query, y hacerlo en el ETL) y que el query sea lo mas "limpio" posible  y es acá donde entra en conflicto el enfoque analítico con el transaccional  ,ya que en el modelo analítico no se modelan entidades y sus relaciones, si no procesos de negocio, las métricas generadas por el proceso  y el contexto o puntos de vista de análisis del proceso y sus métricas(dimensiones)  .En este caso es permitido y altamente RECOMENDADO el tener estructuras de datos redundantes , no normalizadas y sacrificar  la disminución de espacio de almacenamiento .

Entonces entrando en materia(y es acá donde los arquitectos de sistemas y datos encontraran difícil de digerir y aceptar el material)  y  viendo ejemplos reales del error y su solución  , manejaremos 2 situaciones comunes :

1. Modelado de productos y categorías.
2. Modelado de información geográfica(en este ejemplo estado y ciudad)

• Enfoque transaccional: En este enfoque se modelan entidades y sus relaciones,para el primer caso identificando 2 entidades : producto y categoría y la relación entre ambas(un producto pertenece a una categoría y en una categoría se agrupan muchos productos).. Para el segundo caso se identifican 2 entidades: estado y ciudad  y la relación entre ambas(una ciudad pertenece a un estado, un estado contiene muchas ciudades).  Para ambos casos esta es una relación de jerarquía , a nivel físico este diseño implicaría 2 tablas por jerarquía y una llave foránea como relación entre las mismas.A continuación se presenta un modelo ER simplificado(se ha dejado de lado otras entidades y otros atributos de las entidades mostradas con fines de ejemplo)

• Enfoque analítico(dimensional): En este enfoque se modelan procesos de negocio, las métricas generadas por los mismos, y el contexto(descripción,puntos de vista) llamado dimensión en el que se generan las métricas. Para estos 2 ejemplos en vez de 4 entidades(2 para información de producto y 2 para información geográfica) se tienen únicamente 2 dimensiones(seleccionando siempre el nivel mas granular o mas bajo en la jerarquía) , y cada dimensión contiene toda la información de la jerarquía representada , para estos 2 ejemplos , tendríamos que la dimensión de producto, tiene como atributo la categoría del mismo, y la dimensión de ciudad tiene como atributo el estado al que pertenece,esto genera redundancia y rompe reglas de normalizacion  ya que para este ejemplo la categoría se repetiría muchas veces(1 por cada producto en la categoría),pero como se mencionó esto es permitido y recomendado con fines de generar simplicidad de consumo(query fácil de construir) y tiempos de respuesta mas ágiles(query eficiente) ya que ni la base de datos, ni el usuario final debe realizar costosas uniones innecesarias(joins) entre múltiples tablas en la jerarquía. Algo que viene a la mente al arquitecto de datos acostumbrado a modelar de manera relacional , es que esto también genera  un mayor costo en disco pero se deben tomar 2 cosas en cuenta:
1. El mayor costo de disco es permitido y es el precio a pagar por la simplicidad y tiempo de consumo de datos.
2. Comúnmente los modelos analíticos son implementados sobre bases de datos columnares(como Amazon Redshift o SAP Sybase IQ), diseñadas con este tipo de modelado en mente y utilizando internamente estructuras como bitmaps(o indices bitmap) para almacenar una única vez cada valor diferente de la columna y acceder al valor a través del bitmap,logrando así una compresión significativa. Crear un modelo normalizado(y jerarquías con múltiples tablas) en un motor columnar, es desperdiciar y desaprovechar  las capacidades(Y la alta inversión económica!)   y enfoque del mismo.

          Podemos concluir entonces, que es recomendable no tener(o tener un mínimo) jerarquías de múltiples tablas(y las relacione entre ellas) y tener únicamente una tabla con el nivel mas bajo de la jerarquía y agregar el resto de datos de la jerarquía como atributos de la tabla,Y tener un único nivel de unión(de  fact table a la dimensión) aun que esto represente generar redundancia y romper normalizacion.

Esta recomendación no es algo generado por mi persona, lo recomiendan los expertos de la industria(incluso los creadores del modelado dimensional) como podemos ver en las siguientes referencias. Espero que esto sea de utilidad para generar mejores modelos analíticos.

Ver mistake #1

http://www.dataintegration.ninja/mistakes-bottom-up-datawarehouse-development-approach/

Ver rule#6

http://www.kimballgroup.com/2009/05/the-10-essential-rules-of-dimensional-modeling/

O bien, en el libro "The data warehouse toolkit", capitulo 8 ,pagina  398 ver : Mistake #8

Autor: Luis Leal

Predicción de ganancias en R

En este post se quiere dar una pequeña introducción a la predicción de las ganancias en ventas utilizando modelos de regresión lineal en R.

R es un lenguaje y ambiente  de programación para el análisis estadístico, es uno de los lenguajes mas utilizados para la investigación, con R podemos utilizar la data desde cualquier fuente de datos ya sea Excel, CSV, incluso conectarse con una base de datos y utilizarla para realizar este tipo de análisis, esta es una de las grandes ventajas con R ya que podemos utilizar la data cualquier forma que venga, manipularla y obtener resultados.

Los modelos de regresión lineal se basan en la relación entre una variable dependiente y una o mas variables independientes, los modelos de regresión lineal son utilizados para la predicción de los valores de la variable dependiente, se debe llegar a utilizar las variables dependientes correctas para tener un modelo mas preciso y llegar a tener una diferencia entre los valores predichos y la variable dependiente sea mínimo.

Los datos para realizar el ejemplo se obtuvieron de un csv que Pentaho brinda para hacer pruebas, este set de datos es un ejemplo de ventas de vehículos del año 2003 a inicios del 2005. En la data tenemos las columnas ORDERNUMBER, QUANTITYORDERED, PRICEEACH, ORDERLINENUMBER, SALES, STATUS, QTR_ID, MONTH_ID, YEAR_ID, PRODUCTLINE, MSRP, PRODUCTCODE, CUSTOMERNAME, CITY,  STATE, COUNTRY, PRODUCTLINEID, STATE_ID.

Para este post se realizo un script en R y se pretende demostrar como aplicar el modelo linear y predecir las ventas en este caso de vehículos, se agrego el link para descargar el ejemplo.

Si se quiere ver mas a fondo como se realizo este ejemplo, se puede descargar el código fuente, para ejecutarlo cargamos el script R  y ejecutamos la función :

   > predictSales()

 La funcionalidad de este script es con un modelo lineal describir la relación entre la ganancia y la información con la que se cuenta de los pedidos como por ejemplo la ciudad, fecha y el producto, y al final de la ejecución mostrar un gráfico que muestra las ganancias reales y las que genera el modelo. 

Al ejecutar el script se genera un gráfico con las ventas del año 2003 a inicios del 2005.

En este ejemplo se tomaron como variables independientes QTR_ID, MONTH_ID, YEAR_ID, PRODUCTLINEID, STATE_ID y como variable dependiente la ganancia. En R se puede generar un resumen del modelo con lo que podemos obtener valores como el error residual estándar, los grados de libertad, valos que nos indican que tan funcional es nuestro modelo e ir mejorando el modelo cambiando las variables dependientes para obtener un modelo mas eficiente. 

El error residual estándar es la diferencia entre los valores reales y los valores estimados de la regresión, en este caso se obtuvo un error residual estándar de 1,4077.55, este es un valor muy elevado por lo que se debe mejorar el modelo, a continuación se muestra la gráfica generada en R, en negro se muestra la ganancia obtenida de forma mensual y en rojo los valores estimados de la regresión linear. 

En la segunda parte de este post se explicara como mejorar el modelo para estar mas cerca de los valores reales y se estará prediciendo el numero de ordenes de un vehículo para ciertos estados, con esto se podrían tomar mejores decisiones para lograr mayores ganancias.

El código de este ejemplo se encuentra en Github. 

Watch Download

Muchas Gracias.

La importancia menospreciada de la aplicación de índices en un proyecto de BI/DWH

A diferencia de nuestros anteriores posts , este post no esta enfocado al analista de negocio o el tomador de desiciones que utiliza el data warehouse y el sistema o aplicaciones analiticas de inteligencia de negocios, si no que esta mas enfocado al equipo técnico detrás de un proyecto de este tipo(project managers,arquitectos de sistemas, desarrolladores de sistemas,administradores de sistemas y de bases de datos,ingenieros de datos,etc).

Todo aquel que haya tomado un curso de bases de datos, conoce la importancia de la apliacion de índices para mejorar el desempeño de una base de datos,pero la pregunta es , cuantas personas o equipos detrás de la construcción y mantenimiento de un sistema aplican lo aprendido en la teoría para mejorar el funcionamiento de un sistema real en su día a día? . Lamentablemente la respuesta es que muy pocas personas(o casi ninguna) lo hacen a pesar de que de manera académica se ve su importancia y los beneficios obtenidos, esto por muchas posibles razones,según mi experiencia y charlas con colegas ingenieros de sistemas, algunas de estas razones son:

• La constante presión y tiempos apretados para proyectos de este tipo obligan a que el equipo “funcione” y cumpla su objetivo, sin importar si lo hace de manera óptima y eficiente.
• Aun que la importancia de los indices es recalcada en los cursos, la teoría nunca se pone en práctica ya que los cursos universitarios se enfocan en un buen diseño de la base de datos pretendiendo cumplir con los requerimientos funcionales,sin dar importancia a el rendimiento del sistema.
• Muchas personas, no conocen la importancia(o incluso que es) de la aplicación de indices nisiquiera de manera teorica ya que el curso se enfoca en crear un buen diseño y sentencias y herramientas de implementacion y manipulación de ese diseño.
• Muchas veces el adminsitrador de bases de datos piensa que es tarea del desarrollador y el desarrollador piensa que es tarea del administrador de base de datos. En realidad es una tarea conjunta en donde ambos deberían de aportar , el desarrollador comunmente tiene un mayor conocimiento y detalle de la manera y frecuencia en que las aplicaciones acceden a la información y el administrador de base de datos conoce como esta realiza internamente estos accesos.
• Simplemente al equipo no le importa o es algo para lo que no se desea invertir esfuerzo.

En el ámbito de proyectos y sistemas de inteligencia de negocios y data warehouse, este problema se presenta aún con mas frecuencia a pesar de que debería de ser mas importante ya que uno de los objetivos de un sistema de Dwh es agilizar y minimizar el tiempo de acceso a la información, en este caso el problema se presenta debido a las razones ya mencionadas(agendas apretadas,desconocimiento del tema, mala planificación,indiferencia) y otras razones tales como:

• Se utiliza un motor de base de datos optimizado para sistemas analiticos(por ejemplo motorores de bases de datos columnares) y se tiene la falsa creencia o se escucha el falso mito, de que estos motores de base de datos, no necesitan(o incluso no poseen) indices. (Ver al final del post : Ejemplo Aplicado)
• Se tiene la falsa creencia ,de que al tener la información en un diseño optimizado para analisis(como un modelo estrella) se hace innecesario contar con indices ya que no hay manera de agilizar el acceso a la información.
• Nuevamente , mala planificación y no contar con tiempo en la agenda para realizar esto.

En mi experiencia trabajando para una consultora con expertise en BI/DWH , la aplicación de indices nunca estuvo en el plan del proyecto , y se contemplaba como una alternativa, hasta que el performance del sistema se veía degradado.

Según los expertos(y creadores originales) de las técnicas y patrones del modelado dimensional para sistemas de BI/DWH , el diseño de un plan de índices es tan importante, como el diseño del modelo dimensional ,el tiempo para esta actividad debe estar contemplado en el plan del proyecto y debe ser realizado posteriormente(al menos en una versión inicial) justo después de tener el diseño del modelo dimensional realizado y un perfilamiento inicial de la data realizado(para conocer cantidad de registros,tipos de datos , valores unicos en cada tabla). Para mayor información de esto , se puede consultar la metodología o ciclo de vida Kimball y el libro “The Data Warehouse Lifecycle Toolkit”

Ejemplo 

Como se mencionó, una de las razones por las cuales erróneamente no se aplican índices en un sistema de BI/DWH ,es que muchas veces se utiliza un motor de base de datos optimizado para analíticos, por ejemplo una base de datos columnar(como amazon Redshift o Sybase IQ) y se tiene la idea equivocada de que esto hace innecesaria la aplicación de índices, o incluso que el motor de base de datos no brinda esta característica.

En mi experiencia en multiples proyectos con motores de base de datos columnares ,esta fue una tarea menospreciada y olvidada en muchas ocasiones ,pero cuando se presento la necesidad de realizara, se obtuvieron beneficios destacables,por ejemplo para el motor de base de datos columnar Sybase IQ(al igual que la mayoría en el mercado) ofrece multiples tipos de indices y cada tipo se encuentra destinado a cierta tarea, según factores como:

• Tipo de dato
• Cardinalidad de valores en una tabla
• Es una columna utilizada para un join?
• Es una dimension o un indicador?

Para el caso de amazon redshift, el concepto de indice no aplica en el sentido convencional, pero este maneja diferentes conceptos tales como sortkeys,distribution keys y encoding. Que tipo de cada uno de estos aplicar depende mucho de la estructura , cardinalidad , uso(por ejemplo si es ROLAP o OLTP,para ROLAP si es dimension o fact table)  , como ejemplos tenemos:

• Para surrogate keys conviene usar encoding o compresion tipo delta.
• Para llaves foraneas(en una fact table) a dimensiones con cardinalidad menor a 255 valores, usar bytedict(equivalente a indices bitmap en Sybase IQ).

pero los beneficios pueden ser enormes, tanto en performance como en storage(lo cual se traduce en ahorro de dinero).

Referencias utiles

•   Para aprender mas sobre índices en general(para los motores de base de datos mas comunes) consultar:
  • el libro: “SQL Performance Explained” de Markus Winand
  • El sitio: http://use-the-index-luke.com/
    
• Para aprender mas sobre la metodología Kimball , y sus recomendaciones sobre el plan y aplicación de indices, consultar:
  • “The Data Warehouse Lyfecycle Toolkit”
  • “The Data Warehouse Toolkit”
• Para aprender mas sobre los diferentes tipos de indices y su aplicación en el motor SAP Sybase IQ, consultar mi siguiente post :)   

Un poco más allá de reportes

Cuando se escucha hablar sobre el BI (Business Intelligence) dentro de las empresas, es muy común a que se refieran a este como la sección que realiza los reportes de la empresa. Un departamento en el cual se le pide un reporte de forma periódica, lo vemos en una hoja de cálculo, se le pide a lo sumo una cuantas operaciones aritméticas, estadísticas y una gráfica de barras.

Es cierto que el departamento de BI puede realizar este tipo de requerimientos pero es solo una mínima parte del potencial que se puede llegar a tener un departamento de BI. Las empresas generan data de formas muy diferentes y de distinto índole, tanto como lo es en en el aspecto comercial sino también del funcionamiento en sí de la empresa. Pero la data en sí no representa mucho, el potencial se encuentra escondido en este mar de data y por eso es fundamental poder procesarla y poder obtener información, pero muchisimo mas importante es la interpretación que se le pueda dar.

Uno de los aspectos a tomar en cuenta y que se puede pensar que es algo lógico pero muchas veces no se le da la importancia necesaria es: la data. Es el corazón de todo, ya que de nada sirve tener definido los tipos de análisis que se realizarán, las herramientas más complejas y modernas que se encuentren disponibles en el mercado para la presentación, el último motor de base de datos en nuestro datawarehouse,  sino tenemos una data que valga la pena analizar. Se debe contar con una data limpia, confiable y certificada. Tenemos que tener reglas claras para el manejo de la data, datos nulos, el manejo de apropiado de texto. Cuando se maneja tablas dimensionales como por ejemplo en un modelo estrella tener las llaves subrogadas de forma apropiada, si se maneja una tabla de comportamiento en el tiempo (Slow change dimension) tener claro cuánto cambio en el registro vamos a tener, definiendo el detalle de cambio que queremos guardar. Se debe de contar con una data en la cual podamos realizar las operaciones y análisis con toda la certeza de que los valores que representa la data son los correctos, sin necesidad de preocuparnos por algún registro cuyo valor esté fuera de lo normal, la fuente de datos sea la correcta y no alguna temporal o emergente.

Es importante contar con suficiente data para analizar, ya que se si realizara análisis de comportamiento o análisis de series de tiempo no es posible realizar un análisis confiable con un set de datos pequeño en cuestión de historia guardada. Se debe contar data que cubran diferentes series de tiempo,  años, lustros, etc. para realmente encontrar patrones de comportamiento y poder realizar comparaciones respecto de alguna posicion del tiempo.

Ya con nuestras herramientas y la materia prima lista, nos podemos preguntar ¿qué esperamos de estos análisis? Dependiendo del negocio que se está analizando existen diferentes tipos de análisis, una empresa comercial tendria interes en conocer si sus promociones han tenido impacto en los consumidores de forma esporádica e instantánea o realmente han elevado las transacciones en cada consumidor, fue correcto el segmento de clientes que eligieron para dicha promoción dado las características de estos. Si la empresa está teniendo una disminución de clientes, qué características tienen estos, es posible plantear un plan de retención que sea lo suficientemente atractivo para los clientes. Para esto se cuentan con diferentes modelos análisis como análisis de regresión, árboles de decisión, redes neuronales, SVM, Deep Learning, entre otras; las cuales pueden llegar a tener diferentes objetivos como ser un análisis predictivo o un analisis de clasificacion.

Con estas herramientas podemos descubrir nueva formas de estrategias para  alimentar la toma de decisiones dentro del negocio de una forma más analitica con un respaldo matemático bastante sólido.

Con esto podemos tener un departamento de BI involucrado en el negocio y no solamente un departamento de reportería.

Business Intelligence, Data Warehousing, Modelado Dimensional: ¿Que es desde un punto de vista no técnico?

Actualmente , en una era dominada por la información y la tecnología que facilita el acceso(y creación) de la misma,es muy común encontrarse con los términos "Business Intelligence"(inteligencia de negocios,inteligencia empresarial) y "Data Warehouse"(y otros relacionados como "Data Mining", "Big Data","Data Science"), desafortunadamente existe muy poca información relacionada a estos temas desde un punto de vista no técnico , la mayoría de información esta enfocada a personas del área de tecnologías de la información(TI) o informática y comúnmente se encuentra explicado en función de términos tales como  : Bases  de datos,SQL,query,ETL y otros que no pertenecen al vocabulario y conocimiento de un usuario de negocio(tal como un gerente o un tomador de desiciones).

¿Que es un sistema BI/DWH desde un punto de vista de negocio, y que beneficios tiene al mismo? De manera resumida , es un sistema destinado a apoyar,facilitar y eficientar la toma de decisiones. Se basa en el hecho de que la información de una empresa/organización, es uno de sus activos mas importantes pero lamentablemente es también comúnmente uno de los mas desaprovechados debido a las complejidades técnicas que se presentan en su almacenamiento( y acceso a los mismos). Es allí donde entramos en juego las personas encargadas del diseño y construcción de sistemas de BI/DWH.Nuestro trabajo es utilizar nuestro conocimiento técnico(diseño y administración de sistemas y bases de datos,programación y desarrollo de sistemas) para investigar, limpiar ,reorganizar e integrar los datos de una organización con el fin de entregar a los usuarios de negocio un punto único  de acceso a los mismos para tomar decisiones de manera mas acertada y fundamentada en hechos reales del negocio, esto teniendo presentes en todo momento 2  objetivos fundamentales de diseño:

• Simplicidad y facilidad de acceso:  Se busca eliminar toda complejidad inherente de los sistemas y bases de datos de una organización para que la información pueda ser consumida sin problema(y sin necesidad de conocimiento técnico como el lenguaje SQL o las estructuras de datos internas) por cualquier tomador de decisiones en cualquier momento y pueda manipular la información a su gusto(cruces de información,ordenamientos,rankings,tendencias,análisis estadísticos y matemáticos, análisis predictivos,etc) sin solicitar ninguna manipulación o formateo al personal experto en informática. 
• Agilidad y velocidad: En el pasado( y desafortunadamente aún en muchas empresas) ,cuando a un tomador de decisiones le surgía una pregunta de negocio, este solicitaba informes al personal de informática y estos debían preparar la información en un informe, este proceso tomaba mucho tiempo y para cuando la pregunta de negocio era respondida, ya era demasiado tarde(se habían perdido oportunidades de negocio o mejoras) , o bien surgían otras que debían esperar mas tiempo en ser respondidas. Un sistema de BI/DWH debe resolver este problema al permitir al usuario responder preguntas de negocio de manera rápida y en tiempo real cuando las preguntas o necesidades de información surgen, sin tener que solicitar apoyo a informática y de este modo, obtener ventajas competitivas.

Cabe resaltar que en la actualidad ,existe la mala percepción de que una organización que desarrolla informes/reportes o que copia(tal cual) sus datos desde sus sistemas fuente a un área dedicada a consulta ,ya ha adoptado BI,esto no es cierto y se pierden muchos beneficios incluidos los 2 objetivos fundamentales mencionados.

Con esto ya podemos diferenciar los sistemas BI/DWH de los sistemas operativos de una organización.

• Sistema operativo(operacional o transaccional): Sistema dedicado a facilitar(y registrar) las operaciones y transacciones de un negocio , tales como: ventas, inventarios, contabilidad y todas las operaciones del día a día de un negocio.Pueden ser sistemas complejos o archivos de texto o excel. Son el timón que fija el curso de una organización.
• Sistema de BI/DWH: sistema enfocado a la toma de decisiones, destinado a facilitar el consumo de información . Con la analogía del timón, son sistemas para monitorear  las acciones realizadas por el timón y medir el desempeño para tomar decisiones del rumbo  a seguir.

El sistema de BI/DWH debe ser visto por los usuarios como la fuente verídica e integrada de la información de la organización y servir de fuente para aplicaciones analíticas,predictivas y estadísticas o de minería de datos.

Existen muchas herramientas de BI por diversos fabricantes según diversas necesidades pero 

la base para un sistema de BI es el modelado dimensional, del cual hablaré en otra ocasión.

Espero que esta lectura resulte interesante y logre captar la esencia de un sistema de BI.

Muchas gracias!

Post Inicial-Presentacion

DevonGT surge como iniciativa de 2 amigos amantes de la tecnología y las ciencias y surge durante su formación universitaria en esta área. Actualmente los 2 siendo ingenieros en ciencias y sistemas, luego de trabajar por bastante tiempo para otras empresas y organizaciones(siendo compañeros en una de ellas), la idea de DevonGT siempre se mantuvo presente bajo la premisa de dar vida a ideas tecnológicas propias del equipo ,en las cuales el equipo pudiera dar rienda suelta a su creatividad sin las limitantes y restricciones con las cuales es comúnmente encontrarse cuando el equipo desarrollador no es el mismo que ha concebido una idea y cuando el creador de la idea no siente pasión por crear tecnología.

Actualmente(año 2015) el equipo trabaja enfocado en el área de inteligencia de negocios, data warehouse y analíticos y ha desarrollado experiencia en distintas organizaciones tanto privadas como gubernamentales(algunas de las mas grandes en Guatemala) pero también cuenta con experiencia previa en desarrollo de software convencional(aplicaciones de escritorio) , web y  aplicaciones móviles(Android y IOS) entre otras cosas.

Al equipo inicial se han integrado otros entusiastas de la tecnología con habilidades diferentes que se complementan entre sí, de esta forma llegando a ofrecer servicios tecnológicos para empresas y organizaciones siempre manteniendo la premisa de desarrollar todo proyecto con la pasión que se ha tenido desde un inicio de dar vida  a ideas tecnológicas innovadoras para la sociedad.

Además de estar en proceso de desarrollo de ideas propias del equipo, el equipo ofrece sus servicios tecnológicos en :

• Desarrollo de software convencional
• Desarrollo de sitios y aplicaciones web
• Desarrollo de aplicaciones móviles
• Inteligencia de negocios, data warehousing y analíticos, desde reportes básicos a complejos sistemas de data warehouse para apoyar la toma de decisiones.

  Todos estos servicios a la medida y según las necesidades de cada cliente.

Esta publicación es la primera de muchas que planeamos realizar ya que como amantes de la tecnología , a todos en el equipo nos apasiona investigar, experimentar y dar a conocer noticias, experiencias y conocimiento obtenido en el ámbito de las ciencias de la computación y tecnología tanto en el panorama mundial, como en nuestros proyectos y experiencias como equipo. Esperamos que nuestras publicaciones y noticias sean de interés y/o utilidad para muchos lectores.

Pueden escribirnos sus comentarios ,sugerencias o dudas a mail.devongt@gmail.com

Muchas gracias.