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…

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.

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 !

Reinout