Motor de KPIs

En esta release se ha incorporado la definición y creación de KPIs (Key Performance Indicator) en Sofia2. Un KPI consiste básicamente en una métrica que nos ayuda a medir y a cuantificar un progreso en función de unas metas y objetivos planteados, es decir, un KPI se diseña para mostrar cómo es el progreso en un proceso o producto en concreto.

En Sofia2 se ha implementado el concepto de KPI vía el concepto de ontología, en esta se almacenará aquella información procedente de otras ontologías que se considere relevante para el estudio de la evolución de una serie de parámetros.

Por tanto, para crear un KPI, debemos dirigirnos al menú Ontología->Crear Ontología y despues hacer click sobre Crear Ontología de tipo KPI:


Seguir leyendo “Motor de KPIs”

Motor de KPIs

Comó crear un Dashboard paso a paso.

En este post vamos a explicar el proceso de creación de un Dashboard.

En la Plataforma todos los módulos trabajan alrededor del concepto de Ontología, y esto también aplica a los Dashboards. Por tanto lo primero será seleccionar/crear/cargar las Ontologías que va a manejar.

En este ejemplo voy a crear un Dashboard que representa las Ventas de una empresa, así que crearemos:

  • una ontología ‘PuntoVenta‘ para representar los puntos de ventas global (continente)
  • y otra ‘PuntoVentaCliente‘ en la que representamos el punto de venta local (ciudad).

De las diversas formas que tenemos para crear una ontología seleccionamos ‘Creación Guiada Ontología’ dentro del menú Ontologías>Crear Ontología.

Veamos los atributos de cada una de ellas.

Seguir leyendo “Comó crear un Dashboard paso a paso.”

Comó crear un Dashboard paso a paso.

Analysis of the Total Cost of Ownership (TCO) of Sofia2 vs Custom development

In this post we have put together a simple analysis about the TCO of Sofia2 vs a Custom development on a relational database.

The Total Cost of Ownership (TCO) of MongoDB and Oracle includes upfront and ongoing costs including software, hardware and personnel.


The initial costs include:

  • Initial developer effort: Personnel costs + Developer coding required to get the application and data store working together
  • Initial administrative effort: Personnel costs + Admins to install and configure software, cluster machines, set up sharding, etc
  • Software licenses
  • Server hardware: Servers required to run database (excludes storage).  Driven primarily by the number and type of processors and RAM. Other costs include enclosures, network connectivity, cabling, and power supplies.
  • Storage hardware: Storage required to store the data, varies depending on whether internal or shared (SAN) storage is used, the amount of storage and whether hard disk drives (HDDs) or solid state drives (SSDs) are used.


Consistes of:

  • Ongoing developer effort: Personnel + Coding needed to adapt data store to the customer, market and business needs.
  • Ongoing administrative effort: Personnel + Administrative effort required to keep the data store healthy and running.
  • Software maintenance and support: Maintenance: Upgrades and bug fixes for software + Support: On-call assistance for troubleshooting technical problems with software.
  • Hardware maintenance and support: Maintenance: Upgrades and bug fixes for firmware and any software that may come with the hardware + Support: On-call assistance for troubleshooting technical problems with hardware.
  • Miscellaneous Deployment Costs: Other costs associated with keeping database up and running. Includes cloud/hosting/colocation costs, bandwidth charges, electricity feed, etc.

Here is how Sofia2 reduces various costs that make up the TCO of a system:


The initial developer effort refers to the cost of time spent by the developer to ensure that the application and data warehouse work together.

In the case of a development on a relational database, the initial development effort includes tasks such as defining the data model, creating a layer of object-relational mapping (ORM), write the business logic for the application and make the presentation layer for this logic.


Sofia2 is designed to reduce development time, so that a developer can use the platform easily with any language.

