Anne Thomas Manes published on the Burton Groups’s blog, a SOA obituary. According to her, this is mainly due to the high promises that deceived all CTOs that believed in SOA: more agility, lower costs and shorter project periods.

She also sees the economical context of this coming year as the undertaker of SOA. As these projects are by nature transverse and will go across several business units, the funding of such projects becomes a complex issue: who’s the holder, who’s paying for what. In addition to that, in a reduced budget context, anything non-strategic goes straight to the trash can.

While at the theoretical level, I might agree with part of this vision, we still need to have a deeper look into this to match reality.

Let’s go through a set of questions and analyze it:

1. Why did so many SOA projects fail ?

At the time being, if you ask ten persons what SOA is, you will get 10 different answers. Some will wrongly say web services. Some will call it pure architecture, others will call it methods, others will see it as a combination of the two. A paradigm ?

Then if you ask them why SOA ? They will say agility, they will say reducing costs, they will say enhanced governance and they will say easier evolutivity of the systems (versus siloed and obsolete technologies).

All these answers are plain marketing. These are vendor fictional noveling to sell software and projects. The reality behind this is that most decision makers in IT have no idea on what SOA is about, what’s behind the concept and what it takes to build a real SOA project.

Most people will see in SOA a magic wand that will transform their landscape through some kind of sparkling big bang. All older spaghetti cobol systems magically transforming into futuristic orchestrated services based applications.

The fundamental error is there. They define SOA as a goal instead of a mean.

SOA in itself has no purpose and if your system is working fine, keep it there. SOA must be a base for building new applications that will need to interact with existing systems and need to be able to communicate with future (internal and external) bricks of the landscape . Many technologies are associated to SOA, we may cite Software as a Service (SaaS), Business Process Management (BPM), mash-ups and web applications.

SOA must be derived from a business requirement and should not be technologically driven. It must support the implementation of a business process, that goes through different systems, that needs to be monitored through its different milestones and that might need to take in account fast changes (to keep up competitivity).

Transforming the current landscape into services orientation to reduce maintenance costs is a typical error.  This comes from a common confusion between SOA and web services. While you might want to expose an existing functionality as a service to be consumed by a third party application, you may just build a frontal web service that will be invoked. Rather than doing this, many companies will dive into a complex project implementation [reworking] leading to Neverland.

2- How to make SOA projects successful ?

In order to make SOA projects successful, you will need to assess several mitigation points:

a. Do not expect magic: SOA is costy and do not expect a 80% ROI. SOA projects must be appropriately funded by the each involved Line of Businesse at the appropriate balance.

b. SOA must be driven through business needs. A strict governance should be setup with process owners (functional and technical) that will understand all the underlying requirements of its implementation. These two will then monitor the build and runtime. They should be the single point of contact regarding any subjected related to the process.

c. SOA projects are transverse projects. For this purpose they need a common sponsor at the highest level federating all the LOBs effected by the process dealt with.

d. SOAs are based on the principle of reuse of existing business services (a set of lower level [web] services with a business meaning). For this purpose an in-depth analyze should be carried over all the processes that might potentially be effected by the implementation of the new architecture.

e. The transformation should be carried with the support of an architecture framework (e.g. TOGAF, EAF, Gartner’s).

f. Before the implementation project starts, KPIs must be defined. For this purpose, we need to have a common understanding of what the KPIs are, what will be measured, how, what are the business rules and which thresholds should start a preventive action.

g. SOA requires proactivity all along the implementation. It should reflect the process execution in the real world. Interviews with the key-users should be carried in order to have an end-to-end understanding of the processes.

h. Assess the SOA maturity. Before implemeting a Service Oriented Architecture, the organization must ensure that they have the required level of maturity at both the business and technical level allowing them to reach their targets.

3- Are Service Oriented Architectures really dead ?

Service oriented architecture is just a marketing name to define the principle of resources available as a service. These services represent a business object (e.g. credit check) and are orchestrated in order to create a business process.

While this might look new and innovative, this has long been implemented in several industries, only under different names. The main change today resides into the maturity of the underlying technologies and their standardization. As part of the natural life cycle of an IT landscape, systems will adopt new architectural paradigms, including the service approach. Several technologies are there to stay or evolve. They are coercedly linked to the service oriented architecture.

SOA is there to stay. The only thing that might change is really just the name.

Note: This post was also posted on the SAP Developer Network

* ROI : Return On Investment (Retour sur investissement)
* SOA: Service Oriented Architecture, voir article SOA explained

