VeriSM certification

Esta semana he obtenido la certificación VeriSM, y he querido hacer un dibujo al respecto. La próxima semana terminaremos la serie de "Nuevas contrataciones"

--------------------------------------------------

This week I have obtained the VeriSM certification, and I wanted to draw a picture about it. Next week we will finish the series of "New hires"

VeriSM certification

Nuevas metodologías

Hoy está de moda DevOps, una metodología que como la mayoría de ellas, nos pide usar el sentido común.

El objetivo principal, es que trabajemos juntos entre desarrollo y producción. Toda una novedad, ¿no os parece?

--------------------------------------------------

Today we hear a lot about DevOps, a methodology that like most of them, asks us to use common sense.

The main objective is to work together between development and production. A novelty, do not you think?

Nuevas metodologías

Gestionando la demanda

Este proceso nos permite gestionar la cartera de proyectos a largo plazo, y poder manejar los recursos para su ejecución. Pero claro, ¿no va esto en contra de los nuevos métodos ágiles?

---------------------------------------------

This process allows us to manage the portfolio of long-term projects, and to manage resources for implementation. But, does it not go against the new agile methods?

Gestionando la demanda

Seguridad versus agilidad

La gestión de la seguridad es uno de los procesos que podemos encontrar en la mayoría de metodologías. Sin embargo el grado de importancia que se ha ido dando a este proceso ha ido variando a lo largo del tiempo.

-----------------------------------------

The security management is one of the processes that can be found in most of methodologies. However, the level of importance that has been given to this process has been changing over the time.

------------------------------------

Si nos acordamos de la versión 2 de la metodología que más hablamos, la seguridad se encontraba dentro de otro proceso (el de disponibilidad), y no tenía entidad suficiente para ser un proceso independiente. Por aquel entonces la seguridad se basaba únicamente en tres conceptos

•           Confidencialidad
•           Integridad
•           Disponibilidad

Sin duda los tres son de vital importancia, pero claramente no son suficientes para una buena gestión de la seguridad.

De hecho en la versión 3, se convirtió en un proceso independiente, y nos daba ciertas pautas para mejorar las políticas, sistema gestión, gestión de riesgos, etc. De hecho hay una referencia clara a la ISO correspondiente, como mejor forma de gestionar la seguridad.

Y una vez que hemos contado un poco de historia, ahora toca reflexionar cómo podemos agilizar el proceso de seguridad, si fuera posible, y en qué medida debemos manejar el equilibrio entre seguridad y agilidad.

Para un paranoico como yo, creo que no hay equilibrio. La seguridad puede agilizarse a través de automatismos, pero nunca reducirla para tratar de hacerla “ágil”. De hecho, en mi opinión, debe potenciarse, dado que cada vez más, la seguridad se está convirtiendo en el caballo de batalla (o de Troya).

En las normas clásicas hablamos de seguridad, pero cuando se escribieron, prácticamente no había smartphones, lo mismo ocurría con las App’s. No existían los smartwatches, no se habían inventado los wearables, ni se hablaba del Internet de las cosas. Es decir, nada relativo a la ciberseguridad.

Normas actuales como PCI DSS, obligan a realizar hacking éticos de forma periódica, a realizar escaneos de red. Normas no escritas recomiendan tener algún soporte para analizar la Darkweb, y ver que se dice de nosotros. Tener un SOC externo, que realice estas tareas, puede ser altamente recomendables. Etc.

La seguridad es un proceso que tiene que estar presente en todos los proyectos desde el inicio, para que puedan tenerse en cuenta las necesidades desde el primer momento, y no encontrarnos con sorpresas de última hora.

Concienciar a nuestros usuarios, e incluso a nuestros clientes, puede ser muy útil para evitar infecciones de malware.

Ya se sabe que sólo hay dos tipos de empresas. Las que son atacadas, y las que no son conscientes de que están siendo atacadas. Ahora nos toca posicionarnos en una de las dos.

Aligerar los controles para ser más ágiles, puede repercutir en consecuencias graves, así que en mi opinión, este proceso debe estar vivo cada día, incorporando nuevos controles, aún a riesgo de ralentizar el proceso en sí, y no esperar a una nueva versión que puede llegar entre tres y cinco años.

Los datos son la nueva moneda de este siglo, y hay que mantenerlos a buen recaudo y custodiados, así que aquí lo dejo con una pregunta.

¿Estás seguro que estás seguro?

Seguridad versus agilidad

