¿Existe un SaaS equivalente a la custodia de software? Claramente, el código de garantía no es suficiente para garantizar un servicio ininterrumpido. Cuales son las alternativas?

Historia y el futuro del SLA: SLA SaaS, SLA de software y SLA de Telco

Los SLA se evitan debido a la historia. Las compañías de software en las instalaciones nunca podrían garantizar los SLA porque mucho depende de cómo configure y opere el software. Sin embargo, tendrían SLA en torno al soporte que básicamente significaba “le devolveremos la llamada e intentaremos arreglarlo dentro de X horas”. En casos excepcionales, los SLA están firmados incluso por software, pero tienen un alcance tan limitado que es casi ridículo lo que cubren.

Mientras tanto, los ‘proveedores de servicios’ como las empresas de telecomunicaciones han estado ofreciendo SLA, así es como cobran precios superiores por servicios como la conectividad MPLS.

SaaS es (todavía relativamente) nuevo. Las compañías SaaS se consideran a sí mismas (erróneamente) como compañías de software. Los clientes piensan en ellos (erróneamente) como proveedores de servicios.

En lenguaje legal, carecemos de un buen precedente.

Así que todos hemos estado tratando de inventar las reglas a medida que avanzamos. Las empresas SaaS, alentadas por sus inversores, son reacias a asumir la ‘responsabilidad’ de los SLA.

¿A dónde va esto?

Los proveedores de IaaS deberán comenzar a ofrecer SLA. Sabemos cómo se ve una VM con Linux, cómo se ve el tiempo de actividad y cómo medirlo. Si voy a comprar 2 millones de horas de capacidad de cómputo, quiero saber que aumentará 24 × 7 con un 99.99% de disponibilidad. Los proveedores alojados lo han estado haciendo por un tiempo.

Aquí está AWS SLA. Amazon EC2 SLA

Las compañías SaaS aprenderán con el tiempo que nadie se arruina al ofrecer un SLA. Si tiene tiempo de inactividad, tendrá un impacto financiero mucho mayor a través de la percepción del mercado en comparación con los pocos dólares que termine debiendo. Mientras el SLA esté estructurado modestamente, sin daños punitivos extremos, estará en buena forma.

Mientras tanto, los clientes están aprendiendo que los SLA realmente no parecen ser un buen predictor de la calidad y el tiempo de actividad del software.

El gobierno federal generalmente tiene SLA en los contratos. ¿Cómo ayudó eso al sitio web de Obamacare? Sí, podemos recuperar nuestros pocos dólares de impuestos, pero el daño está en miles de millones. Y el daño a CGI Federal está más allá de las sanciones de SLA.

No estoy seguro exactamente cómo se muestra la responsabilidad del SLA en las declaraciones GAAP. Esto seguramente concierne a los contadores ya que afecta el balance general (y puede ser incluso un reconocimiento de ingresos).

Recomendación
Planifique un mundo donde los SLA se vuelvan más comunes. Utilice proveedores de IaaS y PaaS con un buen historial de tiempo de actividad. Evite los SLA en los TOS estándar, pero esté preparado para firmar uno para obtener acuerdos. Ninguna compañía de SaaS de la que he oído ha caído debido a los SLA. Si su sitio está inactivo durante días, se preocupará en lo más mínimo por los SLA.

Los depósitos en garantía SaaS son realmente importantes en las circunstancias adecuadas. Si está trabajando en un contrato de licencia para una pieza de software de misión crítica que tiene el potencial de causar daños graves si se produce la interrupción del servicio o incluso una peor pérdida de datos, entonces necesita una custodia SaaS.

Existen muchos beneficios para el modelo de software SaaS, pero desafortunadamente un mayor grado de seguridad no es uno de ellos. En el modelo de software SaaS, todo está alojado en los sistemas de proveedores SaaS. Esto hace que su cliente esté en riesgo de tiempo de inactividad y pérdida de datos.

Los Fideicomisos SaaS son más difíciles de configurar que el depósito en garantía tradicional, por lo que algunas personas sugieren no incluir la provisión de depósito en garantía SaaS. Sin embargo, si trabaja con una agencia de garantía de software de buena reputación, puede abordar cada dificultad y configurar algo que proteja a su cliente.

Algunas de las dificultades y sus resoluciones:

1. El software SaaS se actualiza con mayor frecuencia y los datos del cliente se actualizan en tiempo real.

   Las custodias SaaS se pueden configurar para transmitir datos de clientes en vivo para que se mantengan actualizados. Aquí hay un aumento de costos para esta solución, pero si el software SaaS es de misión crítica, entonces la frecuencia de las actualizaciones, especialmente para los datos del cliente, es una conversación importante.

