Archives de Catégorie: Architecture applicative

Profitons de l’Open Source…

Avant de parler des stratégies et des tactiques observées, il faut bien se remémorer les trois besoins fondamentaux des DSI : la maîtrise du risque, la maîtrise du coût et la gouvernance. Sur chacun de ces axes, le libre apporte un élément de réponse. C’est en fonction de la criticité du besoin et de la pertinence de la réponse que le libre se diffuse au sein des entreprises et des administrations.

En matière de risque, la première préoccupation des DSI est celle du support et de la pérennité. C’est encore une interrogation soulevée par l’Open Source. D’où le rôle croissant que jouent les prestataires de services spécialisés, qu’il s’agisse d’éditeurs, de distributions, de SS2L, ou d’intégrateurs, qui ont l’avantage d’offrir un service global. C’est aussi une raison pour laquelle les «modèles de maturité Open Source» se développent. Ils ont pour ambition d’aider les entreprises à évaluer chaque composant libre envisagé et à mesurer leur capacité d’intégration dans leur système d’information. Pour la DSI, le critère essentiel à prendre en compte reste donc surtout la disponibilité de prestataires de services fiables.

En matière de maîtrise des coûts, la préoccupation des DSI ne concerne pas uniquement l’achat initial. Elle intègre les coûts de déploiement et d’appropriation, puis les coûts réguliers de mise à jour, alors qu’un éditeur poussera régulièrement aux changements de version pour vendre des extensions et de nouvelles fonctionnalités, l’entreprise est beaucoup plus libre de ses évolutions. Le coût d’évolution est mieux maîtrisé. Il est important de comprendre qu’au-delà des économies, l’Open Source permet à un DSI de maîtriser, de piloter ses coûts, à son rythme, à son échelle.

Enfin, en matière de gouvernance, l’entreprise souhaite souvent bénéficier du maximum de liberté, de souveraineté et rester dans un environnement standard. L’intégration est possible parce que les composants Open Source sont les moteurs des standards. Leur différenciation ne se joue pas dans leur incompatibilité, mais bien plutôt dans la qualité des développements, l’innovation qu’ils apportent et leur capacité à être interopérables, à jouer en équipe en quelque sorte.

Deux grandes approches : le « cherry picking » et le « sourcing stratégique »
Le « cherry picking » est clairement une stratégie opportuniste, au niveau d’un service ou d’un département. C’est d’ailleurs souvent par le « cherry picking » que le libre est rentré dans l’entreprise : pour des besoins ponctuels, un développeur ou un responsable informatique prend au cas par cas des composants Open Source. Soit pour bâtir une nouvelle application. Soit pour réduire le coût d’exploitation d’une solution existante (adoption du serveur http d’Apache, remplacement d’un serveur d’application ou d’une base de données propriétaire par du libre, etc.).

Le sourcin stratégique, plus avancée, est le fait des DSI qui s’approprient le phénomène Open Source et intègrent pleinement son usage au sein de la plate-forme technique de l’entreprise. Cette stratégie concertée a souvent deux origines.

Elle peut résulter d’une volonté d’industrialisation, suite à la multiplication des composants utilisés en mode tactique : une fois le libre largement utilisé, de manière un peu anarchique (surtout pour des raisons de coûts), le management se saisit du sujet et décide de rationaliser et d’industrialiser son emploi, passant ainsi d’ailleurs de la maîtrise du coût à celle du risque et à la gouvernance. C’est une raison pour laquelle le sujet remonte au sein des Directions Générales de Systèmes d’Information. Celles-ci inscrivent alors l’Open Source dans une vision stratégique. Elles demandent aux architectes d’introduire des composants Open Source dans le schéma d’architecture global et de prendre en compte quelques axes de déploiement de logiciels Open Source, dans des segments pertinents du schéma d’architecture.

Publicités

Une approche holistique s’impose

La SOA, approche architecturale d’une problématique plus vaste, n’est qu’une partie de la réponse, et ne peut donc être abordée seule. Un projet SOA doit s’inscrire dans la stratégie que l’entreprise soutient grâce à une architecture claire, souple et réactive. La SOA est donc un moyen, et non une fin en soi. Un projet SOA géré comme un projet informatique banal est voué à l’échec. Un échec mortel, car il n’existe pas de deuxième chance de convaincre l’ensemble des directions générales, financières et métier de révolutionner encore l’architecture du SI. Une SOA mal née et mal gérée risque de rigidifier ce qui doit être assoupli et de complexifier ce qui doit être simplifié.

%d blogueurs aiment cette page :