In the Netherlands, « SOA » is still a strange acronym… Why? It’s also the Dutch acronym for « sexually transmitted diseases ». Everytime I read this term in IT-related publications, I have to smile…
DOA : Vous voulez dire une architecture qui serait le résultat d’un travail de conception ! Effectivement, le concept est séduisant… ;-)
carnetouvert
Là, c’est pas moi qui l’ai dit… ;-)
bon d’accord, je prépare un billet…
carnetouvert
Chose promise…je m’explique…
Le concept de SOA est à mon avis séduisant. La réutilisation du code a toujours existé et c’est même une pratique nécessaire (pourquoi réinventer la roue !).
Il me semble que l’origine de l’acronyme peut venir d’un sentiment de nostalgie face aux applications réalisées. En effet, de nombreuses applications, nécessitant souvent des années de travail, se trouvent soudainement mises au rebus ; remplacées par une nouvelle plateforme. Il peut donc paraître judicieux d’archiver ce code (développements durables (sic)).
Mais lorsque l’on en vient à écrire du code pour gérer le code que l’on souhaite gérer ad libidum, il convient de s’interroger. (les bibliothèques de bibliothèques)
Hormis ce point, le concept mérite réflexion. Et si je vais vite en besogne, mil excuses.
Les professionnels de la SOA détiennent un savoir colossal : la codification des processus de gestion entre applications (+-EAI). Ils sont souvent au c½ur de l’entreprise et c’est davantage leur capacité à coordonner un ensemble de flux d’information qui doit être retenue. (workflows, GED, intranet, ERP…). En cela les AGL qu’ils développent sont des outils puissants, souvent de véritables systèmes experts.
Et donc du concept de service à celui de conception ( design science, dois-je le préciser ? ;-))…il n’y a qu’un pas !?
En partant du principe que ces AGL sont dédiées à la gestion de contenus (les objets-services). Pourquoi ne pas les détourner de leur utilisation et gérer des objets de connaissance (+-KM ; CMS) ? D’où le concept de DOA.
Tu restes un peu mystérieux sur ton concept de DOA. Je ne suis pas sûr d’en saisir toutes les subtilités. Je ne suis pas familier de la « design science », donc tu as bien fait de préciser. J’imagine que cela concerne l’art et la science d’un Stark ou d’un concepteur de Twingo.
Tu dis que, finalement, on peut considérer les services de la SOA comme des objets à « designer ». Ce point de vue me semble rapprocher la SOA du style architectural REST d’une certaine manière. En poursuivant l’analogie entre services d’une SOA et objets de connaissance, tu proposes de gérer les services d’une SOA avec des outils issus du KM ou de la gestion de contenus.
C’est cette manière d’aborder la SOA que tu appelles la DOA.
C’est bien ça ?
Mon avis :
Ton idée me semble très pertinente mais je n’accroche pas sur le terme de DOA notamment parce que le mot « design » me semble galvaudé en anglais. Quand on parle « design », en français, on pense à des choses genre Stark et c’est ok. Mais en anglais, finalement, design c’est juste conception. Peut-être ton acronyme devrait-il être plus explicite (Design-Science Oriented Architecture ?).
De plus, autant je vois où ton histoire peut mener si on la prolonge autour du KM et des CMS, autant je ne vois plus ce que le « design » vient faire dans le monde du KM et des CMS. Ce n’est pas clair pour moi.
Par contre, sur le fond, je partage la même vision que toi : les services d’une SOA devraient être gérés comme des objets de connaissance. C’est un peu le credo de l' »architecture de l’information » (IA comme « information architecture » et non comme intelligence artificielle). Je pense vraiment que l’IA peut apporter beaucoup aux SOA pour en faire quelque chose de vraiment géré.
AM2 Systems a un discours qui touche un peu à cette approche en utilisant les technologies du web sémantique pour proposer un atelier de modélisation des processus d’entreprise sous forme d’ontologies, atelier qui se transforme ensuite en moteur d’orchestration de ces processus. L’idée de cet éditeur logiciel est que les architectes codifient les processus et services sous forme d’ontologies (ayant une forte dimension « temps) puis que cette base de connaissance serve de point de coordination entre les processus et services (déclenchement d’événements, passage d’information d’un workflow à un autre, supervision, traitement d’incidents, reporting, tableau de bord, etc).
In the Netherlands, « SOA » is still a strange acronym… Why? It’s also the Dutch acronym for « sexually transmitted diseases ». Everytime I read this term in IT-related publications, I have to smile…
Reinout
Plus the title of this message can be translated in « SOA, you won’t get me ! ». Double-smile… :-))
Anecdote SOA
Je m’intéresse à vos billets depuis quelques semaines. Merci.
Pour la petite anecdote, il y a quelques mois, je discutais avec un professionnel de la SOA, et lui proposais le concept de…
DOA : Design Oriented Architecture !
DOA : Vous voulez dire une architecture qui serait le résultat d’un travail de conception ! Effectivement, le concept est séduisant… ;-)
Là, c’est pas moi qui l’ai dit… ;-)
bon d’accord, je prépare un billet…
Chose promise…je m’explique…
Le concept de SOA est à mon avis séduisant. La réutilisation du code a toujours existé et c’est même une pratique nécessaire (pourquoi réinventer la roue !).
Il me semble que l’origine de l’acronyme peut venir d’un sentiment de nostalgie face aux applications réalisées. En effet, de nombreuses applications, nécessitant souvent des années de travail, se trouvent soudainement mises au rebus ; remplacées par une nouvelle plateforme. Il peut donc paraître judicieux d’archiver ce code (développements durables (sic)).
Mais lorsque l’on en vient à écrire du code pour gérer le code que l’on souhaite gérer ad libidum, il convient de s’interroger. (les bibliothèques de bibliothèques)
Hormis ce point, le concept mérite réflexion. Et si je vais vite en besogne, mil excuses.
Les professionnels de la SOA détiennent un savoir colossal : la codification des processus de gestion entre applications (+-EAI). Ils sont souvent au c½ur de l’entreprise et c’est davantage leur capacité à coordonner un ensemble de flux d’information qui doit être retenue. (workflows, GED, intranet, ERP…). En cela les AGL qu’ils développent sont des outils puissants, souvent de véritables systèmes experts.
Et donc du concept de service à celui de conception ( design science, dois-je le préciser ? ;-))…il n’y a qu’un pas !?
En partant du principe que ces AGL sont dédiées à la gestion de contenus (les objets-services). Pourquoi ne pas les détourner de leur utilisation et gérer des objets de connaissance (+-KM ; CMS) ? D’où le concept de DOA.
Mais là, c’est une autre histoire.
Tu restes un peu mystérieux sur ton concept de DOA. Je ne suis pas sûr d’en saisir toutes les subtilités. Je ne suis pas familier de la « design science », donc tu as bien fait de préciser. J’imagine que cela concerne l’art et la science d’un Stark ou d’un concepteur de Twingo.
Tu dis que, finalement, on peut considérer les services de la SOA comme des objets à « designer ». Ce point de vue me semble rapprocher la SOA du style architectural REST d’une certaine manière. En poursuivant l’analogie entre services d’une SOA et objets de connaissance, tu proposes de gérer les services d’une SOA avec des outils issus du KM ou de la gestion de contenus.
C’est cette manière d’aborder la SOA que tu appelles la DOA.
C’est bien ça ?
Mon avis :
Ton idée me semble très pertinente mais je n’accroche pas sur le terme de DOA notamment parce que le mot « design » me semble galvaudé en anglais. Quand on parle « design », en français, on pense à des choses genre Stark et c’est ok. Mais en anglais, finalement, design c’est juste conception. Peut-être ton acronyme devrait-il être plus explicite (Design-Science Oriented Architecture ?).
De plus, autant je vois où ton histoire peut mener si on la prolonge autour du KM et des CMS, autant je ne vois plus ce que le « design » vient faire dans le monde du KM et des CMS. Ce n’est pas clair pour moi.
Par contre, sur le fond, je partage la même vision que toi : les services d’une SOA devraient être gérés comme des objets de connaissance. C’est un peu le credo de l' »architecture de l’information » (IA comme « information architecture » et non comme intelligence artificielle). Je pense vraiment que l’IA peut apporter beaucoup aux SOA pour en faire quelque chose de vraiment géré.
AM2 Systems a un discours qui touche un peu à cette approche en utilisant les technologies du web sémantique pour proposer un atelier de modélisation des processus d’entreprise sous forme d’ontologies, atelier qui se transforme ensuite en moteur d’orchestration de ces processus. L’idée de cet éditeur logiciel est que les architectes codifient les processus et services sous forme d’ontologies (ayant une forte dimension « temps) puis que cette base de connaissance serve de point de coordination entre les processus et services (déclenchement d’événements, passage d’information d’un workflow à un autre, supervision, traitement d’incidents, reporting, tableau de bord, etc).
Intéressant…
Mail au webmaster… Puis double-mail… Est ce qu’il y a quelqu’un?
Je suis là. Je te réponds à ton mail prochainement.
Merci pour ce mail au contenu très instructif. Au final, tout viens à point AkiSic attendre!