Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
2129 connectés 

  FORUM HardWare.fr
  Systèmes & Réseaux Pro
  Management du SI

  Urbanisation SI / Architecture d'Entreprise

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Urbanisation SI / Architecture d'Entreprise

n°144339
fookooflak​man
Posté le 20-01-2017 à 18:22:41  profilanswer
 

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 ?

mood
Publicité
Posté le 20-01-2017 à 18:22:41  profilanswer
 

n°144852
CISCOCOM7
Posté le 17-02-2017 à 14:07:14  profilanswer
 

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.

n°144881
fookooflak​man
Posté le 20-02-2017 à 16:56:32  profilanswer
 

CISCOCOM7 a écrit :

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.

n°145057
Chaju
Posté le 01-03-2017 à 11:56:23  profilanswer
 

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é...

Message cité 1 fois
Message édité par Chaju le 01-03-2017 à 11:57:21
n°146572
fookooflak​man
Posté le 16-05-2017 à 11:49:49  profilanswer
 

Chaju a écrit :

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.
 
http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/adm.png
 
En théorie ça a l'air simple. Tu sembles dire qu'en pratique ça l'est moins ?

n°146581
Chaju
Posté le 16-05-2017 à 20:03:17  profilanswer
 

Écueil classique dans lequel tombent les entreprise achitects qui cherchent à faire Agile  :o : 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...

n°146594
fookooflak​man
Posté le 17-05-2017 à 11:30:01  profilanswer
 

Chaju a écrit :

Écueil classique dans lequel tombent les entreprise achitects qui cherchent à faire Agile  :o : 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. :)

n°146724
Chaju
Posté le 23-05-2017 à 11:47:52  profilanswer
 

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

n°146725
fookooflak​man
Posté le 23-05-2017 à 11:59:40  profilanswer
 

Chaju a écrit :

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.

n°146727
Chaju
Posté le 23-05-2017 à 13:29:44  profilanswer
 

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

mood
Publicité
Posté le 23-05-2017 à 13:29:44  profilanswer
 

n°146730
fookooflak​man
Posté le 23-05-2017 à 14:10:11  profilanswer
 

Chaju a écrit :

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.

n°146735
Chaju
Posté le 23-05-2017 à 16:56:00  profilanswer
 

Il n'y a pas qu'un métier  :o 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.

n°146737
fookooflak​man
Posté le 23-05-2017 à 17:07:05  profilanswer
 

Chaju a écrit :

Il n'y a pas qu'un métier  :o 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 :o ), c'est ton expérience en particulier qui m'intéresse. :jap:

n°146753
Chaju
Posté le 23-05-2017 à 21:47:42  profilanswer
 

Ça ce raconte pas si simplement sur un forum.  :o

n°146807
fookooflak​man
Posté le 25-05-2017 à 15:19:17  profilanswer
 

Chaju a écrit :

Ça ce raconte pas si simplement sur un forum.  :o


 
ok [:klm:1]
 
Y a-t-il d'autres architectes d'entreprise / urbanistes SI sur le forum ?

n°146818
true-wiwi
Posté le 26-05-2017 à 13:28:34  profilanswer
 

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


---------------
J'essaie de ne pas vivre en contradiction avec les idées que je ne défends pas.
n°148341
locatek
Posté le 12-08-2017 à 17:01:16  profilanswer
 

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

n°148342
true-wiwi
Posté le 12-08-2017 à 22:06:35  profilanswer
 

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.


---------------
J'essaie de ne pas vivre en contradiction avec les idées que je ne défends pas.
n°148344
Je@nb
Modérateur
In ze cloud
Posté le 12-08-2017 à 23:20:31  profilanswer
 

true-wiwi a écrit :

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


Message édité par Je@nb le 12-08-2017 à 23:21:03
n°148345
true-wiwi
Posté le 13-08-2017 à 08:39:28  profilanswer
 

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.