With Sofia2 Console developers can:

  • Create their own entities (Ontologies in Sofia2, tables in an RDBMS, collections in MongoDB)
  • Define their business rules in a simple and guided way
  • Provide secure access to their entities
  • CRUD access (create, read, update, delete, …) to all these entities through any language (Java, Javascript, C, Android, …) allowing you to develop Web MVC applications (API Java, Python, Node js), HTML5 applications (API Javascript), mobile applications (API Android, iOS, Javascript …) or business modules (Java, Python, C, …)
  • Ability to subscribe to events, queries, rules, … easily and independently of the messaging protocol (JMS, MQTT, AMQP, …)
  • Assisted Publishing and APIs REST website based on entities
  • Integrated GIS Capabilities
  • Integrated Dashboards
  • Integrated reporting
  • Integrated Big Data Repository

 Therefore, we can say that it is much more profitable to develop with Sofia2 that to do a custom development on a relational database.

Another important productivity advantage of Sofia2 is its design of Entities (Ontologies) oriented to dynamic documents and schemas. The way in which the platform stores data from the application corresponds with the technology and current development practices that have evolved considerably since the beginning of the industry of the relational databases 30 years ago.

Some reasons that support the productivity benefits of Sofia2 are:

  • Usability: Sofia2 is compatible with existing development methodologies, allows developers to iterate quickly and continuously on the data model and all from a Web interface. In contrast to a traditional  relational model development that imposes a strict set of constraints to develop, both in terms of data model, rule creation, changes, …
  • Data Model. With Sofia2, the developer only has to create the data model in one place: the product´s own Web Console. In a traditional development developers need to create and maintain the data model in three places using different interfaces: the application, the database itself and the ORM layer.
  • Data flexibility. Unlike a RDBMS, Sofia2 allows developers to easily store polymorphic data and semi-structured and structured data in a individual data store.
  • JSON support. Storage in JSON, mainstay of many current applications, is done smoothly and does not require conversion. With a RDBMS, developers need to “flatten” and transform JSON to store it in relational tables, and then they have to recover the layers to make the extraction of the database.


The Installation and configuration of Sofia2 is cheap and easy. The Platform consists of:

  • CDB (Configuration DataBase): can be any relational database. By default it runs on a MySQL embedded DB.
  • RTDB (Real Time DataBase): where in the RI it is MongoDB making the initial administrative effort is low, an administrator must take into account a single variable: the number of nodes in the cluster. There is only a small set of configuration settings to put the system into operation. MongoDB administrators do not need to integrate layers of cache or create custom logic horizontal partitioning to direct queries to the correct server node. Instead, the memory storage, cache and the horizontal partitioning are core capabilities of MongoDB.
  • HDB (Historical DataBase): It can run on MongoDB or Hadoop depending on the needs or preferences.
  • SIB + Console + Tools + API Manager + Process: all business modules are built on Java, deployed as Web applications on any JEE application server. The bulk of the configuration goes in the CDB so it is not necessary to create complex configuration files.


Sofia2 is a platform with a free version for the open source community (Apache license) and an issue for business subscribes that can be used in different modes: On Premise or Cloud.

This version includes support in various forms (from 8×5 without SLAS to 24×7 with strict SLAS), software updates and solution to errors and some additional functions.

The commercial edition of Sofia2 is billed continuously instead of timely (ie, an annual fee per server).


In general, the cost of Sofia2 servers is considerably lower than in a traditional development on a relational DB for similar workloads and availability. This applies to all components.

Sofia2 is designed to use basic hardware in scalable architectures.

Sofia2 deployments typically use basic and economic Linux servers, which cost only $3.000, even a low-power and high performance can cost just $4.000 (excluding storage).


The scalable architecture of Sofia2 significantly reduces storage costs.

Sofia2 can use local economic storage and allows to efficiently use the solid state drives (SSD).


The dynamics of current development efforts are lower than the initial development effort.

With a traditional development, the cost of making changes in the application is greater, whether they are changes in the schema of a database that is already in production (greater costs than for a database that has not yet been delivered) as in the development of logic, rules, security settings.

