Le «service nul» | – Octets de produit de Rich Mironov


Alors que les clients s’intéressent de plus en plus aux services hébergés et aux ASP, de nombreuses équipes de produits repensent leurs logiciels packagés comme des offres Internet externalisées. Les hypothèses et l’infrastructure nécessaires pour hébergement un service, cependant, est très différent des logiciels sous licence traditionnels. Les applications d’entreprise hébergées ont besoin d’une couche architecturale sous-jacente qui manque dans les applications internes – mais à peu près cohérente entre les offres ASP. J’ai appelé ça le “Service nul.”
D’abord un peu d’histoire. Il y a des années chez Sybase, nous avons eu beaucoup de discussions sur la «libération nulle». C’était un raccourci pour l’effort nécessaire pour sortir une nouvelle version d’un produit logiciel indépendant des modifications spécifiques qui y sont apportées. Imaginez un correctif en ligne pour la suite middleware d’entreprise de Sybase, qui devait ensuite être… portée sur 31 systèmes d’exploitation, exécutée via QA, compatibilité testée, documentée, publiée, mise en scène pour les mises à niveau des clients et annoncée. Cela pourrait représenter 4 mois de travail pour 45 personnes, pour un coût de 2 M $. Le concept de «libération nulle» a permis d’équilibrer les demandes de cycles de libération de plus en plus fréquents par rapport au coût fixe de production.

Pour avancer d’une décennie vers l’émergence des services hébergés et des ASP, voici notre concept connexe: le «service nul». Il s’agit de l’infrastructure technique nécessaire pour exécuter tout service en ligne pour les entreprises – quelles que soient ses spécificités – si le service doit être sécurisé, hébergé, facturé et généralement accessible à tous ses utilisateurs. Autrement dit, il existe un ensemble commun de systèmes et de procédures que la plupart des applications Web devraient avoir.

Comment la réflexion sur le «service nul» aide-t-elle? Au début du cycle de planification, il permet à une équipe de marketing et de développement de diviser en deux les grands projets – un groupe se concentrant sur une infrastructure bien comprise tandis qu’un autre se concentre sur la définition de fonctionnalités de service détaillées. Une partie du travail de mise en œuvre peut commencer immédiatement, en parallèle avec l’analyse du marché.

Que diriez-vous d’un exemple?

Imaginez que votre entreprise soit le leader des logiciels d’application d’outplacement. Les plus grandes sociétés du monde concèdent sous licence votre solution pour suivre les vagues successives de réduction des effectifs – assurant aux cadres RH que les règles d’ancienneté ont été respectées et qu’aucune loi fédérale n’a été violée. (C’est fictif, tu te souviens?) Cependant, les entreprises clientes exécutent votre logiciel sur leurs propres systèmes et vous paient 500 000 $ + chacune pour ce privilège. Vous pensez qu’un marché beaucoup plus vaste existe en tant que service Internet si vous pouvez baisser le prix et affiner les fonctionnalités. En hébergeant une version allégée de votre application en ligne, vous pouvez atteindre des milliers de moyennes entreprises qui pourraient avoir besoin de réduire leur personnel un jour.

Fidèles à leur forme, vos concepteurs de logiciels veulent une carte précise des fonctionnalités de service avant de commencer le développement. Pour le créer, votre équipe marketing a besoin d’une recherche approfondie des clients pour choisir les quelques fonctionnalités importantes parmi vos centaines d’options de configuration. Ce cycle de collecte des exigences prendra six mois d’entretiens avec les clients et de travail de conception avant que la première ligne de code d’application ne soit écrite.

Faut-il attendre le MRD parfait?

N’attendez pas! C’est le moment idéal pour commencer à jeter les bases de votre «service nul». Quelles que soient les fonctionnalités de réduction de taille que vous incluez, la solution devra avoir:

  • Systèmes de secours à chaud pour le basculement d’applications et de bases de données
  • Informations de compte identifiant chaque client (et chaque utilisateur)
  • Délivrance de mot de passe et procédure de remplacement des mots de passe perdus
  • Sécurité pour garder les réductions de personnel de chaque client cachées aux autres
  • Un module de facturation pour envoyer des factures, inscrire de nouveaux clients, afficher l’utilisation à ce jour et couper les comptes en souffrance depuis 60 jours
  • Un engagement de disponibilité ou un accord de niveau de service (SLA), ainsi que des rapports pour mesurer la disponibilité réelle
  • Procédures opérationnelles pour valider et mettre à jour les mises à jour logicielles sans temps d’arrêt du client, ainsi qu’un moyen de les annuler si nécessaire
  • “Merci de votre inscription” des e-mails avec des instructions et des URL pour plus d’aide
  • Portail d’auto-assistance pour les utilisateurs actuels et potentiels
  • Processus de support client (email ou téléphone?) Avec des temps de réponse engagés
  • Rappels de 60 jours avant les renouvellements annuels
  • E-newsletter marketing avec mécanisme de souscription / désinscription
  • Politique de confidentialité publiée pour votre e-newsletter

Vous avez eu l’idée. Il y a beaucoup de travail en attente, et une grande partie pourrait commencer aujourd’hui. Les décisions sur la façon dont votre application doit calculer les packages de sortie (ou autre) ne font aucune différence pour les stratégies de disponibilité, la gestion des mots de passe ou les politiques d’adhésion à la newsletter.

Bon nombre de ces technologies d’hébergement sous-jacentes seront gérées par une équipe d’exploitation. Il s’agit d’un ensemble incroyable de spécialistes en ingénierie de réseau et de production qui assurent le fonctionnement de votre service face aux pannes de courant, aux typhons, aux sauterelles, aux pics soudains du trafic des utilisateurs finaux, à la faillite des opérateurs et aux virus de messagerie. Il n’existe pas de groupe Opérations dans votre modèle actuel de «logiciel sous licence», mais sera essentiel au succès de tout service hébergé. Les trouver peut prendre un certain temps.

Une grande partie du puzzle des opérations est la conception de processus humains: des étapes détaillées pour faire des choses apparemment simples. Qui prendra les appels du service client et à quelle vitesse répondrons-nous? Que se passe-t-il lorsqu’un client souhaite un remboursement partiel au milieu d’une période d’abonnement? Comment vérifions-nous qu’une demande de redélivrance de mot de passe est légitime?

Puis…

En fin de compte, ces deux éléments majeurs – le développement fonctionnel de base et les opérations – devront se réunir. Par exemple, vous pouvez décider que chaque compte aura plusieurs types d’utilisateurs (responsables des ressources humaines, spécialistes de l’outplacement et anciens employés), ce qui oblige certains à jouer avec la sécurité de connexion pour définir correctement les autorisations. Cela implique alors une procédure permettant aux clients de donner des comptes d’utilisateur final, etc. Avoir six mois supplémentaires pour concevoir une fondation accélérera votre mise en œuvre et réduira la panique de dernière minute.

À terme, les initiatives de «calcul utilitaire» de HP et IBM pourraient répondre aux rêves d’infrastructure d’applications comme Jamcracker et Salesforce Force. Cela pourrait nous donner un «shell» hébergé complet pour des services Internet payants et de qualité de production – comme le cadre de commerce électronique et de logistique qu’Amazon fournit à Target. Pour l’instant, cependant, vous devez planifier l’architecture de la plupart de ces installations en interne.

SoundBytes

Pendant que vous planifiez les détails de votre service Internet, vous devez également commencer à cartographier l’infrastructure générique dont vous aurez inévitablement besoin. N’attendez pas la clarté parfaite de l’application pour lancer la conception de vos opérations.



Source

  • Partager cet article

Laisser un commentaire