Accueil
 > Rapports de TEC > Blogue de TEC > SOA dans une perspective de gestion: Part Two

SOA dans une perspective de gestion: Part Two

Écrit par : Joseph J. Strub
Date de publication : juillet 18 2013

Ceci est la deuxième partie d'une note en deux parties. La première partie fournit une compréhension de base de l'architecture SOA, prévoit le déploiement de grands éditeurs de logiciels et les avantages de la SOA.

préoccupations au sujet de SOA

Retour dans la journée lorsque les procédures et sous-programmes étaient à la mode, il y avait un souci de performance: Est-ce l'utilisation de sous-routines, avec toutes ses ramifications en arrière et passer des données, dégrader les performances par opposition pour dupliquer le code dans le flux? Le même souci avec le trafic de messages dans une architecture orientée services (SOA) est exprimée par certaines technologies de l'information (IT) magasins. Les vendeurs minimisent cette préoccupation, expliquant les vitesses de traitement qui aujourd'hui plus que compenser pour les appels de service et l'utilisation de routines généralisées. Le problème est que vous avez besoin de comparer des pommes avec des pommes. La vitesse des processeurs améliorés profiteront à la fois les environnements non-SOA SOA et. Des garanties doivent être apportées que le temps qu'il faut pour traiter une transaction complète dans un environnement SOA n'est pas significativement plus lent que ce que les entreprises connaissent aujourd'hui. C'est pourquoi les alertes de performances mentionnés précédemment sont essentiels à la réussite de SOA.

La culture qui prévaut IT peut inhiber SOA. Traditionnellement, les magasins informatiques sont mesurés par les lignes de code générées. Ceci est contraire à l'intérêt de la réutilisation de SOA. Le paradigme doit être déplacé pour récompenser les implémentations rapides et agiles plutôt que la taille et la complexité des programmes.

Le coût de mise en oeuvre SOA ne sera pas cher. En plus de la réingénierie de votre technologie de l'architecture existante, SOA nécessitera un investissement important en capital humain de sorte que les analystes métier peuvent définir des processus d'affaires finies, les analystes de systèmes peuvent convertir ces processus dans les spécifications et les ingénieurs systèmes et les programmeurs peuvent tout traduire en services fonctionnels et gérable .

manquent pas à ce stade de son déploiement, mais attraper rapidement, sont des outils tiers pour aider à la surveillance et à l'amélioration de la performance dans un environnement SOA définie. Adopteurs précoces de SOA doivent soit construire leurs propres ressources ou de travailler conjointement avec les fournisseurs pour tester les versions bêta des outils. C'est pourquoi, par exemple, les entreprises pionnières utilisent tout de Excel des feuilles de calcul aux bases de données simples comme dépôts pour les services. En utilisant des outils en interne, les entreprises ont la possibilité d'étudier le paysage de la technologie pour la meilleure solution pour leur infrastructure.

Bien qu'il existe des opinions divergentes sur le sujet, que beaucoup considèrent comme des services Web comme un élément obligatoire de la SOA. Pour ceux partageant ce point de vue, les services Web doivent être correctement mis en œuvre pour créer un environnement SOA solide. Bien que certaines entreprises peuvent prendre un et voir attente approche, maintenant serait un bon moment pour obtenir votre maison de services Web dans l'ordre.

Comme implémentations SOA commencent à proliférer dans une entreprise, les solutions traditionnelles, manuel de gouvernance, qui comprennent la conception walk-thru, les pilotes de salle de conférence, et après-coup rapports, peut être insuffisante. Par conséquent, les éléments de l'approche du cycle de vie du système devront être revus pour intégrer une stratégie de gouvernance plus proactive. Pensée guindé que votre cycle de vie applicatif a bien servi votre organisation pendant de nombreuses années peut entraîner rater la cible SOA et la réalisation de ses bénéfices attendus.

Comment pouvez-vous obtenir de la SOA?

Maintenant, vous êtes excité à propos SOA. Vous avez acheté sur les bienfaits et ne pouvez pas attendre pour commencer. Pas si vite!