For example with Sofia2 it is easy for developers to add fields to entities, create new APIs, which leads to significantly lower costs and allows developers to adapt applications as the demands evolve.


The ongoing administrative effort includes activities that keep the system in good working order (for example, updating software or hardware, performing backups and recovery times of unexpected interruptions).

Managing Sofia2 requires much less time and effort compared with traditional development.

Administration of a Sofia2 deployment primarily involves administering Linux configurations and hardware itself; so you only need to know and manage a few parameters.


Sofia2 subscriptions are billed annually per core. This includes access to product support, software updates and bug fixes as well as certain functionalities that are only available in the paid edition.


In addition to tangible cost savings, the model oriented to documents and Sofia2´s flexible schema, the platform also provides greater agility and flexibility to companies, which in turn provide advantages to generate income.

Once the Sofia2 Platform is implanted in a company, they can use the Platform (without the need to build a new infrastructure) for new deployments and to integrate data from other systems so they have them centralized in a common repository with Big Data capabilities. You can also develop Sofia2 applications with any technology and language.

Analysis of the Total Cost of Ownership (TCO) of Sofia2 vs Custom development

Análisis sobre el TCO (Coste Total de Propiedad) de Sofia2 vs Desarrollo a medida

En este post vamos a hacer un pequeño análisis sobre el TCO de Sofia2 vs un desarrollo a medida sobre una base de datos relacional.

El coste total de propiedad (TCO) de MongoDB y Oracle incluye los costes iniciales y corrientes que incluyen software, hardware y personal.


Los costes iniciales se componen de:

  • Esfuerzo de desarrollo inicial: Coste de personal + Programación del desarrollador necesaria para la aplicación
  • Esfuerzo administrativo inicial: Coste de personal + Administradores para instalar y configurar software, máquinas del clúster, particionado, …
  • Licencias de software
  • Hardware de servidores
  • Hardware de almacenamiento Almacenamiento necesario para almacenar los datos, varía en función de si se utiliza almacenamiento interno o compartido (SAN), de la cantidad de almacenamiento y de si se utilizan unidades de disco duro (HDD) o unidades de estado sólido (SSD).



Se compone de:

  • Esfuerzo de desarrollo corriente: Personal + Programación necesaria para adaptar el almacén de datos a las necesidades del cliente, del mercado y empresariales
  • Esfuerzo administrativo corriente: Personal + Esfuerzo administrativo necesario para mantener el funcionamiento y ejecución del almacén de datos
  • Mantenimiento y soporte técnico del software: Mantenimiento: actualizaciones y soluciones de errores del software + Soporte técnico: asistencia para localizar y solucionar problemas técnicos en el software
  • Mantenimiento y soporte técnico del hardware:
  • Costes de despliegue diversos: Otros costes necesarios para mantener la base de datos en funcionamiento. Incluye costes de nube/alojamiento/coubicación, costes de ancho de banda, tarifas eléctricas, etc.

A continuación veremos cómo Sofia2 reduce los diversos costes que componen el TCO de un sistema:


El esfuerzo de desarrollo inicial se refiere al coste del tiempo dedicado por el desarrollador para conseguir que la aplicación y el almacén de datos trabajen juntos.

En el caso de un desarrollo sobre base de datos relacional, el esfuerzo de desarrollo inicial incluye tareas como definir el modelo de datos, crear una capa de mapeo objeto-relacional (ORM), escribir la lógica empresarial para la aplicación y hacer la capa de presentación para esta lógica.

Sofia2 está diseñado para que reducir los tiempos de desarrollo, de modo que un desarrollador en cualquier lenguaje pueda utilizar la Plataforma con facilidad.

