A medida que las bases de datos NoSQL cobran mayor protagonismo, he observado a compañeros del área que se preguntan cómo diseñar las bases de datos no relacionales que, tal como describe la wikipedia, "No garantizan completamente atomicidad, consistencia, y durabilidad, y habitualmente escalan bien horizontalmente". Es decir, el esquema puede variar dinámicamente (agregar campos …
Now days, the NoSql databases have become more prominent. I see people around me wondering how to design these non-relational databases. The Wikipedia describes NoSQL properties like "They do not completely guarantee atomicity, consistency, and durability, and usually scale horizontally well". So, the schema are fully dynamic (you could add in runtime entities and fields). …
Hace ya algún tiempo que decidí profundizar en los estándares de IT y que, de alguna manera, una comunidad promueve y hace que estos sigan siempre vivos y así, sean una referencia para la comunidad. Siempre he pensado que la adaptación de ideas también es innovar, puesto que ningún estándar encaja a la perfección en …
It's been some time ago when I decided to go deeper in the study of IT standards and, somehow, that standards which are supported by a community who make them alive, and doing so, those which are reference blueprints and guides for the community involved. I've always thought that the adaptation of ideas are also …
In this post we'll present our proposal to design an API product global view using Viewpoint Modelling. The solution we have developed ( and used in real life) integrates ArchiMate and UML modelling languages. In one hand, we describe the business solution of an API Product (Which functionalities will be exposed? What is the value of …
Ahora vamos a dar nuestra perspectiva de como modelar APIs. La solución que hemos desarrollado y puesto en práctica utiliza los lenguajes de modelado de ArchiMate y UML. En nuestra propuesta integramos diferentes puntos de vista para tener una visualización global, es decir: la definición de negocio que describe el por qué y para qué …
Y volvió a pasar... Todos reunidos en una sala, más de 20 personas, supuestamente los que "desarrollan el producto" para que otros puedan desarrollar de una manera más productiva y "ágil"... Básicamente los que deberían haber estado desarrollando los SBBs definidos en etapas de diseño de la arquitectura... desde el líder “supremo” (gurú de …
Continue reading "Desde los stakeholders hasta el despliegue…¿Cómo comenzamos este recorrido?"
And it happened again ... All together in a room… more than 20 people, supposedly those who "develop the product" so that “the rest of the development labs” could develop software in a more productive and "agile" way ... Basically those who should have been developing the SBBs which were defined in the early stages …
Continue reading "From StakeHolders to deployment… How to start this journey?"
Debido a la gran densidad de componentes relacionados y distribuidos con los que se construye el software actual, se generan escenarios donde es complejo visualizar el diseño de la solución y sus dependencias. Por lo tanto, es difícil encontrar defectos, aplicar cambios, reutilizar componentes y escalar a nuevas versiones. Nowadays, software is built using a high density …
Continue reading "Modelado sistemas utilizando Puntos de Vista (Viewpoint-Based Modeling)"
La primera entrada de este blog no podía ser otra que la explicación del por qué...(lo creí más interesante que el típico "Quienes Somos"). Del por qué del blog (Razón), del porqué del nombre y del Logo (EAMinds) y del por qué de la imagen principal de fondo (LEGOS). Todos tienen relación con un concepto básico …
EAMinds 