Description du pattern

Le principe du pattern “OpenAPI” consiste à développer et exposer des services utilisables par des tiers, sans avoir d’idée préconçue sur l’usage qui en sera fait.

Le développement porte donc essentiellement sur la logique applicative et le système de persistance. L’interface et la logique métier seront développées par des tiers, peut être plus experts dans les technologies d’interface et les problématiques ergonomiques, des métiers spécifiques, etc. (dans ce sens, voir l’histoire de l’écosystème Twitter à cette adresse).

(Lire la suite…)

Description

En informatique, nous connaissons tous des citations qui rappellent l’importance de la mesure : « Ce qui ne se mesure pas, ne se pilote pas », « sans mesure, tout n’est qu’opinion ».

Les grands du web ont poussé cette logique à l’extrême et ont, pour la plupart, développé une culture poussée de la mesure.

(Lire la suite…)

J’entends souvent la question suivante : L’architecture d’entreprise (EA) doit-elle être centrée sur la vision Métier ou Technologique ?

On parle aujourd’hui de plus en plus régulièrement d’architecture Business et on réalise facilement l’amalgame avec l’EA.

L’architecture Business n’est qu’un domaine de l’architecture d’entreprise qui, pour reprendre la définition donnée par TOGAF, en comporte quatre (Business, data, application, technology). Elle adresse la stratégie Business, l’organisation, les Business process clés et les interactions entre ces éléments. L’architecture d’entreprise adresse également la couche technologique permettant de supporter l’architecture Business.

La notion de capacité (capability) que l’on retrouve dans TOGAF est ici intéressante :
(Lire la suite…)

Cet article fait partie d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé, expliquer les enjeux d’un tel système et nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance. Nous nous attacherons à étayer nos explications de retours d’expériences.

• Les systèmes mutualisés : enjeux et risques
• Les systèmes mutualisés : comment réaliser une gouvernance efficace
• Les systèmes mutualisés : démarrer et ne pas se perdre

Evaluer l’opportunité de lancer un projet de mutualisation et définir le périmètre d’un tel système n’est pas simple et doit faire l’objet d’une analyse en amont qui prend en compte plusieurs variables comme la valeur métier/sectorielle, l’homogénéité des processus dans les entités, etc. Dans ce contexte, l’article part de l’hypothèse que l’opportunité de mutualiser les processus de plusieurs entités de l’entreprise a été identifiée et que la décision de construire un système mutualisé est prise.

Pour réussir à mettre en place un système mutualisé, il faut non seulement réfléchir aux contraintes intrinsèques de la solution mutualisé mais aussi à celles liées au contexte de l’entreprise et à son organisation. Ceci dans le but de concevoir une solution unique faisant converger les processus tout en offrant suffisamment de souplesse pour permettre la subsidiarité nécessaire à chaque entité.

La construction d’un tel système représente un vrai challenge et un jeu de forces qui n’est pas simple à gérer. Néanmoins le projet peut être mieux maitrisé si dès le démarrage nous prenons en compte les éléments suivants :

• Définir le modèle de production et développement
• Définir la frontière entre le cœur et le spécifique
• Définir le niveau de mutualisation
• Concevoir un produit adapté pour maitriser la part du spécifique
• Assurer l’intégration dans des environnements divers
• Adopter une démarche itérative et incrémentale

(Lire la suite…)

Introduction

Cet article est le deuxième d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé, expliquer les enjeux d’un tel système et nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance. Nous nous attacherons à étayer nos explications de retours d’expériences.

(Lire la suite…)

Cet article est le premier d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé et les enjeux d’un tel système, donner nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance.

Les systèmes mutualisés : définition

Un système mutualisé est un système implémentant des processus et des fonctions communes à plusieurs entités. Ainsi, des systèmes multi-entité, multi-pays, multicanal de distribution à destination de populations d’utilisateurs différentes et multi-ligne de marché sont des systèmes mutualisés. Par exemple, les systèmes suivants sont des systèmes mutualisés :

• En assurance : un système multi-ligne de marché de gestion des remboursements santé pour les assurances individuelles et les assurances collectives
• En banque : un système multi-pays de gestion des contrats commun à la France, l’Espagne et la Pologne
• En distribution : un système multi-ligne de marché et multi-pays d’encaissement, commun à des petites, grandes surfaces et magasins discount et installés sur l’ensemble de l’Europe
• En télécommunication : un système multicanal de souscription de contrat utilisé en boutiques, par les conseillers téléphoniques et par les internautes
• En industrie : un portail client multi-ligne de marché et multi-pays, commun à l’ensemble des divisions d’un grand groupe industriel

La problématique des systèmes mutualisés a déjà été abordée par OCTO lors de l’Université du SI : Les SI multi-entité.

(Lire la suite…)

Description

Un Minimum Viable Product (Produit minimal viable), abrégé en MVP, est une stratégie de développement de produit. Eric Ries, qui a fortement contribué à développer cette approche ainsi que le Lean Startup, nous en donne la définition suivante : «  le MVP est la version d’un nouveau produit qui permet à une équipe de collecter sur les clients  early adopters le maximum d’enseignements validés, et ce avec un minimum  d’effort »[1] .

En résumé il s’agit de réaliser rapidement un prototype de produit minimal, afin de vérifier l’existence d’un besoin, d’identifier le marché associé, et de valider les hypothèses business telles que la rentabilité.
(Lire la suite…)

C’est drôle, on sait tous qu’il n’y a pas, en informatique, de « silver bullet ». L’idée qu’une solution technique va tomber du ciel — ou du carquois d’un consultant — relève du voeu pieu, du deus ex machina, voire de la pensée magique.

Vous n’avez probablement pas obtenu vos diplômes parce que soudain quelques jours avant l’épreuve, vous avez trouvé LA technique idéale de mémorisation.

Vous savez que, statistiquement, l’EuroMillion n’enrichit pas ses clients (sinon les riches joueraient à l’EuroMillion).

Mais si vous êtes développeur, chef de projet, directeur d’études ou DSI, en revanche, vous êtes déjà probablement tombé dans le piège d’un nouvel outil ou d’une nouvelle technologie en vous disant : « Cette solution innovante va probablement marcher; en tout cas il le faut absolument (ou: en tout cas j’en ai vraiment envie). Je signe. »
(Lire la suite…)

Agile comme Lean partagent un objectif : réduire les temps de cycle. Or, livrer une version en production est souvent une opération chère. L’objectif de la livraison continue est de réduire au maximum ce coût. Jez Humble, de ThoughtWorks, a donné une formation jeudi 30 juin sur le sujet de la livraison continue. En voici les points clés.

(Lire la suite…)

Nous vous proposons ici de découvrir quelques aspects du lean en citations. Ces citations sont importantes, car pendant une expérimentation lean, elles amélioreront la compréhension et l’apprentissage des pratiques et outils lean. Elles agiront comme des moyens mnémotechniques en plaçant des refrains à nos chansons lean du quotidien.

Pour une présentation du lean, je vous conseille la lecture de cet article introductif : « Qu’est-ce que le Lean? ». J’aborde ici les principes et outils lean suivants :

• Le respect des gens
• L’élimination du gaspillage sur le flux de valeur
• L’amélioration continue

(Lire la suite…)