L'orientation services est un paradigme qui structure nos actions. L'architecture orientée
services (SOA) est un style d'architecture qui résulte de l'application de l'orientation services.
Nous avons mis en pratique l'orientation services afin d’aider les organisations à délivrer
de la valeur métier durable de façon régulière et avec une agilité et une rentabilité accrues,
tout en tenant compte de la nature changeante des besoins métier.
À travers notre travail nous avons été amenés à privilégier :
La valeur métier par rapport à la stratégie technique
Les objectifs stratégiques par rapport aux bénéfices spécifiques de projets particuliers
L'interopérabilité intrinsèque par rapport à l'intégration sur-mesure
Les services partagés par rapport aux implémentations spécifiques
La flexibilité par rapport à l'optimisation
L'amélioration évolutive par rapport à la quête de la perfection initiale
Respecter la structure sociale et décisionnelle de l'organisation.
Reconnaître que l´Architecture Orientée Services exige en fin de compte des changements à plusieurs niveaux.
Le degré d’adoption de l´Architecture Orientée Services peut varier. Les efforts doivent rester gérables et dans des limites raisonnables.
Les produits et les standards seuls ne nous livreront jamais l´Architecture Orientée Services ni n'appliqueront le paradigme de l’orientation
services à notre place
L´Architecture Orientée Services peut être mise en œuvre à travers une multitude de technologies et standards.
Établir un ensemble uniforme de normes et règles d'entreprise,
fondées sur des standards industriels, de fait et communautaires.
Rechercher l'uniformité dans les échanges avec le monde
extérieur, tout en permettant la diversité en interne.
Identifier les services en collaborant avec les intervenants
métier et des technologies.
Maximiser l'utilisation des services en tenant compte du
degré d'utilisation actuel et futur.
Vérifier que les services satisfont aux exigences et objectifs métier.
Faire évoluer les services et leur organisation en réponse à
l'utilisation réelle.
Séparer les différents aspects d'un système qui ont des taux de
changement différents.
Réduire les dépendances implicites et publier toutes les
dépendances externes pour à la fois augmenter la robustesse et réduire
l'impact du changement.
A tous les niveaux d'abstraction, organiser chaque service autour
d'une fonctionnalité cohérente et gérable.
Ali Arsanjani Grady Booch Toufic Boubez Paul C. Brown David Chappell John deVadoss |
Thomas Erl Nicolai Josuttis Dirk Krafzig Mark Little Brian Loesgen Anne Thomas Manes |
Joe McKendrick Steve Ross-Talbot Stefan Tilkov Clemens Utschig-Utschig Herbjörn Wilhelmsen |
Anthony Assi Jean-Paul De Baets Yves Chaix Florent Georges Mario Moreno |