En este artículo presentamos una serie de criterios que ayudan a determinar cuándo tiene sentido almacenar datos en un blockchain. Para entender la manera en que se utiliza esta lista de criterios, los aplicamos en un ejemplo sencillo.
En esta ocasión tengo el gusto de compartir con ustedes la noticia de la reciente publicación del libro que escribí junto con mi colega Rick Kazman quien es investigador en el Software Engineering Institute (SEI). Nuestro libro lleva por título “Designing Software Architectures - A Practical Approach” (Diseñando Arquitecturas de Software - Un Enfoque Práctico) y fue publicado por la editorial Addison Wesley en la colección “SEI Series in Software Engineering”.
A alto nivel hay dos tipos de procesamiento de datos: el primero es el procesamiento de datos en modo batch, el segundo es en modo stream o tiempo (semi)-real. Elaborando un poco más sobre esta diferencia, el procesamiento batch es aquel que nos permite procesar volúmenes de datos en tiempos espaciados (ej. cada 15 minutos, cada 3 horas, o diario). Mientras que el modo stream es aquel que nos permite procesar datos casi al instante en que estos son producidos (ej.
Uno de los temas que hemos explorado durante los últimos meses en los distintos canales de Software Guru, es el de arquitectura serverless (sin servidor). Ya en el primer episodio del vlog Devotion lo comentamos de forma casual, y luego en el congreso SG Next tanto Verónica López como Obie Fernández nos platicaron al respecto con mayor detalle. Así que ahora es mi turno de compartir mi perspectiva sobre este modelo arquitectónico.
En esta ocasión les hablaré de Smart Decisions, un juego que he desarrollado junto con mis colegas Rick Kazman del Software Engineering Institute (SEI) así como Serge Haziyev y Olha Hrytsay de la empresa Softserve. El objetivo del juego es ilustrar la manera en que se realiza el diseño de la arquitectura mediante el método de diseño Attribute Driven Design (ADD). Como parte del juego, se simula el diseño de un sistema de Big Data.
La movilidad ha llegado a los sistema informáticos empresariales. Prácticamente todas las empresas tienen la necesidad de brindar acceso a sus sistemas desde dispositivos móviles.
En esta ocasión resumiré un trabajo que presenté en la conferencia SATURN 2014 de arquitectura de software junto con mis colegas Rick Kazman y Jungwoo Ryoo. Rick Kazman es investigador del Software Engineering Institute y académico en la Universidad de Hawaii. Jungwoo Ryoo es investigador de la Universidad del estado de Pennsylvania y experto en temas de seguridad.
En esta ocasión hablaré acerca del uso de técnicas de desarrollo de arquitectura de software como parte de la etapa de preventa de los proyectos de software.
En esta ocasión hablaré de un tema relacionado con las Interfaces de Programación de Aplicaciones (API) y con las pruebas que juega un papel fundamental dentro de la arquitectura: las interfaces. Las interfaces son los puntos de contacto que establecen un contrato que permite el intercambio de información entre elementos que forman parte de la arquitectura de un sistema de software. Estos elementos pueden ser lógicos (ej. módulos), dinámicos (ej. objetos) o físicos (ej. nodos de hardware).
En el año 2006, Mary Shaw y Paul Clements escribieron un artículo que recapitulaba lo sucedido en los últimos 20 años en relación con la arquitectura de software [1]. En dicho artículo los autores concluyen que, a partir del año 2000, la arquitectura de software entró en una fase de popularización: desde entonces existen gran cantidad de herramientas, servicios, aplicaciones, plataformas, estándares y cursos construidos alrededor de la arquitectura.
El pasado 3 y 4 de febrero se celebró en la Ciudad de San Francisco, en Estados Unidos de Norteamérica, uno de los mayores eventos relacionados con Arquitectura Empresarial a nivel mundial. El tema central de este evento fue “El flujo de la información en la organización sin fronteras”.
A diferencia de las computadoras “tradicionales”, los dispositivos móviles tienen características particulares que incluyen:
En esta ocasión presento en esta columna una entrevista con Luis Carballo, Arquitecto de software de uno de los sistemas más críticos para México. Luis trabaja desde hace 7 años en la Bolsa Mexicana de Valores (BMV) en el área de sistemas en una empresa llamada Bursatec. Él es egresado de la UAM en donde estudió Ingeniería Electrónica y posteriormente realizó una maestría en el ITAM de TI y Administración (luis.carballo@mac.com).
Aprovechando el tema principal de esta edición de SG, en esta ocasión dedicaremos esta sección a hablar sobre certificaciones en arquitectura de software.
En la columna dedicada al diseño de la arquitectura (SG #29) se mencionó que el proceso de diseño involucra la toma de decisiones que dan lugar a las estructuras del sistema. Estos incluyen aspectos tales como los patrones de diseño, las tácticas y los frameworks. En esta columna revisaremos en más detalle estos conceptos y discutiremos la relación que existe entre ellos.
En la última década la arquitectura de software ha cobrado una importancia cada vez mayor. Esta tendencia probablemente continuará, entre otras razones, por qué en la nueva versión de CMMI-DEV (v1.3), se han realizado actualizaciones en las áreas de proceso de ingeniería y se han considerado diversos aspectos relacionados con la arquitectura de software [2].
Quienes hayan estado siguiendo las distintas entregas de ésta columna y que laboren en una organización de desarrollo de software en donde actualmente no se sigan prácticas maduras de arquitectura de software probablemente se preguntarán ¿de qué manera se puede introducir esto en mi organización? En esta columna hablaré de la implantación de prácticas de arquitectura de software dentro de una organización en base a mi propia experiencia.
Etapas del cambio
La arquitectura de software es el resultado de un esfuerzo importante y su desarrollo puede representar una parte considerable del trabajo que se realiza en un proyecto de desarrollo. De lo anterior surge la pregunta, ¿habrá manera de aprovechar el esfuerzo que se hace respecto al desarrollo de la arquitectura de un sistema en el desarrollo de otros sistemas similares?
A lo largo de las distintas entregas de esta columna hemos cubierto las actividades del ciclo de desarrollo de la arquitectura de software y su integración dentro del ciclo de desarrollo de software. En todas estas actividades, hay un rol específico que juega un papel preponderante y es el del arquitecto de software.
A lo largo de las últimas ediciones de esta sección hemos realizado un recorrido a través de las distintas actividades asociadas con el desarrollo de la arquitectura de software, a saber: la captura y especificación de requerimientos que influyen en la arquitectura, el diseño de la misma, su documentación y su evaluación.
En entregas previas de esta sección, nos hemos enfocado en aspectos relativos a los requerimientos que influyen a la arquitectura, y a la manera de diseñar la arquitectura con el fin de satisfacer estos requerimientos. Para ser útil, este diseño necesita ser comunicado de forma adecuada. Así que en esta ocasión abordamos aspectos de comunicación del diseño y más particularmente en la actividad de documentación de la arquitectura.
Como ustedes saben, Scrum es una metodología ágil para la gestión del desarrollo de software, que está basada en un proceso iterativo e incremental. Debido a la importancia de la arquitectura de software, es primordial definir claramente su papel en scrum. Es por esto que en el presente artículo se describe una propuesta del papel de la arquitectura de software en el ciclo de desarrollo de Scrum y de las responsabilidades del arquitecto de software en esta metodología.
Continuando con nuestro recorrido alrededor del tema de la arquitectura de software, en esta ocasión, nos enfocaremos en la actividad de diseño de la arquitectura.
Como mencionamos en el número anterior, la arquitectura de software se enfoca en aspectos de diseño estructural del sistema con el fin de satisfacer ciertos requerimientos clave para el sistema, además de guiar el desarrollo del mismo. En este artículo nos enfocaremos en describir la relación que existe entre los requerimientos y la arquitectura de software.
En el ámbito del software cada vez es más común escuchar el término “arquitectura de software”, y encontrar oportunidades de empleo para “arquitectos de software”. Aún así, este concepto tiende a ser malentendido y la falta de comprensión al respecto de sus principios frecuentemente repercute de manera negativa en la construcción de sistemas de software.
El término “arquitectura de software” y el rol de “arquitecto de software” parecen estar cada día más de moda en nuestra industria. Sólo basta asomarnos a la trama de películas de ciencia ficción como The Matrix: Revolutions donde el arquitecto aparece como un Dios Todopoderoso, responsable de la creación de ese mundo virtual. De igual manera, existe una caricatura donde se hace la analogía entre un programador representando a un padawan (aprendiz de Jedi en la saga Star Wars) y un arquitecto de software representando a un maestro Jedi. El aprendiz no podía creer la cantidad de habilidades y conocimiento que requería para convertirse en un Jedi (o arquitecto según esta analogía), por lo que comenzaba a dudar si sería mejor irse por el lado oscuro de la fuerza.
En el número anterior, dimos un contexto general sobre lo que es ebXML y sus principales componentes. En esta ocasión, mostramos con mayor detalle el funcionamiento de ebXML en un sistema, así como su relación con RosettaNet y Web Services.