---------------
J'essaie de ne pas vivre en contradiction avec les idées que je ne défends pas.
n°148530
PsYKrO_Fre​d
Posté le 23-08-2017 à 10:15:08  profilanswer
 

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.

n°148608
akabis
.
Posté le 24-08-2017 à 17:26:44  profilanswer
 

fookooflakman a écrit :

... 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.


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

Message cité 1 fois
Message édité par akabis le 24-08-2017 à 17:41:30
n°148623
fookooflak​man
Posté le 25-08-2017 à 15:30:01  profilanswer
 

akabis a écrit :


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 ?

n°148627
akabis
.
Posté le 25-08-2017 à 16:10:47  profilanswer
 

Si si j'avais bien compris

 
fookooflakman a écrit :


La gouvernance du SI indique quels sont les objectifs à atteindre.


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

fookooflakman a écrit :


Le BPM c'est précisément un outil de l'urbanisation (architecture) du SI.


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

fookooflakman a écrit :


L'urbanisation (ou architecture) du SI analyse (ou sait) d'où on part et montre le chemin à suivre.


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)

 



Message édité par akabis le 25-08-2017 à 17:02:25
n°148628
Chaju
Posté le 25-08-2017 à 19:07:55  profilanswer
 

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  :o

n°148726
akabis
.
Posté le 04-09-2017 à 09:18:11  profilanswer
 

Chaju a écrit :

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  :o

 

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? :)

Message cité 1 fois
Message édité par akabis le 04-09-2017 à 09:18:28
n°148771
fookooflak​man
Posté le 06-09-2017 à 16:45:48  profilanswer
 

akabis a écrit :

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) ? :p  
 
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.

n°148780
akabis
.
Posté le 07-09-2017 à 09:05:32  profilanswer
 

fookooflakman a écrit :


 
C'est peut-être aussi pour ça qu'on l'appelle architecture d'entreprise (d'où le titre du topic) ? :p  
 
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.

n°148792
fookooflak​man
Posté le 07-09-2017 à 19:48:34  profilanswer
 

akabis a écrit :

Si tout le monde commence à raconter tout et n'importe quoi en galvaudant les définitions mêmes


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.
 

akabis a écrit :

ou en inventant des "urbanisme stratégique"... c'est du grand n'importe quoi.


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

akabis a écrit :

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.


 
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. :D
 
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.

n°148794
Chaju
Posté le 08-09-2017 à 08:49:26  profilanswer
 

En effet  :o
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...

n°148795
akabis
.
Posté le 08-09-2017 à 08:51:10  profilanswer
 

fookooflakman a écrit :

 

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.


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.

Message cité 1 fois
Message édité par akabis le 08-09-2017 à 08:53:35
n°148806
fookooflak​man
Posté le 08-09-2017 à 21:36:05  profilanswer
 

akabis a écrit :


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 :  
 

Citation :

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


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

n°148817
akabis
.
Posté le 11-09-2017 à 08:36:16  profilanswer
 

fookooflakman a écrit :


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),


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

 
fookooflakman a écrit :


- 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,


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.

 
fookooflakman a écrit :


- 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.


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

Message cité 1 fois
Message édité par akabis le 11-09-2017 à 08:37:45
n°148827
fookooflak​man
Posté le 11-09-2017 à 18:19:41  profilanswer
 

akabis a écrit :

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.

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Systèmes & Réseaux Pro
  Management du SI

  Urbanisation SI / Architecture d'Entreprise

 

Sujets relatifs
Serveur PostFix dans une architecture Windows ServerArchitecture de sauvegarde
Nouvelle architecture proxys filtrantsNAS pour petite entreprise
Aide choix cloud entrepriseQuelle architecture pour une petit agence web ?
Architecture réseau pour 220 utilisateursAntivirus Android "d'entreprise"
Fibre petite entreprise, routeur and co 
Plus de sujets relatifs à : Urbanisation SI / Architecture d'Entreprise


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR