How can you do DevOps right if you don't even know what DevOps means?

A lire sur: http://www.theserverside.com/feature/How-can-you-do-DevOps-right-if-you-dont-even-know-what-DevOps-means

By Jason Tee

TheServerSide.com

If there's one thing Simon Maple knows, it's DevOps. But actually understanding the topic in depth comes with a price. Maple, the technical evangelist for ZeroTurnaround, feels like he's banging his head against the wall whenever the trend gets co-opted by the clueless. Since that happens pretty much all the time, he's acquired quite a headache. The worst part is that people don't even understand the words that are coming out of their own mouths. "One of the biggest annoyances for me, personally, is the term DevOps. Everyone wants to jump on the bandwagon, so they call whatever they are doing DevOps." So then, what exactly is DevOps?

According to Maple, DevOps is three things. First, it's about trying to find the slickest path through the business from the developer over to production. This means looking at developmentand operationsas an entire workflow, not just two separate but consecutive processes. Someone has to be willing to stand back and take in the bigger picture.

One of the biggest annoyances for me, personally, is the term 'DevOps'. Everyone wants to jump on the bandwagon, so they call whatever they are doing DevOps. 

Simon Maple,ZeroTurnaroundTechnical Evangelist

Second, it's about making the feedback loops as short and as loud as possible throughout the cycle. Having a short feedback loop means problems are identified as soon as possible and the relevant information gets back to the dev team as quickly as possible. Letting it pile up and figuring it can be dealt with later isn't acceptable. That's one reason the feedback also has to be loud – so it can't be ignored. The feedback loop must be monitored and team members have to be accountable for actually following through and addressing the issues that have been raised.

(For an interesting examination of what this looks like taken to the extreme, check out HCL Technologies with its Employees First philosophy. This company actually extends the feedback loop past operations and to front line employees in a novel way, making developers directly accountable to sales and customer service for how well their solutions work.)

Finally, the company must embrace the fact that the developers and operations teams need to understand each other and the roles they fulfill. According to Simon, "If you don't have this area in and around DevOps, steps one and two aren't going to succeed." In fact, step number three is both the most foundational and the most difficult to achieve since it may entail a full-scale cultural shift.

What DevOps is NOT...

Maple makes it clear that DevOps isn't a title. It doesn't matter how many people on LinkedIn are advertising themselves as DevOps Engineers. It doesn't matter how many recruiters are taken in by this label, thinking they've found the magic person who will fit the bill. DevOps simply isn't a one man job. "It's a way that you structure your team, and a way you allow your team to work.

There are tools available for continuous integration and release management (like the solutions fromLiveRebel) that can enable the three steps outlined above. But tooling alone doesn't enable DevOps. "It's a mindset. Companies need to understand that you can't buy DevOps. You understand and invest in DevOps as a team, a process and a lifestyle." That process can happen on purpose with full buy in up front, or gradually by stealth as part of the natural evolution of a company.

Tooling DevOps

Assuming an organization is ready to make the leap to DevOps, LiveRebel is on hand to make that transition successful. These tools help development and operations teams to work in a more automated way, increasing speed and reducing failures associated with manual steps. In simple terms, the product automates and orchestrates application deployment. Orchestration is key here, since simply making everything easy to do with a click of a button can actually be a disaster if you're doing the wrong thing at the wrong time in the wrong way.

To avoid these issues, the LiveRebel solution bundles the config, database, and application code together for a seamless upgrade experience. The Dev team selects the environment and applications to move up to the next level and the upgrade is automatically coordinated and implemented. It's even timed to avoid killing existing http sessions so users don't experience downtime. If there's a problem at any stage, LiveRebel can automatically roll back the whole shebang to the previous working state. You can literally walk away and know that when you come back, you'll be okay—either in the new state or in the previous good state.

Why is giving Dev more visibility into Ops a good thing? When developers can grab hold of automation and understand the early stages of deployment, they start to truly understand the implication of their choices. As Maple points out, "What you choose in development, you support in production." With a deeper understanding of these consequences, Dev can make smarter decisions and fully support the Ops team in doing their job. It's a positive feedback cycle that just keeps making things better.

How do you define DevOps? Let us know.

Le Disaster Recovery as a Service (DRaaS) révolutionne-t-il le plan de reprise IT ?

A lire sur: http://www.it-expertise.com/le-disaster-recovery-as-a-service-draas-revolutionne-t-il-le-plan-de-reprise-it/

17 déc 2013, by Aurelie Magniez

