Algunas ‘mejores prácticas’ de TI para el fracaso –y algunas ‘mejores prácticas’ para evitarlo

Así es, una mejor práctica no es una receta de cocina. La preparación que hagamos de un ‘platillo’ y su resultado depende de muchos factores referidos a las herramientas, nosotros mismos como çocineros’, de los ‘comensales’ y su entorno.

Una real mejor práctica es considerar la preparación del ‘platillo’ para garantizar su resultado. Así, intervienen el ecosistema tecnológico en operación –moderno, vigente, legacy, integrado, interconectado- plataforma tecnológica e infraestructura de soporte, la cantidad necesaria de especialistas con el perfil apropiado, la experiencia, competencias (conocimientos, aptitudes, actitudes), orientación técnica o de gestión, requisitos del negocio, apetito de riesgo, intereses personales, los recursos para la producción del servicio (en adición al ecosistema tecnológico y el personal de apoyo, se necesita información, aplicaciones, recursos financieros) y capacidades para asegurar el rendimiento esperado (modelo de gestión, organización implementada, procesos establecidos, conocimiento gestionado), ambos activos de servicio necesarios para entregar el servicio con el valor esperado (con la utilidad y la garantía de rendimiento esperada), aparte claro del presupuesto, coyuntura socio-económica, entorno regulatorio y legal, mercado (cultura, exigencias, demografía, restricciones, gobierno, importación/exportación).

Estamos propensos a decir sí o no a todo y esto varia como buena práctica de acuerdo a la cultura y clima organizacional, buscando no quedar mal –aunque esto es lo que ocurre al no cumplir si accedemos o no entregar si era posible y alguien después nos lo hizo ver.

Una real buena práctica es explicar qué debe hacer para satisfacer las solicitudes, luego de realizar el análisis previo correspondiente. Lo que sigue será una conversación más que una excusa.

Tampoco es una buena práctica blandir que se cumple con el acuerdo de nivel de servicio (SLA) aceptado por el cliente, o con el nivel de servicio organizacional (OLA) requerido y comprometido por las áreas internas de la empresa, cuando es evidente la existencia de reclamaciones al respecto, y tratamos de minimizar el impacto haciendo bromas a costa de clientes, usuarios –o peor, de nuestro soporte- ‘inexperto’. Puede haber un contrato en ambos casos, pero no es bueno mantener las relaciones a distancia.

Una real buena práctica es identificar y enfrentar cambios –incluso sustanciales, investiguemos con transparencia. Recuerde que las relaciones requieren confianza, que la confianza no sucede a menos que reconozca a los colegas y clientes como personas reales que, si les gusta, trabajarán con usted para arreglar lo que falla y que el propósito de los contratos no es definir las relaciones -es definir lo que sucede cuando no hay confianza y algo va seriamente mal.

Tomamos como buena práctica poner nombre a nuestros proyectos, desde hace poco incluso, no siempre ha sido así. Pero esta buena práctica de la dirección de proyectos la utilizamos para nombrar el proyecto como una implementación de software (y nos preocupamos de que el producto software funcione) y no como los resultados esperados por el negocio (no establecemos los requisitos y criterios de validación necesarios para el entregable). El trabajo de TI se realiza cuando el software satisface los requisitos y cumple con las especificaciones –se ha hecho el aseguramiento y control de calidad apropiados al producto software, su verificación. Entonces sabemos quién es culpable de no alcanzar los resultados esperados por el negocio ¿verdad?

Una real buena práctica implica identificar al real sponsor del proyecto. Me refiero no al que ha sido nombrado (otra ‘buena práctica’), sino al que le interesa el éxito del proyecto porque su reputación está en juego y actúa en beneficio del negocio, y no asume el encargo sólo por intereses personales. Otra es designar correctamente a alguien realmente encargado de realizar las validaciones oportunas, correctas y apropiadas.

Insistir en un retorno de inversión de la plataforma actual al instaurar la buena práctica del gobierno de TI es también una perjudicial para los proyectos donde la tecnología puede ayudar a los departamentos de negocios a ofrecer mejores resultados más rápido, o para aquellos proyectos que buscan ayudar a impulsar la satisfacción del cliente.

No podemos discutir que estos proyectos son críticos, por lo que una real buena práctica es que se necesita establecer correctamente los casos de negocio oportunos, necesarios y apropiados, y la organización debe implementar los cambios que sean identificados con prontitud.

El aumento de la eficacia de la misión y la eficiencia operativa son beneficios clave que se pueden lograr con el cloud computing. Recordemos la definición del NIST. Pero aplicar una estrategia al respecto es otra cosa, considerando por supuesto la seguridad en la nube. Tomamos como buena práctica la mera adopción de una solución comercial enfocada en IaaS, PaaS o SaaS. Sí hay orientaciones al respecto, pero dependerá de cada organización su definición y el éxito de su implementación ya que se deberá mantener las evaluaciones tecnológicas y las inversiones alineadas con las estrategias empresariales. Es una buena práctica reutilizar el recurso humano (exigirle más, por decirlo amablemente), pero debemos considerar que, probablemente, se requiera una reorganización de la organización de TI para ofrecer mayor agilidad empresarial y soporte a iniciativas empresariales clave.

Es una real buena práctica recordar que el ser humano es adaptable pero no es una máquina multitarea y tiene dignidad. Entonces conviene planificar –una buena práctica que muchas veces olvidamos por las presiones del mercado. Una buena planificación es muy importante porque en ella establecemos roles, responsabilidades, alcance del modelo de despliegue y servicios a emplear o entregar, controles, aspectos de diseño y de operación (que seguramente será necesario afinar), cumplimiento regulatorio y legal, integración de tecnología legacy con la nueva, cargas de trabajo, procesos establecidos, exposición al riesgo o apetito de riesgo, sponsor (real), ámbito de influencia, gobernabilidad, plazos, presupuestos, valor real para el negocio considerando las inversiones con base en su estrategia de negocio digital, entre otros muchos factores a considerar.  Otra real buena práctica es que todos los proyectos que se lancen deberían estar totalmente equipados, con “personal completo”, lo que significa que el proyecto nunca esperará a que un miembro del equipo esté disponible para trabajar en él.

Una buena práctica es emplear métodos ágiles, pero el pretender combinarla con la premisa de abaratar costos ya no lo es. La combinación es factible pero complicada en su control y gestión, y hasta contraproducente en cuanto a resultados esperados. Esto sólo si hablamos de contar con recursos y capacidades internas al país (on-shore); sin hablar de los recursos y capacidades que podrían verse interesantes fuera del país (off-shore).

Una real buena práctica es realizar una apropiada planificación tras reconocer que están implicados diferentes aspectos, no sólo el costo del recurso humano con el perfil adecuado, sino los costos de la tecnología a emplear y los mecanismos de seguridad necesarios, así como aspectos de locación, demográficos, culturares, idiomáticos, entre muchos otros.

Cómo crear un plan contra violación de datos en 9 pasos

Cómo crear un plan contra violación de datos en 9 pasos

Primero tengamos presente que se pueden considerar varios escenarios posibles en un plan contra violación de datos.

Esto porque no podemos anticiparnos a todas las situaciones posibles en que un determinado hackeo se puede desarrollar, y aun así este plan debe ser flexible, como un planeamiento para la recuperación de desastres y planificación de continuidad de negocio (la colaboración en lugar del aislamiento) –y veremos que es muy parecido. Interesante, varios proyectos pueden salir de este esfuerzo.

De hecho, conviene realizar un análisis de los procesos de negocio y las necesidades de continuidad, sin olvidar las necesidades de seguridad de la información, algo que cada empresa debe emprender, y dependerán de los objetivos de la organización sobre el punto de recuperación (RPO) y el tiempo de recuperación (RTO).

Bueno, al grano –y con anticipación porque es importante, de modo que podamos reducir las urgencias o el riesgo durante las urgencias.

  1. Sabemos que debemos empezar con una evaluación de riesgos, para priorizar qué sistemas recuperar y restaurar primero (establecer los componentes esenciales –inventario de por medio del hardware necesario y del software requerido para restaurar la producción; los datos, su tipo y sensibilidad, almacenado/procesados/transportados haciendo uso de estos componentes) –porque ponernos a pensar durante la emergencia podría ser contraproducente. Conviene realizar un análisis de impacto sobre el negocio (BIA) para identificar los procesos críticos (con sus procedimientos por supuesto) y priorizarlos de acuerdo con su impacto en la organización.
  2. No olvidemos implementar controles preventivos (con sus procesos estandarizados, normalizados, documentados), como primer paso tras analizar las brechas, de seguridad de la información, y de recursos y capacidades existentes (financieros, organizacionales, de personal, competencias, experiencia, entre otros).
  3. Conviene establecer umbrales y adecuarlos a los niveles correspondientes de respuesta que hayamos establecido –o que podamos establecer, así como los criterios de evaluación correspondientes al tipo de datos que se verían comprometidos, con base en nuestros recursos y capacidades internos o los que podamos conseguir.
  4. Así como los médicos en la sala de urgencias seleccionan y clasifican a los pacientes para evaluar la prioridad de su atención de acuerdo con sus posibilidades de supervivencia y recursos disponibles, igual debemos realizarlo nosotros, determinando el alcance de ese impacto, cuáles son los sistemas más importantes (misión crítica) y datos (más importantes) y que, por lo tanto, necesitan atención en primer lugar, cómo aislar y proteger los datos (nivel de seguridad necesario para los datos y aplicaciones, ubicación), y cuánto tiempo se espera que dure la interrupción –antes de activar otros medios de continuidad.
  5. De hecho, debemos construir flexibilidad de modo que la empresa pueda responder de la manera que, coyunturalmente (no siempre contará con los recursos y capacidades suficientes o apropiados), le convenga (para no incurrir en problemas legales por incumplimiento con la ley de protección de datos personales, por ejemplo).
  6. Es muy importante establecer, difundir, y mantener vigente la matriz RACI correspondiente, y que ésta sea lo más granular posible, para asegurar que los roles, funciones, y responsabilidades (del personal clave tanto interno como externo, y de apoyo, considerando su disponibilidad y la capacidad de su ubicación oportuna) sobre un conjunto de actividades sean conocidas, claras, justas, entendidas, asumidas, adoptadas, interiorizadas, comprometidas, evitando una situación de juez y parte. Por ejemplo, habría que identificar las personas en la organización que tienen la autoridad para declarar un desastre y por ende, colocar el plan en efecto.
  7. No olvidemos detallar cuándo y cómo invertir en el equipo ejecutivo de gestión de crisis para que se cumplan los requisitos legales y normativos adecuados con respecto a las infracciones de datos. Las personas de relaciones públicas de la compañía pueden ayudar a informar adecuadamente a los clientes y consumidores.
  8. El negocio deberá establecer sistemas alternativos, como decidir cuál de las funciones de la organización son esenciales, y repartir el presupuesto disponible conforme a este criterio, o a establecer acciones manuales (considerando por supuesto la sensibilidad de los datos) que se disparan ante un evento, en la medida que sea posible lo que requeriría posiblemente un esfuerzo de capacitación adicional.
  9. Por supuesto, debemos ejecutar simulacros [lo más reales posibles] de eventos basados en tipos específicos de desastres [no idea, sino realidad], incluyendo brechas de seguridad. Así, la organización deberá proveer los recursos necesarios, establecer si necesita ayuda externa, planificar y programar los simulacros (al elefante nos lo comemos por tajadas), difundir su realización, establecer las estrategias de recuperación, diseñar los escenarios, priorizarlos, evaluar cada qué tiempo realizarlos y obtener la autorización del cuándo realizarlos (no vaya a ser que programemos una prueba justo cuando existe en el mismo día un evento crucial para la organización), cómo los va a realizar (la creación previa de plantillas de verificación ayuda a simplificar este proceso), afinar los planes y mantenerlos vigentes (como dijo Dwight ‘Ike’ Eisenhower, “el plan es nada, la planificación lo es todo”), entre otros factores.

Internet de las cosas -IoT

Según Gartner, el “Internet de las cosas (IoT) es la red de objetos físicos que contienen tecnología incorporada para comunicarse y detectar o interactuar con sus estados internos o con el entorno externo”[1]; y añade que “el valor real del Internet de las cosas va más allá de los dispositivos interconectados”[2][3].

La interacción crea más datos (más complejidad en su tratamiento, más aplicaciones, mejores y más seguras que los traten, mayor necesidad de almacenamiento y procesamiento); la comunicación acarrea más riesgos que deben ser apropiadamente gobernados, una necesidad de mayor y mejor gestión de servicios (decisiones de toda índole más difíciles, para usuarios y operadores); las condiciones actuales y posibilidades futuras requieren recursos y capacidades diferenciados para asegurar que se mantiene el valor de los servicios (que promulga ITIL®) que entregamos –la sostenibilidad operativa.

Todos estamos involucrados y somos responsables del buen o mal uso que hagamos del IoT, en todo nivel. Además, debemos considerar que hay muchas cosas que considerar[4]: capacitación, público objetivo, requisitos de construcción, servicios incorporados, dispositivos (tipos, compromiso de seguridad, manipulación no autorizada[5], otros), disponibilidad, aplicaciones, redes, conectividad, plataforma tecnológica, ecosistema, riesgos directos e indirectos, actualizaciones de firmware o de software, aplicaciones que incorporen la seguridad desde el diseño, la arquitectura de las aplicaciones a este respecto, cifrado de datos, protección de datos personales, categorización de datos, datos sensibles en general, control de acceso, normativas, regulaciones, estándares, metadatos de los dispositivos, sistemas de monitorización y de protección contra intrusiones y ataques, tanto a nivel individual como colectivo[6], monitoreo continuo, localización de los datos porque lo que es delito informático en un país puede no serlo en otro, resiliencia[7], confidencialidad, integridad y disponibilidad, entre muchas otras posibilidades.

IoT no es una cosa; es la integración de varias cosas en una solución de negocio, es el corazón del negocio digital –bueno, cuando ya no sea una buzzword y realmente se de una transformación digital y contemos con tecnología concreta utilizable hasta en nuestros hogares[8] y por todos (refrigeradoras que podrán avisar a sus dueños cuando no haya alimento en ellos[9] es la promesa ¿recuerdan?). Sería bueno saber cuántos y cuáles dispositivos están accediendo a nuestra red local, y algo ‘raro’ como deshabilitar el bluetooth y las funciones que los dispositivos no usan todo el tiempo[10]. No queremos que “alguien” nos haga “gastar” más electricidad de lo habitual. Ya conocemos las deficiencias de seguridad existentes, que no nos pesquen desprevenidos, por ellas al menos[11].

[1]       Fuente: http://www.gartner.com/it-glossary/internet-of-things/; disponible en marzo/2017

[2]       Fuente: http://www.gartner.com/technology/research/internet-of-things/?s=1; disponible en marzo/2017

[3]       Fuente: http://view.ceros.com/gartner/iot/p/1; disponible en marzo/2017

[4]       Fuente: https://ricveal.com/blog/10-retos-seguridad-iot/; disponible en marzo/2017

[5]       Fuente: http://aunclicdelastic.blogthinkbig.com/el-reto-de-la-seguridad-en-iot/; disponible en marzo/2017

[6]       Fuente: http://www.csuc.cat/es/internet-of-things-un-reto-para-la-seguridad; disponible en marzo/2017

[7]       Fuente: http://www.ibm.com/developerworks/ssa/library/iot-trs-secure-iot-solutions1/index.html; disponible en marzo/2017

[8]       Fuente: http://techcetera.co/el-reto-para-la-seguridad-para-el-internet-de-las-cosas/; disponible en marzo/2017

[9]       Fuente: http://www.nacion.com/tecnologia/informatica/Seguridad-principal-reto-Internet-Cosas_0_1571442852.html; disponible en marzo/2017

[10]     Fuente: http://techcetera.co/tiene-el-internet-de-las-cosas-iot-algun-riesgo-para-su-hogar/; disponible en marzo/2017

[11]     Fuente: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/insecurity-in-the-internet-of-things.pdf; disponible en marzo/2017

Autoservicio de TI

Desplegar tecnología para lograr que los usuarios de ésta se ayuden cuando tienen dificultades con la tecnología (sí, más tecnología para la tecnología) es algo que por mucho tiempo se ha tratado –y en algunos casos esta “innovación” ha funcionado y en otros no; bueno, siempre hay espacio para mejorar.

Los medios de acceso son variados. Existen versiones de respuesta humana o incluso robótica. Las interfaces son cada vez más útiles y usables. Sistemas de información y flujos de trabajo unos más integrados –y útiles- que otros. Actividades unas mejor implementadas que otras, como emisión y renovación de la identificación del usuario, entrenamiento, disponibilidad de opciones tipo push-pull para instalaciones o actualizaciones, ejecución de políticas de retención, solicitudes variadas (provisión de recursos, programación de atenciones, consultas sobre funcionalidad u operación, requerimientos de reparación, de información), entre otras[1]. Todos gozan de una interesante y mayor agilidad, los que entregan (TI tradicionalmente), y los que reciben (siempre el usuario). La experiencia de usuario está garantizada –depende del usuario calificarla.

fig1

Empoderar a los consumidores (usuarios y clientes) de servicios especializados para que ellos mismos se auto atiendan cuando tienen necesidades relacionadas con la tecnología de la información está muy de moda hoy en día[2].

