Accueil
 > Rapports de TEC > Blogue de TEC > Établir Architecture d'entreprise Gouvernance

Établir Architecture d'entreprise Gouvernance

Écrit par : Alex Cullen
Date de publication : juillet 18 2013

Présentation

Le but de l'architecture d'entreprise est de définir comment construire des systèmes et des capacités pour le plus grand bien de l'entreprise. Gouvernance architecture est le processus par lequel les projets informatiques sont examinées en fonction de leur alignement avec une architecture définie, et les modifications correctives apportées.

John Zackman, dans un article récent (DM Review, Décembre 1999) a appelé l'architecture d'une activité «contre-culture». Ce qu'il voulait dire par ce n'était que c'est l'attention a été concentrée sur la production de code en cours d'exécution, et non sur la conception des avantages sociaux futurs incorporels. Architecture sans gouvernance essaie de promouvoir cette activité contre-culture à des équipes de projet qui sont goaled et évalués par d'autres critères souvent contradictoires. En tout assez grande taille IT organisation, les projets sont identifiés et exécutés de manière distribuée. Il est difficile pour ces projets d'aligner avec une sorte de «plan directeur». Sans un plan directeur, l'environnement informatique global; plates-formes, composants et applications, est difficile à comprendre, et encore moins gérer. Les difficultés de nombreuses organisations avaient à préparer efficacement pour Y2K témoigne des dangers de développer et maintenir des applications en l'absence d'un tel plan.

Si l'Architecture d'Entreprise est la base de ce «plan directeur», la gouvernance architecture est le moyen par lequel les avantages de l'architecture d'entreprise en termes de flexibilité, la rentabilité et la capacité globale de soutenir un changement de l'entreprise sont réalisées à travers des projets . La gouvernance est ancrée sur l'examen des projets et des postes de contrôle aux points appropriés du cycle de vie.

Cet article traite des questions autour de la mise en œuvre la gouvernance de l'architecture, et ce qui constitue des approches viables à établir des processus efficaces de gouvernance.

Architecture d'Entreprise

L'environnement informatique: applications, plates-formes, la technologie, les changements que l'entreprise prend en charge les changements. Il est désormais au cœur de la stratégie de l'entreprise, au lieu d'être un joueur d'appui. Dans le nouveau monde de la gestion d'entreprise e-business répondre en augmentant la pression de «livrer la marchandise»: de nouvelles applications, de nouvelles façons d'utiliser les applications existantes, l'intégration accrue.

Pour s'assurer que les investissements de l'entreprise fait aujourd'hui continueront à avoir de la valeur dans l'avenir, les entreprises à développer des règles pour contraindre la diversité et de canaliser les ressources dans le développement des compétences qui peuvent être appliquées à travers des programmes et projets. Ces règles comprennent l'architecture d'entreprise et dans la plupart des grandes organisations il existe une fonction spécifique dans l'organisation est, l'architecture d'entreprise, qui prend le rôle de chef de file dans l'identification, la formalisation et la publication de l'architecture

Typiquement une architecture d'entreprise abordera les domaines suivants:

  • Normes techniques. Ceux-ci sont à la base de tout programme de l'architecture. Les normes techniques peuvent être assez général: "TCP / IP", "Oracle", ou très spécifiques: "Solaris 2.6", "Netscape Enterprise Server 2.5.1", "NT 4.0sp6a". Les normes techniques sont des moyens essentiels pour maîtriser la diversité de l'infrastructure IT.
  • L'architecture technique ou d'architecture pour la conception technique. Ce sont les définitions de la façon dont les applications doivent utiliser les normes techniques. Encore une fois, ils peuvent être assez général: «Les bases de données devraient être sur des serveurs distincts de code de l'application", ou très spécifique: "les applications qui nécessitent un support de transaction complexe, et sont utilisés par plus de 100 utilisateurs, devraient utiliser les conceptions net-centric avec une entreprise Java gestion des transactions à base de haricots ». Parfois, le terme «modèles d'application» est utilisé pour décrire ce niveau de l'architecture. Architecture de conception technique contrôle la diversité des types d'applications qui sont développées, déployées et soutenues. Ils peuvent également réduire les risques de projet en les orientant vers des "modèles testés".
  • Architecture de l'application de
  • ou l'architecture des applications d'entreprise. Cette architecture se concentre sur la façon dont la fonctionnalité d'affaires est fourni dans le portefeuille d'applications d'entreprise, les fonctions qui sont communes, comment elles sont partagées, les dessins de ces fonctions, et comment les données que ces fonctions utilisation est gérée de manière à assurer la qualité et la disponibilité . L'avantage de l'architecture à ce niveau est atteint lors de la planification de nouvelles initiatives informatiques.