La continuité d’activité, avec la mise en place de plans assurant la reprise après un sinistre, est devenue un sujet central pour les entreprises.

Intéressant à l’origine plus particulièrement le monde de la finance, soumis à de fortes réglementations (Bâle III, SOX), la nécessité d’assurer la continuité de l’activité en cas de crise s’est étendue aux autres secteurs, également soumis à de nouvelles réglementations (1), notamment les entreprises appartement aux Opérateurs d’Importance Vitale (OIV) : hôpitaux, entreprises de transports, opérateurs d’eau et d’électricité…

L’importance croissante du système d’information en tant que support aux processus opérationnels impose aux entreprises de se doter, dans le cadre de leur Plan de Continuité d’Activité (PCA), d’un plan de reprise IT ou plan de secours informatique que nous désignerons par son appellation anglo-saxonneDisaster Recovery Plan (DRP).

Le principe général du DRP est de « répliquer » les données et services IT utilisés par l’entreprise sur un site (de secours), qui ne serait pas soumis aux mêmes risques de sinistre que les infrastructures principales.

Le principal frein pour la mise en place d’un tel dispositif, outre sa relative complexité logistique et technique, est en général son coût. Le DRP représente en effet un investissement et une charge de maintien en condition opérationnelle importants, pour une rentabilité d’utilisation relative, n’étant potentiellement activé qu’en cas de crise liée à un sinistre.

C’est pourquoi les dispositifs mis en place se limitent en général à ne rétablir que les services IT supportant les activités critiques et vitales de l’entreprise, la mettant potentiellement en danger en cas de crise prolongée.

La volonté de réduction des coûts d’investissement pour le DRP amène aujourd’hui les entreprises à se tourner vers des opérateurs du « cloud » offrant des catalogues de services IT adaptés aux besoins du DRP, qui s’appuient sur les points clés suivants :

• Mise à disposition de ressources SaaS et IaaS, par opposition à un investissement matériel
• Allocation dynamique des ressources en fonction du besoin
• Facturation à l’usage
• Niveau de service – résilience du cloud

Le DRP « traditionnel » basé sur des infrastructures « propriétaires » migre donc vers le DRaaS ou Disaster-Recovery-as-a-Service (aussi appelé simplement RaaS : Recovery-as-a-Service).

Le DRaaS, un DRP à moindre coût

Le marché du DRaaS est en pleine expansion. En février, Gartner estimait ce marché à 564 millions de dollars en 2013 avec un taux de croissance annuelle d’au moins 21% pour les trois prochaines années (2).

A la différence du DRP traditionnel, il s’agit pour l’entreprise de répliquer ses données et services IT non plus sur une infrastructure dont il est propriétaire mais en utilisant des ressources chez un fournisseur de cloud publique via l’allocation des ressources nécessaires (serveurs virtuels, stockage, réseau…). Il bénéficie ainsi de coûts très compétitifs : le prix d’un serveur dans le cloud ne coûte en effet qu’une centaine d’euros par mois.

Hors crise, le DRP n’utilise que les ressources nécessaires au maintien des services minimum (sauvegarde des données et services associés…) réduisant ainsi le nombre de serveurs virtuels alloués. En cas de crise, des ressources supplémentaires seront provisionnées en quelques minutes grâce à l’allocation dynamique du cloud.

En résumé, le DRaaS permet de s’affranchir des coûts d’investissements et d’exploitation d’un second datacenter pour passer à des coûts d’OPEX modérés ; la DSI pouvant ainsi se recentrer sur des services offrant plus de valeurs aux métiers.

Les acteurs du DRaaS

Sur ce marché très actif de la continuité dans le cloud, on trouve des spécialistes de la sauvegarde, de l’hébergement et de nombreux opérateurs et fournisseurs cloud comme Amazon, Symantec avec Microsoft Azure, NTT ou encore Colt, qui adressent ce marché via leurs offres IaaS (Infrastructure-as-a-Service).

Bien sûr, les grands acteurs de la continuité d’activité ont également enrichi leurs catalogues d’offres packagées basées sur le cloud. Ainsi, SunGard assure via son service DRaaS, le DRP de Rémy Cointreau USA, la branche américaine du groupe français de spiritueux (3).

Ces acteurs ciblent avant tout les PME et ETI (Entreprises de Taille Intermédiaire) qui n’ont souvent pas de DRP, mais cela devrait intéresser à terme les grands comptes attirés par les coûts attractifs et l’allègement des charges pour leur DSI.

Des limites à ce modèle