Los usuarios finales obtienen las herramientas que necesitan para maximizar la productividad, tienen acceso a una vasta base de conocimiento[3] –y hasta a información a la que antes no tenían acceso (y no hablo de seguridad sino de alcance, disponibilidad, re-utilización porque esta iniciativa depende de la calidad y cantidad de información disponible y las facilidades disponibles para accederla[4] y generarla, incluso por comunidades de usuarios[5], y las medidas adoptadas para retener su control), y los departamentos de TI reducen la tensión cotidiana de las llamadas que llegan al servicio de atención al cliente[6].

Interesante. Se reducen costos al pasar del “modo bombero” a un estado de eficiencia y efectividad, y se re-enfoca la mesa de servicio a incrementar la satisfacción del cliente o del usuario.

Sí, nada nuevo hasta aquí. Pero, Gartner[7] nos alerta de las generalidades en que hemos incurrido antes, lo cual nos fuerza a sincerar los resultados frente a las expectativas de esta innovación –y preparar un buen caso de negocio primero.

  • El autoservicio de TI reduce costos en el soporte nivel 1 principalmente con relación a las solicitudes varias que ya comentamos. Algunas cosas todavía requerirán una llamada al servicio de TI o la asistencia de un técnico de soporte. Es una mezcla cuyo balance debe ser cuidadosamente considerado con respecto al valor esperado, con el objetivo de no incurrir en gastos innecesarios –aunque suene trillado esto último.
  • El autoservicio de TI requiere cuidado y actualización constante; no es una inversión que se realiza una sola vez y nos olvidamos luego. Es un continuo asegurar que el servicio lo seguimos entregando ‑como área de TI- como fue comprometido, y nuestro “consumidor” lo sigue recibiendo –su apreciación del valor- de forma oportuna, consistente y constante. El conocimiento, hemos mencionado, juega un papel vital y como tal debe ser gestionado apropiadamente para mantener su vigencia y utilidad.
  • Los usuarios finales acudirán a los autoservicios sólo si no tienen alternativa, lo cual dependerá de la estrategia que implemente la organización para su “adopción”, ya que la inclinación a su aceptación potencialmente será variada –tanto como la cultura organizacional, la mentalidad de los usuarios, la brecha generacional, así como los plazos límite que se establezcan.
  • Para una implementación exitosa del autoservicio de TI se requiere de requisitos previos que lo complementen, como un conjunto correctamente seleccionado de herramientas y procesos, adecuados, probados, afinados, y mantenidos, por personas con roles y competencias técnicas apropiadas, que apoyen, por ejemplo: la automatización de las actividades antes enumeradas, entre otras; y a los usuarios en las decisiones que deben tomar y en las tareas que deben realizar. Si se implementa adecuadamente, el autoservicio puede mejorar la satisfacción del cliente, proporcionar análisis de tendencias de incidentes, identificar oportunidades de capacitación, permitir ejecutar escenarios del tipo “que pasa si” para determinar a dónde llegarán las finanzas de la compañía para el trimestre, y consolidar el conocimiento que existe actualmente en los silos en toda la organización de soporte. La retroalimentación obtenida de un piloto o varios] es atractiva –y útil, para identificar la diversidad de información que sea requerida y permitir flexibilidad y agilidad en satisfacerla.
  • Así es, no dejemos de lado la utilidad, usabilidad, garantía, no sólo de los servicios entregados, con base en procesos gestionados y sujetos a una mejora continua, sino también de los medios utilizados para su entrega, como la interface de usuario utilizada –portal bien diseñado, amigable e intuitivo por supuesto, con el que sea fácil pedir ayuda.

Como siempre, una buena venta del valor del servicio ayudará a que los usuarios lo adopten voluntariamente (menor rechazo inicial; servicios conscientes del contexto que conocen su rol, ubicación y equipo[8]; adopción más rápida; disponibilidad de diferentes medios de contacto; apoyo a las aplicaciones actualmente en uso –aunque no hayan sido provistas por el departamento de TI; naturalidad, facilidad y flexibilidad en el procesamiento de solicitudes; compromiso consciente; finalmente interiorización), buscar qué necesitan hacer, qué quisieran hacer y no pueden –aún, qué les ha funcionado, qué les molesta, y otros posibles aspectos a considerar[9] -una mejora continua de funcionalidad y alcances, promocionar lo realizado, buscando cada vez una mayor aceptación. Identificar los temas correctos que ayudarán a los usuarios a ayudarse a sí mismos, toma tiempo y esfuerzo, no olvidemos considerar el costo total de propiedad de la solución integral.

[1]        Fuente: http://www.techrepublic.com/blog/10-things/10-ways-it-can-use-self-service/; disponible en dic/2016

[2]        Fuente: http://www.computerworld.com/article/2500959/enterprise-applications/self-service-it.html; disponible en dic/2016

[3]        Fuente: http://www.servicenow.com/products/express/it-self-service-portal-for-smb.html; disponible en dic/2016

[4]        Fuente: http://whatis.techtarget.com/definition/customer-self-service-CSS; disponible en dic/2016

[5]       Fuente: https://www.atlassian.com/it-unplugged/best-practices-and-trends/technologies-for-self-service-success; disponible en dic/2016

[6]        Fuente: http://www.axiossystems.com/solutions/end-user-self-service; disponible en dic/2016

[7]        Fuente: http://www.gartner.com/newsroom/id/1426813; disponible en dic/2016

[8]        Fuente: http://www.bmc.com/it-solutions/it-self-service.html; disponible en dic/2016

[9]        Fuente: http://www.informationweek.com/strategic-cio/team-building-and-staffing/7-ways-to-avoid-self-service-it-pitfalls/a/d-id/1297292; disponible en dic/2016

DevOps – ITIL: riesgos y oportunidades

DevOps es un término con diferentes significados para diferentes personas. De hecho, no hay –aún- algo como un “manifiesto”.

Tampoco es que un NetOp o un SysAdmin o algún otro rol se conviertan por arte de magia en un DevOp[1]. Tampoco es una tecnología en concreto[2]. No se trata de resolver un problema de TI sino de innovación, del negocio.

