RFI Demande d information Réf. : RFI_OMAT_final.doc DIT - SIAM Page 1/14 Request For Information - Outil de Modélisation des ArchiTectures
SOMMAIRE 1. OBJET DE LA DEMANDE D INFORMATION... 3 2. PÉRIMÈTRE DE L INFORMATION... 3 2.1. PÉRIMÈTRE TECHNIQUE... 3 2.1.1. Fonctions attendues... 3 2.1.2. Caractéristiques générales... 6 2.2. PÉRIMÈTRE DE L EXPLOITATION... 6 3. RÉPONSES AUX QUESTIONS... 6 3.1 CONSTITUTION DES DOSSIERS DE PRÉSENTATION... 6 3.2 CONTACTS CHEZ LE POUVOIR ADJUDICATEUR... 6 4. DIVERS... 6 4.1 PROTECTION DES RÉPONSES... 6 4.2 RÉMUNÉRATION DES RÉPONSES... 6 ANNEXE 1 :... 7 ANNEXE 2 :... 9 ANNEXE 3 :... 10 EXEMPLES DE DIAGRAMMES D ARCHITECTURE... 10 SAT : 10 Tableau des composants :... 10 SATD :... 12 DSD (schémas réseaux) :... 13 Diagramme UML (modélisation applicative) :... 14 2/14
La présente Demande d Information (DI) ne constitue ni une consultation, ni un appel d offres, ni un quelconque engagement de l administration à lancer ultérieurement une opération sur le même objet. Réciproquement, les réponses à la DI ne constitueront pas des engagements contractuels ou précontractuels de la part de leurs auteurs. Pour des raisons de compréhension, il est dénommé «la société», ci-après dans la DI, les candidats y répondant. 1. Objet de la demande d information La présente demande d information (DI) se place dans le cadre d analyses préliminaires conduites par la Banque de France (la Banque) en vue d industrialiser les processus d élaboration des schémas d architectures informatiques, et de mettre en place un référentiel de partage. Les services informatiques de la Banque de France souhaitent disposer d un outil de cartographie et de modélisation des architectures applicatives et techniques. Cet outil devra améliorer la qualité des modèles tout en garantissant la cohérence des données partagées. L outil devra être basé sur un référentiel de partage regroupant toutes les données et les briques techniques utilisées par les équipes. 2. Périmètre de l information Afin de permettre une utilisation optimale des informations recueillies, les volets 1 et 2 appelés en annexe devront être complétés de tous les renseignements utiles à caractère technique, financier et juridique. 2.1. Périmètre technique L évolutivité de la solution sera un point clé du choix, le nouvel outil devra être en mesure de s adapter aux besoins spécifiques de la Banque de France. L outil permettra d industrialiser la modélisation des architectures et faciliter le passage des vues métiers aux vues applicatives et techniques. 2.1.1. Fonctions attendues Les fonctionnalités attendues pour le nouvel outil sont présentées en deux parties : - les besoins des architectes techniques - les besoins des architectes applicatifs - les besoins communs Le tableau suivant décrit l ensemble des besoins et fonctionnalités attendues par l outil : 3/14
Réf. Besoins Description de la fonctionnalité Besoins spécifiques pour la modélisation technique FT1 Disposer d un référentiel de partages des briques techniques. L outil devra fournir une bibliothèque des briques techniques validées et réutilisables par les architectes. FT2 Contrôler formellement l architecture. L outil devra accéder en lecture uniquement à la CMDB de la banque pour contrôler formellement l architecture. Le but est d identifier les écarts entre les composants à déployer tels que décrits dans le schéma d architecture et ceux véritablement déployés dans l architecture technique de production finale. FT3 Partager l information. L outil sera utilisé par les architectes (Systèmes et Réseaux). Il devra donc leur faciliter le travail tout en séparant les vues de modélisation (vue de l infrastructure des serveurs et vue de la topologie réseau). FT4 FT5 FT6 Générer des documents d architecture techniques (SAT, SATD, DSD). Rétro documenter les évolutions techniques. Garantir la cohérence des données dans les rapports et les documents rédigés. L outil facilitera la réalisation des diagrammes d architecture techniques (Cf. Annexe1) tout en assurant la cohérence des données décrites dans les schémas et dans les tableaux (idéalement via la production automatique des tableaux en fonction des schémas modélisés). L outil prendra en compte les évolutions techniques engendrées par la modification d un composant, dans toutes les architectures impactées. Faciliter la mise à jour des documents lors d une modification d une donnée ou d un modèle d architecture. FT7 Suivre les modifications. Les modifications réalisées sur les données du référentiel et les documents d analyse devront être suivies ( versioning des documents). 4/14
Besoins spécifiques pour la modélisation applicative FA 1 Construire des modèles Merisiens et UML. Diagramme d états, de séquence, modélisation XML Schémas, web service. FA 2 Modéliser des SAA. Shémas d Architecture Applicative. FA 3 FA4 Modéliser des Framework architecturaux. Modéliser du packaging et du déploiement de logiciel. FA5 Générer du code. Capacité de l outil à générer du code compilable, en fonction de la modélisation des schémas et diagramme décrits en FA1, FA2, FA3 et FA4. Besoins communs FB1 FB2 FB3 Disposer d une interface Ergonomique. Gérer une forte Volumétrie. Disposer d un moteur de recherche. Capacité de l outil à masquer les fonctionnalités non utilisées. Le temps de réponse de l outil devra être comparable aux outils bureautiques. Capacité de l outil à gérer un gros volume de données et de schémas dans sa base de données. L outil doit fournir une interface permettant la recherche des informations en base de données. FB4 Gérer des alertes. L outil doit lever une alerte automatiquement en cas d une incohérence (par exemple un changement X a provoqué l incident Y). FB5 Importer et exporter des données. L outil doit permettre de récupérer les données des outils bureautiques (Word, Visio, xls, XML) et idéalement de sauvegarder dans ces formats. FB6 Reprendre l existant. L outil doit pouvoir récupérer les diagrammes actuels rédigés sous VISIO et POWERPOINT. FB7 Administrer l outil finement. Possibilité d attribuer des droits d utilisation et un espace de travail pour chaque utilisateur /groupes d utilisateurs. FB8 Construire et modifier le méta-modèle. Possibilité de visualiser l enrichir. le contenu du méta-modèle et de FB9 Suivre les méthodologies standards. L outil devra intégrer des méthodologies et standards de modélisation des SI (togaf, Archimat, etc.). 5/14
L offreur ou l éditeur de la solution devra s engager à répondre à toutes les fonctions en précisant si sa solution est compatible ou non avec chaque fonctionnalité. 2.1.2. Caractéristiques générales La solution présentée par le candidat devra permettre de répondre à toutes les fonctionnalités décrites dans le tableau précédent. L offreur devra détailler les modules qui permettent de traiter chaque fonctions en précisant les moyens d organiser et de structures le méta modèle et les rapports d analyse. 2.2. Périmètre de l exploitation La solution devra être disponible pour les utilisateurs et administrable par la banque de France aux heures de travail standards. Idem pour le service du support. 3. Réponses aux questions La Banque attire l attention sur l importance de remplir l ensemble des volets du périmètre d information et de les retourner conformément aux indications contenues au paragraphe 3.1, cidessous. Les auteurs des réponses devront fournir des exemples de diagramme et pourront être invités à présenter oralement leurs réponses. 3.1 Constitution des dossiers de présentation Les dossiers de présentation doivent contenir : Une plaquette(s) de/des auteurs répondant à la DI, présentant l activité principale et la dimension de l entreprise(s), ses partenaires et clients dans la mesure du possible ; Les volets de réponses au périmètre de l information : La Banque accepte tout autre document qui pourrait présenter un intérêt pour la réalisation de son étude. Il est souhaitable que les sociétés rédigent en français leur réponse à cette DI. Les propositions, ainsi que toutes questions éventuelles, devront parvenir par courrier électronique adressé à la boîte achats_informatiques@banque-france.fr. 3.2 Contacts chez le pouvoir adjudicateur Pour toute information complémentaire à la présente DI veuillez contacter par courrier électronique : achats_informatiques@banque-france.fr. 4. Divers 4.1 Protection des réponses Il appartient à la société questionnée de mentionner le cas échéant les informations contenues dans sa réponse devant être protégées par le secret commercial. 4.2 Rémunération des réponses Les sociétés répondant à la DI ne peuvent prétendre à aucune rémunération pour les prestations réalisées pour l établissement de leurs réponses. 6/14
Annexe 1 : Demande d information concernant l outil de modélisation des architectures VOLET 1 ASPECTS TECHNIQUES Merci de bien vouloir renseigner le tableau et répondre aux questions suivantes : Réf. Questions Réponses de l offreur P01 P02 P03 P04 Présenter les solutions permettant la communication entre l outil et la CMDB. Dans l hypothèse où la solution que vous proposez repose intégralement ou en partie sur un développement spécifique, pouvez-vous préciser l ampleur des développements à prévoir (pour chacun des volets technique, applicatif et commun)? En tenant compte des fonctionnalités définies dans le chapitre 2, donner une estimation de coût en jours/homme pour l organisation d un méta modèle et la définition d un référentiel de partage. Lister le taux de couverture des besoins de chaque volet (technique, applicatif et commun). P05 P06 P07 P08 Dans quelle mesure l offre facilite le rapprochement des vues (système, réseau, applicative)? Quelle est la capacité de l outil pour la production des rapports d analyse et le stockage des modèles d architectures? Comment peut-on personnaliser les rapports d analyse et le méta modèle? En tenant compte des diagrammes d architectures techniques fournis en annexe, dans quelle mesure l offre permet de modéliser ce type de schémas? Il est souhaitable de pouvoir décrire les types d objets techniques et flux réseaux existants dans le référentiel standard de l outil. 7/14
Dans le tableau ci-dessous, indiquer les fonctionnalités de base fournies par la solution proposée : Repère Fonctions Satisfaite FT1 Un référentiel de partages des briques techniques Non satisfaite Variante / écarts FT2 FT3 FT4 FT5 FT6 FT7 FB1 FB2 FB3 FB4 FB5 FB6 FB7 FB8 FB9 Interfaçage avec la CMDB Partage de l information Génération des documents d architecture techniques SAT, SATD, DSD Retro documenté les évolutions techniques Garantir la cohérence des données dans les rapports et les documents rédigés Traçabilité de modification Ergonomie Volumétrie Moteur de recherche Gestion des alertes Import et export des données Reprise de l existant Administration de l outil Construction et modification du méta modèle Bonnes pratiques méthodologiques 8/14
Annexe 2 : Demande d information concernant l outil de modélisation des architectures VOLET 2 ASPECTS FINANCIERS 1 VENTILATION DES PRINCIPAUX POSTES DE COÛTS Les informations demandées dans ce paragraphe sont destinées à permettre l'évaluation du coût global au travers d'une décomposition analytique de coûts. Il est souhaitable de renseigner les rubriques suivantes de la façon la plus exhaustive possible. Les données à fournir pour les différentes rubriques sont des coûts ou des informations permettant d'estimer les coûts. 2.1 Estimation des coûts d'acquisition L outil sera utilisé par les différents services informatiques (50 personnes) de la Banque et selon les besoins spécifiques de chaque entité. L offreur fournira une estimation: Des prix des licences (fixes et flottantes) de chaque module de la solution y compris les modules d administration et de génération des rapports d analyse. De la durée de la prestation pour la mise en place du référentiel et l interfaçage avec la CMDB Des prix de la prestation et des services du support Du coût d hébergements de la solution sur le site de la Banque de France (serveurs, BDD) 9/14
Annexe 3 : Exemples de Diagrammes d architecture SAT : Tableau des composants : <Type de serveur> <Nom du serveur> <Localisation du serveur> Composants Versions Commentaires Système d exploitation Unix Standard BDF SGBD Oracle 10g R2 Standard BDF Application MonAppli Interfaces réseau Base MonAppli Ethernet, carte ILO, interface d administration, etc. 10/14
<Type de serveur> <Nom du serveur> <Localisation du serveur> Composants Versions Commentaires Système d exploitation Windows 2003 SP2 Domaine : INTRA Standard BDF Outil Sun JDK 6.0 update 14 Application JEE Struts Hibernate Composant open source Apport du projet Développement Composant open source Composant open source Application MonAppli Ordonnancement / planification Partage JDBC Oracle (OJDBC) JBoss 5.0.1 GA (+ JBossWeb2.1.2) Batchs Java Hibernate JDBC Oracle (OJDBC) Client Autosys 4.5 AU_PARTAGE Composant open source Embarqué dans l application Développement Composant open source Standard BDF 11/14
SATD : 12/14
DSD (schémas réseaux) : Architecture logique Schémas d architecture fonctionnelle 13/14
Diagramme UML (modélisation applicative) : EST CONSTITUE DE DOSSIER DE COLLECTE EST DE TYPE DE SUPPORT TYPE DOSSIER COLLECTE SUPPORT DE COLLECTE EST CONSTITUE DE POSTES ELEMENTAIRES POSTE DE COLLECTE DEFINIT UN POSTE DE COLLECTE EST COMPOSEE DE PO STES ELEMENTAIRES POSTE ELEMENTAIRE DE COLLECTE COMPARE POSTE DE REFERENCE 2,2 2,n POSTE CALCULE REGLE DE CONTROLE A POUR OPERANDE A POUR OPERATEUR EST CALCULE POUR S APPLIQUE A POUR OPERATEUR DE COMPARAISON OPERATEUR POSTE DESCRIPTIF POSTE COMPTABLE COLLECTE FAIT REFERENCE V ALEUR COLLECTEE FAIT REFERENCE DONNEE CALCULE E POSTE DONNEE INDIVIDUELLE DEVISES POSTE SECTORIEL SOUS FAMILLE DE BILAN ACTIVITE INSEE APPARTIENT FAMILLE DE BILAN CATEGORIE DE BILAN A POUR CATEGORIE DE BILAN FAIT REFERENCE POSTE DESCRIPTI F BILAN SOCIAL BILAN PARTIEL BILAN BILAN AGREGE EST EXPRIME EST RELATIF A EXERCICE BILAN DE GROUPE A POUR SOUS FAMIL LE D'ORIGINE EXERCICE COMPTABL E ENTITE JURIDIQUE ENTITE PARTIELLE A POUR ACTIVITE PRIN CIPALE DECLAREE CONCERNE ENTITE ECONOMIQUE ENTITE AGREGEE A POUR ACTIVITE B DF A POUR COMPTOIR GESTIONNAIRE UNITE ADMINISTRATIVE A POUR COMPTOIR COMPETENT ENTITE DE GROUPE BILAN CONSOLIDE BILAN COMBINE ENTITE COMBINEE ENTITE CONSOLIDEE 14/14