Cadre de référence ITA&S-F

Nous avons créé le cadre ITA&S (ITA&S-F) pour les raisons suivantes :

• Pour mieux intégrer les aspects affaires aux aspects TI, par exemple, nous utilisons les dimensions d'affaires pour :
  • Définir un périmètre pour les feuilles de route (roadmaps)
  • Qualifier les métriques/KPI qui sont utilisées pour surveiller si les processus atteignent leur objectif
  • Supporter le modèle de données dimensionnelles d'entreprise
  • Exemples de dimensions d'affaires : organisation, industrie, emplacement, rôle, produit, service, segment et canal
• Se concentrer sur un nombre limité d'artefacts AE puisque les architectes d'entreprise n'ont pas sufffisament de temps pour maintenir les 50+ artefacts définis dans TOGAF et être en mesure de prendre en charge les offres AE (voir les offres AE ci-dessous)
  • Les artefacts AE sont appelés produits persistants AE car leur cycle de vie est très long par rapport aux offres AE qui sont basées sur les demandes ponctuelles.
• Ces produits persistants AE doivent être maintenus dans un outil AE, et le rôle principal de ces outils AE est de maintenir les relations et les cartographies de tous ces objets
• Puisque que nous avons créé de nouveaux aspects architecturals tels que la Dimension d'affaires, nous avons dû créer un métamodèle pour prendre en charge les spécificités de l'ITA&S-F. Nous avons donc décidé d'implémenter le métamodèle ITA&S-F dans Casewise.
• Pour faire la différence entre les dépendances de projets et les dépendances d'architecture
  • L'ITA&S-F maintient les dépendances d'architecture et associe les objets d'architecture versionnés aux programmes et projets
  • Ce découplage permet de garder les feuilles de route de l'architecture totalement insensibles aux changements de calendrier ou de portée des programmes/projets
  • L'objet d'architecture versionné (représentant un changement architectural) est associé à des programmes/projets
  • Ainsi, lorsque la portée d'un programme/projet change, l'objet d'architecture versionné doit simplement être réaffecté à un autre programme/projet
  • Cette approche permet de surveiller lorsque les décisions de programme/projet en silo empêchent d'atteindre les objectifs de l'entreprise puisque tous les objets d'architecture versionnés sont liés aux objectifs de l'entreprise
  • Ce découplage des dépendances architecturales avec les programmes/projets a également été intégré dans le métamodèle ITA&S-F dans Casewise pour simplifier la maintenance des roadmaps d'architecture.

Nous aimons voir les groupes d'architecture d'entreprise être structurés en pratiques AE et, par conséquent, la pratique AE maintient une offre de services/produits AE à la disposition de ses clients d'affairess. Il est donc impératif de maintenir un ensemble minimal de produits persistants afin d'être prêt lorsqu'une conseil/recommendation est demandée. Ces demandes sont les offres AE. Les offres EA ont une valeur directe pour l'entreprise, il peut s'agir :

• Opinions sur ce que l'entreprise devrait faire pour se rajeunir
• Plans (feuilles de route)
• Soutien à l'analyse de rentabilisation
• Planification budgétaire informatique pour les portefeuilles d'applications
• Recommandation de logiciel/produit
• Évaluations
• Conseils sur l'architecture de la solution
• Conseil sur le volet informatique d'une fusion et acquisition
• ...

Lorsqu'il y a une demande pour ceux-ci, il n'y a pas de temps disponible pour mettre à jour les produits AE persistants tels que la liste des applications, les processus métier, les modèles de données, etc. Cette approche (offre de services AE et produits persistents AE) pourrait être utilisée sur des frameworks populaires tels que TOGAF, FEA et autres. .