La SOA (Service Oriented Architecture) représente depuis quelques années l’un des principaux maux de tête des DSI, des architectes, des éditeurs et des sociétés de conseil. Gartner prévoit que 80% des  projets informatiques seront basés sur la SOA en 2008. Aujourd’hui, 40% des entreprises démarrent des projets dans ce même sens. Cependant, on trouve difficilement une définition communément admise de la SOA.
Je me propose d’être votre guide afin de mieux appréhender cette notion plus ou moins obscure. Nous vulgariserons l’ensemble des concepts au delà des aspects techniques (qui ne seront pas traités dans cet article).

Selon Gartner :

Developers will shift their focus to business processes and away from software functionality. In turn, software will become a facilitator of rapid business change, not an inhibitor. The value creation in software will shift to subscription services and away from packaged software, and to composite applications (i.e., best of breed) and away from monolith suites.
By 2006, more than 60 percent of the $527 billion market for IT professional services will be based on Web services standards and technology. By 2008, 80 percent of software development projects will be based on SOA.  The distinction between software integrators and vendors will blur as packaged applications are broken apart and delivered as service-oriented business applications.

Le mot architecture peut prendre différents sens. Il peut représenter d’une part une description d’un système (image d’un environnement à un instant donné) ou représenter l’acte de conception, ce qui implique une notion de mouvement. Dans chacun des cas, on peut faire un parallèle avec les différentes notions autour de la SOA, selon que l’on parle de technologie ou de méthodologie.

L’OASIS définit la SOA comme suit :

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Si l’on suit cette définition, la SOA serait donc un paradigme. Elle n’est ni technologie ni méthodologie, mais une manière de concevoir des composants distribués réutilisables offrant un certain nombre de possibilités (exposition, découverte des services, consommation des services..).

Ainsi on en vient à la définition de la SOA comme étant une architecture applicative utilisant des composants logiciels (services) autonomes, réutilisables, faiblement couplés, exposés (par des fournisseurs) et consommés par des utilisateurs (appelés consommateurs) afin de répondre à des besoins spécifiques métier.

Le principe consiste à réutiliser un composant existant exécutant une fonctionnalité métier (eg. virement bancaire), et de le doter d’une interface de communication basée sur des standards. Ce dernier est référencé dans un annuaire ou un dépôt de services (Enterprise Services Repository) de manière à ce que l’on puisse le retrouver de manière simple à travers la phase de découverte puis d’y faire appel (consommation).

L’idée derrière ce concept est de s’éloigner des solutions orientées technologies pour pour privilégier une orientation métier centrée sur les processus. En se concentrant sur ces services, les applications sont agrégées pour répondre à des besoins opérationnels de manière plus significative et en alignement avec les objectifs de l’entreprise.

Une application ne pourra jamais répondre à elle seule à tous les besoins de l’entreprise. Il y’aura toujours des fonctionnalités manquantes, ansi une entreprise aura nécessairement besoin de plusieurs applications pour mettre en oeuvre ses processus opérationnels.

Au sein de ces différentes applications, nous identifierons les différentes fonctionnalités utilisées pour exécuter un processus et les exposerons, elles deviendront alors des services, représentant une vue logique de la part des utilisateurs. Ces services seront alignés de manière plus fidèle aux processus opérationnels éliminant ainsi les limitations des entreprises qui étaient contraintes d’adapter leur vision à la technologie. Par ailleurs, cette notion de services prend un sens plus large lorsqu’elle intègre des opérations effectuées auprès des partenaires et fournisseurs en les incluant de manière totalement transparente dans la chaîne d’opérations (et donc dans le processus), à moindres coûts.

L’étape suivante consiste à définir les interactions entre les différents services, ce que l’on appelle l’orchestration de services (à travers un BPMS*). Cette orchestration consiste à décrire la manière dont les services font appel les uns aux autres afin de respecter le déroulement et les contraintes des processus d’entreprise.

Les architectures orientées services ne sont pas une invention récente, les principaux travaux remontent aux années 90. Cependant, la maturité nécessaire à leur exploitation en terme de technologie et de méthodologie n’est atteinte que depuis 3-4 ans, grâce notamment aux standards d’interopérabilité (XML, Web services).