2. El software SaaS está diseñado para ejecutarse en Internet.

   No se necesita mucho conocimiento técnico para configurar el software para que se ejecute en la intranet de su empresa en lugar de Internet. Aquí hay algunas excepciones a la regla, ya que cada pieza de software es diferente, pero en general esto es cierto.

   También puede seguir el camino de que su proveedor de custodia configure un entorno de producción en estado frío, lo que básicamente significa que es totalmente capaz de ejecutarse, pero no hasta que se produzca un evento de lanzamiento. Esto es útil en un escenario ultra sensible donde incluso un par de horas de inactividad es inaceptable.

3. Materiales de depósito incompletos

   Al igual que una custodia de software tradicional, el código fuente de una custodia SaaS y otra documentación deben tener verificaciones técnicas realizadas periódicamente para garantizar que la custodia sea utilizable en caso de una liberación.

   A pesar de que el desarrollador de software está depositando el código fuente en la custodia con la mejor de las intenciones, ocurren errores. Falta documentación, las contraseñas están mal documentadas, las dependencias de terceros no se describen ni se incluyen, y más. Una verificación técnica los detectará y ayudará a garantizar que su cliente esté protegido.

   Afortunadamente a lo largo de los años, las verificaciones técnicas han disminuido en costo y se pueden hacer por tan solo un par de miles, dependiendo de la complejidad del software.

4. A su cliente le falta la experiencia técnica

   Esto puede ser una preocupación ya que su cliente está en el negocio de creación de widgets y no en el negocio de software SaaS. Sin embargo, al igual que contratar a un mecánico cuando la transmisión de su automóvil se rompe, su cliente puede contratar a las personas adecuadas para ayudarlos a mantener el software SaaS.

   Además, el proveedor de software SaaS debería poder incluir una lista de los desarrolladores que realmente desarrollaron el software SaaS en los materiales de depósito. Estas personas a menudo no tienen trabajo porque su empleador se declaró en bancarrota, lo que provocó esta custodia de SaaS.

Los depósitos en garantía de SaaS son para mitigar el riesgo. Si se hace bien, puede asegurarse de que su cliente esté protegido.

Esta experiencia proviene no solo de trabajar en la industria de custodia de software en EscrowTech, sino también como desarrollador de stack completo.

Perspectiva estadounidense

En mi experiencia, una disposición de custodia de software no es una disposición obligatoria en un acuerdo de licencia de SaaS . Ofreceré una perspectiva histórica de por qué este es el caso.

Cuando las custodias de software se desarrollaron por primera vez hace décadas, tuvieron un breve aumento de popularidad (varios años). A los licenciatarios les gustó la idea de un nivel adicional de seguridad si el licenciante cerraba.

Pero ese aumento de popularidad terminó cuando la mayoría de los licenciatarios se dieron cuenta de que era poco probable que quisieran realizar la inversión financiera requerida en tecnología y personal para usar el software del licenciante si surgiera la necesidad de ejercer sus derechos de custodia. Y probablemente no estarían en una posición financiera para hacer esa inversión lo suficientemente rápido en caso de emergencia , incluso si quisieran, porque el tiempo de entrega requerido para la aprobación del presupuesto del proyecto de TI es demasiado largo.

Por supuesto, en una situación de SaaS, la utilidad de una custodia de software es aún menor, porque el titular de la licencia probablemente no tenga interés o necesite ejecutar una operación de SaaS por sí mismo.

Sin embargo, lo que el licenciatario de SaaS necesita es acceso rápido garantizado a una copia de todos sus datos en un formato utilizable en cualquier momento.

El depósito en garantía de SaaS cuando se realiza correctamente ayudará a proteger el SaaS
usuario contra desastres legales y comerciales. EscrowTech tiene la capacidad
para entrar en funcionamiento con 24 horas de anticipación con la aplicación SaaS poblada por
Datos del cliente actual del usuario de SaaS. En casos de misión crítica
software no es aceptable que el usuario de SaaS deje de funcionar incluso por un corto período
período de tiempo. Suponiendo que el usuario de SaaS poseía sus datos de cliente
de acuerdo con su acuerdo de licencia, el tiempo que tomaría recuperar el
Los datos de un proveedor descontento o en bancarrota representan un gran riesgo para el SaaS
usuario. Envíeme un correo electrónico a [correo electrónico protegido] . Los depósitos en garantía SaaS pueden estructurarse en múltiples
formas dependientes de los usuarios de SaaS requerían “Estado de preparación”. Consulte https://escrowtech.com/saas_escr …