Evidemment, ce modèle impose des prérequis et des contraintes. Tout d’abord, ces acteurs n’offrent pas tous les mêmes prestations. Si certains ne proposent ni plus ni moins qu’un service IaaS avec à charge de l’entreprise de manager son DRP, d’autres accompagnent les entreprises sur sa mise en place et en assurent la gestion et le déclenchement en cas de sinistre.

D’autre part, au-delà des SLA classiques des offres cloud, tous les fournisseurs ne proposent pas les mêmes solutions d’administration et les mêmes engagements de délais d’allocation dynamique de ressources, capables de répondre aux besoins exprimés par les notions de RTO (Recovery Time Objective, durée maximale d’interruption admissible) et RPO (Recovery Point Objective, perte de données maximale admissible) traditionnellement utilisés dans le DRP.

De plus, le DRaaS ne peut s’appliquer qu’à des environnements virtualisés avec un certain niveau de standards, afin d’éviter des problèmes d’interopérabilité avec le fournisseur. Certains points doivent donc être étudiés lors de la sélection du fournisseur :

• Ses outils de virtualisation sont-ils interopérables avec les miens ?
• A-t-il les mêmes templates de machines virtuelles que mes serveurs ou permet-il d’importer mes propres templates ?

Par ailleurs, les capacités actuelles du réseau limitent les volumes de données pouvant transiter dans le cloud. Un besoin de réplication de données important lié au DRP peut augmenter de façon significative le coût du service. En effet, un lien réseau dédié entre l’entreprise et un datacenter du fournisseur peut vite alourdir la note. D’autre part, des applications gourmandes en bande passante et requérant des RTO et RPO très bas, comme les applications transactionnelles financières par exemple, ne seront pas éligibles au DRaaS.

Enfin, comme dans tout projet cloud, il y a également descontraintes légales et de sécurité sur l’hébergement de données à l’extérieur de l’entreprise. En particulier, tous les fournisseurs ne sont pas capables de garantir leur localisation en France.

En amont d’un projet DRaaS, il est donc nécessaire d’évaluerl’éligibilité des applications au cloud et de conduire uneanalyse de risques sur la continuité d’activité et sur les données pouvant être mises dans le cloud.

Vers un DRP hybride

Les entreprises pourraient donc se diriger vers une stratégie de DRP hybride, avec les services externalisables dans le cloud (après des transformations si nécessaires), les autres services restant sur un DRP classique.

Etude de DRP hybride

C’est aussi l’opportunité d’élargir le périmètre du DRP et sécuriser d’autres services de production, voire également des environnements de développement pour des projets applicatifs en cours.

Attention toutefois à ne pas trop alourdir les process du DRP avec des architectures multiples. A la DSI de s’adapter au modèle en ajoutant à ses compétences la casquette de gestionnaire de services cloud.

Le DRaaS, profitant de l’usage croissant du cloud par les entreprises, devrait donc se développer, mais il pourrait bien être rattrapé à son tour par l’augmentation du nombre de services d’entreprises en mode cloud, SaaS et IaaS en tête. De par sa résilience intrinsèque, le cloud pourrait bien résoudre de lui-même l’épineux problème du DRP…

 Références :

1. http://www.sgdsn.gouv.fr/site_rubrique70.html
2. Voir Market Trends: Assessment of the Rapidly Growing Market for Cloud-Based Recovery Services.https://www.gartner.com/doc/2324315
3. http://blog.sungardas.com/insider/2013/09/remy-cointreau-tastes-the-future-of-fine-spirits/

Réussir le passage à l’IT en mode service

A lire sur: http://connect.emc2.fr/reussir-le-passage-a-lit-en-mode-service/

Ajouté le 13 janvier 2014 à 23 h 46 min

Le passage d’un mode traditionnel de fourniture de l’IT à un mode service, avec la facturation correspondante aux métiers, peut se faire sans le Cloud. Mais ce dernier constitue une opportunité opérationnelle susceptible de faciliter cette transformation.

Le passage de la fourniture traditionnelle de l’IT à un mode service est une priorité pour les entreprises, très importante, sinon critique pour 70 % d’entre elles dans la région EMEA, selon une récente étude IDC réalisée pour EMC et VMware. A la clé, 47 % des DSI sondées dans le monde entier, pour cette étude, y voient la perspective d’économies, mais aussi, à 43 %, celle d’une meilleure satisfaction des utilisateurs finaux. Côté métiers, 48 % des sondés attendent un meilleur alignement de l’IT sur leurs besoins, et 45 % une plus grande efficacité.