La SOA vise à améliorer le rapport d’alignement entre l’IT et le métier, à répondre aux besoins des entreprises en terme de TCO (Total Cost of Ownership) en réduisant les coûts de développement, déploiement, intégration et de maintenance, tout en leur offrant une grande agilité dans la définition de leur business process et leur implémentation dans le système d’information et la capacité d’élargir le champ d’application des processus métier de manière transverse à travers différents silos applicatifs.

A ce titre, on devrait voir apparaître des réorganisations au sein des DSI. De nouveaux périmètres de responsabilité apparaîtront et seront axés autour des processus, ces derniers seront supervisés par un BPX (Business Process Expert dont le rôle sera de formaliser le processus en utilisant le SI comme moteur d’innovation) et un responsable IT (chargé des applications au sein desquelles est exécuté le processus).

Afin de définir l’ensemble des périmètres, d’identfier les intervenants ainsi que les besoins en termes de ressources et des services à exposer, il convient de suivre une méthodolofie d’analyse selon une approche top-down, telle que décrite ci-dessous :

Dans cette démarche, le contexte est défini par les objectifs stratégiques énoncés par la direction. Ces derniers donnent lieu à la mise en place de différents processus métier afin de guider le travail de ses employés en conformité avec la stratégie préconisée. A ce niveau là, il faut identifier l’ensemble des fonctions auxquelles l’on a recours afin d’éxecuter un processus ainsi que les KPI  (Key Performance Indicator) à observer. I faut arriver à un découpage de ce processus en étapes de manière à obtenir une granularité assez fine tout en conservant un degré de pertinence légitime. Cette étape est particulièrement sensible et doit faire l’objet de la plus grande attention. Elle nécessite un travail conjoint des experts BP et IT en concertation avec les responsables du métier et des key-users. Si à ce stade notre analyse n’est pas suffisament cohérente, cela peut avoir un impact négatif sur la suite du projet et notamment lors de la définition des services.

Une fois les fonctions identifiées, il faut se reporter au parc applicatif afin de déterminer l’ensemble des logiciels qui fournissent ces services, déterminer les flux qui transitent entre eux, les types de données ainsi que l’endroit où ces dernières sont stockées. Cette étape est aussi sensible que la précédente du fait qu’elle va nous permettre de définir le processus de ré-urbanisation, d’identifier les services et de les exposer, de créer un entrepôt unique pour les données maîtres (Master Data Management) et de mettre en place une plateforme d’intégration et un catalogue de services (UDDI) afin de pouvoir composer aisément les services au sein d’une application composite tierce de type portail ou mash-up.

L’intérêt des architectures orientées service réside dans différents facteurs:

• Alignement IT et Business
• Agilité de l’entreprise à travers la fluidité de ré-aménagement de ses processes métier
• La réduction de la complexité du système d’information (centralisation des flux, des données)
• La réutilisation des services développés au sein de l’ensemble des applications qui pourront y faire appel. De plus grâce aux principes d’interopérabilité, les applications deviennent totalement indépendantes de la technologie sous-jacente. Elles communiquent entre elles à travers des interfaces faisant appel à des protocoles standards.
• L’utilisation du legacy software et de son intégration avec les nouvelles technologies mises en oeuvre. Il n’est nul besoin de renouveler totalement son parc applicatif. La SOA constitue une évolution et non une révolution.
• Une amélioration de la gouvernance des systèmes d’information, une réduction du TCO et une augmentation du ROI (Return On Investment)

Ici se termine ce premier article. Nous aborderons les aspects techniques ainsi qu’une analyse plus approfondie de la business value dans de prochains articles.

* BPMS : Business Process Management Suite

Je suis tombé par hasard sur cette fiche de l’onisep qui présente le métier d’Architecte des systèmes d’information. J’aimerais la partager avec vous afin de vous donner un aperçu sur ce métier peu connu des néophytes.

UN BATISSEUR INFORMATIQUE

L’évolution des technologies a rendu les architectures informatiques plus complexes et donné naissance à un nouveau métier : l’architecte en système d’information. Son rôle dépasse l’expertise technique, car il doit faire du système d’information de l’entreprise un véritable outil de développement et de stratégie.

Activités

A la frontière de l’informatique et de l’organisation

L’architecte en système d’information intervient pour créer, refondre un système jugé obsolète ou pour en construire un, commun à plusieurs entreprises appelées à fusionner. Le système d’information peut être divisé en sous-systèmes : commercial, comptable, industriel, etc.

Assembler des briques matérielles et logicielles