Para eso a través de la Consola Sofia2 (Sofia2-Console) el desarrollador puede:

  • crear sus entidades (Ontologías en Sofia2, tablas en un SGBDR, colecciones en MongoDB),
  • definir sus reglas de negocio de forma sencilla y asistida,
  • establecer seguridad en el acceso a sus entidades,
  • Acceso CRUD (consulta, inserción, borrado, actualización,…) a todas estas entidades a través de cualquier lenguaje (Java, Javascript, C, Android,…) lo que le permite desarrollar tanto aplicaciones Web MVC (API Java, Python, Node.js), aplicaciones HTML5 (API Javascript), aplicaciones móviles (API Android, iOS, Javascript…) o módulos de negocio (Java, Python, C,…)
  • Capacidad de suscripción a eventos, consultas, reglas, …de forma sencilla e independiente del protocolo de mensajería (JMS, MQTT, AMQP,…)
  • Publicación asistida y web de APIS REST a partir de las entidades
  • Capacidades GIS integradas
  • Dashboards integrados
  • Informes integrados
  • Repositorio Big Data integrado

Por lo tanto, podemos decir que resulta mucho más rentable desarrollar con Sofia2 que hacer un desarrollo a medida sobre bases de datos relacionales.

Otra  ventaja de productividad importante de Sofia2 es su diseño de Entidades (Ontologías) orientado a documentos y a los esquemas dinámicos. La forma en que almacena datos de la aplicación se corresponde con la tecnología y prácticas de desarrollo actuales, que han evolucionado considerablemente desde los comienzos de la industria de las bases de datos relacionales hace 30 años.

Algunos motivos que respaldan las ventajas de productividad de Sofia2 son:

  • Facilidad de uso: Sofia2 es compatible con las metodologías de desarrollo actuales, permite a los desarrolladores realizar iteraciones de forma rápida y continua sobre el modelo de datos y todo desde un interfaz Web. En contraposición un desarrollo tradicional modelo relacional impone un estricto conjunto de limitaciones al desarrollo, tanto a nivel de modelo de datos, de creación de reglas, cambios,…
  • Modelo de datos.Con Sofia2, el desarrollador solo tiene que crear el modelo de datos en un lugar: la Consola Web del propio producto. En un desarrollo los desarrolladores necesitan crear y mantener el modelo de datos en tres lugares mediante el uso de diferentes interfaces: la aplicación, la propia base de datos y la capa ORM.
  • Flexibilidad de datos.A diferencia de una SGBDR, Sofia2 permite a los desarrolladores almacenar con facilidad datos polimórficos, así como datos semiestructurados y estructurados, en un almacén de datos individual.
  • Soporte JSON.El almacenamiento en JSON, pilar básico de numerosas aplicaciones actuales, se realiza sin dificultades y no requiere conversión. Con una SGBDR, los desarrolladores necesitan “aplanar” y transformar JSON para almacenarlo en tablas relacionales, y más tarde tienen que recuperar las capas al realizar la extracción de la base de datos.


La instalación y configuración de Sofia2 es económica y sencilla.

La Plataforma se compone de :

  • BDC (Base Datos Configuración) : puede ser cualquier base de datos relacional. Por defecto funciona sobre una BD embebida MySQL.
  • BDTR (Base Datos Tiempo Real): en la RI es un MongoDB lo que hace que el esfuerzo administrativo inicial sea bajo, un administrador solo debe tener en cuenta una variable: el número de nodos en el clúster. Solo existe un reducido conjunto de ajustes de configuración para poner el sistema en funcionamiento. Los administradores de MongoDB no necesitan integrar capas de memoria caché ni crear lógica de particionado horizontal personalizada para dirigir las consultas al nodo servidor correcto.  En lugar de esto, el almacenamiento en memoria, caché y el particionado horizontal son capacidades centrales de MongoDB.
  • BDH (Base Datos Históricoa): puede funcionar sobre MongoDB o Hadoop en función de las necesidades o preferencias.
  • SIB + Consola + Tools + API Manager + Process: todos los módulos de negocio de la Plataforma están construidos en Java, se despliegan como aplicaciones Web en cualquier servidor de aplicaciones JEE. El grueso de la configuración va en la BDC por lo que no es necesario crear ficheros de configuración complejos.