Chacun de ces domaines de l'architecture limite potentiellement le choix de la solution pour les fonctions individuelles. Si le processus fonctionne bien les synergies créées à partir s'appuyant sur une infrastructure partagée, et la mise en œuvre accélérée possible de concevoir autour de composants standardisés feront plus que compenser une sous optimisation locale.

Mais est important de réaliser que si les architectes ont tendance à considérer ces choix comme clairement articulés, de manière appropriée en couches, et justifiable, chaque projet est aux prises avec des décisions à travers ces couches touchant seulement des morceaux de l'ensemble de la solution. Pour une équipe de projet, il n'y a pas de démarcations propres, seuls les points du cycle de vie du projet où les différentes décisions sont prises.

Architecture du système

Dans un projet quelque sorte l'architecture du système sera générée au début du processus. Cela devient tellement partie des meilleures pratiques qu'il ya maintenant une norme IEEE pour l'architecture du système. Une architecture du système doit montrer comment la conception proposée répond aux besoins des utilisateurs. Cette architecture de système est généralement détenu par l'équipe du projet et est l'un des blocs de construction, ainsi que le plan du projet, pour contrôler la portée et la qualité.

nous pouvons penser à l'architecture d'entreprise comme l'ajout d'une deuxième série d'exigences sur la base de la politique de gestion et les décisions et créant ainsi un sur-ensemble d'exigences pour être introduit dans le processus de l'architecture du système. Toutefois, les exigences souvent contradictoires: faible coût par rapport à l'application d'extensibilité de projet, par exemple.

conflit entre les exigences peut être résolu par l'une des techniques suivantes:

    Innovation
  • et le design créatif qui conduit à radicalement nouvelles et meilleures solutions.
  • Un compromis laid qui mène aux besoins de personne respectée de manière efficace.
  • Optimisation de certaines exigences tout en ignorant ou du bout des lèvres à d'autres.
Des solutions novatrices class=articleText>

gouvernance

Le but du processus de gouvernance est de créer des points d'intervention dans l'acquisition de la technologie et des processus de développement que la force compte de la façon dont l'ensemble des exigences est abordée motivée.

Les pressions pour ne pas honorer l'architecture d'entreprise sont nombreux.

  1. Culturellement, il ya «faiseurs». L'horizon de planification est d'ordre tactique - «la prochaine étape». Il s'agit d'une réponse à des pressions commerciales pour fournir des applications. Les opérations informatiques du personnel sont conservateurs - tout en reconnaissant la nécessité d'affaires, chaque nouveau système permet d'optimiser l'environnement opérationnel plus difficile.
  2. La réussite du projet
  3. est mesurée en termes de calendrier, les coûts et les fonctionnalités telles que définies par le promoteur de l'entreprise. «Améliorer l'environnement global IT 'n'apparaît pas comme une exigence du projet.
  4. La nécessité d'une plus grande rapidité de livraison. Méthodologies de développement rapide sont remplaçant cycle de vie des projets structurés. Les approches délibératives de la planification ne correspondent pas à ce modèle.
  5. Alors que les budgets ont été libérées après Y2K, il ya une énorme demande refoulée pour la révision de l'application. Les organisations informatiques sont en cours demandé de «faire beaucoup plus avec un peu plus de budget".
  6. "Acheter avant de construire" apporte des packages d'applications qui doivent être adaptées à l'environnement informatique existant.
  7. Développement d'applications externalisées apporte le point de vue du sous-traitant de l'architecture au niveau du projet dans l'environnement.
  8. Acquisitions d'entreprises
  9. , où les impératifs initiaux sont d'abord, pour connecter des systèmes et, deuxièmement, les coûts d'extraction.

