Pi­lo­ter la com­plexi­té

In­dus­trielle, la nou­velle DSI s’or­ga­nise pour ap­por­ter tou­jours plus de va­leur ajou­tée aux mé­tiers.

IT for Business - - DOSSIER -

Dur mé­tier que ce­lui du DSI qui va de­voir com­po­ser avec un exis­tant — qui n’a au­cune rai­son de dis­pa­raître puis­qu’il fonc­tionne bien — et une ex­plo­sion de mi­cro-ser­vices, par­fois réuti­li­sables, par­fois je­tables, sou­vent consom­més en in­terne, mais aus­si par des par­te­naires, conçus par ses dé­ve­lop­peurs ou pro­po­sés en Saas, Iaas ou Paas par des pres­ta­taires de cloud… Le tout en res­pec­tant des règles de per­for­mances, de sé­cu­ri­té, de confor­mi­té, de qua­li­té, de dé­ploie­ment sur des en­vi­ron­ne­ments va­riés en sou­te­nant un rythme de pro­duc­tion tou­jours plus ra­pide et bien en­ten­du sans perdre de vue les coûts…

Trou­ver la bonne or­ga­ni­sa­tion

« Pour ga­gner en agi­li­té, les en­tre­prises vont gé­né­rer une com­plexi­té phé­no­mé­nale, il faut en avoir conscience dès le dé­part, sou­ligne Xa­vier Pois­son, vice-pré­sident In- direct Di­gi­tal Ser­vices chez HPE. L’or­ga­ni­sa­tion phy­sique est très symp­to­ma­tique de ce qui se trame avec la dis­pa­ri­tion des bu­reaux au pro­fit d’un open space, et même main­te­nant d’en­tre­pôts tels qu’on en trouve chez les GAFA avec des gens qui bougent en fonc­tion du pro­jet du mo­ment. Il faut al­ler cher­cher dans les start-up la ci­né­tique de trans­for­ma­tion de l’en­tre­prise » . Pour ali­gner la gou­ver­nance sur des axes qui re­posent à la fois sur les coûts et sur la va­leur ap­por­tée aux mé­tiers, « les DSI vont de plus en plus pri­vi­lé­gier des or­ga­ni­sa­tions ba­sées sur la chaîne de va­leur de Por­ter en adop­tant un mo­dèle bi­mo­dal avec, d’un cô­té, des équipes dé­diées à la trans­ver­sa­li­té qui gé­re­ront le socle di­gi­tal com­mun et, de l’autre, des équipes ver­ti­cales dé­diées aux Bu­si­ness Units », es­time aus­si Da­vid Fer­rei­ra, évan­gé­liste De­vops et agi­li­té chez Cap­ge­mi­ni. Ou­til d’ana­lyse stra­té­gique, le con­cept de chaîne de va­leur a été dé­ve­lop­pé par l’éco­no­miste Mi­chael Por­ter dans l’ou­vrage L’avan­tage concur­ren­tiel pu­blié en 1980. L’idée gé­né­rale consiste à créer de la va­leur au sein d’une or­ga­ni­sa­tion en iden­ti­fiant et op­ti­mi­sant un en­chaî­ne­ment d’ac­ti­vi­tés et en co­or­don­nant les bonnes com­pé­tences et res­sources né­ces­saires à sa réa­li­sa­tion. Dans le mo­dèle de Por­ter, la va­leur se ca­rac­té­rise par le dé­ve­lop­pe­ment d’un avan­tage concur­ren­tiel par la marge (di­mi­nu­tion des coûts), par une dif­fé­ren­tia­tion (faire plus pour les clients) ou les deux. Nor­ma­le­ment, ce mo­dèle est plu­tôt uti­li­sé pour l’ana­lyse stra­té­gique des en­tre­prises mais, pour Da­vid Fer­rei­ra, il est par­fai­te­ment adap­té au pi­lo­tage de la DSI avec des équipes trans­ver­sales orien­tées coûts et des équipes ver­ti­cales fo­ca­li­sées sur la va­leur.

« Le risque d’une or­ga­ni­sa­tion par bu­si­ness unit, tem­père tou­te­fois Franck Farre, ar­chi­tecte so­lu­tions chez SQLI, c’est de dé­ve­lop­per trois fois le même ser­vice dans trois BU dif­fé­rentes. La réuti­li­sa­tion n’est certes plus la prio­ri­té dans un sché­ma de nu­mé­rique à la de­mande, mais il se­rait dom­mage de pas­ser à cô­té quand elle est pos­sible. D’au­tant que c’est le prin­cipe fon­da­teur d’une in­for­ma­tique orien­tée ser­vices : dé­ve­lop-