Sofia2 es una Plataforma con una versión gratuita para la comunidad de código abierto (licencia Apache) y una edición para suscriptores comerciales que puede usarse en modo On Premise o en Modo Cloud.

Esta versión incluye soporte técnico en diferentes modalidades (desde 8×5 sin SLAS a 24×7 con SLAS estrictas), actualizaciones de software y soluciones de errores y algunas funciones adicionales.

La edición comercial de Sofia2  se factura de forma continua en lugar de puntualmente (esto es, una cuota anual por servidor).


En general, los costes de servidores de Sofia2 son considerablemente inferiores a los de un desarrollo tradicional sobre BD relacional para cargas de trabajo y disponibilidad similar. Esto aplica a todos los componentes.

Sofia2 se diseña para utilizar hardware básico en arquitecturas escalables.

Los despliegues de Sofia2 normalmente utilizan servidores Linux básicos y económicos.


La arquitectura escalable de Sofia2 permite reducir considerablemente los costes de almacenamiento.

Sofia2 puede utilizar el almacenamiento local económico y permite realizar un uso eficiente de las unidades de estado sólido (SSD).


Las dinámicas del esfuerzo de desarrollo corriente son menores a las del esfuerzo de desarrollo inicial.

Con una desarrollo tradicional, el coste de realizar cambios en la aplicación es mayor, bien sean cambios en el esquema de una base de datos que ya se encuentre en producción (coste mayor que para una base de datos que aún no se ha entregado), como en el desarrollo de la lógica, reglas, seguridad, configuración).

Por ejemplo con Sofia2 resulta fácil para los desarrolladores agregar campos a las entidades, crear nuevas APIs, lo que se deriva en costes considerablemente inferiores y permite a los desarrolladores adaptar las aplicaciones a medida que evolucionen las demandas.


El esfuerzo administrativo corriente incluye actividades que mantienen el sistema en buen estado de funcionamiento (por ejemplo, actualización del software y hardware, realización de copias de seguridad y recuperación de tiempos de interrupción inesperados)

Se requiere mucho menos tiempo y esfuerzo para administrar Sofia2 en comparación con un desarrollo tradicional.

La administración de un despliegue de Sofia2 implica principalmente administrar configuraciones de Linux y el propio hardware; solo es necesario conocer y administrar unos pocos parámetros.


Las suscripciones de Sofia2 se facturan anualmente por core. Esto incluye el acceso al soporte técnico del producto, actualizaciones de software y soluciones de errores, así como ciertas funciones que solo se ofrecen en la edición de pago.


Además de los ahorros de costes tangibles, el modelo orientado a documentos y el esquema flexible de Sofia2 también aportan mayor agilidad y flexibilidad a las empresas, que a su vez proporcionan ventajas para generar ingresos.

Una vez implantada la Plataforma Sofia2 en una empresa esta puede utilizar la Plataforma (sin necesidad de montar nueva infraestructura) para hacer nuevos desarrollos y para integrar datos de otros sistemas de forma que los tenga centralizados en un repositorio común y con capacidades Big Data. Además puede desarrollar aplicaciones Sofia2 en cualquier tecnología y lenguaje.

Análisis sobre el TCO (Coste Total de Propiedad) de Sofia2 vs Desarrollo a medida

Gobierno de Ontologías en Sofia2 (parte II)

Continuando con el primer post sobre gobierno sobre Ontologías en Sofia2 hoy veremos otros aspectos importantes a la hora de definir nuestras ontologías, como es la nomenclatura y tipado.


  • Utilizar nombres en inglés y se seguirá el estándar Java (aka “camel”).
  • Para la definición de plantillas nombres cortos y autoexplicativos con primera letra en mayúsculas. Las primeras letras identifican el tipo de ontología:

Feed: Feed

Command: Cmd

Alert: Alrt

Schedule: Schdl

Audit: Adt