Bueno, sí, la relación entre desarrollo de software (valor traducido en la funcionalidad requerida) y operaciones (valor traducido en estabilidad tangible) está en las siglas pero, por la literatura que circula al respecto, aún no hay una definición estándar[3]. Pero, de hecho, usualmente encontramos  el “yo me ocupo sólo de mi parte” o “en mi máquina funciona, es tu problema” o “es tu culpa”[4], entre otros muchísimos aspectos sociales o técnicos de la “relación”; así, la palabra “relación” es circunstancial –algo que DevOps e ITIL buscan eliminar.

devop01

Está el enfoque técnico pero también está la necesidad del negocio. Las personas, los procesos y la tecnología van de la mano en este moderno enfoque estratégico.

devop02

De hecho, cada negocio es distinto y cada empresa tendrá que analizar la velocidad de los despliegues y la frecuencia de los mismos para someter a consideración la más apropiada y mejor alternativa de solución –una solución a la medida para cada empresa, considerando que a algunas les contará más trabajo que a otras la adopción de este paradigma[5]. Flexibilidad, adaptabilidad y velocidad son aspectos que los usuarios y clientes valoran de los servicios que consumen porque están convencidos de que con estos servicios logran una ventaja competitiva -pueden llegar a ser más eficientes, efectivos, productivos.

devop03

En la siguiente figura se muestra la brecha entre Dev y Ops:

devop04

Así, es requerida una plataforma tecnológica (hardware, software, infraestructura) altamente automatizada (pruebas de código incluidas), con un flujo de trabajo automatizado (versiones, personalizaciones, configuraciones), y monitorizada de forma continua para asegurar que se cumple con los niveles de servicio comprometidos por el negocio (se valida y verifica que se alcanzan los objetivos estratégicos) y que el servicio está garantizado ya que satisface los requerimientos de: seguridad (seguridad de la información por supuesto, una necesidad en la estrategia DevOps[6] para generar confianza); capacidad (rendimiento, escalabilidad, tanto del hardware y software base como de las aplicaciones); disponibilidad, continuidad; soporte; confiabilidad –recordemos la garantía de valor según ITIL; ¿estarán los procesos de la organización preparados para este paradigma?

devop05

En ambos entornos hay bastante que mejorar ya que lo requerido por el negocio es la satisfacción del cliente o consumidor con el servicio recibido (el valor del servicio estratégico que ha sido diseñado y transicionado a producción se valida, verifica y aprecia en la operación con el cumplimiento de los SLA). Esto implica poner en práctica las mejores recomendaciones de nunca pasar un defecto conocido por los centros de trabajo, de no permitir nunca que una optimización local o particular genere una degradación global, de siempre buscar incrementar la fluidez de las comunicaciones, y de siempre buscar alcanzar una profunda comprensión del sistema (según Deming). Debemos entonces tener en cuenta el rendimiento del servicio completo, de extremo a extremo, y no de individuos, componentes, áreas o departamentos por separado.

La retroalimentación es entonces clave para saber y reconocer si las expectativas del negocio se están aterrizando completa y correctamente[7] –preguntemos a los stakeholders su visión y apreciación holística de los resultados[8]. Entendamos y respondamos sus inquietudes, acerquemos y amplifiquemos los lazos de retroalimentación cuando y donde sean necesarios, incorporemos el conocimiento donde –con conciencia- lo requiramos. ¿Serán efectivos los procesos de gestión de cambios, de configuraciones, de versiones, de accesos, y de problemas, entre otros?, ¿estarán a la altura de las nuevas necesidades?, ¿estarán a punto los ambientes de prueba necesarios[9]?, ¿estamos midiendo los resultados esperados –el valor para el cliente- o todavía medimos salidas de componentes/sistemas/áreas/departamentos individuales? Las profesiones son diferentes (know-how, habilidades, conocimientos, necesidades de capacitación, etc.), los roles son diferentes, y es claro que la responsabilidad es compartida[10].

Los marcos de trabajo y herramientas también son numerosas y diferentes para cada profesión; usualmente hablamos de “llevar” a la nube y tal vez también sea bueno considerar “traer” de la nube. Incluso las diferentes herramientas que existen también tienen enfoques digamos, “sesgados” en uno u otro entorno. Sin embargo, hay buenas noticias: existen varias alternativas; pero también hay malas noticias: existen varias alternativas. Esto implica adoptar e interiorizar una cultura que fomente: (a) experimentación continua, correr riesgos y aprender de los fracasos –la búsqueda de la innovación, reducir el “time-to-market”, salir de nuestra zona de confort, entre otros aspectos positivos; y (b) la comprensión de que la repetición y la práctica es el requisito previo para la maestría –incrementar la resiliencia, estabilidad, garantía, cumplimiento, seguridad de la información, eficiencia, efectividad, rapidez, flexibilidad y adaptabilidad para responder a nuevas o cambiantes necesidades, empleo eficiente de modernas tecnologías disruptivas, entre otros beneficios. Integrar las diferentes alternativas de solución es lo importante –y es lo riesgoso para el negocio, aunque a nosotros los especialistas esta integración nos resulte interesante. ¿Cuánta integración es necesaria, en cuántas fases lo lograremos, cuál es el plazo o cuáles son los plazos, quién realizará esta integración (o con quién), con qué se realizará?, son algunas preguntas que deberemos responder.

Requisitos y beneficios podrían verse mezclados y esto podría ocasionar confusión –y problemas- en su adopción; así, cada empresa deberá establecer los principios, métodos y prácticas DevOps que sean más apropiados para sus negocios.