per la fonc­tion­na­li­té une fois et l’uti­li­ser plu­sieurs fois en l’ex­po­sant via une API, quitte à en­ri­chir la fonc­tion­na­li­té exis­tante par un nou­veau ser­vice pour la com­plé­ter ou l’adap­ter à de nou­veaux be­soins ».

Flui­di­fier les pro­ces­sus ITIL

Quel que soit le mo­dèle d’or­ga­ni­sa­tion re­te­nu, la DSI du nu­mé­rique à la de­mande n’échap­pe­ra pas à l’in­dus­tria­li­sa­tion, seul moyen pour ve­nir à bout de cette com­plexi­té crois­sante. Pré­sente sur les couches d’in­fra­struc­ture ou en­core dans les or­ga­ni­sa­tions De­vops, l’au­to­ma­ti­sa­tion est la clé de cette in­dus­tria­li­sa­tion. Elle gagne même les ou­tils de pi­lo­tage de la DSI. Ain­si, les pla­te­formes ITSM ( In­for­ma­tion Tech­no­lo­gy Ser­vice Ma­na­ge­ment) as­so­cient le libre-ser­vice à l’au­to­ma­ti­sa­tion pour des pro­ces­sus plus agiles, vi­vant au rythme du nu­mé­rique à la de­mande.

Lo­gi­que­ment, ap­pli­quer un ré­fé­ren­tiel de bonnes pra­tiques pour ali­gner L’IT sur les be­soins mé­tiers de­vrait être la bonne chose à faire quand on évo­lue vers le nu­mé­rique à la de­mande. Sauf que les pro­ces­sus de ce ré­fé­ren­tiel ne s’exé­cutent pas aus­si vite qu’on le sou­hai­te­rait. Prin­ci­pal point de dis­corde dans le dé­bat qui op­pose De­vops à ITIL, ré­fé­ren­tiel adop­té par une grande ma­jo­ri­té de DSI, ce manque de ra­pi­di­té re­lève moins des prin­cipes ITIL que de son im­plé­men­ta­tion. Pro­ces­sus trop lents, do­cu­men­ta­tion ma­nuelle de ré­fé­ren­tiels qui ne sont sou­vent plus à jour, so­lu­tions trai­tant uni­que­ment l’as­pect tech­nique (bases de don­nées, gestion de confi­gu­ra­tion, etc.)… Sous cou­vert de ma­na­ge­ment, ITIL a pro­gres­si­ve­ment été can­ton­né à la gestion des in­ci­dents…

La nou­velle gé­né­ra­tion de pla­te­formes ITSM change la donne. Plus in­té­grées et do­tées de mé­ca­nismes d’au­to­ma­ti­sa­tion, en par­ti­cu­lier pour les pro­ces­sus qui ont du mal à s’exé­cu­ter, elles re­po­si­tionnent la gestion des pro­cess de ma­nière plus trans­verse au sein de la DSI et fa­vo­risent une vi­sion glo­bale des ser­vices et de la qua­li­té as­so­ciée. Dans cer­tains cas, la gestion peut être pous­sée jus­qu’au cloud, L’ITSM mo­derne dé­mon­trant ain­si sa ca­pa­ci­té à s’adap­ter aux pro­ces­sus nés des in­fra­struc­tures hy­brides. Com­pa­tibles ITIL, mais aus­si COBIT, MOF ( Mi­cro­soft Ope­ra­tion Fra­me­work), Six Sig­ma, ou en­core ISO 20000 et TOGAF ( The Open Group Ar

chi­tec­ture Fra­me­work) se­lon les so­lu­tions, cette nou­velle gé­né­ra­tion est gé­né­ra­le­ment « co­de­less » . En d’autres termes, le dé­ve­lop­pe­ment, l’au­to­ma­ti­sa­tion, l’adap­ta­tion ou en­core la ra­tio­na­li­sa­tion des pro­ces­sus de L’IT sont réa­li­sés sans pro­gram­ma­tion. Le prin­cipe est éten­du à la créa­tion de work­flows, mais aus­si d’in­ter­faces gra­phiques, de ta­bleaux de bord sans ou­blier les fonc­tions d’in­ter­opé­ra­bi­li­té. Dans ce cadre, le nou­vel ITSM se met aus­si à la page en s’in­ter­fa­çant avec les work­flows De­vops afin de fa­vo­ri­ser au maxi­mum l’au­to­ma­ti­sa­tion. Dans une lo­gique d’amé­lio­ra­tion conti­nue des pro­ces­sus, L’ITSM en­re­gistre, par exemple, les in­ci­dents qui, quand ils sont trop ré­pé­ti­tifs, de­viennent un pro­blème né­ces­si­tant un cor­rec­tif. La de­mande est alors trans­mise au work­flow De­vops, la li­vrai­son du cor­rec­tif étant pro­pa­gée dans L’ITSM. En­fin, L’ITSM fa­vo­rise aus­si la stan­dar­di­sa­tion et la ra­tio­na­li­sa­tion des ser­vices de L’IT grâce aux ou­tils de ca­ta­logue de ser­vices.