Ces défis deviennent des opportunités pour vendre des affaires et la gestion informatique sur les avantages de la gouvernance de l'architecture. Sans aucun processus d'examen, ces défis sont relevés ponctuels et le résultat est supérieur chaos. La gouvernance devient le moyen d'équilibrer l'impact de ces défis et de les utiliser pour l'optimisation de l'environnement dans son ensemble.

gouvernance architecture doit être un processus de bout en bout unique, mais avec différents types de commentaires et points de contrôle pour évaluer les différents types de décisions sont prises.

Pré-requis pour le processus de l'architecture efficace

gouvernance fonctionne mieux quand il s'agit d'un processus de collaboration. Dans certaines organisations, cela n'est pas possible et la tension entre les architectes d'entreprise et les équipes de projet est résolu par le pouvoir politique. En règle générale cependant, ce n'est pas durable et l'architecture d'entreprise formel est abandonnée.

Pour les approches de collaboration pour travailler, il doit y avoir une certaine harmonisation des objectifs et efficace, fréquente et la communication ouverte. Les facteurs qui contribuent à l'institut ceux-ci incluent:

  • Objectifs clairs qui cadrent avec les intérêts de l'organisation. Par exemple, s'il ya un seul groupe qui fournit des services d'infrastructure, ils ont un intérêt naturel pour les projets utilisant des technologies standard dans les configurations standard. La haute direction de l'autorité budgétaire sur de nombreux domaines et projets de développement seront intéressés par les normes de conception et de soutenir les processus d'examen qui minimisent les dépenses de projets redondants.
  • Une bonne compréhension par les acteurs de l'objet de l'examen de l'architecture. Ces intervenants comprennent les promoteurs de projets, chefs de projets, la gestion de l'infrastructure IT partagée et de la gestion de l'autorité du budget de fonctionnement.
  • Disponibilité
  • aux équipes de projet de documentation, ou plus important encore, des gens qui comprennent ce que l'on cherche à atteindre - les objectifs et l'état actuel de la spécification de l'architecture. Il devrait y avoir «architectes conseils" disponibles pour les équipes de projet. Ces architectes-conseils équilibrer les objectifs de l'équipe du projet avec les intérêts de l'ensemble de la fonction informatique dans les conceptions «conforme» du projet.
  • Un processus du cycle de vie d'un projet cohérent (SDLC). Ceci est important pour le moment de l'examen des points de contrôle. À titre d'illustration dans la section suivante, une phase du cycle de vie 4 du projet: planification, conception, construction et mise en œuvre, est utilisé.
  • Avec un SDLC est la nécessité pour la documentation du projet cohérent. Le début d'un projet devrait générer un document de lancement du projet fournissant une vue de haut niveau de la portée du projet, les objectifs, approche. Cela déclenche le début du processus d'examen. Durant les premières phases, les facteurs qui orientent la conception et le dessin lui-même, doivent être documentés augmentent avec le degré de spécificité. Tous ces documents doivent être disponibles et partagées à l'extérieur de l'équipe de projet.

au point du processus

Le cœur d'un processus de gouvernance est la présentation et l'examen dans le but de découvrir des lacunes dans le champ d'application du projet, l'approche et le choix de la technologie.

Une analogie pour la gouvernance est souvent le processus de permis de construire pour des projets de construction. Il ya certainement un élément de la vérification de la conformité aux normes, mais une bonne conception nécessite plus que la conformité aux normes. architectes d'entreprises sont souvent les mieux placés, grâce à leur exposition à tous les projets de l'entreprise, à identifier les possibilités de réutilisation de la technologie existante et d'améliorer la prestation des niveaux de service

Parmi les principaux points de décision dans la conception d'un processus de gouvernance sont:

L'examen et l'instance dirigeante