La diferencia crucial entre una custodia de software y SaaS
El depósito en garantía es la entrega de los datos del cliente. Las soluciones SaaS ofrecen muchos beneficios sobre el software tradicional, pero
También vienen con más riesgos que con el software tradicional. Un depósito en garantía en este caso puede ser aún más importante.

Los SLA han existido en el mundo B2B durante décadas. El alojamiento administrado y los servicios ASP en los años 90 los tenían para cualquier contrato empresarial. Sin embargo, fueron difíciles de rastrear y definir, y, como Jason Lemkin dice anteriormente, al cliente realmente no le importa el SLA tanto como le importa tener un estándar exigible que pueda mantener a su proveedor.

No creo que los proveedores de SaaS lo eviten al tratar con Fortune 1000 en cualquier cosa crítica para su negocio. Ahora que la nube es una alternativa real tanto financiera como técnicamente para las corporaciones, verá los SLA como una oferta estándar con mayor frecuencia. La tecnología ahora está ahí para rastrear los SLA automáticamente y ponerlos a disposición del cliente en tiempo real (lo hacemos en nuestro producto). Esto ya está llegando al mercado de las pequeñas y medianas empresas (PYMES) que no tenían la influencia necesaria para exigir SLA en el pasado.

Acabo de dirigir un programa para implementar una plataforma SaaS para una empresa con la que consulto en Dubai. La plataforma que hemos licenciado ha sido desarrollada por una empresa mediana en Suecia y alojada en servidores dentro de un centro de datos de terceros en Malmo.

Al evaluar nuestros riesgos, implementamos algunas directivas para garantizar la mejor protección para mitigar nuestros riesgos. Estas directivas incluyen:

• En nuestro acuerdo de SaaS con el proveedor, incluimos una cláusula de “luces encendidas” que se coordinó de forma consecutiva con el centro de datos de terceros.
• Nos aseguramos de que el proveedor tuviera una política de respaldo sólida que cumpliera con nuestras políticas internas de respaldo. Como parte de nuestro proceso de auditoría trimestral, llevamos a cabo verificaciones para asegurarnos de que las bases de datos que contienen nuestra puedan restaurarse.
• Implementamos un enfoque de cinturones y frenos que incluía un acuerdo de custodia de software que incluía el código fuente, las imágenes de la aplicación y las actualizaciones periódicas de las bases de datos que un agente de custodia mantendría en confianza. Utilizamos los servicios de Escrow London http://www.escrowlondon.co.uk . Incluimos una verificación para garantizar que el sistema pueda reconstruirse en un entorno limpio en un escenario del fin del mundo. La verificación implicó que uno de sus consultores visitara el sitio del desarrollador y documentara el proceso de reconstrucción. La segunda parte de la verificación se realizó en su laboratorio.

Para las empresas corporativas, la implementación de plataformas SaaS plantea desafíos pero ofrece grandes ventajas de eficiencia si se realiza correctamente.

Mi empresa ofrece un sistema de gestión de contenido SaaS y, como empresa relativamente joven, recibimos con frecuencia esta pregunta (“¿qué sucede si cierra su negocio”) de nuestros clientes más expertos. Por lo general, podemos hablar con ellos y hacerlos sentir cómodos.

Les hemos dicho que estamos comprometidos a lanzar el software como código abierto en caso de que no podamos proporcionar el servicio por cualquier motivo, y que ya hay más que suficientes clientes para que resulte atractivo que alguien más se haga cargo del sistema. .

Hemos analizado una empresa que puede formalizar esto y hacer que sea más una garantía: http://osescrow.com/ . Me encantaría saber de cualquiera que los haya usado, o algo equivalente.

Por supuesto, y creo que esta es la esencia de la pregunta, tener el software es solo una pieza para poder operar la infraestructura y mantenerla. Ese es un problema difícil de resolver de una manera sólida.

Una cosa en la que he pensado es en encontrar un emprendedor que quisiera competir / asociarse con nosotros: les licenciaríamos nuestro software y recortaríamos su flujo de ingresos, y las dos compañías serían proveedores alternativos, algo así como una vez se esperaba tener una fuente alternativa en la industria de los semiconductores.

