Categories
54cuatro

Preciado Time to Market (en español)

Este articulo fue publicado en linkedin 

#Agile, #DevOps, #Cloud, #Microservicios, pusieron en foco optimizar el Time to Market (o sus derivados #TTM, #T2M, #Time2Market).

¿Pero que es realmente Time to Market y porque es tan importante?

El TTM se relaciona directamente con la velocidad con la que un producto puede ser lanzado o en el caso de la tecnología, en la rapidez con la que se puede entregar valor (ya sea un nuevo producto, una nueva característica de algo existente, una mejora, etc).

El TTM es importante por motivos varios. En la actualidad, los clientes, tanto internos como externos, se han vuelto más exigentes. Exigen mayor calidad y mayor velocidad. Es también importante porque la agilidad con que se crean nuevos productos, se agregan nuevas características o se genera valor es un diferencial respecto a competidores más lentos, por lo tanto, una ventaja competitiva.

Focalizando en lo que hace a productos tecnológicos, años atrás cuando el modelo de desarrollo estaba basado en una metodología de cascada, los ciclos de vida de desarrollo eran muy altos, lo que generaba cancelaciones de proyectos, mayor tasa de errores, y hasta la depreciación de lo que se estaba construyendo antes de conocer la luz. Todo esto representaban perdidas económicas significativas.

En la actualidad, con metodologías ágiles de trabajo y la automatización de las cadenas de desarrollo, se logró que la entrega de software sea más rápida y regular, lo que genere una ventaja competitiva, aumentando la calidad y optimizando tiempos, algo que se torna importante tanto para el #Time2Market como para la optimización del #ROI, promueve la mejora continua y por lo tanto existe un notorio aumento del rendimiento y la rentabilidad.

Optimizar el TTM trae aparejado aspectos muy positivos. Al tener toda nuestra cadena de desarrollo automatizada, es más simple recolectar los resultados del testing, e incluso del feedback de los usuarios, lo que permite no solo mejorar la calidad del software sino incluso re-adaptar las estrategias empresariales. También, a partir del desarrollo SOA y ahora Microservicios, se logró reducir la tasa de errores, ya que desarrollos chicos suelen tener menos complicaciones que aquellas implementaciones gigantes (monolíticas) que requerían muchos cambios, muchas personas, mucha burocracia.

Resumiendo: la capacidad de entregar desarrollos de forma ágil, cumpliendo con estándares de calidad, eficiencia y seguridad, nos permite crear valor en las compañías, mejorar los costos operativos y marcar diferenciales competitivos de mercado que se terminan traduciendo en mejor imagen de la compañía, mayores ventas y ahorros operativos.

Entonces… ¿Es importante mejorar el time to market? 

[popup_anything id=”2076″]

Categories
54cuatro

Planeando una continuidad operativa ante desastres

La adopción de los planes de recuperación ante desastres (#DRP por sus siglas en inglés Disaster Recovery Plan) son una necesidad sin discusiones en el ámbito de las grandes compañías, pero gradualmente muchas empresas de tamaño medio y pequeño planean Planes de Continuidad de Negocio (#BCP) a través de herramientas que le permitan el recupero operativo de sus aplicaciones ante una falla crítica.
Debido a la creciente oferta de servicios #Cloud es que la posibilidad de contar con un sitio de contingencia es algo cada día más sencillo y accesible.

¿Qué necesito para planificar un plan de recuperación?

Fundamentalmente conocer cuáles son los objetivos del plan. Una vez estipulado el alcance es necesario contar con un inventario físico y aplicativo. Toda esta información es importante para el proceso de planning.

De ser posible se debe crear un mapa de arquitectura que contenga la relación de las aplicaciones, dependencias, resguardos, el flujograma de comunicaciones y que tenga un mapeo relacionado entre cada servicio y cada servidor, de manera de conocer que corre cada equipo.

Entrando en el plan se debe conocer previamente dos ítems fundamentales: RTO y RPO.

  • El #RTO (recovery time objective) es ni más ni menos que el tiempo máximo definido para una aplicación para que la misma pueda estar fuera de línea.
  • El #RPO (recovery point objective) tiene que ver con la cantidad de datos que se pueden perder en determinado tiempo.

Es de esperar que los costos aumenten a medida que los tiempos de recuperación solicitados sean más cortos. De manera que -a modo de ejemplo- un sistema de ventas, cobranzas y/o facturación, puede tener un tiempo de RTO y RPO menor que un sistema de mensajería y colaboración; dado que su organización puede tolerar más tiempo sin email o perder los emails de las últimas horas, pero no puede tolerar estar sin facturar o perder la facturación de una hora atrás.

Basados en las definiciones tomadas en cuenta para incorporar en el plan de continuidad operativa, el siguiente paso es dimensionar el sitio de contingencia para lo que sea fundamental la información técnica mencionada anteriormente y que conformará la fase de planning.

Planning

El planning determinará las características del sitio secundario. Y esas características deben contener información importante:

  • ¿Se procesa el 100% o solo partes críticas de la plataforma?
  • ¿El sitio secundario soporta toda la carga o será limitado en potencia? Como paso adicional, se deben considerar factores de red y seguridad.
  • ¿Cómo se harán las réplicas?
  • ¿Cómo se aseguran las copias de información?
  • ¿Cuánto ancho de banda consumirá?
  • ¿Se mantendrán las direcciones IP?

Dependiendo de la respuesta el plan puede tener infinitas combinaciones de ejecución acordes a los requerimientos de su negocio.

Y no está de más mencionar que existen cuestiones políticas.

  • ¿Quién determina el RTO/RPO?
  • ¿Quién determina la pérdida total del sitio primario y da la orden de ejecutar el lanzamiento de la plataforma desde el sitio secundario?
  • ¿Qué cambios aplicativos deben realizarse?
  • ¿Qué cambios en los accesos (ej DNS) deben realizarse?

DRP

Así como el proceso paso a paso de la ejecución del DRP debe ser debidamente documentado también dentro del listado de tareas es importante tener el detalle del rollback, y determinar en qué momento y como se ejecutará el proceso de “devolución” de los servicios al sitio primario.  Todos estos pasos deben ser documentados a detalle, y el plan debe ser probado en su funcionamiento (se recomienda un test anual) para confirmar que ningún paso sea erróneo.

Obviamente cada negocio tiene reglamentaciones como #SOX, #ISO, Bancos, u otros casos que complejizan la operatoria. Técnicamente cada aplicación tiene un funcionamiento que genera el análisis puntual de cada una y en muchos casos tareas previas de adecuación antes del armado del sitio de resguardo. Cada caso es una situación especial que amerita algo mucho más profundo que este pequeño artículo.

Gonzalo D’Angelo

[email protected]

[popup_anything id=”2076″]