Creo que a todos nos duele la cabeza el sólo pensar las mejoras que debemos implementar en nuestros respectivos ecosistemas tecnológicos, empezando por un cambio de cultura para eliminar los silos; aportar transparencia en las actividades de desarrollo y de operaciones; adoptar e interiorizar la calidad[11] y la colaboración[12]; trabajar en equipo, de forma más cercana, en un marco de respeto mutuo, generando confianza, aportando mayor agilidad al negocio y notables incrementos de productividad[13]; establecer procesos y responsabilidades claras; identificar mejoras necesarias en los procesos, tecnología y capacidades, habilidades, y conocimiento de las personas.

Para tener éxito con un DevOps disciplinado, necesitamos ocuparnos de las 5P de la mejora[14] (donde tal vez sean las personas lo más importante, como ya hemos visto):

  • Propósito/Objetivo: involucra todos los elementos que constituyen la intención de la organización. Esto incluye la misión, visión, objetivos y estrategias de la organización. Implica identificar los principales puntos fuertes, puntos débiles, oportunidades y amenazas;
  • Principios: son las filosofías que guían la empresa, los supuestos, o actitudes sobre las que la organización debe operar y cómo debería conducir sus negocios. Esto incluye la base de integridad, ética, y valores nucleares a los cuales se espera que los empleados se comprometan cuando son contratados. Implica identificar la cultura y los valores de la organización;
  • Procesos: son las estructuras organizacionales, sistemas, y procedimientos que se utilizan para fabricar los productos o desarrollar los servicios que provee la organización, así como la infraestructura y reglas que apoyan estos sistemas y procedimientos. Implica una lista de todos los procesos y exponerlos mediante diagramas de flujo, mapas de procesos, técnicas como 6W-2H; identificando los responsables de cada proceso;
  • Personas: son los individuos (y equipos de personas) que realizan el trabajo que es consistente con los Principios y Procesos de una organización para lograr su Propósito. Son los componentes activos que obtienen resultados. Implica determinar en qué medidas las personas están calificados para las funciones que desempeñan; identificar las necesidades de formación;
  • Rendimiento: involucra todas las métricas, mediciones y resultados esperados que muestran el estado de la organización, y son utilizados para la toma de decisiones. Los resultados son re‑alimentados al proceso de gestión estratégica con el fin de proveer retro‑alimentación y control. Implica identificar las medidas de rendimiento usados; establecer indicadores clave de rendimiento (KPI); establecer un sistema métrico.

El modelo de negocio determinará el marco de trabajo, mejor práctica, o norma que se empleará[15] y el contexto en el que actuarán (ITIL y DevOps, por ejemplo, complementándose ambos), enderezando el timón cuando y cuantas veces sea necesario. Es buscar agregar/obtener valor a/de los servicios que la empresa entrega. Esto implica buscar convertirnos en seres realmente proactivos –una nueva especie en el mundo informático de más de una empresa.

[1]       Fuente: https://www.quora.com/Is-DevOps-the-new-name-for-SysAdmin-Why-are-all-DevOps-tools-related-to-infrastructure-and-system-admin; disponible en agosto/2016

[2]       Fuente: http://searchdatacenter.techtarget.com/es/consejo/Definicion-de-DevOps-mejor-explicamos-lo-que-no-es; disponible en agosto/2016

[3]       Fuente: https://www.youtube.com/watch?v=o7-IuYS0iSE; disponible en agosto/2016

[4]       Fuente: http://es.slideshare.net/therobot/que-demonios-es-eso-de-devops-y-porquedebera-interesarme; disponible en agosto/2016

[5]       Fuente: http://www.javiergarzas.com/2014/12/devops-en-10-min.html; disponible en agosto/2016

[6]       Fuente: https://www.newcontext.com/devops-needs-security/; disponible en agosto/2016

[7]       Fuente: http://itrevolution.com/the-three-ways-principles-underpinning-devops/; disponible en agosto/2016

[8]       Fuente: http://www.drdobbs.com/architecture-and-design/getting-devops-right-the-lay-of-the-land/240062639; disponible en agosto/2016

[9]       Fuente: http://www.itproguy.com/devops-practices/; disponible en agosto/2016

[10]     Fuente: https://www.youtube.com/watch?v=_I94-tJlovg; disponible en agosto/2016

[11]     Fuente: https://www.paradigmadigital.com/techbiz/que-es-devops-y-sobre-todo-que-no-es-devops/; disponible en agosto/2016

[12]     Fuente: http://blog.itlinux.cl/blog/2013/10/23/que-es-devops/; disponible en agosto/2016

[13]     Fuente: http://www.claranet.es/devops-que-es-y-como-lo-aplicamos-como-proveedor-de-cloud-hosting; disponible en Agosto/2016

[14]     Fuente: http://www.12manage.com/description_pryor_5_ps_model.html; agosto/2016

[15]     Fuente: http://www.ca.com/us/rewrite/articles/devops/devops-and-itil-always-let-your-business-context-be-your-guide.html; disponible en 2016

Los proyectos –que apoyan los negocios

Moira Alexander[1] escribió para la revista especializada CIO[2] un artículo interesante donde planteaba algunos proyectos “que todo negocio puede poner en práctica este año para ayudar a asegurar que las personas, procesos y tecnologías están trabajando juntos de manera efectiva para crear mejores oportunidades o evitar perderlas”.

Estos proyectos son los siguientes:

  • Poner más énfasis en proyectos que apoyen la estrategia [de las organizaciones].
  • Re-evaluar las necesidades del comprador/cliente [retroalimentación].
  • Adoptar la mejora de procesos de negocio [incrementar la eficiencia –y rendimiento].
  • Revisar la oferta de servicios de los proveedores [las necesidades cambian].
  • Revisar y mejorar los sistemas de información y la tecnología [factor competitivo en este mundo globalizado].
  • Re-despliegue de recursos humanos [sin crear pánico, buscar que la tarea sea realizada de la manera apropiada por la persona apropiada y a la primera vez].

Sí, para sobrevivir debemos evolucionar; esto es, tener la capacidad de anticipar el futuro y transformar la empresa en una empresa digital[3]. Los CIO estratégicos aseguran que las inversiones en TI están siendo impulsadas por las ganancias que esta digitalización promueve, por el incremento en agilidad que se genera y por el incremento en la experiencia del usuario[4].