SOA est difficile à vendre aux cadres de l'entreprise. SOA permet à votre entreprise d'être plus flexible et agile. Cependant, il est difficile de faire une analyse de rentabilisation ou de développer des économies basées sur la flexibilité et l'agilité. Sauf dans les rares cas où la réactivité peut signifier la justification gagner ou de perdre des parts de marché, pour un changement de technologie est construit sur la résolution des problèmes de l'entreprise ou de gagner un avantage concurrentiel. Rappelez-vous que Y2K apporté d'importantes améliorations des systèmes pas à cause d'une utilisation plus efficace de la technologie, mais plutôt en raison de sa menace de fermer les entreprises.

Comme on l'a indiqué plus haut, la réutilisabilité des services est un point de dessin majeur de l'architecture SOA. Faire de ce concept une réalité, c'est plus facile à dire qu'à faire. Nous n'avons pas pu le faire pour les objets et nous ne pourrions pas y arriver pour les composants. Qu'est-ce qui nous fait penser que la SOA sera différent? Oh, oui gouvernance de son entreprise fera l'affaire. Même si la gouvernance d'entreprise pourrait appliquer une politique SOA, nous ajoutons une autre couche du personnel de gestion et probablement. Grande-maintenant nous sommes responsables de l'augmentation des charges de personnel et les frais généraux.

SOA peut être expliqué comme l'informatique d'entreprise, services réutilisables, et une méthodologie de construction plus rapide. Alors que la SOA peut être, un concept compréhensible simple, il nécessite une courbe d'apprentissage abrupte pour les entreprises souhaitant adopter cette technologie et de récolter les bénéfices attendus. Les développeurs traditionnels, qui prennent la grosse approche de l'image vers l'intégration d'applications, devront rompre les flux et les processus en petites bouchées si réutilisabilité est de s'épanouir. Développer un noyau de professionnels de l'informatique pour diriger l'effort ne sera pas seulement limiter votre exposition aux revers mineurs, mais aussi de créer un groupe de disciples SOA à passer le mot.

autre paradigme qui doit être changé est l'image traditionnelle de l'informatique professionnelle. L'image d'un "bits-et-octets" ermite qui vit quelque part dans une grotte de la technologie et parle en trois acronymes lettre ne sera pas coupé. Si les professionnels sont à travailler efficacement côte à côte avec leurs homologues d'affaires aux processus finis du modèle, les deux groupes doivent parler un langage commun. Ce langage doit être dans la langue de l'utilisateur final. Bien que vous puissiez dire que votre entreprise a déjà surmonté cet obstacle, essayez corroborer cela avec la communauté des utilisateurs. Certes, les bus de services d'entreprise (ESB), les référentiels et les répertoires sont importants pour la réussite de SOA, ils ne doivent pas concerner l'utilisateur et ne fera que l'eau boueuse.

