Pourquoi les cas d'utilisation de l'architecture d'entreprise sont importants
Trop d'équipes d'architecture d'entreprise ont du mal. quand nous développer des équipes d'architecture d'entreprise, nous commençons par la meilleure pratique claire et demandons, "pour quel changement les parties prenantes veulent-elles de l'aide ?"
Nous nous concentrons sur les cas d'utilisation, car l'activité de base architectes d'entreprise effectuer est le même. Nous développons un l'architecture d'entreprise qui aide les parties prenantes à prendre de meilleures décisions et à mener des initiatives de changement réussies. C'est pourquoi nous pouvons avoir la base universelle de la Norme TOGAF.
Nous faisons les mêmes choses. La seule différence est la question à laquelle nous répondons. Différentes questions signifient que nous analysons différentes choses, avec différents problèmes de base.
Lorsque nous connaissons le cas d'utilisation, nous pouvons concevoir l'équipe d'architecture d'entreprise. Ensuite, nous pouvons développer l'équipe d'architecture d'entreprise. Pendant le développement de l'équipe, vous devez récolter de la valeur.
Architecture d'entreprise Cas d'utilisation Décrire les types de changement
Nous utilisons la classification suivante pour décrire les cas d'utilisation de l'architecture d'entreprise. Premièrement, il y a les grands types de changement. Deuxièmement, les modèles TOGAF des équipes d'architecture d'entreprise performantes. Troisièmement, les problèmes courants sur lesquels il vaut la peine de concentrer une équipe d'architecture d'entreprise.
Grands types de changement Cas d'utilisation de l'architecture d'entreprise
Cas d'utilisation d'un changement stratégique ou perturbateur
Cas d'utilisation de changement incrémentiel
Cas d'utilisation du modèle d'équipe d'architecture d'entreprise
Cas d'utilisation de l'exécution de la stratégie de soutien
Prise en charge du développement et de l'exécution du portefeuille Cas d'utilisation
Cas d'utilisation de soutien à l'exécution de projet
Prise en charge du cas d'utilisation de la livraison de solutions
Cas d'utilisation courants de l'architecture d'entreprise
Atténuation des risques technologiques
Rationalisation du portefeuille d'applications
Développez votre équipe d'architecture d'entreprise avec des cas d'utilisation d'architecture d'entreprise
La troisième étape du développement de votre équipe d'architecture d'entreprise consiste à savoir quel type de changement votre entreprise attend de vous. Ce que vous pourriez faire n'a aucune importance. Ce que vous pensez être précieux n'est pas pertinent. Ce qu'un expert suggère, c'est que la "meilleure équipe EA" n'est pas pertinente. Malheureusement, la plupart modèles de maturité de l'architecture d'entreprise suggérer un « meilleur but ». Alignez votre équipe EA sur les cas d'utilisation appréciés par votre entreprise.
Grands types de changement Cas d'utilisation de l'architecture d'entreprise
Une entreprise devra changer de deux manières, de manière perturbatrice ou progressive.
Le changement perturbateur sera délibéré ou réactif. Soit l'entreprise se lancera dans une initiative stratégique délibérée, soit elle réagira à une menace ou à une opportunité dans son écosystème. Lorsque nous procédons à un changement perturbateur délibéré, nous l'appelons généralement Changement stratégique.
Lorsqu'une entreprise s'embarque dans un changement perturbateur, elle lutte pour sa survie.
Le changement progressif est beaucoup plus courant. Des centaines, voire des milliers de fois plus fréquents. La raison est simple. La plupart du temps, nos organisations réussissent. Nous sommes rentables. Dans le secteur public, nous nous acquittons de notre mandat. Pendant le changement incrémentiel, nous effectuons des corrections de cap mineures. Une partie des organisations d'amélioration continue le font toujours.
Cas d'utilisation d'un changement stratégique ou perturbateur
Mis à part les mots qui nous font nous sentir mieux, tout changement perturbateur signifie que nous changeons de cap pour survivre. Notre organisation est en danger. Nous devons apporter des changements significatifs et durables.
Nous allons changer de cap pour des raisons internes ou en réaction à des forces externes. Le plus souvent, nous réagissons à une opportunité ou à une menace émergente dans notre environnement. Ici, les architectes d'entreprise essaient d'aider à saisir une opportunité ou à esquiver une menace. La capacité à effectuer des changements perturbateurs dépend de votre agilité de l'entreprise.
En bref, un changement stratégique modifie la façon dont une organisation entend engager son environnement. La symbiose de l'organisation et de son environnement force les conversations sur l'environnement.
La mise en œuvre d'un changement stratégique implique d'apporter des ajustements aux caractéristiques clés d'une entreprise, parfois en réponse à de nouveaux risques ou possibilités du marché. Ce changement résulte de la haute direction, en particulier du directeur général. Le processus d'ajustement d'une stratégie est connu sous le nom de transformation stratégique. Une stratégie est un plan à long terme pour atteindre des objectifs spécifiques. Les stratégies doivent se concentrer sur la transformation à long terme puisqu'elles sont tournées vers l'avenir. Pour rester pertinent dans un marché en constante évolution, c'est essentiel. La pratique consistant à gérer la stratégie de manière disciplinée pour atteindre les objectifs et les missions de l'entreprise est connue sous le nom de gestion du changement stratégique.
Le changement stratégique présente quelques inconvénients, notamment sa difficulté à prévoir et à gérer. Pour cette raison, de nombreuses entreprises font des plans pour tous les résultats possibles. La gestion stratégique du changement est cruciale pour la viabilité à long terme d'une entreprise. Les entreprises qui rejettent le changement stratégique finiront par être évincées du marché ; Nokia est un exemple bien connu dans le secteur des smartphones. Les entreprises ne prospéreront pas si elles ne sont pas prêtes pour des changements brusques, imprévus et drastiques. De nombreuses entreprises revendiquent la transformation, mais elles le font rarement.
Les entreprises fondent leurs jugements sur des informations, des faits et des scénarios car elles sont incapables de prévoir l'avenir avec précision. Ces circonstances sont très importantes. Et si ces choses arrivaient ? Comment cela affecterait-il notre fonctionnement ? Trouver une aiguille dans une botte de foin peut sembler être cela, mais de nombreuses grandes entreprises ont résisté aux bouleversements en prévoyant des événements qui pouvaient sembler improbables à l'époque. Cela inclut également la gestion des risques. Si une entreprise prédit que quelque chose se produira dans le futur, elle a deux options : accepter le risque ou diminuer le risque.
Comment nous concevons des équipes d'architecture d'entreprise pour un cas d'utilisation de changement stratégique
La capacité d'architecture d'entreprise la plus critique pour prendre en charge les changements stratégiques ou perturbateurs est de pouvoir se développer Feuilles de route d'architecture. En particulier, votre équipe EA doit développer des scénarios de feuille de route et Feuille de route d'architecture de type 4 : analyse de scénarios sur plusieurs candidats.
Nous recommandons le Sept leviers de la transformation numérique pour une compréhension concise du changement numérique perturbateur. Tout changement stratégique modifie l'engagement d'une organisation avec son environnement. Lorsqu'une organisation entreprend une transformation numérique, Levier 7 - Ecosystème et Business Model comprennent la modification de l'environnement.
Enfin, nous savons que l'engagement avec les parties prenantes comprendra l'exploration de l'orientation. En termes de SMA TOGAF, l'équipe explorera plusieurs Visions d'architecture de phase A. Cela nécessitera de doter en personnel des personnes à l'aise avec l'ambiguïté.
Caractéristiques de l'agilité d'entreprise
Vigilance: pouvez-vous détecter les opportunités et les menaces ?
Accessibilité: pouvez-vous accéder aux informations pertinentes à temps pour répondre ?
Décisivité: pouvez-vous prendre des décisions en utilisant les informations disponibles ?
Rapidité: pouvez-vous mettre en œuvre vos décisions dans le temps disponible ?
La flexibilité: que faites-vous pour réduire les barrières à l'action ? Pensez à votre des exercices d'étirement
Cas d'utilisation de changement incrémentiel
Le changement incrémentiel est le cas d'utilisation le plus courant de l'architecture d'entreprise. C'est un sweet spot naturel pour une équipe d'architecture d'entreprise. S'attaquer à un espace problématique implique généralement d'optimiser le changement. Le décomposer pour fournir les termes de référence des projets de changement et la clarté de la valeur ajoutée.
Un changement progressif est un changement graduel au lieu de changements brusques ou en une seule fois. Vous préférerez les progrès lents et progressifs et l'amélioration avec le changement. Votre approche préférée consiste à innover avec ce qui existe déjà plutôt que de toujours proposer de nouveaux concepts ou d'apporter des changements audacieux et radicaux. Vous apprécierez d'améliorer les points forts actuels et de visualiser les situations à travers la perspective d'améliorations potentielles. Les plans sont simples à diviser en phases et à appréhender lorsqu'ils s'étalent sur des échelles de temps progressives.
Le statu quo peut être modifié, ajusté ou affiné par un processus connu sous le nom de changement incrémentiel, qui n'implique que de petites modifications simples. Compte tenu de cette description, il est essentiel de souligner que cette forme de changement organisationnel, également appelée changement de premier ordre, ne modifie pas les fondamentaux d'une organisation. À plus grande échelle, le changement progressif fait référence à relativement peu de changements apportés aux systèmes, hiérarchies, modèles, biens, services et processus préexistants.
De plus, la transformation incrémentale combine plusieurs traits divers. Cela se produit principalement en une série de petites étapes. Aucune étape du processus ne prend un temps excessivement long, même si elle peut se dérouler sur une longue période. Parfois, les étapes sont planifiées à l'avance, même si ce n'est pas obligatoire. Parfois, lorsque des problèmes se développent et sont résolus en cours de route, ces changements peuvent se produire spontanément et passer inaperçus pour la direction.
La mise en œuvre d'un changement progressif présente divers avantages. Nous l'avons étroitement lié à ceux qui construisent des entreprises prospères qui persistent pendant au moins 10 à 15 ans. Vous ne serez pas paralysé par des pensées grandioses, mais vous ferez réellement les choses, une étape à la fois. Votre bilan parle de lui-même ; votre succès continu est la preuve que tout le monde peut compter sur vous.
En bref, le changement progressif est une priorité stratégique et garantit que le changement est optimisé.
Le plus souvent, un changement progressif améliorera l'un des éléments suivants :
- le coût d'une organisation
- qualité des produits ou des services
- améliorer l'agilité de l'entreprise
Améliorer le coût
Les organisations ont cherché à améliorer leur position en matière de coûts depuis que nous avons des organisations commerciales. le Carte des valeurs de Deloitte fournit un cadre analytique simple pour explorer la réduction des coûts.
Améliorer la qualité
Il existe de nombreuses techniques non architecturales visant à améliorer la qualité, notamment Six Sigma. Aujourd'hui, engager des architectes d'entreprise pour améliorer la qualité signifiera une transformation numérique.
le Sept leviers de la transformation numérique fournit un cadre pour la qualité - parlez-vous de :
- la qualité des processus métiers (Levier 1),
- la qualité de l’engagement client (Levier 2),
- la qualité des produits (Levier 3),
- la qualité si IT & Delivery (Levier 4), ou
- l'impact qualité de votre culture organisationnelle (levier 5)
Améliorer l'agilité de l'entreprise
Les caractéristiques de l'agilité d'entreprise sont tirées du sport et de la boucle OODA. Les activités de réponse à une menace ou à une opportunité inattendue dépendent de votre capacité à observer le changement, à décider quoi faire et à compléter votre réponse. Tous les sportifs qui réussissent travaillent à fermer ces cycles.
On appelle le 5ème attribut de agilité d'entreprise flexibilité en raison de la racine sportive de la Boucle OODA. Les athlètes pratiquent et travaillent sur la flexibilité. Votre organisation devrait faire de même. Réduisez les obstacles à l'observation d'une menace ou d'une opportunité, à la collecte d'informations, au choix d'une réponse et à la réalisation des actions nécessaires.
Toutes les meilleures organisations avec lesquelles nous avons travaillé travaillent consciemment à l'amélioration continue.
Comment nous concevons des équipes d'architecture d'entreprise pour un cas d'utilisation de changement incrémentiel
La capacité d'architecture d'entreprise la plus critique pour prendre en charge les changements incrémentiels est de pouvoir développer Feuilles de route d'architecture. En particulier, votre équipe EA doit développer Feuille de route d'architecture de type 1 : cartes thermiques et Feuille de route d'architecture de type 3 : impact et dépendance.
Le changement progressif dépend entièrement de la capacité d'analyser le changement par rapport à plusieurs critères. Un architecte d'entreprise qui n'est pas à l'aise pour créer Vues est inutile. Le changement incrémentiel nécessite un compromis d'architecture efficace.
Enfin, nous savons que l'engagement avec les parties prenantes comprendra la facilitation du changement et la transition vers la planification du changement avec les sponsors. En termes de SMA TOGAF, l'équipe développera des feuilles de route d'architecture claires. Cela nécessitera de doter en personnel des personnes ayant de solides compétences analytiques et une expérience dans la conduite de changements efficaces.
Cas d'utilisation du modèle d'équipe d'architecture d'entreprise
Le deuxième ensemble de cas d'utilisation d'architecture d'entreprise provient de la objectif de votre équipe EA. Les équipes EA performantes seront optimisées pour fournir une architecture pour soutenir la stratégie, le portefeuille, le projet ou la solution.
J'ai expliqué ces objectifs dans le Guide du chef d'équipe EA et le Guide du praticien de l'architecture d'entreprise.
Architecture d'entreprise pour soutenir le cas d'utilisation de la stratégie
Les équipes d'EA qui soutiennent la stratégie fourniront une architecture cible de bout en bout sur trois à dix ans. Leurs feuilles de route d'architecture couvriront généralement de nombreux programmes de changement.
L'architecture d'entreprise pour soutenir la stratégie est utilisée pour identifier les initiatives de changement et soutenir le portefeuille et les programmes. Établit les termes de référence, identifie les synergies et régit l'exécution de la stratégie via le portefeuille et les programmes.
Architecture d'entreprise pour prendre en charge le cas d'utilisation du portefeuille
Les architectes d'entreprise qui prennent en charge le portefeuille assistent les initiatives de changement interfonctionnelles, multiphases et multiprojets. Leurs livrables couvriront généralement un seul portefeuille.
L'AE pour soutenir le portefeuille identifiera les projets et définira leurs termes de référence, alignera leurs approches, identifiera les synergies et régira leur exécution des projets.
Dans l'économie de marché contemporaine, les entreprises doivent constamment s'adapter pour rester compétitives. Une telle croissance entraîne des modifications dans toute l'organisation à de nombreux niveaux. Les changements doivent être soigneusement planifiés et surveillés au fur et à mesure de leur mise en œuvre. Approche EA et langages de modélisation proposés pour la planification globale et la communication avec les parties prenantes. La gestion de portefeuille de projets (PPM), qui comprend la gestion de programme et de projet, offre une exécution et une livraison des modifications contrôlées.
Étant donné que l'EA et la PPM sont deux approches différentes, il est crucial qu'elles soient entièrement liées à des processus opérationnels coordonnés et efficaces. Leur mise en œuvre combinée doit produire plus de valeur ajoutée qu'elle ne le ferait si elle était effectuée séparément ou sans corrélation.
Peu de ressources sont accessibles pour rechercher l'intégration des champs EA et PPM. Cela peut être dû à une forte relation symbiotique entre ces deux approches. Personne n'a encore étudié à fond la difficulté de leur intégration. Il existe de nombreux cadres qui tentent de traiter presque toutes les facettes de la gestion des changements d'entreprise et informatiques, mais aucun d'entre eux n'a été et ne sera probablement jamais normalisé à l'échelle internationale.
Étant donné que la gestion de projet et de portefeuille n'est pas une gestion du travail axée sur les objectifs, EA ne peut pas l'aborder. Ce que propose EA, c'est une technique qui identifie un certain nombre de modules de travail qui ont été convenus dans l'ensemble de l'entreprise et qui doivent être planifiés, exécutés et livrés par des projets gérés par PPM. La gestion des changements dans l'entreprise au niveau de la structure organisationnelle, du support applicatif, de la structure des données et de l'infrastructure technologique est ainsi assurée conjointement par EA et PPM.
Architecture d'entreprise pour prendre en charge le cas d'utilisation du projet
Les équipes EA qui soutiennent le projet assistent directement la méthode de livraison du projet de leur organisation. Ils travailleront généralement sur un seul projet.
L'architecture d'entreprise pour soutenir le projet clarifiera le but et la valeur du projet. Il mettra en évidence la synergie entre les projets et les dépendances futures. Une utilisation critique permet gouvernance architecturale, et soutenir l'alignement entre les projets.
Les feuilles de route sont produites par EA en tant que produit livrable pour identifier les liens entre les capacités organisationnelles et les objectifs organisationnels. La technique décrit un chemin de la façon dont ces objectifs seront atteints en énumérant divers ensembles de tâches entre les processus existants et les processus ou objectifs de l'état futur, les dépendances et l'analyse des écarts.
Les objectifs élargissent la vision de l'entreprise. Les objectifs sont des repères nécessaires pour réaliser la vision de l'entreprise. Afin de produire une feuille de route exécutable qui garantira la réalisation de la stratégie commerciale, EA encourage également le dialogue et propose un mécanisme entre le bureau de gestion de projet et la direction de l'entreprise. En l'absence d'un département EA au sein d'une organisation, un PMO peut utiliser une analyse métier pour compiler les exigences informatiques qui soutiennent les objectifs commerciaux, en mettant en évidence les intersections potentielles entre EA et le PMO.
L'architecture d'entreprise aide la gestion de projet au niveau de la livraison du projet ou de la solution en spécifiant les lots de travaux qui font partie d'une stratégie de gestion de projet. Pour déterminer ce qui doit être fait pour atteindre les objectifs spécifiés, les équipes de projet consultent un catalogue de lots de travaux. Ces modules de travail facilitent la gestion des ressources, ce qui est important pour la gestion des ressources humaines du projet et l'estimation des ressources de l'activité. Pour exécuter et superviser correctement un projet, les deux sont des éléments cruciaux d'une stratégie de gestion de projet approfondie.
Le bureau de gestion de projet et la direction commerciale consultent l'architecture d'entreprise. En collaboration avec les dirigeants d'entreprise, EA développe une proposition de structure qui comprend toutes les exigences de l'architecture d'entreprise, y compris l'objectif, la vision, la mission, les capacités, les objectifs commerciaux, la portée, le processus et les exigences fonctionnelles.
Architecture d'entreprise pour prendre en charge le cas d'utilisation de la livraison de solutions
Les architectes d'entreprise travaillant pour soutenir la livraison de solutions se concentrent généralement sur un seul projet ou une partie importante de celui-ci. Leur architecture définit la manière dont le changement sera conçu et mis en œuvre. Il assure la compréhension des contraintes, des contrôles et des exigences d'architecture. Il agit directement comme le cadre de gouvernance de l'architecture pour changer.
Les architectes d'entreprise déploient beaucoup d'efforts pour trouver les lacunes architecturales, évaluer les correctifs et les dépendances potentiels, et identifier et hiérarchiser les projets, mais quelque part en cours de route, ils perdent leur concentration. L'architecte d'entreprise est également impliqué dans les architectures de transition, qui montrent comment l'architecture d'entreprise sera dans un certain état à un moment donné et comment le projet fournira progressivement ces architectures de transition.
Avec l'aide de l'architecture d'entreprise, toutes les initiatives reconnues peuvent voir leur valeur commerciale estimée développée. Nous pouvons affirmer que l'achèvement du projet prend du temps, et comme les architectes d'entreprise sont très occupés, ils passent souvent à d'autres tâches urgentes au sein d'une organisation et peuvent ne plus être conscients ou informés des efforts continus. Savoir quels projets se sont terminés avec succès et ont produit des avantages commerciaux, et lesquels ne l'ont pas été, ainsi que les causes potentielles de succès ou d'échec pour la planification future, est utile pour la gestion de portefeuille.
Acceptez les éloges si le projet réussit et produit des avantages, mais s'il y a des revers, examinez les causes et déterminez si le début était imparfait. Les architectes d'entreprise doivent suivre les projets jusqu'à leur achèvement, maintenir des lignes de communication ouvertes avec les parties prenantes de l'entreprise, rester en contact avec les équipes de projet et essayer d'assurer le succès du projet.
Comment nous concevons des équipes d'architecture d'entreprise pour les cas d'utilisation de modèle d'équipe EA
Lors de la conception d'une équipe d'architecture d'entreprise pour soutenir un objectif standard, nous recherchons le Modèle de référence de capacité d'architecture d'entreprise.
Ensuite, nous examinons les capacités clés alignées sur chaque objectif.
Capacités de stratégie de soutien
- Développer une stratégie d'entreprise
- Élaborer une stratégie ministérielle
- Développer une stratégie d'initiative
- Développer des feuilles de route stratégiques
Prise en charge des capacités du portefeuille
- Activer l'établissement du programme
- Développer une architecture de solution (portefeuille)
- Élaborer des feuilles de route du programme
Soutenir les capacités du projet
- Activer l'établissement de projet
- Développer une architecture de solution (projet)
- Effectuer un soutien à l'approvisionnement
- Développer des feuilles de route de projet
Prise en charge des capacités de livraison de solutions
- Développer l'architecture de la solution (livraison de la solution)
- Effectuer un soutien à l'approvisionnement
Enfin, nous savons que le modèle d'engagement évolue lorsque l'objectif passe du soutien de la stratégie au soutien de la livraison de solutions. Tout au long du continuum stratégie-livraison de solutions, les architectes passeront de :
- explorer les architectures cibles avec les parties prenantes pour assurer la gouvernance pour les parties prenantes
- fournir des conseils et des contraintes aux sponsors pour assurer la gouvernance des sponsors
En termes de SMA TOGAF, les produits du travail de l'équipe changeront en fonction du modèle qu'ils prennent en charge.
| Architecture pour soutenir la stratégie | Architecture pour prendre en charge le portefeuille | Architecture pour soutenir le projet | Architecture pour prendre en charge la livraison de solutions | |
| Produit de travail de la phase A : vision de l'architecture | Livrable clé
Avant le cadrage d'une séance de planification stratégique Actualiser avant le lancement de la budgétisation du programme |
Livrable clé
Avant le début de la planification budgétaire |
Souvent non utilisé
L'activité de production d'une vision chevauche l'architecture du portefeuille/programme candidat et la feuille de route de l'architecture Le livrable peut être utilisé au lancement de l'analyse de rentabilisation |
Utilisation limitée
L'utilisation principale est antérieure au cycle de mise en œuvre (via des fournisseurs internes ou des partenaires d'exécution) |
| Produit de travail des phases B, C et D : architecture de domaine candidat | Livrable clé
L'utilisation principale est la compréhension des parties prenantes de la cible et du travail. L'utilisation secondaire est la création de spécifications d'exigences d'architecture pour les architectes |
Livrable clé
L'utilisation principale est la compréhension des parties prenantes de la cible et du travail. L'utilisation secondaire est la création de spécifications d'exigences d'architecture pour les architectes |
Avant le lancement du projet et la finalisation du business case
L'utilisation principale est la création de spécifications d'exigences d'architecture pour les implémenteurs |
Avant l'engagement des partenaires d'exécution (y compris les fournisseurs internes)
L'utilisation principale est la création de spécifications d'exigences d'architecture pour les implémenteurs |
| Produit de travail des phases B, C et D : éléments de la feuille de route du candidat | Livrable clé
L'utilisation principale est la compréhension du travail par les parties prenantes. L'utilisation secondaire est la création de contraintes pour les architectes |
Livrable clé
L'utilisation principale est la compréhension des parties prenantes du travail et de la dépendance. L'utilisation secondaire est la création de contraintes pour les architectes |
Utilisation limitée Peut être utilisé comme entrée pour des projets avec plusieurs modifications interactives |
Avant l'engagement des partenaires d'exécution (y compris les prestataires internes).
L'utilisation principale est l'identification du changement requis et les préférences sur la façon d'exécuter le changement, pour gérer la sélection et l'engagement des partenaires de livraison de solutions |
| Produit des travaux des phases B, C et D : spécification des exigences d'architecture | Utilisation limitée
Habituellement, les architectes peuvent déduire les contraintes d'une architecture supérieure. |
Utilisation limitée
Habituellement, les architectes peuvent déduire les contraintes d'une architecture supérieure. |
Livrable clé
Avant la fin du lancement du projet |
Livrable clé
Avant l'engagement et la contractualisation |
| Produit de travail de la phase E : architecture d'entreprise candidate | Pendant la séance de planification stratégique
Actualiser au besoin dans la budgétisation du programme |
Livrable clé
Avant le début de la planification budgétaire L'utilisation principale est l'acceptation de la cible par les parties prenantes et la définition de l'écart |
Avant le lancement du projet et la finalisation du business case
L'utilisation principale est la création de spécifications d'exigences d'architecture |
Avant l'engagement des partenaires d'exécution (y compris les fournisseurs internes)
L'utilisation principale est la création de spécifications d'exigences d'architecture |
| Produit de travail de la phase E : Feuille de route de l'architecture | Pendant la séance de planification stratégique
Actualiser au besoin dans la budgétisation du programme |
Livrable clé
Avant le début de la planification budgétaire Actualiser au besoin pour soutenir la budgétisation et la gestion du programme |
Utilisation limitée
Peut être utilisé comme entrée pour des projets avec plusieurs modifications interactives |
Avant l'engagement des partenaires d'exécution (y compris les fournisseurs internes)
L'utilisation principale est l'identification du changement requis et les préférences sur la façon d'exécuter le changement, pour gérer la sélection et l'engagement des partenaires de livraison de solutions |
Tableau de TOGAF 10 Guide de la série TOGAF : Guide de l'architecte d'entreprise pour le développement de l'architecture
Cas d'utilisation de problèmes courants d'architecture d'entreprise
On nous demande continuellement d'optimiser une équipe d'architecture d'entreprise pour des cas d'utilisation courants basés sur des problèmes. La plupart de ces cas d'utilisation d'architecture d'entreprise sont orientés informatique. Ils répondent aux questions d'EA avec une orientation informatique.
Cas d'utilisation de l'atténuation des risques technologiques
Dette technologique. De nombreuses organisations accumulent des dettes technologiques. Lorsque les organisations sont confrontées à une véritable dette en espèces, elles font deux choses, s'attaquent à la source de la dette ou déclarent faillite.
Le risque technologique est un risque pur et simple. Le risque est l'efficacité de l'incertitude dans la réalisation des objectifs. La technologie qui crée le risque d'atteindre les objectifs doit être traitée.
Les organisations dépendent de la technologie pour gérer correctement leurs opérations dans tous les secteurs. Le cyber-danger est inhérent à toute technologie et peut prendre de nombreuses formes différentes à partir de nombreuses sources. Les causes les plus fréquentes mais les plus évitables des violations de données sont les pannes informatiques, les applications vieillissantes et l'infrastructure qui les prend en charge. Les effets d'une cybercatastrophe peuvent être très difficiles à surmonter en termes de pertes monétaires et de réputation.
Quel que soit le talent de votre équipe, la gestion des risques technologiques est un problème vaste et complexe qui ne peut être résolu par une maintenance manuelle des données. Les architectes d'entreprise peuvent facilement obtenir des données produit à jour sur toutes les technologies. Cette connaissance est nécessaire pour concevoir, gérer et retirer correctement les composants technologiques ainsi que pour évaluer le risque des paysages applicatifs.
Conception de l'équipe EA pour atténuer les risques technologiques
Lorsque nous sommes confrontés à l'atténuation des risques technologiques, nous utilisons le Naviguer dans l'Atlas SABSA et Naviguer dans l'Atlas de gestion de programme et de portefeuille. Nous extrayons les domaines de risque de SABSA et examinons la technologie en termes de portefeuille.
Dans tous les cas, vous recherchez une feuille de route claire et exploitable pour obtenir ces résultats.
Cas d'utilisation de la modernisation informatique
La technologie de l'information agit comme toute autre infrastructure - elle vieillit. À mesure qu'elle vieillit, l'informatique échoue de plus en plus à répondre aux espoirs et aux rêves actuels. Nous aimons considérer l'infrastructure informatique comme une infrastructure qui ne s'use pas physiquement. D'autres infrastructures souffrent de l'usure - un camion parcourt des kilomètres. Vent, pluie, sel, rouille, hochet et roulis. Ça s'use.
En revanche, l'infrastructure informatique continue de fonctionner. Pensez à un vieux Model-T. Démarre, tourne, perd de l'huile comme à l'état neuf. Cependant, il ne peut pas transporter 50 000 livres à 65 MPH comme un camion semi-remorque moderne.
Modernisation C'est souvent comme un remplacement de flotte - tout est connecté. Nous aimons la théorie, supprimant ou s'éloignant des applications gourmandes en ressources. Trouvez des remplaçants pour ceux dont le coût de possession est élevé. Ensuite, vous vous heurtez à la réalité de l'ancienne application traitant un tiers des revenus, l'entreprise se concentrant sur de nouveaux services pour de nouveaux revenus.
Les initiatives de modernisation informatique utilisent fréquemment une stratégie incrémentale, qui consiste à moderniser progressivement les actifs informatiques jusqu'à ce que l'ensemble du système ait été mis à niveau. Il s'est avéré utile de moderniser progressivement les systèmes d'information, notamment pour réduire les aléas opérationnels qui surviendraient si tout était fait en même temps. L'inconvénient de cette stratégie est que les équipes de développement fonctionnent de manière isolée et manquent d'une large perspective. L'architecture d'entreprise intègre toutes les couches d'une organisation, de l'entreprise à l'infrastructure informatique, permettant aux responsables informatiques de hiérarchiser les initiatives de modernisation en fonction des objectifs commerciaux et de voir comment ces projets affecteront leurs systèmes informatiques.
L'architecture d'entreprise relie les objectifs commerciaux aux capacités commerciales dans le contexte de la modernisation informatique. Afin de cartographier les capacités commerciales actuelles et de comprendre comment elles peuvent évoluer, les architectes d'entreprise collaborent avec les équipes commerciales. Cela permettra d'avoir une vision plus claire de la façon dont une capacité devrait se développer dans les années à venir ou si elle cible une nouvelle catégorie de consommateurs.
En alignant les objectifs de transformation, les capacités commerciales et les fonctions informatiques nécessaires dans un calendrier, les architectes d'entreprise peuvent utiliser une feuille de route d'entreprise pour capturer les demandes commerciales présentes et futures. La future architecture informatique qui prendra entièrement en charge les capacités commerciales prévues sera définie.
L'architecture d'entreprise peut également spécifier l'architecture informatique future, ce qui est utile. Les architectes d'entreprise cartographient l'environnement informatique actuel comme point de départ. Pour ce faire, les applications et la technologie d'une organisation doivent être inventoriées. Les cycles de vie des applications, les coûts, les déploiements, les flux d'échange et la façon dont ils servent l'entreprise ne sont que quelques-uns des aspects qui peuvent être utilisés lors de l'inventaire des applications. Les architectes d'entreprise peuvent créer une nouvelle architecture informatique basée sur les capacités métier reconnues lorsque l'inventaire des applications est terminé. Les cartes des capacités métier aident à démontrer les ressources informatiques nécessaires pour prendre en charge les opérations métier au fur et à mesure que l'organisation évolue pour résoudre de nouveaux problèmes.
Grâce aux initiatives de modernisation informatique, certains composants ou parties de l'environnement informatique peuvent être mis à jour pour répondre aux nouvelles capacités commerciales une fois que l'architecture informatique prévue, y compris les applications et les technologies, a été établie.
Enfin, l'architecture d'entreprise peut coordonner votre plan informatique avec vos objectifs d'entreprise. Chaque projet est accompagné d'une justification ou d'une analyse de rentabilisation, décrivant pourquoi il devrait être fait, ainsi que les coûts, les ressources, un calendrier et tout danger potentiel.
Les entreprises peuvent constituer un conseil exécutif composé à la fois d'experts en informatique et en affaires pour hiérarchiser ces initiatives. Les projets sont hiérarchisés en réunissant les deux types de leaders en fonction des objectifs de chaque partie prenante.
Nous pouvons former la feuille de route informatique une fois que les tâches ont été hiérarchisées et placées dans un calendrier. Une déclaration des objectifs commerciaux stratégiques, un calendrier de projet, une analyse de rentabilisation, le coût prévu et la durée de chaque projet sont tous des composants nécessaires d'une feuille de route informatique efficace.
EA Team Design pour la modernisation informatique
Bon équipes d'architecture d'entreprise vous aider à obtenir une vision claire de vos investissements informatiques, de leur valeur actuelle et vous fournir des conseils pragmatiques sur où investir. Le conseil en investissement est un problème de portefeuille. La modernisation informatique n'est pas qu'un problème technologique. Nous renforçons toujours la Architecture d'entreprise car concevoir uniquement pour la technologie ne réussira pas.
Pour activer le cas d'utilisation de la modernisation informatique, nous nous alignons sur concevoir pour l'architecture pour prendre en charge le portefeuille.
Cas d'utilisation de la transformation numérique
Trop souvent, on voit des gens parler de Transformation numérique et Cloud Transformation en tant que commutateur d'infrastructure. Quelle absurdité.
Il y a Sept leviers de la transformation numérique. Vous pouvez contrôler tous les sept leviers ou vous pouvez essayer de changer sans contrôler votre trajectoire, votre vitesse ou ... Chaque levier active ou désactive une fonction de changement différente.
- Levier 1 - Transformation des processus métier
- Levier 2 - Engagement et expérience client
- Levier 3 - Numérisation du produit ou du service
- Levier 4 - Transformation de l'informatique et de la livraison
- Levier 5 - Culture organisationnelle
- Levier 6 - Stratégie
- Levier 7 - Ecosystème et Business Model
Conception d'équipe EA pour la transformation numérique
La transformation numérique nécessitera des réponses à certaines questions stratégiques. Cependant, beaucoup peuvent être répondus rapidement, laissant l'exécution. En conséquence, nous nous alignons sur concevoir pour l'architecture pour prendre en charge le portefeuille.
Cas d'utilisation de la transformation cloud
De nouveaux modèles d'entreprise axés sur les services et générateurs de valeur sont désormais possibles grâce à la technologie cloud. Les réductions de coûts, les gains de productivité, l'accélération des délais de mise sur le marché et la capacité d'évoluer avec la demande ne sont que quelques-uns des avantages du cloud computing. Après le passage au cloud, les entreprises peuvent également augmenter considérablement l'utilisation des actifs, réduire les coûts d'exploitation et remodeler les relations avec leurs employés informatiques.
Le cloud est un facteur important dans la détermination de la stratégie informatique et commerciale. Mais la compréhension de la transition vers le cloud est sérieusement entravée par des environnements d'entreprise complexes et une technologie en constante évolution.
Des changements organisationnels, opérationnels et technologiques majeurs sont nécessaires pour réussir la migration vers le cloud. Les restrictions budgétaires, l'exigence d'une croissance exponentielle, la complexité des règles commerciales à mesure qu'elles deviennent plus sophistiquées et les lois externes ne sont que quelques-uns des obstacles qui affectent l'adoption du cloud en cours de route. La capacité à mettre en œuvre une feuille de route de l'infrastructure traditionnelle au cloud est un must pour les architectes d'entreprise.
L'architecture d'entreprise offre une perspective automatisée et globale des infrastructures multi-cloud à l'échelle de l'entreprise, ce qui facilite la gouvernance et l'amélioration de vos projets cloud. Un large éventail d'éléments, y compris les capacités existantes et futures, la stratégie du portefeuille d'applications, les questions opérationnelles et organisationnelles relatives aux personnes et aux processus, ainsi que les indicateurs de coût, doivent être pris en compte pour une transition vers le cloud réussie. Pour réduire les risques et maintenir la conformité dans les déploiements cloud, il est essentiel de bien comprendre ces complexités. Afin de simplifier l'importation de données, l'architecture d'entreprise s'intègre aux principaux fournisseurs de cloud et offre une perspective sur l'architecture cloud. Les architectes d'entreprise peuvent spécifier les capacités cibles, choisir si les applications doivent rester sur site ou être transférées vers le cloud, et définir les capacités cibles.
Conception d'équipe EA pour la transformation du cloud
La transformation cloud est un problème de portefeuille. L'entreprise est en train de repenser son organisation informatique. Nous renforçons toujours la Architecture d'entreprise car concevoir pour la technologie échouera. Nous devons restructurer l'organisation informatique.
Pour activer la transformation cloud, nous nous alignons sur concevoir pour l'architecture pour prendre en charge le portefeuille.
Cas d'utilisation de la rationalisation du portefeuille d'applications
Nous pouvons bien faire la rationalisation des applications, ou mal, lorsqu'elle est bien faite, les dépenses informatiques peuvent être réduites de plus de 20%. Quand c'est mal fait, il n'y a pas de sauvegarde. Déjà.
La rationalisation des applications est motivée par l'impact commercial et la valeur commerciale, et non par le coût informatique. Vous devez préparer votre portefeuille informatique en fonction du profil technique et de la valeur commerciale. Investissez dans ceux qui ont un profil technique et une valeur commerciale prêts pour l'avenir. Explorez les meilleures façons de prendre votre retraite ou de remplacer ceux qui vous retiennent.
Le côté commercial ignore souvent l'exigence de coordonner le paysage informatique de support puisqu'il est principalement concerné par la promotion du développement économique. Par conséquent, différentes applications sont fréquemment introduites à des moments différents selon les besoins des différentes équipes. Le côté commercial est aveugle au fait que le fait d'avoir un environnement informatique composé d'applications avec des cycles de vie contradictoires, des technologies en double et des fonctionnalités qui se chevauchent entraîne souvent de graves problèmes d'intégration et des inefficacités organisationnelles. L'exploitation d'un environnement informatique coûteux et restrictif entraîne des centaines de millions de dollars supplémentaires dépensés en informatique tout en réduisant immédiatement la satisfaction et la qualité de service des personnes qui en dépendent.
Les grandes entreprises lancent fréquemment un nombre important d'applications en même temps. Par conséquent, l'exécution de systèmes plus anciens et la maintenance des applications consomment une part importante des dépenses informatiques. Ces programmes ne doivent pas tous être essentiels à la mission. Les entreprises bénéficient d'un écosystème d'applications correctement rationalisé pour rester au fait des tendances d'innovation modernes, fournir un service client de classe mondiale, réduire les coûts et se développer dans le monde entier. Bien que les projets de réduction des applications nécessitent une dépense ponctuelle, les économies dépassent de loin le coût.
Les architectes d'entreprise peuvent commencer à travailler sur l'optimisation du portefeuille d'applications alors que le côté commercial continue d'autoriser l'acquisition d'applications à gauche et à droite.
Les architectes d'entreprise peuvent d'abord rassembler toutes les données pertinentes sur toutes les applications déployées et les importer dans leur logiciel préféré. Les architectes d'entreprise peuvent déterminer le projet de rationalisation des applications et le hiérarchiser en fonction du modèle opérationnel de leur entreprise en commençant par un processus de base particulier ou une unité commerciale entière, par exemple, à partir de cette vue organisée de l'inventaire complet des applications et de leur valeur commerciale directe. .
Les architectes d'entreprise peuvent ensuite utiliser la matrice d'applications et les enquêtes de rationalisation des applications pour évaluer rapidement l'utilité des applications et proposer des recommandations basées sur les données sur les applications à tolérer, investir, déplacer ou supprimer.
Les architectes d'entreprise auront désormais les connaissances dont ils ont besoin pour créer une feuille de route pour mener à bien l'effort de rationalisation à travers une série d'initiatives de démantèlement. Ce plan de route peut également être utilisé comme référence à l'avenir pour déterminer si des applications supplémentaires sont nécessaires ou non.
EA Team Design pour la rationalisation des applications
La rationalisation des applications est un problème de portefeuille. La rationalisation des applications échoue toujours sans un solide Architecture d'entreprise. Nous veillons toujours à ce que l'équipe EA dispose d'une capacité d'architecture métier, même si nous nous concentrons sur l'ingénierie inverse.
Nous nous alignons sur concevoir pour l'architecture pour prendre en charge le portefeuille pour le cas d'utilisation de la modernisation des applications.
Cas d'utilisation de l'intégration d'acquisition
Intégrez toujours les acquisitions conformément à la stratégie et à l'objectif de l'acquisition.
Une acquisition se fera pour quelques raisons simples
- acquisition de clients
- acquérir des produits
- acquérir des actifs physiques
- acquérir la capacité
Nous aimons le serment médical, Premierement ne faites pas de mal. Si nous avons fait une acquisition pour la clientèle, notre intégration doit d'abord s'assurer que nous conservons les clients existants.
Les acquisitions pour Capability sont les plus difficiles. En règle générale, l'acquéreur a une lacune et cherche à accélérer le développement de ses capacités en utilisant la nouvelle capacité. Nous utilisons cet exemple de développement des capacités dans notre cours à la demande Architecture d'entreprise avec TOGAF et Navigate cours.
Les dirigeants d'entreprise et de capital-investissement prévoient que l'activité de fusion et d'acquisition augmentera dans les années à venir, tant en termes de volume que de valeur en dollars des acquisitions.
Cependant, les fusions et acquisitions échouent souvent parce que les entreprises impliquées ne peuvent pas s'intégrer correctement ou ne peuvent pas réaliser les synergies projetées. Il y a plusieurs raisons pour lesquelles les intégrations informatiques échouent. Après une fusion, il est extrêmement difficile pour deux organisations de réussir l'intégration de leurs systèmes informatiques tout en maintenant leurs opérations commerciales. Il est nécessaire d'unifier divers éléments technologiques, normes et procédures.
Il existe plusieurs conditions de départ pour les fusions. Parfois, une grande entreprise en mange une toute petite, et d'autres fois, une fusion se produit entre égaux. Acquérir des compétences techniques ou conquérir de nouveaux marchés géographiques sont deux objectifs possibles. L'architecture d'entreprise a le potentiel d'être extrêmement importante pour le succès de l'intégration informatique dans chacun des scénarios susmentionnés. La base pour choisir les applications appropriées pour un environnement informatique cible commun est fournie par l'architecture d'entreprise, qui aide à rationaliser les applications, à consolider les emplacements et à consolider les emplacements. Cela permet aux entreprises de tirer parti des synergies, de réaliser des économies et d'aligner stratégiquement leurs opérations à l'avenir. Le succès à long terme d'une fusion est influencé par la création d'une synergie entre deux services informatiques.
Conception de l'équipe EA pour l'intégration des acquisitions
L'intégration d'acquisition est un problème de portefeuille. Une intégration d'acquisition centrée sur l'informatique échouera toujours. Architecture d'entreprise est le fondement d'une intégration efficace de l'acquisition. Sans savoir pourquoi votre entreprise a fait l'acquisition, l'approche par défaut consiste à changer l'organisation acquise. Changez-le au point de détruire la proposition de valeur. L'équipe EA a besoin d'une solide capacité d'architecture d'entreprise, même si nous nous concentrons sur l'ingénierie inverse.
La deuxième capacité critique est Architecture des risques. Ces raisons simples vous indiquent quelle valeur doit être protégée. Naviguer dans l'Atlas de la gouvernance, des risques et de la conformité utilise Asset and Risk pour clarifier ce qui doit être protégé et quelles menaces endommageront l'actif.
Nous nous alignons sur concevoir pour l'architecture pour prendre en charge le portefeuille pour le cas d'utilisation d'intégration d'acquisition.
Cas d'utilisation de l'architecture de sécurité
le SABSA se concentrer sur la valeur, soit en réalisant un avantage, soit en prévenant un inconvénient, est essentiel.
En tant qu'architecte d'entreprise, votre travail consiste à protéger l'actif et à éliminer l'incertitude. Votre organisation est plus en sécurité lorsqu'elle a la certitude qu'elle répondra à ses attentes.
Pour faire simple, l'architecture de sécurité est la partie de l'architecture d'entreprise qui concerne la protection des données d'entreprise. Les politiques et pratiques de sécurité fondamentales d'une organisation pour protéger les données sont décrites par son architecture de sécurité, qui comprend également les équipes du personnel et leurs rôles et responsabilités, ainsi que d'autres systèmes. Il s'agit d'une explication plus complète de l'architecture de sécurité. Pour aider à garantir que l'architecture de sécurité correspond aux exigences commerciales actuelles et futures, ces informations sont fournies dans les exigences organisationnelles, les priorités, la tolérance au risque et les considérations connexes.
Pour informer la planification de la sécurité à tous les niveaux, il est essentiel de disposer d'une architecture de sécurité solide. Il offre les détails approfondis nécessaires pour faire les meilleurs choix sur les procédures et les solutions à utiliser dans l'environnement informatique, ainsi que sur la façon de gérer le cycle de vie de la technologie. Une documentation et une publication approfondies de l'architecture de sécurité des informations d'entreprise sont également essentielles pour se conformer aux diverses normes actuelles de l'industrie et aux exigences légales.
Une collection d'outils de TOGAF est disponible pour créer une architecture de sécurité d'entreprise à partir de zéro pour la première fois. Il aide à définir des objectifs précis et à combler les écarts entre les nombreux niveaux de votre EISA. La Cadre TOGAF est suffisamment flexible pour vous aider lorsque les exigences de sécurité de votre entreprise changent.
EA Team Design for Security Architecture Cas d'utilisation
Le cas d'utilisation de l'architecture de sécurité se concentrera sur la suppression de l'incertitude ou la réduction de la menace. Dans les deux cas, il s'agit d'un problème de portefeuille.
Nous tirons parti Naviguer dans l'Atlas de la gouvernance, des risques et de la conformité qui combine Actif avec Risque et Menace. Nous regardons les choses de valeur. Ce qui menace leur valeur et ce qui crée de l'incertitude. La base pour faire face à l'incertitude et à la menace est Architecture des risques. Naviguer dans l'Atlas de la gouvernance, des risques et de la conformité utilise Asset and Risk pour clarifier ce qui doit être protégé et quelles menaces endommageront l'actif.
Nous tirons parti Intégration des risques et de la sécurité avec TOGAF. Nous avons écrit ce guide avec l'Institut SABSA apporté les meilleures pratiques Architecture de sécurité et gestion des risques d'entreprise.
Nous nous alignons sur concevoir pour l'architecture pour prendre en charge le portefeuille pour le cas d'utilisation d'intégration d'acquisition.
Réflexions finales sur les cas d'utilisation de l'architecture d'entreprise
Il n'y a aucune raison pour que les équipes d'architecture d'entreprise aient du mal à s'engager. Les dirigeants de chaque organisation recherchent des conseils utiles sur un changement efficace.
La difficulté est lorsque l'équipe EA suit l'un des deux schémas d'échec. Soit ils :
- ne prennent pas en charge le cas d'utilisation pour lequel les parties prenantes souhaitent obtenir de l'aide
- essayer d'utiliser les parties prenantes pour conduire un autre programme
Nous concevons et développons des équipes EA pour gagner leur vie. Nous nous concentrons sur ces cas d'utilisation, car ils attirent notre attention sur le changement qui compte. Gardez à l'esprit que le Cas d'utilisation courants de l'architecture d'entreprise sont presque toujours traités par une équipe EA conception pour prendre en charge le portefeuille.
Lorsque nous connaissons le cas d'utilisation, nous pouvons concevoir l'équipe d'architecture d'entreprise. Ensuite, nous faisons les trois mêmes choses :
- Améliorez les compétences de votre architecte
- Développez votre méthode d'architecture d'entreprise
- Améliorez l'utilisation de l'architecture par votre organisation
Si vous voulez de l'aide pour développer votre équipe EA - atteindre. Nous aimerions vous aider. Avec notre Approche EA prévisible, nous nous assurons que vous disposez d'une architecture d'entreprise utile en cours de développement au fur et à mesure que votre équipe se développe.