KPI: Kpi

  • Para la definición de ontologías primera letra en minúscula, empiezan siempre por el tipo de ontología. Ejemplo para una Espira: feedEspira, cmdEspira, adtEspira …
  • Para la definición de atributos de las ontologías primera letra en minúsculas, sin espacios, sin caracteres especiales.
  • Para la definición de constantes utilizadas como valores posibles para los atributos de las ontologías: todas las letras en mayúsculas. Por ejemplo: MOBILE, FIXED, VIRTUAL.

Seguir leyendo “Gobierno de Ontologías en Sofia2 (parte II)”

Gobierno de Ontologías en Sofia2 (parte II)

Gobierno de Ontologías en Sofia2 (parte I)

Como ya conocéis las ontologías son el concepto clave de Sofia2 y el que le da esa visión semántica (en este post podéis ver cómo se trabaja con ontologías en la Plataforma).


En este primer post de una serie de 3 definiremos los conceptos básicos:

Gobierno de Ontologías en Sofia2 (parte II)

Gobierno de Ontologías en Sofia2 (parte III)

Otro tema fundamental en un Sistema es que existan una serie de normas, estándares de definición, tipos de datos predefinidos,… en general un gobierno de los conceptos que se manejan en el sistema:

Imaginemos una Smart City en la que Sofia2 se usa como Plataforma IoT para interconectar cualquier tipo de red de sensores, parece lógico que todos los dispositivos envíen la información de su posición geográfica en el mismo formato, o la medida y su magnitud de forma coherente.

Para ayudar en este gobierno Sofia2 propone una serie de recomendaciones de las que en diversos post haremos un repaso.

(no quiero dejar de agradecer a Oscar Sacristán el trabajo como creador e impulsor de estas normas 🙂 Gracias!!!).

Seguir leyendo “Gobierno de Ontologías en Sofia2 (parte I)”

Gobierno de Ontologías en Sofia2 (parte I)

Cómo trabajar con Ontologías en Sofia2

En Sofia2 una ontología representa un concepto/recurso dentro de mi dominio/Smart Space. Sofia2 ofrece una interfaz Web (+API REST) de Configuración en la que los usuarios con permisos (colaboradores y administradores) pueden crear sus ontologías.

Una ontología se define a través de un esquema JSON.

Para simplificar la creación de Ontologías la Plataforma ofrece el concepto de Plantillas, que son esquemas JSON predefinidos que puede usar y ampliar el usuario para crear sus ontologías:

Comencemos con la definición de un Ontología sencilla como la que representa un Sensor de Temperatura que almacena identificador, timestamp, medida, unidad y coordenada GPS

Una instancia de esta ontologías podría ser algo como:


“SensorTemperatura”: {


“timestamp”:{“$date”: “2014-01-27T11:14:00Z”},




“type”: “Point”,




En Sofia2 ya está predefinida esta ontología:

Esta ontología está definida como pública, lo que implica que cualquier persona puede consultar datos de esta.

Si pinchamos Ver podremos ver el esquema JSON que describe esta Ontología:


Puedo ver las instancias cargadas sobre las ontologías que puedo al menos consultar a través de la opción Consulta a la BDTR:

Veré la información de la última instancia insertada en la BDTR de SOFIA2

"_id": {
 "$oid": "51e3dbd465701fd8e0f69828"
 "contextData": {
 "session_key": "08bf50c8-6ea6-41dc-99ac-5d12a6f517a3",
 "user_id": 1,
 "kp_id": 9,
 "kp_identificador": "gatewaysensores",
 "timestamp": {"$date": "2014-01-27T11:14:00Z"}


“SensorTemperatura”: {


“timestamp”:{“$date”: “2014-01-27T11:14:00Z”},




“type”: “Point”,





Podemos observar que la información devuelta incluye:

  • El identificador de esa instancia:

  • Información de contexto: como el KP, instancia, usuario, sesión y fecha en la que se insertó.

  • Instancia de la Ontología

Cómo trabajar con Ontologías en Sofia2