Las arquitecturas evolucionan todo el tiempo. Esto es lo que escribí hace 3 años como los requisitos comerciales de una arquitectura. Me quedaría con esto hoy. El punto más importante, y el que nos ha valido la pena en SalesSeek muchas veces es tener acceso a través de la API web.
Sobre los detalles del manejo de un gran número de organizaciones, este artículo más técnico puede ser útil – Arquitectura de enrutador de usuario para arrendamiento múltiple – Blog de SalesSeek
Requisitos comerciales de arquitectura
- Cómo establecer un precio de suscripción al pasar de una licencia perpetua a un modelo saas
- ¿Qué es Heroku en términos laicos?
- ¿Qué empresas prominentes de SAAS están empleando estrategias de RSE?
- ¿Cuáles son buenas alternativas para Zenefits?
- Cómo medir el tiempo de actividad de SaaS
Esta breve nota describe los estándares arquitectónicos requeridos. Ninguno de estos tiene la intención de exigir la arquitectura implementada real o la selección de productos, sino que representan los requisitos comerciales que cualquier arquitectura elegida debe abordar.
Si alguno de estos requisitos no puede cumplirse, cualquier exención debe ser una decisión comercial consciente y deliberada, teniendo en cuenta todos los factores en competencia.
Diseño de aplicaciones
Infraestructura de API web
El sistema debe estar diseñado para aislar las llamadas y respuestas de los clientes, convirtiendo efectivamente la aplicación en una API, con la interfaz web como uno de esos usos de la API. Esta es una sobrecarga moderada, pero pagará dividendos al admitir múltiples clientes y al habilitar una capa API de acceso público en el momento adecuado. Una vez más, la ventaja de comenzar de esta manera es evitar gastos más adelante, así como acelerar el desarrollo en múltiples plataformas como teléfonos inteligentes y tabletas emergentes.
Prueba : habilite la funcionalidad “agregar contacto” mediante programación.
Control de acceso – Datos
Ya sea implementado o no, cada elemento de datos lógicos debe poder controlarse, en principio, mediante seguridad basada en roles con grupos. Esto es necesario para respaldar los controles internos de privacidad que dependen de los requisitos del mercado, y es muy probable que requieran cambios y evolución frecuentes, de ahí la necesidad de flexibilidad arquitectónica.
Prueba: dé a los gerentes acceso de solo lectura a las previsiones de sus vendedores.
Control de acceso – Funcionalidad
Todas las funcionalidades agrupadas lógicamente para tener acceso controlado. Esto nos permitirá, según el cliente, configurar un conjunto funcional (por ejemplo, crear / leer / actualizar / eliminar contacto es un conjunto único). Parte de esto es admitir la funcionalidad escalonada a múltiples puntos de precio. Dentro de esto, el administrador del cliente también debería poder restringir aún más la disponibilidad de la funcionalidad, si elegimos mostrar esta capacidad.
Prueba : Empaquete una oferta de gama baja pura del administrador de contactos.
Internacionalizacion
Todas las partes de la aplicación que tocan datos deben ser totalmente compatibles con la internacionalización. Este es un requisito previo a cualquier expansión internacional, ya que incluso en el Reino Unido, tanto los detalles de contacto como los símbolos de moneda pueden extenderse más allá del conjunto de caracteres estándar. Si se diseñó desde el principio, esto debería ser una sobrecarga mínima (muchos componentes como Java lo admiten de forma nativa).
Prueba : admite “Die Großväter” como contenido.
UI Message File
A corto plazo, esto permite cambios rápidos de contenido textual en la pantalla a medida que se desarrolla la aplicación. A largo plazo (horizonte de 2 a 3 años), esto también facilitará la traducción de la interfaz de usuario para admitir la localización y permitirá que un socio realice dicho trabajo de forma independiente. Para empezar, esta es una sobrecarga de muy bajo costo, pero puede ser extremadamente costosa realizar ingeniería inversa en una fecha posterior si falta.
Prueba: cambie el elemento de menú “agregar contacto” a “nuevo contacto” en producción en menos de 30 segundos (suponga una implementación automatizada).
Interfaz interna de SQL
Para facilitar la expansión y utilizar herramientas de informes de terceros, el sistema debe proporcionar una interfaz SQL a los datos (incluidos los controladores de base de datos disponibles). No es necesario que sea el único o incluso el modo principal de acceso a los datos de la aplicación, sino que debe ser una opción disponible. Esto abrirá opciones de integración con terceros.
Prueba: habilite las herramientas de consulta / visualización comúnmente disponibles para acceder a los datos.
Infraestructura de sistemas
Sin punto único de falla comercial
La planificación de continuidad del negocio debe surgir de un análisis de costo / beneficio, pero no debe limitarse a fallas puramente técnicas. Cuestiones comerciales y disputas ocurren, y esto puede llevar a la suspensión del servicio crítico de un proveedor, como un proveedor de hosting. Esto debe anticiparse y el plan de respaldo (por ejemplo, mover el sitio de respaldo a una organización separada) debe cubrir explícitamente los casos de fallas comerciales.
Prueba: la tarjeta de crédito de la empresa utilizada para pagar los servicios de Google expiró el sábado.
Operaciones continuas
La implementación del sistema debe permitir operaciones continuas, es decir, todos los componentes de software y hardware (no solo la aplicación) deben poder intercambiarse en caliente sin suspensión del servicio. El rendimiento degradado y la necesidad de que el usuario inicie sesión nuevamente es aceptable durante dichos períodos. Al eliminar la necesidad de ventanas de mantenimiento, esto proporciona una flexibilidad de implementación mucho mayor.
Prueba: no es necesario avisar a los clientes sobre el tiempo de inactividad del sistema.
Control de acceso – Clientes
Todos los datos del cliente deben agruparse lógicamente por cliente para permitir que las operaciones de copia de seguridad / cifrado / equilibrio de carga, etc. se apliquen a los clientes según corresponda
Prueba: Mover clientes AK al sistema 1 y LZ al sistema 2, sin interrupciones.
Flexibilidad de arrendamiento múltiple
Es altamente deseable ejecutar siempre una sola imagen para todos los clientes. Sin embargo, siempre habrá situaciones (por ejemplo, demostraciones, pruebas) en las que se necesitan varias imágenes, así como potencialmente la flexibilidad para admitir diferentes clientes con diferentes imágenes.
Prueba: migre a todos a la nueva versión, excepto a estos dos clientes.
Seguridad
La seguridad es una preocupación transversal, por lo que es importante que ninguna elección arquitectónica limite la capacidad de implementar la seguridad de las mejores prácticas. Esto afecta principalmente a las áreas de API web y control de acceso, pero potencialmente cubre todo. Además, la seguridad debe integrarse en el nivel arquitectónico cuando sea posible. Si bien ningún sistema puede garantizar el 100% de seguridad, tampoco hay razón para cometer errores no forzados, como el hecho reciente de LinkedIn (que no protege adecuadamente las contraseñas) que dañan la confianza del mercado.
Prueba: no hay oportunidad para que nadie critique la política de seguridad.
