Comme je commence à étudier le sujet, ce que je comprends de l'urbanisation du SI est qu'elle est une méthodologie qui permet de rapprocher les processus métiers des aspects techniques de l'informatique, pour faire évoluer tout le monde dans le même sens et de manière cohérente.
 
Parmi les différentes méthodologies il semblerait que TOGAF soit une des plus populaires.
 
Est-ce que des membres du forum sont architectes/urbanistes ? Pouvez-vous partager votre expérience en la matière ? Utilisez-vous des méthodes autre que TOGAF ?

Hello,
Pour la partie architecture réseau
Perso, non car tu fais toujours dans le prévisionnel logique même si la plus part du temps tu as des changement radicaux ))). Après tout dépend dans quelle boite tu es et quels sont leurs moyens. Qui drive quoi et qui annonce la couleur lors du bilan capex/opex.

 
Salut,
 
Je crois qu'on ne parle pas de la même chose. Ou peut-être que tu dois expliquer un peu mieux ce que tu fais.

Salut,
 
Je suis urba depuis un certain temps.
L'objectif de l'urbanisme SI est bien (entre autres missions) de faire en sorte que le SI soit correctement aligné avec la stratégie de l'entreprise, tout en étant optimisé, flexible et évolutif. La vision est plutôt macroscopique et l'urba intervient en support au métier, aux managers et aux équipes techniques.
TOGAF est une methodo comme une autre, qui a le mérite d'être rigoureuse, surtout quand une entreprise découvre la démarche d'urbanisme, mais pas toujours efficace suivant l'organisation de l'entreprise (je ne l'utilise pas, je prends des libertés).  
La question du moment: comment rendre compatible urbanisme et agilité...

 
En fait c'est amusant que tu dises ça parce qu'en préambule du bouquin que je lis, ça dit justement que TOGAF est particulièrement "agile" de base car tu peux faire toutes les itérations que tu veux au sein même de la roue de TOGAF.
 

 
En théorie ça a l'air simple. Tu sembles dire qu'en pratique ça l'est moins ?

Écueil classique dans lequel tombent les entreprise achitects qui cherchent à faire Agile   : il ne faut pas confondre rendre la methodo urba agile (ça c'est facile et bénéfique) et faire intervenir les principes et études urba auprès des équipes de dev qui font de l'agile. Là, pb, car points de vue a priori incompatibles...

 
C'est bien de la méthodologie (TOGAF) elle-même dont il est question, et que celle-ci s'inscrit bien dans une démarche agile. Il ne s'agit pas d'interférer dans la méthodologie utilisée par les dév.
 
Cela dit, l'approche TOGAF, et son architecture logicielle modulaire, me semble compatible avec l'agilité. Peut-être que non, mais je veux bien que tu détailles dans ce cas.

Faire une analyse urba avec une démarche type agile (ou plutôt itératif flexible, car rien à voir avec Agile) à la togaf ou autre, c'est très bien. Mais si les équipes de dev n'ont rien à faire des conclusions urba parce qu' ils ont leurs use cases et leur cycle scrum avec iterations et résultats courts, bah tu pédales dans la semoule...

Je t'invite à lire l'article "agile & enterprise architecture" de arpan acharya

 
Ok je crois que je viens de comprendre ce que tu expliques. En gros l'agilité (Scrum) chez les dévs serait a priori incompatible avec la démarche TOGAF du fait qu'ils vont procéder par une approche qui tient plus du prototype minimaliste qui évolue au fur et à mesure de leurs itérations, plutôt qu'une structuration modulaire bien propre qui a priori nécessite plutôt un cycle en V.
 
Est-ce bien résumé ? ^^
 
Dans tous les cas je vais essayer de dégoter ce bouquin.

Oui c'est cela.
Mais il ya un espace pour la synergie

 
D'accord. Mais en effet, dans le bouquin que je lis, il est plutôt question du côté "itératif et flexible" (je te cite) de la démarche TOGAF elle-même, sans aucun lien avec la méthodologie choisie pour les éventuels développements. Mais je lirai certainement plus tard l'autre ouvrage que tu recommandes.
 
Est-il possible d'en savoir plus sur ton expérience ? Je ne suis pas urbaniste mais je m'intéresse à ce métier, tout feedback est le bienvenu.

Il n'y a pas qu'un métier   chaque entreprise a sa propre vision du rôle et de la place de l'urbanisme. Certains seront proches du top management et de la stratégie d'entreprise, d'autres feront plus d'architecture et d'autres des études fonctionnelles. Les plus chanceux aborderont toutes les strates d'analyse, du métier jusqu' aux environnements infra, mais cela me semble utopique d'être bon partout.

C'est un métier qui demande beaucoup de connaissance du business et de l'environnement applicatif de l'entreprise. Et aussi un bon relationnel (argumentation, compromis, pédagogie,...).
Et globalement, il s'agit d'éclairer des discussions sur des solutions par une recherche d'efficacité long terme et à l'échelle de l'entreprise.

Ok pour les considérations générales (osef ), c'est ton expérience en particulier qui m'intéresse.

Ça ce raconte pas si simplement sur un forum.  

 
ok
 
Y a-t-il d'autres architectes d'entreprise / urbanistes SI sur le forum ?

Je serai preneur aussi de retour, j'envisage un poste dans ce domaine à moyen terme

Bonne question !
 
 
Moi aussi. Mais qu'est ce que "Architecte système" ?

De but en blanc je dirais que c'est le mec chef d'orchestre qui conçoit les plans d'un système d'exploitation.
 
Genre archi logiciel mais niveau supérieur. Peut être que je me trompe ceci dit.

je pense oui

Si on parle d'architecte système, visiblement wikipedia n'a pas l'air de contredire mes propos.
 
Par contre si on parle de la notion d'architecte de système d'informations, effectivement ça n'a rien à voir.

mmm Wikipedia = la référence ??? allons, allons...
 
Architecte Système et Réseaux par exemple, c'est lui qui va décider de quel solution technique et comment on va la mettre en place par rapport à un besoin informatique ou une problématique...
 
Je décide de mettre 2 ESX en redondance sur tel site, de mettre du wifi, bref ....  
 
Architecte Developpement c'est la même chose mais sur la partie developpement...
 
QUand on parle urbanisation du SI, on se rapproche plus de l'architecture système et réseaux...
 
 
Il doit connaitre :  
La stratégie de l'entreprise.
Les couches métiers, fonctionnelles, et technique.
 
Il doit avoir une vision IT et une vision Métier idéalement.
 
 
Donc rien avoir avec une personne qui conçoit les plans d'un système d'exploitation.

Ce n'est pas de l'urbanisation du SI.

"rapprocher les processus métiers des aspects techniques de l'informatique" (il manque une étape dans la phrase)
C'est de l'alignement stratégique ou gouvernance des systèmes d'information... loin, loin de l'urbanisation.
La gouvernance ou co gouvernance est de comprendre en quoi le SI supporte, améliore, répond aux besoin des métiers et à la stratégie de l'entreprise...la valeur ajouté du SI
A ce stade on se fout de la technique.

On commence généralement par du du BPM (business process management): modélisation des processus métiers
Comment fonctionnent les métier, les flux informationnels.
Comment on les optimise, les sécurise (avec du contrôle par ex), les simplifie.
... toujours pas de technique.

A partir de là on cherche les tâches à non valeur ajouter afin de les automatiser (éviter les ressaisie par ex.)

A coté de ça on peut lancer un petit audit COBIT
On va travailler sur des axes: intégrité, disponibilité, sécurité, cohérence des datas, etc etc.
Et en plus, connaitre le taux d'adéquation SI/métier et connaitre les axes a travailler (en fonction de la stratégie de l'entreprise/métiers)
... toujours pas de technique.

On a une photo des  flux métiers (BPM), une photo de l'état de gouvernance (cobit), une idée des axes à améliorer (stratégie, besoins)...
Bien évidement on a une cartographie du réseau, systèmes, des flux datas au sein et entre appli, etc. etc. le tout à jour.
On créer un portefeuille projet et on priorise.
... toujours pas de technique.

On lance les projets: ayé! on entre dans la technique... mais quelques mois sont déjà passés

 
J'ai l'impression que nous sommes d'accord mais que nous ne nous sommes pas compris.
 
La gouvernance du SI indique quels sont les objectifs à atteindre.
L'urbanisation (ou architecture) du SI analyse (ou sait) d'où on part et montre le chemin à suivre.
Le BPM c'est précisément un outil de l'urbanisation (architecture) du SI.
 
Tu as l'air de penser que l'urbanisation du SI est technique (ou alors tu crois que j'associe l'urbanisation à la technique, mais ça n'est pas le cas).
L'idée est qu'il faut du lien entre le métier et la technique, et que dans un monde idéal, c'est un architecte (ou urbaniste) qui s'occupe de faire ce lien.
Et j'explique ici que c'est (en théorie) en amont des projets d'évolution du SI.
 
Est-ce plus clair exprimé comme cela ?

Si si j'avais bien compris

On peut dire ça ainsi, même si ça va plus loin.
On utilise généralement l'outil COBIT pour ceci et se donner les axes d'amélioration: on a une photographie de l'état de gouvernance par rapport à un benchmark.

En parallèle, mais plutôt en amont, on lance un BPM

Le BPM n'a rien à voir avec le SI: on étudie les processus métier, on les cartographie.
Ce n'est pas un outil SI (donc pas un outil d'urbanisation), mais un outil métier.
(j'ai donné d'autres détails en amont sur le bpm)

A ce stade on a une photographie de nos processus et de l'alignement stratégique (+les autres axes COBIT)
On commence le travail par une optimisation des processus... c'est au niveau métier.

Une fois fait, et avec la stratégie de l'organisation (au niveau métiers et entreprise), on met en place le schéma directeur sur les axe à travailler.

Maintenant et seulement maintenant on entre dans le SI... pas encore dans l'urbanisation.
On cartographie: CMDB/CMS, applis, données, ...

Maintenant nous disposons des stratégies métiers et de l'organisation.
Nous disposons de l'etat de gouvernance
Nous disposons des cartographies fonctionnelles et processus, voire procédures
Nous disposons des cartographies IT

Maintenant on urbanise

Je ne suis pas d'accord, l'urbanisation ne nous montre pas le chemin à suivre, c'est déjà fait... on est dans l'opérationnel: on fait suivant le plan déjà établit en amont.

On pourrait résumer ainsi:
On construit ou planifie la construction (urbanisation) en fonction d'un plan (stratégie) pour aligner (gouvernance) le SI (CMDB/CMS, applis, données, ...) avec les besoins métiers (BPM)

L'urbanisation n'est pas pour moi l'étape finale, c'est bien une pratique qui couvre toutes les étapes que tu cites : analyse de l'ensemble des strates de l'entreprise (et encore, ce n'est que l'urbanisme stratégique, soit seulement l'une des missions de l'urbanisme). Enfin c'est comme ça que je la pratique  

J'entends mais regardons la dénomination même: urbanisation du SI (pas des métiers, mais bien du SI).
On parle management stratégique pas urbanisme stratégique, qui n'existe pas... WTF?

 
C'est peut-être aussi pour ça qu'on l'appelle architecture d'entreprise (d'où le titre du topic) ?  
 
Cela dit, ça dépend simplement des responsabilités confiées à l'architecte/urbaniste en question.
Certains auront des rôles plus étendus, d'autres plus limités, à la manière de chefs de projet ou autres ingénieurs aux intitulés de postes parfois galvaudés.

 
Si tout le monde commence à raconter tout et n'importe quoi en galvaudant les définitions mêmes ou en inventant des "urbanisme stratégique"... c'est du grand n'importe quoi.
 
La 1ère règle des référentiels (c'est le niveau foundation des certifs) est d'avoir un même vocable pour que tout le monde parle de la même chose sans perdre de temps en palabres inutiles (ce que nous faisons là).
 
Donc je vous laisse à vos ça dépend parce que ça dépasse... les échanges auraient pu être intéressant.

C'est justement ce que tu sembles faire en attribuant le nom d'urbaniste à des personnes qui ne s'occupent "que" de la technique. L'architecte d'entreprise ou urbaniste des SI est bien plus que ce que tu lui attribues, et si tu as rencontré des urbanistes SI qui n'étaient "que" des architectes techniques alors tu as travaillé en effet pour des entreprises qui galvaudaient ce titre ou cette fonction et tu propages leur erreur en tenant le même discours.
 

Ce n'est pas à moi qu'il faut dire ça, tu peux répondre à l'intéressé.
 

 
Ces quelques lectures devraient t'aider à dépasser ce malentendu.
 
Définition Wikipedia
"L'architecture d'entreprise (AE) (discipline souvent appelée en France Urbanisation informatique) est une démarche qui consiste à mettre en place un cadre d'architecture de référence et à aligner les objectifs métiers avec les composantes des systèmes d'information. Ainsi l'AE définit une composante de la stratégie informatique au travers du cadre de présentation des technologies et des processus. En procurant une meilleure connaissance de son patrimoine informatique, l'AE contribue à une meilleure agilité du SI en réponse aux évolutions rapides des organisations et des stratégies métiers."
 
Présentation Wikipedia de TOGAF
[...]
A : vision de l'architecture
B : architecture business
C : architecture des systèmes d'information
D : architecture technologique
E : opportunités et solutions
F : planning de migration
G : gestion de l'implémentation
H : gestion du changement d'architecture.
[...]
Au cours de l’exécution d’un cycle ADM, un certain nombre de sortants sont produits : processus, exigences d’architecture, plans de projets, etc. Le Cadre de Contenu (Architecture Content Framework ou ACF) fournit alors un métamodèle, offrant une classification standardisée de ces éléments. L’objectif est de les structurer de façon cohérente en définissant des relations pour chacun d’entre eux, formant l’Architecture d’Entreprise.
[...]
 
On pourrait rentrer plus en détail de la méthode TOGAF et de ses outils (exemple : ArchiMate), mais je me demande pourquoi tu n'en démors pas alors que tous les éléments sont là pour te montrer que tu te trompes.
 
Par ailleurs, ne viens pas me la faire à l'envers en me disant que Wikipedia est bidon parce que je suis justement en train de préparer ma certification TOGAF et je peux t'assurer que ce qu'il y a écrit est correct.
 
Ce que tu ne sembles pas intégrer, c'est qu'un architecte d'entreprise n'est pas obligatoirement un membre de la DSI et qu'il peut très bien faire partie du métier, tout comme un MOA représentant le métier pourrait être embauché dans un DSI... Peu importe le département où il est embauché en fait, et peu importe qu'on l'appelle urbaniste des SI ou architecte d'entreprise.
 
Tu peux éventuellement prendre connaissance de cette offre d'emploi trouvée sur l'apec qui est bien raccord avec ce que je te dis.
 
Ou tu peux aussi voir cet article sur un site spécialisé qui inclue même des notions de gouvernance.

En effet  
Quoi qu'il en soit, un urba ou équivalent doit savoir sortir du cadre théorique (et des methodos officielles qu'il faut savoir dépasser) pour s'adapter aux besoins de l'entreprise. Il n'est donc pas étonnant que la fonction varie d'une entreprise à l'autre...

Ne n'ai jamais dit ca, surtout que le terme que l'on emploi généralement est non gouvernance mais co-gouvernance des SI donc piloté par les métiers.

Ensuite pour TOGAF je n'ai jamais dit qu'il ne prenait pas en compte l'ensemble des strates de l'entreprise.
Encore une fois il faut lire les choses.
Je dis simplement que c'est un projet d'entreprise ou à chaque strate, il y a un travail à faire:
- non seulement de photographie et je pense qu'un seul outil (en l'occurrence TOGAFF) ne peux couvrir tous les champs car chaque partie à des outils extrêmement performant
- Mais surtout repenser chaque partie pour améliorer la performance globale de l'entreprise, et là encore, ce n'est pas le rôle de TOGAF.

Dans ton exemple, tu surlignes architecture business... je suis désolé mais ce n'est pas TOGAFF qui va t'apporter les outils du management stratégique, discipline qui concerne la stratégie d'entreprise.

Quel est le but de l'outil?
créer une architecture SI orienté business dans le but d'améliorer les performances du SI

Si le process business est mauvais, l'urbanisation des SI ne l'améliorera pas
Par contre, ce que j'ai expliqué depuis le début le fera lui

Le problème, et c'est flagrant chez les techniques, est que tu vois le SI comme la solution alors que ce n'est qu'un outil (si tu ne sais pas planter un clou, tu peux avoir le meilleur marteau du monde... tes clous seront toujours de travers).
D'où l'incompréhension de ce que j'explique depuis le début.

Après tu peux me balancer les liens que tu veux, j'ai une formation initiale technique doublée d'une formation initiale en gestion d'entreprise (IAE). Et en tant qu'ancien manager de transition et DSI, des projets comme celui-ci j'en ai fait quelques uns.
J'essaye juste d'expliquer la différence entre l'outil (le SI) et la solution (les process) et que ce sont bien des disciplines différentes et que ton référentiel Togaf ne peut pas faire pas les 2.
Tu ne veux pas l'entendre et tu veux avoir raison... très bien, que veux tu que je te dise d'autre.

 
Je mets de côté :
- ton argument d'autorité qui n'apporte pas grand chose à la discussion (ok tes diplômes et ton expérience sont chouettes),
- ton souhait de me faire dire que l'IT est magique et résout tous les problèmes sans même que je n'ai esquissé l'ombre de cette idée,
- ton raccrochage aux branches en essayant de parler de stratégie alors que le but de mon argumentation est uniquement de déconstruire ton idée que l'architecte est un pur technicien de l'informatique.
 
Je tente une dernière approche : ici ça dit bien que des outils comme UML ou BPMN font partie des outils servant l'architecture business.
 
Non, l'architecte ne se contente pas d'apporter des solutions techniques à des processus métier tout fait. Son rôle est aussi de modéliser les processus et doit donc pouvoir challenger un processus métier.
Et si, justement, il est là pour réconcilier les process métier avec l'évolution du SI sur le plan technique, c'est là tout l'enjeu de ce job.
 
Cependant, si le responsable/directeur du métier se fourvoie en considérant que l'architecte d'entreprise "n'est qu'un informaticien qui essaie de m'apprendre mon métier, mais quel connard" alors en effet, ça ne sera que rarement productif.
Et réciproquement, s'il est hiérarchiquement rattaché au métier, il se peut qu'il se trouve à parler à un DSI qui se dirait que "ce n'est qu'un utilisateur qui essaie de m'apprendre mon métier, mais quel connard".
Ce rôle n'est probablement pas être très simple à endosser dans certaines organisations.
 
edit :  
 

Non, la finalité est d'améliorer les performances du business, le SI n'en est que le support.

Quand on en vient à sortir des blogs, comme tu le fais, pour argumenter... ça me semble plus pertinent.

Comme quoi tu n'as rien lu, rien compris et est bien là pour faire le beau.
Puisque je dis justement le contraire depuis le debut.

Déconstruction... donc tu es bien là pour montrer comme tu es le plus beau et que tu as raison et non avoir une discussion constructive
Amuses toi bien

 
Je passe encore une fois les petits pics parce que ça ne m'intéresse pas. Nous sommes partis sur de mauvaises bases, parce que tu n'apportes plus d'argument et moi je suis intéressé par ton expérience.
 
Peut-on reprendre à partir du moment où le malentendu est arrivé ?
 
Je cherche à comprendre pourquoi ta vision basée sur ton expérience semble être différente d'un référentiel (théorique) largement partagé :
- soit ma compréhension du référentiel est erronée (c'est possible),
- soit ton expérience est particulière (c'est possible),
- soit nous sommes d'accord mais notre manière de nous exprimer ne nous permet pas de le vérifier (c'est possible aussi).
 
Je suis prêt à tout lire et entendre, mais il me faut des arguments, pas juste de la gentille invective.

Salut à tous,
 
Le topic avait été pourri par quelqu'un qui pensait tout savoir sur tout, et moi je contnue de citer mes sources.
 
Je confirme et je signe le fait que UML ou BPMN font bel et bien partie des outils de l'architecture d'entreprise - ou tout du moins de la méthodologie TOGAF qui est une méthodologie de référence -, et qu'il en est fait mention dans toute une section du livre que je lis au sujet de cette méthodo.
Ce ne sont pas des outils réservés aux métiers, et bien heureusement.
 
Je recommande d'ailleurs ce livre qui s'appelle "TOGAF en pratique" (2ème édition), écrit par Philippe Desfray et Gilbert Raymond, et vous pouvez regarder toute la section 6.2 qui s'y rapporte.
 
Je continue à étudier ce sujet parce que je trouve cette méthodologie bien faite, avec ces 4 niveaux d'architecture :
- architecture métier
- architecture des données
- architecture applicative
- architecture technique
 
Et cette méthodologie bien détaillée me permet d'avoir une bonne approche des concepts de l'architecture d'entreprise et de sa gouvernance.
 
De manière générale, sauf pour les fiches de postes dans des sociétés qui utilisent visiblement TOGAF, je vois qu'on parle plus souvent de schéma directeur et de seulement 2 niveaux d'abstraction de l'architecture : fonctionnelle et technique.
 
Qui ici occupe un poste d'Architecte d'entreprise (ou d'Urbaniste SI puisque c'est son autre petit nom) ? Quelqu'un pourrait me dire si son rôle se cantonne à celui d'architecte ou s'il pilote en plus les projets que le schéma directeur lui "impose" ?

Accompagner les équipes de développement dans la mise en place de ce que préconise le sdsi fait selon moi partie du job (le mien en tout cas). Il ne s'agit pas de piloter mais de contribuer au design détaillé, dans un esprit de co construction: participer aux ateliers préliminaires, se mettre d'accord sur les détails qui n'auront pas été vus, conseiller.
Faut pas rester dans sa tour d'Ivoire, quoi...

Remarque : ça n'est probablement pas possible quand le sdsi est fait par un consultant qui se barre à la fin de la prestation, comme ça se voit souvent.

 
Pour rappel, tu as écrit cette ânerie :
fookooflakman a écrit :
Le BPM c'est précisément un outil de l'urbanisation (architecture) du SI.
 
Je te renvoie à la définition du BPM/N: https://fr.m.wikipedia.org/wiki/Bus [...] d_notation
 
Une chose est certaine, tu n'as jamais fait de BPMN  
 
et beaucoup de chose que tu avances prouve que tu n'as abordé le sujet de l'urbanisation que d'un point de vue théorique.
Tout comme lorsque tu abordes la gestion de projet en parlant de Scrum et du cycle en V, on voit bien que tu ne connais ni les approches agile ni les approches  prédictive.
 
Et tout le long c'est comme ça.
 
Essayes d'aborder honnêtement les discussions, plutôt que de faire croire que tu maîtrises des sujets que visiblement tu n'as que survolé.
Ça ferait plus avancer les choses
 

Je vais déterrer un vieux post mais bon.
 
Pour ceux qui sont urbanistes, vous avez quoi comme formation/exp/background ?
 
Je pense m'orienter vers ce métier sur le moyen termes.
 
Je suis admin sys alternant pour le moment, je voudrais faire de l'AMOA avant de basculer sur l'urbanisation.

 
ma boite fusionne avec une autre grosse boite équivalente, et pour le futur groupe des postes d'urbaniste sont ouverts et je me suis positionné dessus (mobilité interne), ca sera pour moi l'occasion de me détacher un peu du quotidien et de la pression en prod, et d'avoir une vision plus large en sortant des compartimentations d'organigramme.
J'y vais un peu avec ma mÿthe et mon couteau, j'espere que ca ne sera pas un dead end

Intéressant, tu peux donner plus de détails ?
 
Vous avez du legacy, cloud ? Plusieurs environnements ?