A la hora de las ideas, olvídese de los rangos –talento es talento (lo que hay dentro).

La comprensión de ITIL® nos permitirá optimizar los servicios de TI porque ahora podemos ver a estos servicios holísticamente –su ciclo de vida, y ayudará a crear mejores estrategias para mantener a los clientes contentos. Deberemos empezar entonces por evaluar la actual oferta de servicios de TI.

Aunque toda empresa es diferente, en cuanto a tecnología, siempre existirán las de adopción temprana y las tradicionales [que no siempre encuentran obstáculos]. No olvidemos establecer los factores críticos de éxito y sus respectivos indicadores.

Para mantener el talento emocionado por su trabajo, asegúrese de contar con un plan regular de rotación de proyectos para asegurar que van a obtener consistentemente proyectos frescos en adición a sus funciones, y de manera más regular. Y, claro, asegure que su talento balancee su carga laboral con la familiar (se distraiga) para evitar el stress.

[1]      Fuente: http://www.cio.com/author/Moira-Alexander/; disponible en mayo/2016.

[2]      Fuente: http://www.cio.com/about/about.html; disponible en mayo/2016

[3]      Fuente: http://www.cio.com/article/3072655/leadership-management/how-cios-can-guide-digital-business-transformation.html; disponible en mayo/2016

[4]      Fuente: http://core0.staticworld.net/assets/2016/01/14/2016-state-of-the-cio-executive-summary.pdf, disponible en mayo/2016

 

Seguridad de la información con la tendencia BYOD

El crecimiento y las innovaciones que brindan las redes sociales y las tecnologías de conectividad plantean una serie de oportunidades y riesgos para las empresas[1].

Bring Your Own Device (BYOD) es una tendencia cada vez más generalizada en la que las empresas permiten a los trabajadores llevar[2] [y utilizar –comprometiendo la seguridad de la información] sus dispositivos portátiles personales para llevar a cabo tareas del trabajo y conectarse a la red y recursos corporativos –la tecnología más avanzada aprovechable por la empresa pero sin los costos inherentes [¿qué tan cierto es esto y en qué grado?].

BYOD se requiere en algunos mercados verticales, como hospitales, escuelas, y algunas empresas manufactureras siguen exigiendo la movilidad y el uso que ofrecen estos dispositivos. ¿Su empresa requiere apoyar esta tendencia? ¿En dónde se requieren estos dispositivos? ¿Habrá que re-diseñar la red de datos?

Los usuarios adquieren dispositivos de su agrado y mantienen su status; ahorran los que permiten su uso –claro la empresa (menos costos en aparatos, licencias, renovaciones, seguros, entre otros –er, ahorros)[3]. En cualquier caso, su uso se incrementa:

BYOD

Todos ganan flexibilidad y movilidad; las empresas ganan además acceso remoto redefiniendo lo que significa “estar en la oficina”[4] [¿alguien dijo teletrabajo?] y personal más productivo [tal vez discutible esto último] pero, consideremos lo siguiente:

  • El control se complica:
    • Impacto en la confidencialidad-integridad-disponibilidad;
    • Re-evaluación de la clasificación de la información –y sus riesgos;
    • Los roles y autorizaciones;
    • Necesidad de incrementar recursos de red –para evitar degradación [¿qué consume más ancho de banda de comunicaciones, un Smartphone personal del cual ignoramos su configuración (aplicaciones instaladas) o una computadora propiedad de la empresa?];
    • Con BYOD, voz, vídeo, comunicaciones unificadas, y aplicaciones hambrientas de ancho de banda están siendo transportadas a través de la infraestructura inalámbrica, que probablemente no esté preparada para esta carga sin precedentes;
    • ¿Malware y rootkits? –claro que sí[5];
    • Necesidades adicionales/diferentes de protección Wi-Fi;
    • Control de tráfico;
    • Control de accesos;
    • Seguridad en la transmisión [¿VPN tal vez[6]?] y almacenamiento de los datos –cifrado de datos seguramente será una consideración de importancia;
    • ¿Problemas de identidad o filtración de información?;
    • Entre otros.
  • El entorno de trabajo se complica
    • Se debe reforzar el soporte técnico y mantenimiento de TI;
    • No olvidemos la gestión que sería requerida y los aspectos normativos y legales inherentes[7] [¿conocen –algunos seguramente recuerdan- términos como precedente jurídico?].
    • Entre otros.
  • Se vuelve menos confiable por la diversidad de alternativas tecnológicas, y su configuración[8].

Así, sería muy importante disponer de una solución Mobile Device Management (MDM) con la cual, entre otras funcionalidades se podría contar con[9]:

  • La instalación masiva de aplicaciones en los terminales conectados a la red
  • El control de las apps que pueden ser utilizadas permitiendo al personal de TI gestionar y bloquear tipos concretos de aplicaciones según categorías
  • El control de acceso de los dispositivos
  • La localización y el seguimiento de cualquier dispositivo
  • El bloqueo de funciones
  • La sincronización de archivos
  • El control de consumo telefónico y de datos
  • El borrado remoto de los datos de cualquier terminal
  • Y el establecimiento de una contraseña de bloqueo desde el servidor
  • Aplicación de políticas de DLP, cifrado y cumplimiento de normativas, mediante el bloqueo de dispositivos no cifrados o desbloqueados ilícitamente
  • Penalizaciones en caso de incumplimiento de roles[10]