Sospecho que alguien en algún lugar ha encontrado un equivalente a la custodia de software para SaaS … o al menos algo que satisfaga a las personas de compras del cliente. Jeremy Aber ( http://www.aberlawfirm.com/ ) podría ofrecer más asesoramiento legal.

Un mejor enfoque que pasar por esta gimnasia legal y lógica podría ser explicar más claramente al cliente y a sus profesionales de compras cómo funciona SaaS y por qué es fundamentalmente diferente del software en las instalaciones. El cliente obtiene las ventajas de una mayor flexibilidad, una implementación más rápida, actualizaciones más fáciles, menores costos de hardware, etc., precisamente porque no posee el software.

Si bien proporcionar una custodia de software generalmente no tiene sentido, la mayoría de los contratos de SaaS sí proporcionan un mecanismo para que el cliente recupere sus datos en caso de que el proveedor fallezca o cuando caduque la suscripción.

El depósito de garantía de software es un espejismo que las compañías creen que proporcionaría continuidad comercial. La mayoría del software SaaS (que vale la pena) tiene una arquitectura altamente optimizada para alojar a cientos de clientes desde el software hasta el hardware subyacente. Entonces, con solo obtener software (sin importar la complejidad del código, el modelo de datos) no sería bueno para las empresas. Las empresas no tienen los recursos y las habilidades que pueden sustentar dicho servicio, aunque solo sea para su empresa. Prefiero que los clientes incorporen cláusulas en su contrato que requieran que el proveedor de SaaS comparta la información de desempeño de su compañía que les permita rastrear / monitorear si la compañía está funcionando bien o está bajando el tubo y tomar medidas oportunas cuando vean que las cosas van mal.

No. Aunque muchos clientes de SaaS piden esto, no tiene sentido. Aquí hay algunas razones por las cuales:

1. El software SaaS a menudo no está diseñado ni documentado para el alojamiento en las instalaciones de los clientes. Si un proveedor de SaaS se declarara en quiebra, sería costoso y difícil sacar el software de Escrow y configurar un servicio local.

2. El fideicomiso se trata de proteger la inversión inicial de los clientes. El software tradicional a menudo se compra por adelantado con 3-5 años de “privación”. El modelo SaaS es más “pago por uso”, menos inversión para proteger.

3. El software SaaS es a menudo un ‘organismo vivo’ con muchas actualizaciones al año. Desde un punto de vista práctico, el mantenimiento del depósito en garantía podría ser difícil.

4. Realmente no compra / vende un software sino un servicio: el fideicomiso es para software, no para servicios.

Havig dijo que el contrato debe permitir al cliente conservar la propiedad total y el acceso a sus datos también después de una quiebra.

Dos riesgos principales al licenciar aplicaciones basadas en la nube que el depósito de código fuente tradicional no aborda incluyen:

1. Tiempo de inactividad inmediato de la aplicación
2. Pérdida de acceso a datos críticos.

NCC Group ha desarrollado un protocolo que incluye el entorno de la nube sobre el código fuente para que usted, como usuario final, pueda reconstruir la aplicación y volver a implementar en la nube si ocurriera un evento desastroso para el proveedor de software.

Mi empresa es una firma de garantía de propiedad intelectual y he estado proporcionando servicios de custodia de software y seguridad de la información durante más de 30 años al sector público y privado.

Por favor hazme saber si tienes preguntas.

Aaron Chai

415.268.9256

[correo electrónico protegido]

Simplemente recogiendo la respuesta de Jason M. Lemkin, se puede acceder a nuestro informe de tiempo de actividad a través del informe de tiempo de actividad de edocr.com, enterrado en nuestro escritorio de soporte, pensando si agregar esto a nuestro pie de página en la próxima actualización …

Si se trata de un SaaS B2B, los clientes prefieren tener un SLA y un contrato (incluso si se trata de un localizador, solo aceptan tipos) independientemente del precio.

¿Cuándo esperan? Yo diría que alrededor del precio de USD 1k / mes.

El proveedor determina sus SLA de servicio y su socio de alojamiento, los SLA de alojamiento asociados con la oferta del software de un modelo SaaS / normalmente en la nube; pero cada vez más clientes pueden elegir su propio proveedor de alojamiento para asegurarse de obtener la resistencia y la seguridad y, de hecho, la velocidad que necesitan

La mayoría de los proveedores de SaaS ofrecen un SLO estándar (objetivo de nivel de servicio). No encontrará un SLA “típico” en SaaS. La mayoría de los proveedores indicarán un% de disponibilidad mensual (es decir, 99.99% de tiempo de actividad) que puede incluir o no minutos de mantenimiento mensual planificado del sistema. Verifique la letra pequeña.