L’architecte commence par étudier l’existant : les systèmes d’exploitation, les matériels, les logiciels, les réseaux en place. Plusieurs systèmes peuvent cohabiter sans être compatibles. En fonction du schéma directeur élaboré avec l’entreprise, l’architecte en système d’information construit la cartographie du système d’information. Il choisit les technologies qui vont être utilisées dans le système, dans le respect des contraintes de coût, de délai, de sécurité… et en exploitant au mieux les possibilités existantes. Il est assisté par l’ingénieur système, l’ingénieur réseau et l’ingénieur en intelligence artificielle lorsque le système d’information comprend un système expert.

Faire des choix cohérents

Il doit aussi comprendre comment fonctionne l’entreprise et formaliser les différents métiers de l’entreprise en concepts fondamentaux. Il décide des outils d’information, de l’implantation des postes de travail, de l’organisation des procédures. Il pilote le déploiement du système d’information.

Au-delà du technique

Son rôle n’est pas strictement technique. Il prévoit et organise les évolutions et la cohérence du système d’information, en repérant et en analysant tout événement susceptible d’avoir un impact sur celui-ci. Il informe et conseille la direction de l’entreprise sur les modifications technologiques ou organisationnelles que peut entraîner un nouveau système d’information.

Conditions de travail

Dans les grandes entreprises et dans certains cabinets-conseils

Les architectes en système d’information sont recrutés essentiellement au sein des grandes entreprises utilisatrices (télécommunications, banque, grande distribution, automobile, grandes entreprises publiques et industrielles…) et dans certains cabinets-conseil. Ceux-ci interviennent auprès des entreprises en amont de toute intervention informatique. Ils appartiennent au marché des services informatiques au même titre que les éditeurs, les constructeurs et les sociétés de service et d’ingénierie informatique (SSII).

C’est un poste qui requiert une grande disponibilité. Les réunions et les déplacements sont fréquents.

Carrière-promotion

Vers de hautes fonctions

Un architecte en système d’information peut évoluer vers des fonctions de responsable de site ou de division dans une entreprise. Il peut aussi devenir consultant en organisation.

Qualités requises

Avoir une vision stratégique de l’entreprise

C’est un métier qui requiert un niveau technique très élevé et une maîtrise des nouvelles technologies : des systèmes d’exploitation, systèmes gestionnaires de bases de données ou équipements réseaux.
Il faut posséder une connaissance approfondie de l’entreprise et de ses métiers, une expérience confirmée de la conduite de projets.

La faculté à écouter et à communiquer, à travailler en équipe, la capacité à négocier et convaincre, le sens stratégique et politique, sont déterminants.

Débouchés-Salaires

Pour des diplômés expérimentés

Ce n’est pas un métier ouvert aux débutants. Il s’adresse plutôt à des diplômés de niveau bac + 5 ou bac + 6 avec une expérience de 5 à 10 ans.

Les SSII ont parfois des difficultés à recruter des architectes en système d’information confirmés.

En 2000, le salaire brut annuel peut varier de 50 000 euros à 65   000 euros.

source: Onisep

David Clarck a été l’un des plus importants architectes des protocoles qui régissent Internet aujourd’hui durant les années 70 et 80. Aujourd’hui, il travaille avec la NSF (National Science Foundation) afin de créer un nouvel Internet, celui-ci serait plus sécurisé, plus pratique, plus opérationel.

le problème d’Internet aujourd’hui est qu’il fonctionne avec des protocoles imaginés il y’a 30 ans, ceux-ci ont permis énormément de choses (web, e-commerce, partage de fichier), mais il est temps d’évoluer vers de nouvelles choses, par exemple de l’Internet à ultra haut débit, une immersion dans des arènes 3D, la participation à distance à des émissions de télévision…

Aujourd’hui, il veut construire un réseau dont le rendement soit 10 fois meilleur que celui que l’on utilise aujourd’hui. Il pourrait être testé sur le National LambdaRail qui est le réseau utilisé pour expérimenter de nouvelles technologies réseau.

Le laboratoire sera constitué cet été, Clarck fera intervenir de nombreux spécialistes en systèmes, réseaux et sécurité afin de dessiner une nouvelle architecture pour l’interconnexion des ordinateurs à travers le monde et imaginer de nouveaux protocoles.

A quand l’implantation de ce nouveau réseau ? L’Internet tel que nous le connaissons aujourd’hui deviendra obsolète dans quelques années ? Est ce que les idées imaginées dans Matrix deviendront réalités dans des futurs proches ?

Affaire à suivre…