La question d'établir l'examen et l'organe directeur est de savoir comment centralisée ou décentralisée, il est, et qui remplit cette fonction. Un organe centralisé permet un meilleur contrôle, un organisme décentralisé, une meilleure réactivité aux questions de domaine spécifique. La participation d'un large éventail de parties prenantes peut être plus facile avec un groupe décentralisé, mais encore une fois, cela peut conduire à plus de compromis et moins de contrôle. Certains des facteurs entrant dans cette décision sont: 1) la façon dont les questions locales importantes sont l'organisation générale, 2) la portée de la définition de l'architecture, et 3) la nécessité de buy-in par les équipes de projet et de leur gestion. Sur ce dernier point, prendre une leçon de formes démocratiques de gouvernement, que pour obtenir la volonté du peuple d'être gouverné, vous devez les inclure dans l'organisation régissant. Qu'est-ce que cela signifie pour la gouvernance architecture est que toutes les parties de l'organisation informatique doivent être représentés. Identifier qui devrait être l'évangéliste architectural au sein de chaque région, et les amener dans le corps dirigeant.

Plus d'un organe ou d'un organisme unique avec différents sous-groupes, peut être nécessaire. Différents types d'architecture: la technologie ou de l'application, exigent différents représentants dans la gouvernance de l'architecture. gestionnaires des relations d'affaires devraient participer à l'application examen de l'architecture. Les services d'infrastructure devraient être très impliqués dans la révision de l'architecture technique.

déterminer quels projets se examiné

Si tous les projets se revu ou seulement les grands? Bien qu'il puisse être attrayante pour réserver examen de l'architecture pour les projets jugés «importants», dans la pratique, cela peut être gênant. Définir le seuil est difficile (et peut-être politique). Tous les projets doivent avoir un certain niveau, si ce n'est pour déterminer leur impact, et la nécessité d'un processus d'examen complet. Des seuils peuvent être utilisés pour piloter les types et la profondeur de l'examen. Critères du seuil pourraient inclure la taille / coût du projet, si elle est «introduit quelque chose de nouveau qui sera vécu avec pendant longtemps», si le projet fait partie du programme en plusieurs phases, et si oui, est-ce la première phase.

calendrier et le contenu commentaires

tant que projet progresse depuis sa création grâce à la conception et à la construction, l'équipe du projet va prendre de nombreuses décisions d'importance architecturale. Le but de l'examen est de vérifier leurs décisions avant qu'elles aient progressé trop loin de les modifier ou de vérifier leur pensée avant qu'ils aient pris une décision. Timing nécessite un équilibre entre «trop tôt» - les options sont encore identifiés et triés, et «trop tard» - l'équipe agit sur une décision de conception. Une façon de résoudre ce dilemme est d'avoir un architecte conseil qui peut fournir fréquents points de contrôle et d'orientation, soutenus par des examens de projets basés sur la phase par le comité. L'existence de ces commentaires progressive base donne le pouvoir de l'architecte-conseil chaque fois qu'un projet est aux prises avec «la voie rapide contre la bonne manière" décisions.

Le contenu de l'examen est une fonction de l'endroit où dans le cycle de vie d'un projet, et le but ou le type d'examen. L'utilisation d'un cycle de vie en quatre phases, la planification, la conception, la construction et la mise en œuvre, et les trois types d'architecture discuté précédemment, chaque type d'architecture peut être affecté à un examen au cours d'une phase. Le but de chaque type d'architecture sera utilisé pour déterminer quelle information est présentée, et quels sont les résultats possibles. Le tableau suivant est un exemple de la façon dont cela pourrait correspondre.

Phase Type d'examen / checkpoint Résultats
P Lanning

Application Architecture portée et approche projet:

  • Fonctions Répertoire d'entreprises
  • Données Sujets
  • L'intégration avec d'autres applications

approuvée ou révisée portée et approche [1] Projet exigences de conception technique:

    Fonctions de levier
  • au sein des systèmes existants
  • Source de réutilisation des données
Conception

Technical Architecture / Design

  • Système Design |
  • Développement langue
  • Database
  • Plates-formes

  • Approche d'intégration d'application

  • Nouvelles technologies introduites

approuvé la conception technique du projet.

Identifié écarts d'architecture.

Construction

configuration technique et des opérations du modèle [2]

  • L'utilisation des normes
  • Configuration de la plateforme

Approuvé configuration technique et les spécifications de la plate-forme