Mais l’une des principales difficultés tient à la définition de l’approche, celle d’un catalogue de services et d’une tarification. Eric Chicha, Directeur Global Services Senior d’EMC France, explique que le passage au Cloud, entièrement ou partiellement, en interne, en public ou en mode hybride, constitue là une opportunité : « c’est une facilité opérationnelle qui permet d’optimiser les coûts et de rationaliser une informatique traditionnelle, pour passer à un IT délivré et facturé comme un service. »

Analyser le patrimoine applicatif

Là, la première étape constitue à identifier les éléments du patrimoine applicatif à faire migrer en mode Cloud : « une vision claire des applications et de leurs dépendances à d’autres serveurs ou composants est essentielle. » Ce qui requiert une analyse non pas statique mais dynamique du patrimoine : « il est très difficile de découvrir que certaines applications peuvent appeler d’autres composants par la seule analyse des exécutifs résidant sur les serveurs. D’où le besoin de suivre l’exécution des applications pour observer les liens entre les architectures physiques d’exécution. »

Et d’illustrer par l’exemple : « l’un de nos clients s’est inscrit dans une trajectoire de virtualisation de ses 400 applications, réparties sur 1 200 serveurs physiques. Un volume suffisant pour qu’il soit humainement difficile d’obtenir une vision claire de la manière dont ces applications s’exécutent sur les serveurs. » L’étude dynamique de l’environnement a duré trois mois, afin de tenir compte des traitements part lots à périodicité élevée, en s’appuyant sur la solution Adaptivity.

Hélas, relève Eric Chicha, « beaucoup d’entreprises se lancent ne serait-ce que dans une architecture virtualisée sans avoir nécessairement le réflexe de faire cette analyse, » essentielle pour définir les priorités et identifier les applications qui, pour certaines, n’ont pas de vocation économique à être virtualisées.

Cette analyse est aussi indispensable que la définition de la plateforme, avec l’architecture cible et la pile technologique sur laquelle elle s’appuiera, avant de passer à la virtualisation, paquet par paquet, tout en précisant les procédures d’exploitation et en assurant la formation des personnels, depuis l’exploitation jusqu’au développement en passant par l’outillage.

Définir un catalogue de services

Le second volet, à conduire en parallèle, touche à la constitution d’un catalogue de services. En commençant par le plus bas niveau : « le provisionnement d’une machine virtuelle capable d’exécuter différentes charges, par exemple, » explique Eric Chicha. Et là, un conseil : « inutile de chercher à réinventer ce qui existe déjà. AWS est un modèle pour toutes les DSI qui veulent aller vers l’IT en mode service. » Cela ne signifie pas que suivre ce modèle soit trivial, ni qu’il corresponde complètement aux exigences de métiers et de services de la DSI : « l’économie des directions informatiques est généralement basée sur un partage de coûts variables. Or les fournisseurs externes facturent suivant un niveau de service. La difficulté consiste donc à offrir un service lisible en comparaison de concurrents externes tels qu’AWS, à un prix fixe. » Un véritable tour de force. D’autant plus que l’infrastructure interne est susceptible de fournir des services qui ne seront pas tous consommés. Un défi auquel sont confrontés les fournisseurs de services Cloud public, mais en bénéficiant d’un levier d’échelle.

Mais l’expérience peut s’avérer utile : « la problématique est bien connue des utilisateurs de mainframes, habitués à la planification de la capacité et au partage des coûts. » En outre, certains clients d’EMC choisissent d’y déporter leurs coûts fixes, par exemple en achetant des capacités de sauvegarde externe… en mode service : « il peut s’agir de capacité seulement, ou du service complet. »

La question des développements

Eric Chicha tient enfin à insister sur la question clé, mais pas forcément toujours identifiée, des développements : « de plus en plus de clients prennent des ressources Cloud pour les développements et la qualification, avec l’avantage de la flexibilité. » Ici, les environnements utilisés dans ce cadre ne sont pas, par construction, les mêmes que ceux utilisés pour la production. « D’où le concept de DevOps, qui permet d’aligner ces environnements et renforce ainsi la valeur ajoutée de la virtualisation. Toute modification de l’environnement de production sera de fait répercutée immédiatement sur ceux de développement et de qualification. » Une approche qui fluidifie le cycle de vie des applications mais qui a aussi ses limites : « dans ce cas-là, on ne peut plus s’appuyer sur des fournisseurs de cloud externes, à moins que leur infrastructure ne soit totalement alignée avec celle dont dispose la DSI en interne. »