Adaptar modelos tradicionales, para convertirlos en ágiles

Durante años hemos trabajado en base a modelos tradicionales como ITIL, ISO 20000, Cobit, Prince2, etc, con buenos resultados y una importante aportación de valor, al obtener mejoras sustanciales, sobradamente demostradas por multitud de compañías.

En los últimos años, la explosión de las aplicaciones web, y sobre todo las App’s, han hecho saltar las alarmas a los profesionales de TI, sobre todo en el lado de la operación, donde no podemos atender con la agilidad que nos requiere el negocio, las nuevas necesidades, siguiendo con los modelos tradicionales.

----------------------------------------------

For years we have worked based on traditional models such as ITIL , ISO 20000, Cobit , Prince2 , etc. with good results and a significant contribution of value , to obtain substantial improvements , amply demonstrated by many companies.

In recent years , the explosion of web applications , and especially the App 's, have set off alarms to IT professionals , especially on the side of the operation, where we cannot deal with the agility that requires us business , new needs , following traditional models.

------------------------------------------

En la parte de desarrollo, han llegado nuevos métodos como SCRUM, Kanban, etc, que nos ayudan a agilizar los procesos de desarrollo, para poder realizar nuevas aplicaciones, o modificaciones a las mismas, en un tiempo menor.

Así que ahora nos toca ponernos las pilas en la operación, para que la reducción de tiempos en la creación de nuevos desarrollos, se vea acompañada con la misma reducción en la implantación. Es el momento de tener una Gestión de Servicios Ágil, o como lo denominamos en ITSMF, una ITSMAgil.

¿Esto significa que antes no éramos ágiles?. Por supuesto que no, pero lo que sí está claro, es que si seguimos los procedimientos tal y como los tenemos documentados hasta ahora, los tiempos se alargan. No por falta de agilidad, sino por exceso de actividades intermedias.

Las opciones son varias. Podemos abandonar los modelos tradicionales, lo cual sería un error, en mi humilde opinión, o bien actualizarlos al contexto actual.

Por otro lado podemos utilizar nuevos moldeos como DevOps, que nos permitirán trabajar en modo binomio entre Desarrollo (Dev) y Operaciones (Ops), y que incluye en su ciclo de vida, a todas las partes involucradas, trabajando al mismo tiempo, y en constante armonía.

Desde el Comité de Estándares, queremos dedicarnos este año a analizar cómo podemos agilizar los modelos, y adaptarnos a los nuevos tiempos, y para ello hemos creado 7 Grupos de Expertos con las siguientes temáticas:

1.       La Gestión TI a dos velocidades (Bimodal IT)

2.       La Gestión de los nuevos Servicios Digitales

3.       La Conexión Ágil, extremo a extremo, desde el negocio hasta la producción

4.       La Gestión de Servicios alojados en Cloud externos

5.       La Gestión de Servicios en Pymes

6.       La Adaptación de los modelos estructurales como: ITIL, ISO20000, COBIT, PRINCE2

7.       Nuevos modelos que se incorporan al mercado como IT4IT

Este documento es una pequeña introducción al grupo número seis, “adaptación de modelos”, donde intentaremos liberar de grasa a los modelos actuales aplicando LEAN, y convirtiéndoles en algo más sencillo, y por lo tanto más ágiles.

No es una revolución, sino una evolución natural para adaptarnos a las nuevas necesidades. 

No es una nueva versión oficial de los modelos, sino una reflexión de los que día a día estamos en el terreno.

No es un intento de echar por tierra el buen trabajo que hemos desarrollado con estos modelos, sino romper con los moldes establecidos y replantearnos los procesos desde cero.

Los modelos se han creado a partir de buenas prácticas, y éstas a su vez van evolucionando. Entonces, ¿por qué no las trasladamos a los modelos?.

Las formas de trabajar cambian. Bimodal IT nos dice que hay dos velocidades. La que trata proyectos tradicionales como aplicaciones financieras o bancarias, y la que trata proyectos ágiles como una App para compra o de recetas de cocina. Entonces, ¿por qué sólo tenemos modelos de una velocidad en operación?

Durante las siguientes semanas, iremos desgranando los procesos de los modelos de referencia que hemos mencionado anteriormente, y aportando nuestra visión de cómo deberíamos evolucionarlos, para que se adapten a los nuevos requerimientos.

Hay que ganar en agilidad, tenemos que convertirnos en Agileman.

 

Adaptar modelos tradicionales, para convertirlos en ágiles