documentée modèle de fonctionnement

Mise en œuvre Volonté de mise en œuvre [2]

[1] Application Architecture Review, au lieu de faire approuver / refuser des décisions, peut alternativement fournir des orientations qui doivent être reflétées dans les modèles examinés dans le cadre de l'architecture technique.
[2] Opérations modèle et l'exécution commentaires de préparation, bien que n'étant pas spécifiquement axée sur l'architecture, donner la possibilité à valeur ajoutée à des fonctions de services partagés.

Lorsqu'une organisation met en œuvre un processus d'examen de l'architecture pour la première fois, trois avis peut être beaucoup de choses à mettre en œuvre à la fois. Quelle évaluation pour commencer doit être tranchée en fonction des circonstances de l'organisation.

qualitative ou quantitative?

Il est le commentaire de la relative immaturité du processus de l'architecture que la plupart des entreprises ont gouvernance de l'architecture limité aux commentaires qualitatifs de dessins. Toutefois, les entreprises qui ont adopté de solides méthodologies d'ingénierie des systèmes développent également des indicateurs de processus basés pour estimer TCO, la maintenabilité, la disponibilité et la capacité à répondre à des objectifs de performance dans le cadre de l'examen.

processus d'escalade

Il y aura de nombreux cas où le projet n'est pas conforme aux normes de l'architecture. Certaines déviations peuvent être de petite conséquence: une version différente du logiciel ou une configuration non-standard d'un serveur dédié. D'autres peuvent avoir beaucoup plus d'impact, allant de la création d'un besoin de ressources de soutien dédiés à violer une stratégie de gestion des données clients.

  1. Le cœur du processus de gouvernance est de savoir comment ces "écarts" sont résolus ou atténués. La gouvernance ne peut pas devenir inflexible (tout comme il ne peut pas être trop souple), sans efficacité dégradants. La clé est d'établir une politique sur la gestion des écarts. Certaines entreprises ont développé notation formelle des écarts, avec un score de seuil pour réévaluer ou de refuser l'approbation du projet.
  2. Les écarts de
  3. peuvent entraîner une mise en œuvre plus ou dépenses d'appui - une «taxe».
  4. Les écarts de
  5. peuvent déclencher «l'examen de niveau de la direction» - même comme un «heads-up» à la haute direction.
  6. Les écarts de
  7. peut signifier que le projet ne peut pas utiliser certaines parties d'une infrastructure commune. - Serveurs partagés, gestion et système de surveillance, personnel commun et doit donc assumer les frais de sa propre infrastructure.
  8. Les écarts de
  9. pourraient exiger que l'équipe du projet fait un travail extra - vérifier et évaluer l'impact sur l'environnement, le budget global, la stabilité et la facilité de gestion de l'infrastructure.
  10. Psychologique - un big red "V" sur un projet, avec les pairs et la pression de la direction pour «ne pas laisser cela se produire à nouveau." Comment ce mécanisme fonctionne bien dans le temps est une fonction de la culture et de la gestion des objectifs.

Conseils sur la mise en œuvre

Avez-vous besoin d'attendre que l'architecture est tout défini à aller de l'avant avec un processus de gouvernance proactive? La logique voudrait oui. Cependant, la définition pleinement une architecture d'entreprise prend beaucoup de temps, et à bien des égards, en raison de changer, n'est jamais complète. Une approche plus réaliste est «juste assez l'architecture à des projets directs ainsi que les dimensions critiques". Ces dimensions découlent des intérêts de l'organisation IT dans la gouvernance de l'architecture en premier lieu. Gouvernance nécessite un changement de culture, et la lutte contre le changement de culture, d'établir une norme de revues de conception pour les projets, peut mieux être dissociée de définition de l'architecture. Les facteurs critiques peuvent être établissant:

  • Les critères que les projets sont mesurés contre et
  • Valeur
  • de commentaires, même quand ils sont «informationnelle» dans l'identification des problèmes et des opportunités.