Maî­tri­ser l’ex­plo­sion des ser­vices

Éga­le­ment cen­tral dans l’offre D’API Ma­na­ge­ment, le ca­ta­logue de ser­vices consti­tue le point d’an­crage de toute ar­chi­tec­ture mi­cro-ser­vices. Il four­nit un ac­cès com­plet et ra­pide aux ser­vices dis­po­nibles avec une dé­fi­ni­tion de leur rôle, des condi­tions d’ac­cès ou en­core des règles d’usage. Es­sen­tielle pour per­mettre aux par­te­naires d’uti­li­ser cor­rec­te­ment le ser­vice ou en­core maî­tri­ser le cycle d’évo­lu­tion de l’ar­chi­tec­ture mi­cro-ser­vice, cette do­cu­men­ta­tion consi­dé­rée comme une tâche fas­ti­dieuse est sou­vent né­gli­gée par des dé­ve­lop­peurs. Heu­reu­se­ment, en ap­pui sur des fra­me­works

pro­prié­taires ou open source tels que Doc­co, Dexy et plus fré­quem­ment Swag­ger, les pla­te­formes D’API Ma­na­ge­ment gé­nèrent au­to­ma­ti­que­ment tout ou par­tie de la do­cu­men­ta­tion né­ces­saire.

Au­to­ma­ti­ser et contrô­ler les connexions entre une API et les ap­pli­ca­tions qui l’ex­ploitent, ga­ran­tir la co­hé­rence entre plu­sieurs ver­sions et mises en oeuvre d’une même API, four­nir des mé­ca­nismes de gestion de la mé­moire et du cache pour amé­lio­rer les per­for­mances, pro­té­ger L’API de tout usage in­adap­té en l’in­cor­po­rant à des pro­cé­dures et des règles de sé­cu­ri­té ou en­core sur­veiller le tra­fic : les pla­te­formes D’API Ma­na­ge­ment sont des ou­tils pen­sés pour gé­rer la com­plexi­té des ar­chi­tec-

tures mi­cro-ser­vices. Su­jet clé de l’in­dus­tria­li­sa­tion de la DSI, elles n’en fi­nissent

pas d’étendre leur cou­ver­ture fonc­tion­nelle avec, par exemple, des conver­tis­seurs d’in­ter­faces SOAP, JMS ou MQ en REST ou conte­nus JSON, fa­vo­ri­sant ain­si une meilleure co­ha­bi­ta­tion entre l’exis­tant et les nou­velles ar­chi­tec­tures. En phase de pro­duc­tion, L’API Ma­na­ge­ment four­nit aus­si des fonc­tions de mo­ni­to­ring, de sur­veillance du contrat de ser­vice avec un par­te­naire, de ré­gu­la­tion des ac­cès, voire de ré­duc­tion du tra­fic ou de cou­pure cir­cons­tan­ciée pour, par exemple, pro­té­ger l’in­fra­struc­ture in­terne en ré­gu­lant la consom­ma­tion de bande-pas­sante.

Très étof­fée, l’offre émane d’édi­teurs tra­di­tion­nels de L’IT tels qu’ax­way (API Ma­na­ge­ment Plus), IBM (API Ma­na­ge­ment on pre­mises ou dans Blue­mix), Dell (Boo­mi Atom­sphere), Mi­cro­soft (Azure API Ma­na­ge­ment), Oracle (API Ma­na­ger), SAP (Ha­na Cloud Pla­te­form), Soft­ware AG (Web­me­thods API Ma­na­ge­ment), Tib­co (Ma­she­ry) ou en­core CA Tech­no­lo­gies avec API Ma­na­ge­ment, so­lu­tion do­mi­nante sur le mar­ché, se­lon Gart­ner, sui­vie par celle D’IBM. Elle est com­plé­tée par des pla­te­formes open source, Kong étant la plus po­pu­laire. •

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.