7 Reasons IT Organizations Should Adopt Six Sigma

A lire sur: http://www.cio.com/article/745749/7_Reasons_IT_Organizations_Should_Adopt_Six_Sigma

Deploying a process-improvement strategy can help your IT department be more productive and reduce errors. We talked to Six Sigma (and other) experts about why the move makes good business sense.

By Jennifer Lonoff Schiff 
Thu, January 09, 2014

CIO — Since General Electric adopted Six Sigma, a process-improvement strategy developed by Motorola in the 1980s, in the 1990s, the term/methodology has become a catch phrase for quality improvement. And although originally intended for use in manufacturing and the supply chain as a way to reduce or eliminate defects, the data-driven, process-improvement strategy has since been applied to other sectors and services, including IT.

So how can a process-improvement strategy such as Six Sigma benefit your IT organization? CIO.com asked IT as well as Six Sigma and other experts. They provided seven reasons why adopting a process-improvement strategy makes good business sense, no matter what business you are in.

1. It can help you make better decisions. "IT organizations usually have large numbers of change initiatives running in parallel, addressing a wide range of factors," says Jim Shulkin, vice president of Marketing at Daptiv, a provider of on-demand project portfolio management software.

"Implementing [a process-improvement strategy, whether it's Six Sigma or] project portfolio management (PPM) helps you decide which projects to undertake, [how to] streamline existing processes and then drive through and monitor [them] to achieve strategic objectives," Shulkin says. "For IT organizations specifically, PPM involves managing the process of translating the strategy and objectives into the right projects and then focusing on the execution of these projects towards the delivery of overall strategic objectives."

Seven Steps to Manage Stakeholder Expectations

A lire sur: Method123

You performed an initial stakeholder analysis when you defined and chartered the project. The stakeholder analysis should also be updated periodically to ensure that the stakeholders are being engaged successfully. If the stakeholders are not being engaged as you wished, you should update or change your activities. It is possible that you will also discover new stakeholders as the project progresses, and they should be accounted for in this process as well.

1. Establish an agreement. This is probably the most overlooked yet most obvious piece. It is difficult or impossible to manage stakeholder expectations if you do not have some agreement to begin with. You need to agree on what the expectations are. 
2. Manage change. Once an agreement has been reached, changes should be managed through the change management process. This ensures that the stakeholder approves all changes and helps keep expectations in line.
3. Communicate proactively. When the agreement has been reached, continue to communicate proactively through the status reporting process or as part of a broader Communication Management Plan – especially if there are any problems meeting the expectations. This helps the stakeholder keep up-to-date on progress, issues, risks, etc. The main motivation is to avoid surprises.
4. Periodically assess performance. The project manager should be assessing expectations on an ongoing basis. If it looks unlikely that you will meet expectations, immediate steps should be taken to get back on track.
5. Deliver against the expectations. Again, this may seem obvious. However, once an agreement has been put into place, you need to make sure that you deliver as expected. One of the weaknesses on the part of many people is that they do not fulfill their agreed-upon expectations, and they do not communicate with the stakeholder to inform them of the status and acknowledge the missed expectation.
6. Reset expectations if necessary. If you determine that the original agreement cannot be satisfied, the agreement should be re-negotiated. This process includes gathering the facts surrounding the inability to meet the original agreement. In addition, alternative courses of action should be formulated to determine how to perform as closely to the original agreement as possible in a way that will satisfy both parties. Once a modified agreement has been reached, reset the expectations and begin the work necessary to meet the requirements of the new agreement.
7. Complete the agreement. Review the completed work with the stakeholder to ensure that the terms of the agreement have been fully met. If not, negotiate what will be required to fulfill the agreement.

The project manager should ensure that the stakeholders are involved in the project and that the expectations of the stakeholders and project manager are always aligned. Then manage the expectations and achieve the commitments.

Ten Great Time Management Tips

A lire sur: tenstep

Organizations can be more efficient and effective if work is properly planned and delegated. Personal working habits should also be efficient. There are lots of things happening during the day that impact your work. You are trying to work on many things that need help from others. The others are also working on many things that rely on help from you. Here are some time management techniques that may not be so obvious.

• You all know about writing down the things you need to do during the day. This is the classic to-do list. It is always the place to start.
• Properly schedule your activities. Make sure you should book time for yourself to do things you need to get done.
• Allow some time for unexpected events and interruptions.
• Try to plan variety. Lack of variety will only make you tired, and it is hard to do good work when you're tired. A lack of variety can also make your job boring. 
• Avoid over-commitment. It is not always easy, but the following steps could help:

