En utilisant des fonctionnalités SaaS dans le Cloud l’entreprise entend faire évoluer son modèle de coût et augmenter son agilité.
Si cela est fort bien pour les métiers, la DSI ne peut ignorer les périmètres dans le Cloud, et pas seulement sur le sujet de la sécurité. En effet, le Système d’Information voit sa complexité augmenter : aux périmètres internes (« on premises ») s’ajoutent maintenant les périmètres dans le Cloud. Il faut bien réaliser que cela induit une complexité particulière, et qu’il y a une bonne approche pour aborder et maîtriser cette complexité.
Il est souvent possible d’utiliser une application SaaS en relative isolation du reste du SI, tout au moins pour des fonctionnalités périphériques au cœur de métier. Mais le contexte réel est vite plus compliqué. Par exemple :

• l’application SaaS doit interagir avec les référentiels de l’entreprise,
• l’application Saas n’est pas forcément déployée sur l’ensemble de l’entreprise, certains départements continuent d’utiliser des solutions internes. Il est alors nécessaire de consolider les données de façon transverses entre solutions internes et solution SaaS,
• des processus métiers impliquent des fonctions de plusieurs applications, certaines SaaS d’autres non,
• plusieurs Clouds différents peuvent être utilisés.

Voici deux exemples de processus transverses rencontrés sur le terrain :

• le traitement d’une commande implique à la fois les solutions de gestion client (CRM), les solutions de ressource planning (ERP) en usine, et la solution de Product Lifecycle Management (PLM)
• la mise en place d’une Bill Of Material utilise un processus entre le PLM et les ERP en usine.

L’utilisation d’applications SaaS intégrées avec des applications en interne nous ramène au sujet classique : l’architecture d’entreprise du système d’information. Les différentes applications doivent pouvoir :

• communiquer entre elles,
• évoluer indépendamment les unes des autres,
• fournir des éléments de pilotage,
• sans oublier les questions de sécurité et de qualité de service.

Sur tous ces sujets la DSI doit être impliquée, que les applications soient dans le Cloud ou non. Le Système d’Information devient un système hybride, avec des fournisseurs internes, externes en hébergé, et externes dans des Clouds différents.
Dans l’univers du Cloud il n’y a pas de standard unique : les mécanismes de communication, les modèles de sécurité, les modèles de données, les sémantiques des objets diffèrent suivant les fournisseurs. Les standards techniques y sont nombreux.
Le risque est donc grand de reproduire sans y prendre garde un des travers classiques de l’architecture d’entreprise : l’introduction d’un nouveau silo. Si l’on multiplie ceci par le nombre d’applications SaaS utilisées, avec la facilité initiale de mise en œuvre inhérente, on comprend pourquoi la DSI doit prendre le sujet à bras le corps.
Avant de s’embarquer « in the large » dans le monde SaaS, il est primordial d’établir une vision et une stratégie unifiant la prise en compte des applications SaaS et internes. Sinon assez vite les objectifs ciblés en terme d’agilité et de réduction de coût attendus du Cloud se transformeront dans les faits en accroissement de la complexité d’évolution, et en accroissement de coûts de maintenance et d’administration.
L’approche standard pour traiter des architectures d’applications d’entreprise s’applique :

• Isoler les composants, ne pas réaliser d’intégration point à point, passer par un système de médiation,
• Mettre en place un couplage faible entre les différents composants de l’architecture, les isolants les uns des autres.
• Utiliser des interfaces stables
• Ne pas gérer d’état entre les différents composants

 
Une couche d’intermédiation entre tous les composants applicatifs prendra en charge une grande partie de cette approche. C’est justement ce que permet de faire le produit middleware « Oracle SOA Suite ».
 
L’approche de plusieurs de nos clients est de commencer par mettre en place la couche SOA, puis ouvrir vers le SaaS.
 
 
En conclusion de ce billet, un focus sur deux points forts de Oracle SOA Suite qui facilitent l’ouverture du SI vers le SaaS :

• La virtualisation de service. Elle permet de remplacer relativement facilement un fournisseur de service par un autre, par exemple dans le Cloud. Le service utilisé n’est pas appelé directement, mais passe par l’intermédiaire du bus SOA. Changer de fournisseur de service n’a pas d’impact sur l’utilisateur de service. Le bus prend à sa charge l’appel du bon service web, ainsi que les transpositions nécessaires, la nouvelle API utilisée pouvant être différente.

• La sécurité. Oracle API Gateway contrôle comment les composants et utilisateurs du SI sont exposés à l’extérieur. Il permet de mettre en place des stratégies d’autorisation et d’authentification des services web, découplées de la mise en œuvre de ces services. Cela permet d’appliquer ces stratégies aux services en internes et aux services dans le Cloud, d’une façon cohérente, en extension des solutions de sécurité déjà déployées (Oracle SOA Security and Access management).