Un des critères clés de succès, souvent négligés par les «architectes introvertis», est «Communications, communications, et plus de communication». Les objectifs du processus d'examen et doivent être bien comprises. Les règles concernant la conduite des analyses, et comment les résultats de l'examen devraient être reflétées dans un livrables du projet, doivent être documentés et communiqués. Discussions minutes devraient être documentées et mises à la disposition de toute personne associée à un projet ou à un besoin de savoir. La formation devrait être offerte aux gestionnaires de projet. Le processus doit être «libre et équitable» - pas un processus mystérieux avec des gagnants et des perdants.

Ne négligez pas la nécessité de mesurer et communiquer la valeur des processus de gouvernance. Identifier ce qui doit être mesuré sur la base des intérêts de l'organisation, ainsi que les intérêts de l'équipe de projet. Certaines mesures possibles sont les suivantes:

  • Le nombre de projets examinés comme une partie de l'ensemble du portefeuille de projets, ou de le dépenser.
  • Résultats classés par catégorie: projets approuvés, approuvé avec conditions, en attendant l'approbation ou refusée.
  • Types
  • des questions d'architecture soulevées et examinées.
  • La fréquence relative des différents types d'écarts d'architecture étant demandés ou autorisés.

Quis custodiet ipsos custodes? ("Qui surveille les surveillants?")

Cet article se concentre sur la façon de gagner le respect d'une architecture d'entreprise. Cependant, il est important de reconnaître la nécessité de conserver l'architecture pertinente et utile. Comment la direction savait que l'architecture est pratique, bien définies et bien ciblé?

Malheureusement, il n'existe pas de normes généralement acceptées pour une architecture d'entreprise. Les auteurs de ce document ont vu très peu d'architectures d'entreprise soutenus par chiffres précis de réduction des coûts, amélioration de la qualité ou de réduction du temps de livrer. En l'absence de ces mesures de soutien pour l'architecture d'entreprise dépend de la qualité perçue du processus de l'architecture.

Le processus de gouvernance définies ici fournit quelques informations sur ces questions et les renseignements recueillis à partir des revues de projet doit être une entrée dans la prochaine évolution de l'architecture. Cependant, il doit aussi y avoir un processus formel de gouvernance pour le développement, l'adoption et le maintien de l'architecture elle-même.

Conclusion

Projets de développement d'applications

informatiques sont souvent confrontés à «la voie rapide par rapport à la bonne manière» décisions. Les équipes de projet sont tous trop familiers avec les résultats des années de mise en application sans plan directeur, que les résultats ont fait leur tâche actuelle plus difficile. Les pressions pour livrer ne leur donnent pas le temps ni la place pour considérer considérations d'architecture primordiaux. Un processus d'examen et de la gouvernance est essentielle pour faire contrepoids à ces pressions à court terme, alors même que «plan directeur» de l'architecture est un catalyseur des prestations de développement à long terme.

Si l'architecture d'entreprise est d'être efficace, il doit être intégré à la gestion du projet à travers un processus de gouvernance qui soit compatible avec la culture de gestion. La gouvernance doit s'appuyer sur les intérêts de l'organisation IT et les processus de développement d'applications en cours d'utilisation. Il devrait être construit comme un processus de bout en bout, en commençant par le lancement d'un projet, et sensible aux décisions de conception qui sont faites tout au long du cycle de vie du projet. Pour parvenir à l'organisation de buy-in, une large participation doit être recherchée. Règles sur les conséquences de la non-conformité doivent être clairs.

Définition d'une architecture informatique, que ce soit au niveau de l'architecture des applications, ou des normes techniques, est un investissement important de temps et d'énergie Enterprise. La valeur de cet investissement est réalisé à travers des projets de développement d'applications. Architecture d'entreprise Gouvernance est un complément essentiel à la définition de l'architecture.

Les auteurs

Alex Cullen est le directeur de l'architecture d'application à John Hancock Financial Services.

Jon Blunt est le directeur exécutif de l'Information Architects Cooperative (AITC), une association d'architectes d'entreprise à partir d'une variété de grandes entreprises.

Commentaires sur cet article peuvent être envoyées à Alex à acullen@jhancock.com, ou Jon à jblunt@infoed.com.

Note de

éditeur:. Cet article a été modifié de sa forme originale depuis la date de publication originale

 
comments powered by Disqus

Recherches récentes :
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.