• Do not be afraid to say no
• If something is not your job, say so
• If you do not know how to do something, say so (although you need to be open to learning)
• If you do not have time for something, say so

• That being said, you cannot say no to everything. If your help is really needed you should try to assist. You need to collaborate with others if you expect them to collaborate with you.
• Always be prepared by carrying a little work around with you, so that you can use free time effectively.
• Confirm appointments to avoid mix-ups.
• If people keep you waiting, ask them to come to you in the future.
• If you have subordinates, see if some work is appropriate to delegated - recognizing you don't want to overload them either.

You cannot always change the nature of the chaos around you. But you do have control over your own work habits. Use your own time wisely.

Budget de la DSI : calme plat, malgré un cap digital à franchir

A lire sur: http://www.zdnet.fr/actualites/budget-de-la-dsi-calme-plat-malgre-un-cap-digital-a-franchir-39797066.htm

Décisions IT : Après l’industrialisation, la DSI entre, selon Gartner, dans une 3e phase, marquée par une accentuation de la numérisation de l’entreprise. Une étape qu’il faudra cependant pour les DSI entreprendre à budget constant (+0,2%).

Par Christophe Auffray | Mardi 14 Janvier 2014

2014 marque le début d’une nouvelle ère pour les DSI selon Gartner, qui n’hésite pas à parler de troisième ère de l’IT d’entreprise, qui succèderait ainsi à l’ère de l’industrialisation. Derrière cette formule, ce qu’annonce le cabinet c’est une nouvelle étape dans la numérisation de l’entreprise.

D’ailleurs, cette nouvelle étape de transformation inquièterait une majorité des 2339 DSI interrogés. 51% d’entre eux craignent ainsi que le torrent numérique se produise plus vite qu’ils ne peuvent y faire face. Ils sont en outre 42% à estimer que la direction des systèmes d’information ne dispose pas des compétences nécessaires pour accompagner ces changements. Pas franchement un climat de sérénité donc.

Renover l'existant et explorer de nouvelles pistes technologiques 

« Les DSI sont confrontés aux mêmes défis qu’au cours des précédentes années, mais aussi à un flot d’opportunités et de menaces liées au numérique. La numérisation soulève des questions en matière de stratégie, de leadership, de structure, de compétence, de financement, et de presque tout le reste » juge Dave Aron, vice-président de Gartner.

Et la continuité dans les défis, les DSI l’observeront notamment au niveau des budgets IT. Ces derniers sont dans l’ensemblestables d’une année sur l’autre. En 2014, la règle demeure et Gartner table sur une hausse de tout juste 0,2%, en moyenne.

Si la tendance reste la même, le cabinet s’attend néanmoins à ce que la pression s’accentue sur les budgets IT : « Cela est particulièrement difficile puisqu’il faut à la fois rénover le cœur des systèmes IT et des services, et aussi exploiter de nouvelles options technologiques ». Nombre de DSI n'ont pas attendu une "troisième ère" pour cela...

Toutefois, la DSI ne portera pas à elle seule les investissements technologiques et le développement du numérique dans l’entreprise. Après tout, cela doit-il être sa chasse gardée ? Les DSI indiquent qu’en 2014, 25% de la dépense IT se fera en dehors du budget IT. Et le chiffre réel pourrait être bien supérieur, estime Gartner.

Des métiers plus autonomes financièrement. Signe de défiance ? 

Selon une étude d’IDC, cela est particulièrement vrai pour le marketing dont le budget numérique ne serait ainsi abondé par la DSI qu’à hauteur de 35%. La fonction, de plus en plus consommatrice de numérique, prendrait elle-même à sa charge la majorité de ces dépenses.

Néanmoins, pour Gartner, cette plus grande autonomie financière des directions métiers pourrait aussi souligner les doutes éprouvés par celles-ci à l’égard de la DSI, ainsi perçue comme trop lente à répondre à leurs besoins.

« Pour saisir les opportunités numériques générées par la troisième ère, les DSI doivent faire preuve de rapidité et d’innovation, tout en étant confrontés à de l’incertitude » souligne Gartner, pour qui cela impose aux DSI de gérer deux approches, avec d’un côté une IT classique, « sûre et stable », et de l’autre une démarche rapide, plus agile et non linéaire.

Là encore, ce n'est pas forcément nouveau comme ont déjà puen témoigner des DSI, à plusieurs reprises, sur ZDNet.fr.