Mais la question à un million de dollars est, "Comment pouvons-nous mettre en œuvre ne SOA?" Certains fournisseurs suggèrent un déploiement progressif. Mais cela revient à cheval sur un bateau avec un pied sur le bateau (l'environnement SOA) et d'autres sur la terre ferme (l'infrastructure actuelle du logiciel). Alors que le bateau dérive plus en plus loin, vos ressources sont étirées à leurs limites. Vous tombez, et votre état actuel et futur commencez à patauger. Même si cela peut être fait, vous feriez mieux d'être un bon nageur et avoir quelqu'un sur le personnel compétent en RCR, c'est-réanimation de base du programme.

Selon l'âge de vos applications existantes, les interfaces de programmation internes et externes peut être difficile à trouver avec un seul programme, beaucoup moins que dans toute bibliothèque d'applications de l'entreprise. Pour utiliser un service, les interfaces actuelles doivent être arrachées ou neutralisées. Pensez-y. Prendre la vérification de crédit / mise à jour de service, par exemple. Cela pourrait être utilisé dans la prise de vue standard, traitement des déclarations, génération de devis, commandes ponctuels, ventes promotionnelles, des réductions prises, et qui sait où encore. Maintenant, allez dans chacun de ces programmes ou modules, retracent la logique d'interface, et de déterminer quels changements doivent être faits. Pas une tâche facile. Bien que vous puissiez avoir accès au code source, vous ne pouvez pas avoir les ressources techniques pour jouer à ce jeu de Hide'n'Seek technique. Alors que le fournisseur du logiciel peut offrir de l'aide, pouvez-vous les moyens?

Alors que nous parlons de ressources techniques, de profiter de l'agilité de SOA, les services devront peut-être modifié ou, osons le dire, améliorée. Encore une fois, si vous n'avez pas les moyens techniques pour effectuer ce type de modification, vous pouvez être à la merci de l'éditeur du logiciel. Si vous soutenez le cas d'agilité pour SOA, assurez-vous que votre entreprise peut soutenir ou, au moins, payer pour cela.

Malheureusement, la SOA peut être Y2KAOA c'est-à-Y2K All Over Again. SOA n'est pas un cas de migration, c'est un cas d'arracher et abattre à la fondation de la technologie, et de le remplacer sur une échelle de l'entreprise. Alors que les grandes entreprises peuvent se permettre le luxe de choix, petites et moyennes entreprises (PME) n'ont certainement pas. Pour utiliser une analogie, SOA est similaire à l'époque où la transmission automatique a été offert dans les voitures. Il a fait la conduite plus facile et moins stressant. Mais vous n'avez probablement pas prendre votre voiture de levier de vitesse à votre mécanicien local et ont remplacé la transmission manuelle. Alors que votre voiture actuelle ne peut pas avoir été le dernier et le meilleur de la technologie automobile, il était fonctionnel et a servi un but précieux. De même, le logiciel de votre entreprise actuelle est la plus probable s'acquitte de sa mission déclarée. Tout simplement parce que la nouvelle technologie est vanté par les éditeurs de logiciels ne signifie pas que vous allez abandonner ce que vous avez. Non, vous allez attendre jusqu'à ce que vous pouvez établir une analyse de rentabilisation pour remplacer le logiciel comme un traitement plus rapide pour faire face à l'accroissement des commandes, de meilleurs algorithmes de prix qui reflètent les pratiques de votre entreprise, ou l'amélioration des outils d'analyse financière et de décision. Lorsque vous pouvez faire l'analyse de rentabilisation, vous devez déterminer quelles solutions logicielles sont construites sur la technologie SOA et d'intégrer cet avantage dans votre évaluation et de sélection.

Résumé

Certains d'entre vous peuvent dire: «Ne peut pas cet auteur se décider? Est-il en faveur de la SOA ou pas?" Comme nous l'avons vu, il ya peu de doute que la SOA pourrait offrir des avantages réels et tangibles en termes de services réutilisables et un déploiement plus rapide des applications. Si nous pouvons obtenir ces avantages cette fois encore autour d'être vu. Peu importe, SOA n'est pas une technologie qui peut être mis en œuvre de façon progressive ou au coup par coup. Vous ne pouvez pas obtenir votre gros orteil humide; elle exige une immersion complète. Quand vous pouvez faire un argument convaincant pour votre gestion de mettre à niveau votre portefeuille d'entreprise, SOA peut être suffisamment mature pour être considéré comme une alternative raisonnable. À l'heure actuelle directeurs de l'information (DSI) serait mieux servie par regarder dans les coulisses et le suivi de l'évolution de la SOA tout en conservant leur gestion informée. Comme le premier modèle de l'année d'une nouvelle ligne de la voiture, il peut être judicieux de mettre en œuvre la première version du logiciel à l'aide SOA. Enfin, ce qui est particulièrement intéressant, c'est que peu de fournisseurs offrent même une solution basée sur SOA, mais nous avons déjà parlé SOA 2.0 et avancée SOA .

propos de l'auteur

Joseph J. Strub possède une vaste expérience en tant que chef de projet senior et consultant pour les projets de planification et d'exécution de la planification des ressources d'entreprise (ERP) pour les systèmes de fabrication et de distribution, pour les grandes et moyennes entreprises dans le commerce de détail, de la nourriture et des boissons, des produits chimiques, et des biens de consommation emballés (CPG) les industries de process. Il a développé des programmes de marketing et de communication pour les organisations informatiques et consultés sur off-shore, l'externalisation des opportunités pour les entreprises multinationales. En outre, Strub a été consultant et auditeur des systèmes d'information avec PricewaterhouseCoopers et un développement et un soutien gestionnaire d'applications pour plusieurs sociétés Fortune 100. Actuellement, Strub est un consultant indépendant.

Il peut être contacté à JoeStrub@WriteTechnologyPlus.com.

 
comments powered by Disqus

Recherches récentes :
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.