La visibilidad lleva al control y el control lleva a la protección[11]. Así es, cada empresa tiene mucho que evaluar. Sobre todo porque el dispositivo NO le pertenece a la empresa así que hay MUCHAS limitaciones –pero el empleado debe ser consciente que para trabajar con sus propios dispositivos muchas veces debe renunciar a parte de su libertad y privacidad[12]. Entonces se debe establecer una política BYOD  para controlar su uso[13] la que debería tener en consideración lo siguiente:[14]

  • Personalización. Haga políticas específicas para casa caso sobre el uso y el acceso a la información por parte de los usuarios, puesto que cada uno de los trabajadores necesitará ciertas aplicaciones que quizá no le interesen a otros.
  • Restricción. La política de privacidad debe ser selectiva y restrictiva, ya no solo según el usuario, sino también según el tipo de datos a los que se tenga acceso [BYOD resulta atractivo porque las estrictas líneas de demarcación sobre lo que puede visitarse, descargarse y utilizarse en un dispositivo propiedad de la empresa se difuminan en un dispositivo propiedad del empleado, que incluye contenido tanto personal como profesional por diseño] –atenta contra el auto-servicio a que estaría acostumbrado el empleado.
  • Vincule las políticas y procesos de MDM con la estrategia general de administración y seguridad.

En adición a tener que implementar políticas de seguridad más estrictas –o “razonables” [cierto, ¿quién y cómo se definen? –no olvide crear la política antes de obtener la tecnología[15]], también se debe Invertir en sensibilización y capacitación de los usuarios. Los empleados deben ser entrenados en la importancia de adherirse a la política BYOD y los estragos que pueden ser causados por un fallo de seguridad. Una vez que la política BYOD está en su lugar y se comunica a los usuarios, debe haber una manera de monitorear y hacer cumplir la misma.

Tal vez sea conveniente analizar y sopesar si se debe desarrollar apps dedicadas –y seguras por supuesto- o continuar utilizando acceso web a los sistemas de información críticos. Recordemos no bajar la guardia –los ataques seguramente serán cada vez más selectivos. Si no tenemos madurez tecnológica para cumplir con las reglas y acuerdos establecidos para mantener la seguridad, poco se puede exigir [tal vez crear un perfil “de trabajo” y uno “personal”, para mantener separados apps y datos de cada uno podría ser una buena idea] -evitando proteger los datos corporativos con códigos de acceso personal[16].

No olvidemos nuestros procedimientos documentados [¿recuerdan las ISO, sobre todo la ISO9000?]. La auditoría es fundamental, para que sepamos cuándo se ha accedido a una aplicación, quién lo ha entrado, qué documentos ha utilizado, modificado, descargado, otros.

[1]      Fuente: http://www.welivesecurity.com/wp-content/uploads/2014/01/documento_guia_byod_W.pdf, enero/2014

[2]      Fuente: http://computerhoy.com/noticias/moviles/que-es-byod-ventajas-e-inconvenientes-7250, diciembre/2013

[3]      Fuente: http://www.isaca.org/chapters8/Montevideo/Events/Documents/presentacion%20-%20maximiliano%20alonzo%20-%20byod%20ventajas%20desventajas%20y%20consideraciones%20de%20seguridad.pdf, noviembre/2015

[4]      Fuente: https://www.cisco.com/web/about/ac79/docs/re/byod/BYOD_Horizons-Global_ES.pdf, 2012

[5]      Fuente: https://www.sophos.com/es-es/products/your-needs/technology-case-studies/byod.aspx, noviembre/2015

[6]      Fuente: http://blog.ontrackdatarecovery.es/6-tips-para-mejorar-la-seguridad-byod/, agosto/2014

[7]      Fuente: http://viewer.zmags.com/publication/60f900a3, noviembre/2015

[8]      Fuente: http://www.flukenetworks.com/expertise/topic/byod, noviembre/2015

[9]      Fuente: http://www.trendmicro.es/productos/mobile-security/, noviembre/2015

[10]    Fuente: http://www.ibm.com/developerworks/ssa/cloud/library/cl-cloudbasedBYOD/, mayo/2013

[11]    Fuente: http://media.kaspersky.com/sp/business-security/win-security-battle.pdf, 2014

[12]    Fuente: http://www.pymesyautonomos.com/tecnologia/politicas-de-fugas-de-datos-seguridad-y-byod-cuando-el-enemigo-esta-detras-del-teclado, diciembre/2014

[13]    Fuente: http://searchdatacenter.techtarget.com/es/consejo/Como-crear-una-politica-de-BYOD, enero/2014

[14]    Fuente: http://www.raona.com/es/Solutions/Template/164/C%C3%B3mo-establecer-una-buena-pol%C3%ADtica-de-seguridad-para-tu-estrategia-BYOD, 2013

[15]    Fuente: http://content.maas360.com/www/content/eb/maas360-ten_commandments_of_byod_bring-your-own-device.pdf, octubre/2011

[16]    Fuente: http://f6ce14d4647f05e937f4-4d6abce208e5e17c2085b466b98c2083.r3.cf1.rackcdn.com/tips-to-avoid-seven-deadly-sins-mobile-security-pdf-6-w-1851.pdf, julio/2015

Servicios gestionados

(Artículo preparado para difusión interna en la Red Científica Peruana -RCP)

Resumiré los dos artículos siguientes de la empresa N-able.

Los servicios gestionados son un modelo innovador de negocio y de entrega de servicio que está revolucionando la manera en que los revendedores de valor agregado, integradores de sistemas y proveedores de servicios de TI están haciendo negocios. Continue reading

Fundamentos de una práctica exitosa de servicios gestionados

(Artículo preparado para difusión interna en la Red Científica Peruana -RCP)

(SearchNetworkingChannel.com White Paper) Con el patrocinio de N-able Technologies.

Interesante la tecnología, interesante la aplicación correcta, interesante la integración.

Muchas empresas hoy claman que ofrecen servicios gestionados cuando lo que realmente hacen es solo supervisión remota y algo de gestión. Mientras que esto es un paso en la dirección correcta, sólo una parte de la solución. Hay tres elementos necesarios para una transformación exitosa de servicios gestionados: una plataforma interoperable para el monitoreo remoto y gestión; empleo de las mejores prácticas para configurar y usar la tecnología; y un sistema completo de ventas y mercadeo“.