Historically, the Agile approach is a set of practices used for IT development projects. 

The Manifesto published in 2001 proposes 4 main values to revolutionise the performance of companies:

This emphasis on human interaction between the development team and business teams aims at reducing the time to market of the products developed, as opposed to projects conducted in V-model which, once delivered, may no longer satisfy changing business requirements.

Today, this practice is applied in most companies at all levels. In the latest State of Agile Report, out of more than 4,000 companies surveyed worldwide, 95% declared that they use agile and 65% of them have been practising it for at least 3 years.  In addition to IT, the methodology is also used in marketing, human resources, sales, and finance departments. 52% of the companies surveyed stated that at least half of their company’s departments adopt agile processes and therefore the scalability of such practices should not be ignored.

Beyond a project management method, it is a new philosophy with gamified elements. We no longer speak of meetings but of ceremonies, with new roles appearing such as product owner and scrum master. Using this philosophy, the desire is to create an atmosphere of co-construction and to make maximum use of collective intelligence to improve the company’s performance.

Although the concept of security is present in the manifesto, the integration of such measures into product development is not properly addressed. The method by which security is implemented in V-model projects does not apply to the agile philosophy and thus new ways of implementing security should be identified for it.

What are the trends and challenges of this field?

One of our challenges is to provide our clients with a global view of their problems. Adopting an agile approach requires a change in all levels of the business from security, to quality teams and as such the effect on all levels of the business must be considered.

In terms of organisation, the ISS must reposition itself as a service to the business and thus shift its image from a ‘policeman’ to a support function. The role of Security Champion (a member of the feature team such as a developer) becomes the point of contact for the ISS teams. In doing this a connection can be created with each feature team, thus increasing autonomy over security integration. This is not something that can be achieved overnight, it requires training to highlight cybersecurity issues and share knowledge (particularly the basics of ISS and secure development). In addition to this, a security Guild should be created, bringing together ISS experts, security champions as well as security enthusiasts. This allows members to exchange information on the latest security news, good practices as feedback and lessons learned from the field. This Guild must be set-up in such a way to allow easy communication between members (such as on an internal wiki).

After the security champion receives training from the ISS team, they become the security referent and thus developers can turn to them for questions and advice. Therefore, the role in itself is fairly technical. In adopting an agile approach, the ISS experts will keep their role, but the relationship will change from that of control and audit to support and facilitative. Audits can still be carried out (such as penetration tests) at the request of the feature team or on the initiative of the security experts. Methodological tools must also be available to help the Champions in their tasks and this includes rewriting risks in conversational format. To adapt to the use of User Stories by feature teams, the ISS team could try writing Evil User Stories, which correspond to an action carried out from the point of view of an attacker. For example:

Faced with these risks, there are Security User Stories, proposing remediation solutions for EUS, with ready-to-use acceptance criteria. All this can be integrated into a security baseline (also in backlog format, in a product management tool, such as JIRA for example), proposing a minimum-security base to be integrated into the products.

In addition to organisational support for the teams, technical support must be provided by optimising the continuous integration and deployment chain (CI/CD) with tools aimed at automating security as much as possible, which can be called the Security Stack or Security Pipeline: code review, vulnerability scans, detection of secrets, security of the Infrastructure as Code, etc.).  Particular attention must be paid to its own security, so as not to produce the opposite effect… From a shift-left security perspective, security is integrated into the product by default, right from the start. It therefore adapts its velocity to that of an agile approach and enables a shift from a DevOps logic to that of DevSecOps. 

Another role can be created, that of AppSec Manager. This is part of the ISS team and is an expert in software security as well as an expert in the security stack. Their role is to help the developers to prioritise and remedy the vulnerabilities reported by the Stack. They work in tandem with the Risk Manager/IS expert, who provides them with knowledge of the risks associated with the product, which enables a more detailed analysis of the vulnerabilities to be dealt with as a priority. All this helps to create a culture of security by design.

What do customer expect?

CISO customers expect to be reassured that security in agile mode will not cause them to “lose control” over the proper implementation of security. The model we propose empowers the feature teams, gives them tools, but security retains control by centralising the performance indicators, by having the capacity to carry out random checks/according to predefined criteria, via bug bounty for example or an envelope of pentester days, to be distributed over the various products.

Secondly, as a consultant, I think that clients expect us to share our convictions and very concrete examples of what we have been able to achieve for other clients. To meet this demand, Wavestone’s Cybersecurity and Digital Trust (CDT) practice has created several methodological accelerators based on feedback from the field, ready to be shared and adapted. Being able to carry out the mission in Agile mode was also part of the expectations, favouring co-construction rather than providing fixed and almost finalised deliverables from the first draft. In this gamification perspective, which is very important from an agile approach, we offer original co-construction workshops based on collective intelligence, thanks to our Creadesk asset, which trains consultants and provides them with tools for remote collective work.

Any final advice for our readers?

Implementing a true test & lean approach is crucial. In order to extract the most benefit from using co-constructing tools, we must regularly test and verify them in the field. While anticipating problems is crucial, significant value can be achieved when one we confront the problems as they arise. It allows us to be in direct contact with the business and feature teams, to show them that concrete actions are being implemented. The approach is agile, flexible, and scalable. The accelerators, methodologies and tools proposed evolve during the pilots and become even more relevant for the second wave of pilots, until all the feature teams are integrated.

At the same time, it is important to remember that change management is essential. A real communication plan is needed – building communities of practice/guilds from the beginning of the pilots and identifying early adopters who will be valuable drivers of change within the teams. Agile has a real and rapid impact in everyday life and at all team levels: implementing this change is essential.  

Cet article Agile Security, Emma Barféty interview est apparu en premier sur RiskInsight.

“Security accreditation is a formal act by which the authority responsible for a system commits its responsibility to risk management.” [1]. It is of course mandatory in some cases[2], but beyond that, it is also a way of sending a strong message to users and top management: security is indeed a major topic for the organization. Agile methodology was at first designed for projects, but it can be a real opportunity for security teams to reduce security risks.

This method disrupted working habits of product teams and ISS teams (Information System Security). The latter have to find a way to go beyond adapting old accreditation method and propose a new relevant solution to still comply with the original goal of the accreditation: “Find a balance between acceptable risk and security costs, then have it formally accepted by a manager/an authority who has the power to do so[3]”.

One solution: provisional accreditation and long-term accreditation

As a famous Agile Security expert from Wavestone once said: “Agile and accreditation, it’s not rocket science”. Without denying the difficulties, explaining it is quite simple. Faced with teams that must deliver faster and provide continuous releases, the risk levels and therefore the security accreditation must be dealt with at the same pace.

What should the accreditation consider?

As always, security accreditation is all about giving thorough information on a project’s security risk level to the Accreditation Authority, for them to decide if it’s acceptable with regard to the organization ISS criteria (e.g. number of EUS still on the backlog, percentage of security baseline rules implemented on a given scope, etc.). Then, they take responsibility for the possible residual risks.

For example, only a few features are available to a few users at the beginning of a project. This small scope will display a lower level of risk (because of a low level of exposure) despite not being fully secured yet. Provisional accreditation (for a few months for example) may be issued to allow experimentation. It will have to be renewed when renewal criteria (defined in advance) are met.

Figure 1 – Product exposure to residual risk
From the ANSSI guide (in French): Digital Agility and Security, October 2018 (link to the guide)

For a project at cruising speed, accessible to its target audience with all the expected features, a firm accreditation (3 years for example) is pronounced. The criteria for renewal, leading to the issuance of a new accreditation, are also defined in advance.

When to renew the accreditation?

The criteria used to know when to renew the accreditation are closely linked to the project, the context, or the scope, but here are some examples to build these criteria. The provisional accreditation is valid until:

• New critical features are added (“critical” depending on the project),
• A new threshold for the number of users has been reached (defined in advance, depending on the associated risks),
• New personal data must be integrated and processed by the project,
• New features related to payments must be implemented,
• A new level of transaction volume is reached,
• And of course when the accreditation deadline is reached.

Long-term accreditation is valid for a longer time because less changes are expected at this stage of the project. That being said, the accreditation will have to be renewed regularly (at least every 3 years) to check on security levels and in a will of continuous improvement.

What evidence should squads bring?

Squads/feature teams should be able to bring different types of evidence/proofs (of the security level) to the Accreditation authority/responsible for the accreditation. The Evil User Stories (EUS) serve as what we used to call risks, where prioritization gives information about their criticality (see our article on how to lead a workshop on risk analysis in Agile). An extract from the backlog can be used as proof that the main EUS have been processed and that residual EUS are known (and accepted by the Accreditation Authority).

The Security Form (or Passport, detailed in this article on Agile transformation – in French -) is also a relevant way to follow-up on security levels of projects.

Code review and vulnerability scan reports can also be used (for squads that have integrated DevSecOps and have the appropriate tools).

If the X-team exists (see our article on the new ISS roles in Agile and the corresponding organization) or if an external audit team was able to perform them, the penetration test reports are also presented.

Any other existing documents can be used to give all necessary information (architecture documents, applicable regulations, etc.).

For provisional accreditation, these documents don’t have to be gathered in a proper “accreditation folder”, which would imply losing time for squads. What is necessary is to ensure they exist and are available to anyone involved in the accreditation process (accreditation authority or their delegate, ISS team, etc.).

Who are the actors in this process?

During product development, the Security Champion (see this article for definition) is in charge of organizing the risk analysis workshops (identification of EUS and associated Security Stories). The ISS team is of course involved in the process, bringing their knowledge to the squads during workshops.

The Product Owner is responsible for the creation and updates of the necessary documentation. They also make sure the ISS team is informed and asked for help when needed.

The accreditation Authority should be a business manager (e.g. the Business Owner) as usual. They must have the capacity to accept residual risks and validate the product security levels. As security should not slow down any Agile processes, the signing of a provisional accreditation may be delegated to the Product Owner, as they are representative of the Business Owner in the squad. The temporary accreditation can thus be signed faster if criteria for validity are met. In some cases, where projects would pose a risk to other businesses or systems, a transversal officer/business owner must be found, to sign for both businesses or systems. If no one is found, or no compromise is achieved, the Chief Information Officer (CIO) will assume responsibility, as it is their role to ensure the operational conditions of the Information System.

As a conclusion, security accreditation remains key when speaking about integration of security into projects, in particular within the Agile framework which changes the product teams’ way of working. The ISS teams must take advantage and (re)join these product teams (through the Security Champion and the security training of the product teams) and thus work together towards the incremental reduction of risk.

More articles to come on Agile Security, stay tuned!

[1] ANSSI guide (in French): Digital Agility and Security, October 2018 (link to the guide)

[2] (French regulations only) For administrations: decree n ° 2010-112 of February 2, 2010, terms of the General Safety Reference System (RGS). For any product dealing with information coming under National Defense secrecy: Interministerial General Instruction 1300. For operators of vital importance: cyber section of the LPM (law n ° 2013-1168 of 18 December 2013 – article 22), to strengthen the security of the critical information systems they operate, carried out as part of an accreditation process.

[3] ANSSI guide (in French): The nine steps of the security accreditation, August 2014 (link to the guide)

Cet article Security accreditation for Agile projects: how to successfully do it ! est apparu en premier sur RiskInsight.

Un e-commerce pionnier

Les premiers à avoir dû rendre compatibles robustesse et agilité sont sans aucun doute les acteurs du e-commerce. Ils ont dû pour cela résoudre trois difficultés majeures :

1. Le business demande un time to market au jour le jour
2. Le succès fait accroître le besoin en puissance de façon exponentielle (comme le montre la  vente sur internet)
3. Le digital rend les architectures systèmes de plus en plus complexes et hétérogènes (il suffit de regarder l’exemple du transport aérien)

Agile robustesse, impossible équation ?

Observons leur exemple pour voir comment ils ont su répondre à la problématique du  « tout digital », allant parfois à l’encontre de certaines certitudes.

Conviction°1 : adapter la proximité MOA-MOE

L’organisation globale des entreprises doit tenir compte de l’agilité du SI sachant qu’il faut distinguer trois cas « types » : SI « classique », SI « ERP » et SI « multi-canal ». Pour le dire simplement : plus le besoin en agilité est fort plus les acteurs métiers et IT doivent être proches. L’organisation en mille-feuille, de par son manque cruel d’agilité et de par la multiplicité des acteurs qui la composent, souffre par définition d’inertie. Il ne faut pas d’ailleurs se limiter à rapprocher uniquement  les équipes MOE et les équipes MOA : il est nécessaire que les acteurs de la mise en production acquièrent une vraie sensibilité « métier ».

Conviction°2 : nommer un responsable système de bout en bout

La multi-canalité et le « tout digital » ont mis en évidence la difficulté de garantir une vision complète et maîtrisée du SI par des équipes organisées par technologies ou domaines fonctionnels. Cependant, la notion ou le rôle d’un responsable « système » (de bout en bout) est encore peu fréquent et incompatible avec les organisations en place. Il s’avère que ce manque de vision et de responsabilité transverse est l’une des causes majeures des difficultés et des coûts de mise en production. Pour pallier à ces difficultés, les entreprises mettent en place des batteries de tests de non-régression générant des coûts récurrents importants. Par souci d’agilité, il faut adapter ces tests en permanence et en raison de la complexité des chaînes de liaison, il est difficile de disposer des tests complets et pertinents.

Conviction°3 : recruter des profils plus qualifiés

Le recrutement de talents pour la filière SI se limite encore trop souvent aux « études », réputées plus créatives. Mais cette stratégie a ses limites. En effet, la crise a imposé un gel des embauches, ce qui a conduit à un vieillissement des équipes et donc à une perte progressive de connaissance sur les nouvelles technologies, les nouveaux usages et les nouvelles méthodes de travail. Par ailleurs, la complexité des architectures nécessite aujourd’hui, notamment dans les activités historiquement considérés comme « techniques », moins de valeur créative ce qui a conduit à une réelle perte d’attractivité. Pourtant, la mise en production ne doit plus être considérée comme un simple geste technique mais comme clé de voûte de la qualité du système entier ! Elle nécessite des compétences fortes et transverses.

Conviction°4 : partager les risques entre Métiers et DSI

L’entreprise a aujourd’hui besoin d’accroître sa capacité de gestion de risque. Les trois points évoqués précédemment sont des conditions nécessaires pour améliorer la situation et enfin trouver des gains escomptés dans la durée. Mais le partage des risques entre les acteurs métiers et  les acteurs IT en fonction des enjeux business permet de tirer profit des investissements à réaliser. Bien entendu ceci passe par la mise en place d’un pilotage fondé sur des indicateurs pertinents. La question du coût de mise en production est relative et doit être directement reliée à l’impact métier… soit la prise de risque associée.

Bien sûr, les grandes entreprises ne peuvent pas pleinement se comparer à ces acteurs du e-commerce qui, pionniers en la matière, ont été privilégiés par la petitesse de leur structure et par l’unique objectif qu’ils suivaient de mener à bien leur business naissant. Mais les grandes sociétés ont tout de même beaucoup à apprendre d’eux. À chacun de trouver sa recette pour conjuguer succès rapides et une stratégie moyen terme.

Cet article Une mise en production agile et robuste, et si l’équation était finalement possible ? (2ème partie) est apparu en premier sur RiskInsight.

Dans un contexte économique difficile, accroître la fiabilité de la mise en production des applications représente un gisement d’économies souvent inexploité » annonce Pierre Audoin Consultants en septembre 2013, suite à l’enquête menée auprès de 50 entreprises et administrations. Face à cette préoccupation majeure des DSI qu’est la maîtrise des coûts, l’enquête fait ressortir un certain fatalisme de la part des entreprises interrogées par rapport à la qualité et in fine au coût engendré par ces opérations fréquentes et parfois complexes. Le cabinet PAC fait preuve dans ce document d’une vision claire de la frontière existante entre les études build et la production run, même si cela n’est qu’une partie du problème global. Il apporte aussi quelques pistes clés pour améliorer à la fois la préparation et l’exécution des mises en production, mettant en avant des bonnes pratiques sur l’outillage et en particulier sur le référentiel ITIL. Des pistes intéressantes que nous avons souhaité creuser davantage. Mais pour ce faire, il est avant tout nécessaire de faire un vrai retour en arrière sur la chaîne de valeur informatique. Nos recommandations feront quant à elles l’objet d’un prochain article.

Retour sur les 1^ères organisations informatiques

Retournons 30 ans en arrière ! À cette période, les organisations informatiques se sont  structurées en fonction de la chaîne de valeur de l’informatique de l’époque. Il s’agissait des applications « métiers » implémentées sur des systèmes centraux plutôt monolithiques et développées sur des spécifications répondant aux exigences « métiers » particulières à chaque entreprise. La réalisation de ces applications, leur maintenance et leur exploitation étaient organisées d’une façon séquentielle. Les cycles d’adaptation et d’évolution étaient assez longs. Le cœur du SI concernait le « produit », l’utilisateur accédait par un terminal « passif ».

La grande stabilité des applications et le côté « monolithique »  des architectures centrales rendaient des opérations de mise en production assez simples, voire « mécaniques » et par conséquent plutôt fiables. Nous avons pu constater que la chaîne de valeur IT était alors naturellement industrialisée, sans qu’un effort particulier n’ait dû être fait. Par ailleurs, le faible nombre de fournisseurs et la prédominance d’IBM a largement facilité la tâche à l’époque.

ITIL : une solution pas forcément miraculeuse

Il est intéressant de rappeler que l’arrivée d’ITIL dans les années 80/90 coïncide avec l’émergence des architectures distribuées, rendant les mises en production plus complexes et faisant naître par la même occasion le besoin d’une formalisation des processus, pour retrouver une robustesse comparable. Toutefois la mise en production était alors restée une activité « technique » et par conséquent prise en compte par les techniciens de la production informatique. Ces activités étaient très loin des préoccupations des acteurs métiers… et les organisations IT et leur fonctionnement n’ont pas été mises en cause pendant longtemps.

Bien que proposée comme une solution clé par l’enquête PAC, la mise en place d’ITIL « pur(e) et simple », voire son implémentation « doctrinaire », peut aujourd’hui se révéler contreproductive car elle ne répond plus aux exigences d’agilité et de robustesse. En effet, la crise de 2008 et ses conséquences économiques ont mis à l’ordre du jour la question de l’efficacité de la mise en production.

Quelle réalité aujourd’hui ?

La généralisation des architectures « composites », l’arrivée de la « multi-canalité » et l’explosion du digital changent profondément la donne et mettent en cause les paradigmes du passé. Il faut l’avouer, les conséquences à venir dépassent largement le domaine des « bonnes pratiques » de la production informatique. Aussi, fort de cette compréhension du passé, LA question à laquelle il faut se soumettre est celle qui permet de trouver le meilleur équilibre entre l’agilité et la robustesse du SI. Pour le savoir, rendez-vous dans quelques jours pour une autre chronique.

Cet article À l’ère du « tout digital », la mise en production (re)devient un enjeu d’agilité et de robustesse (Partie 1) est apparu en premier sur RiskInsight.

Des missions au service d’une adoption progressive du Cloud

En mettant en place un incubateur Cloud, la DSI se donne les moyens de piloter la trajectoire et le rythme de la transformation qu’induit le Cloud. Elle peut aussi promouvoir l’usage des services Cloud qui permettront de combiner au mieux innovation, maîtrise financière et maîtrise technique du SI.

Dans ce cadre, l’une des priorités de l’incubateur est de se faire connaître, de promouvoir son action afin de capter au plus tôt les initiatives Cloud qui pourraient émerger. Ceci fait, son leitmotiv doit être de favoriser ces initiatives en facilitant le déploiement et l’intégration de ces nouveaux services dans le SI.

Pour cela, il doit jouer un rôle de conseil et de contrôle dans le cadre des projets, pour anticiper d’éventuels écueils techniques ou juridiques réels, mais aussi permettre de relativiser un certain nombre de risques ou de freins non justifiés.

Il diffuse également son expertise et ses retours d’expérience issus d’initiatives précédentes, pour sensibiliser les Métiers et les équipes de la DSI aux impacts du Cloud. Ceux-ci concernent aussi bien le SI (problématiques d’intégration et de réversibilité, décommissionnement de l’existant pour justifier le ROI de l’initiative…) que l’utilisation des services (limitations fonctionnelles liées à l’usage d’une solution standard, perte de maîtrise sur les processus d’évolution et de gestion des changements…).

Ensuite, en s’appuyant sur une veille marché active, il identifie les périmètres du SI éligibles au Cloud et promeut les nouveaux usages porteurs de valeur pour l’entreprise.

Enfin, il a vocation à préparer la transformation de la DSI et du SI pour passer à l’ère du Cloud. Il animera ainsi les réflexions autour des évolutions et de l’outillage nécessaires à la DSI pour maîtriser les impacts du Cloud sur les plans suivants : compétences et organisation, modèle économique et pilotage des coûts, garantie de la qualité de service et de la sécurité sans oublier la mise en cohérence et l’homogénéité du SI.

Si son action est efficace, l’incubateur favorisera un passage en douceur vers une gestion industrielle des services Cloud par les équipes de la DSI.

Une structure visible et agile…

Pour assumer pleinement son mandat, l’incubateur doit bénéficier d’un haut niveau de sponsorship et d’un rattachement transverse au sein de la DSI pour être légitime et connu des Métiers.

Il doit également avoir la capacité de mobiliser les ressources de la DSI, sans pour autant s’inscrire totalement dans le cadre des processus classiques de la DSI. Ainsi, il sera en mesure d’accélérer et de favoriser les  initiatives, en  particulier lorsque le service Cloud concerné est en phase d’expérimentation ou de pilote. C’est la seule façon pour l’incubateur de réussir à ancrer la DSI dans l’adoption du Cloud et la seule façon de démontrer la valeur ajoutée que la DSI peut apporter aux utilisateurs. À l’image d’une cellule « Innovation », c’est au travers de la réussite durable des initiatives qu’il aura accompagnées et du changement d’image de la DSI qu’il aura véhiculé que l’incubateur prouvera sa propre valeur et justifiera l’investissement qu’il représente.

…mobilisant de larges compétences regroupées sur quelques personnes

Afin de conserver l’agilité nécessaire, l’incubateur doit rester compact : 3 à 5 personnes. En revanche, le succès de l’incubateur repose avant tout sur la qualité du casting de ces personnes.

Pour mener à bien les missions de l’incubateur, les profils à cibler sont ceux alliant compétences IT larges et parfaite connaissance de l’entreprise et disposant d’un leadership fort pour promouvoir de nouveaux usages et de nouvelles pratiques. De tels profils sont généralement des ressources critiques et libérer une partie de leur temps pour qu’ils se consacrent à l’incubateur est un réel investissement.

Cet investissement est un impératif pour la DSI. Même si l’appel à de la prestation externe est envisageable pour apporter compétences techniques et connaissance des offres Cloud, il n’est pas suffisant pour assurer la maîtrise de l’organisation et de l’existant de l’entreprise.

Si les bonnes ressources ne sont pas disponibles en nombre suffisant, mieux vaut privilégier le caractère compact de l’équipe à la couverture exhaustive des compétences nécessaires.

Quelles actions pour débuter ?

La priorité doit être donnée à l’accompagnement des initiatives qui permettront d’obtenir des quick wins visibles par le Métier et aux actions de communication valorisant les apports du Cloud et de l’incubateur. C’est par ce biais que l’incubateur pourra réellement être l’avant-poste de la transformation induite par le Cloud.

Deux éléments nous semblent essentiels à produire immédiatement par l’incubateur : un kit de sensibilisation aux bénéfices et aux impacts du Cloud (paiement à l’usage, localisation des données, évolution des relations DSI / Métiers…) et le catalogue des services Cloud déjà déployés ou à venir.

Une chose est sûre, l’objectif n’étant pas de pérenniser son existence dans l’organisation, l’incubateur doit avancer vite et donner la priorité à l’action et non à la réflexion !

Cet article Aller vers le Cloud oui, mais comment légitimer la DSI ? est apparu en premier sur RiskInsight.

Une adoption motivée par réduction des coûts et recherche d’agilité

Malgré la dynamique du marché et la promesse de gains sous-jacente, les DSI des grandes entreprises tardent à se mettre en mouvement, réagissant plus au Cloud qu’elles ne l’anticipent. Elles le privilégient essentiellement pour des usages à risques techniques limités et à ROI rapide, principalement en IaaS et en SaaS.

SaaS : une utilisation massive des services standardisés

Le SaaS est aujourd’hui le principal vecteur d’adoption du Cloud. L’adoption du SaaS est centrée sur les fonctions support dont l’usage est standardisé (bureautique, messagerie, CRM, paie…). Le SaaS est également fortement sollicité pour les services de sécurité (antivirus, proxy, services de tests d’intrusion…) qui nécessitent une puissance de calcul importante, des évolutions en cycle court ainsi qu’une disponibilité maximale pour des employés de plus en plus mobiles.

PaaS : une adoption encore confidentielle

C’est le segment le moins bien appréhendé par les grands groupes aujourd’hui. Il correspond à la fourniture d’une plateforme d’exécution de code informatique. Il permet la mise à disposition d’une application en limitant très fortement les opérations sur les couches sous-jacentes (systèmes, bases de données, serveurs d’applications…). Le PaaS reste aujourd’hui cantonné chez les grands comptes à des usages « jetables », comme des prototypes ou des sites web temporaires (événementiels).

IaaS : des déploiements essentiellement en mode « privé »

Le modèle IaaS, fourniture de machines virtuelles (VMs) et ressources associées depuis un Cloud, qu’il soit public ou privé, permet d’introduire davantage d’agilité. Les grandes entreprises déploient aujourd’hui beaucoup de IaaS privés, dans l’optique de capitaliser sur leurs compétences internes et leurs investissements en infrastructures. De son côté, le IaaS public est mis en œuvre de façon très ciblée, par exemple pour une filière web, ou dans une logique de « bac à sable ».

Pour autant, grâce à la consolidation à grande échelle, c’est le modèle public qui permet d’obtenir les gains fonctionnels et financiers les plus importants. C’est pourquoi les stratégies de déploiement de IaaS privés sont ou doivent être considérés comme une étape sur une trajectoire plus ou moins long terme de généralisation d’IaaS public.

Un avenir qui promet plus d’innovation et de valeur ajoutée

La 1ère phase d’adoption du Cloud est motivée par la recherche d’économies et l’optimisation du niveau d’agilité. Ces prochaines années, le marché devrait évoluer pour offrir des solutions avec une valeur ajoutée de plus en plus forte, pour répondre à la fois aux offreurs en quête de relais de croissance et aux entreprises utilisatrices souhaitant optimiser leur marge en se recentrant sur leur cœur de métier.

Le SaaS devrait s’imposer dans les entreprises comme le choix par défaut. Les éditeurs de logiciels vont proposer de manière systématique leurs solutions en mode SaaS, en partenariat avec les fournisseurs IaaS. Ils s’assureront ainsi des revenus constants et proposeront à leurs clients des services très industrialisés, flexibles et au meilleur coût.

L’usage du PaaS devrait exploser lorsque les problématiques de portabilité des applications, bien souvent surestimées, seront résolues. Il devrait alors devenir le socle d’exécution par défaut de toutes les applications qui ne seraient pas consommées en SaaS. Ces plateformes vont s’enrichir pour fournir aux développeurs un maximum d’accélérateurs et de nouvelles possibilités (composants et connecteurs pré-packagés, services de sécurité, réseaux de distribution de contenus… ) et donc en faire un choix par défaut dans les filières de développement.

Par ailleurs, les éditeurs de progiciels devraient rapidement proposer leurs solutions en mode pré-packagé pour les plateformes PaaS du marché. Le IaaS devrait perdurer pour adresser des besoins applicatifs très spécifiques. Mais il ne permettra pas d’aller chercher toutes les économies d’échelle d’une approche Cloud.

 Ce sont le SaaS et le PaaS qui porteront le marché demain.

Cet article Le Cloud : quelle réalité marché derrière les nuages ? est apparu en premier sur RiskInsight.

Une infrastructure prépackagée livrée clé en main

Dans une infrastructure convergente, les différents composants (serveurs, stockage, réseau, sécurité) sont considérés comme des ressources interopérables gérées par une plate-forme commune : un moteur de services partagés. Ces infrastructures donnent la possibilité d’assembler ou de désassembler un pool de ressources à la demande pour ajuster au mieux le dimensionnement de l’ensemble du socle technique aux besoins réels d’une application. L’infrastructure est alors facilement scalable en cas d’augmentation de la charge.

Avec ce type de solutions, plutôt que d’assembler des composants individuellement, le client peut maintenant acheter un « bloc » de composants dans une offre prépackagée et préconfigurée par le fabricant. Ces offres sont généralement déclinées en plusieurs niveaux différents ayant chacun un dimensionnement spécifique et contenant plus ou moins de modules. Selon le besoin, le client peut ainsi choisir une offre « standard » (des serveurs d’application avec prise en charge du stockage et mise en réseau par exemple), ou opter pour une offre « haut de gamme » donnant accès en plus à des mécanismes intégrés de redondance.

Par ailleurs, à la différence des mécanismes de virtualisation serveurs, les infrastructures convergentes permettent une virtualisation de bout-en-bout d’une architecture en couvrant plusieurs types de composants, du matériel au logiciel.

Les infrastructures convergentes, un gain en efficacité et en productivité

Les systèmes d’information de nos clients sont souvent constitués de plusieurs outils  hétérogènes complexifiant le déploiement de nouvelles infrastructures. Avant même de commencer l’installation des composants applicatifs, un temps non négligeable est consacré aux phases amont d’évaluation des ressources, d’installation du matériel, d’intégration des serveurs et des périphériques. Cette étape amont est à la fois gourmande en temps et en ressources, pour une valeur ajoutée métier faible. En proposant la construction d’une infrastructure opérationnelle à partir d’une pile d’éléments pré-intégrée et pré-testée, les infrastructures convergentes réduisent considérablement la durée de cette phase.

Outre le gain de temps, les solutions d’infrastructures convergentes permettent un suivi centralisé et outillé des composants du SI. En effet, elles consolident plusieurs outils de supervision en une seule console assurant la gestion intégrale de l’environnement du datacenter. Les administrateurs sont alors capables d’avoir une vision globale du SI, d’orchestrer les différentes briques de manière optimale en éliminant les tâches manuelles, à la fois fastidieuses et génératrices d’erreurs.

La convergence au détriment de la souplesse du SI

Si les solutions d’infrastructures convergentes semblent séduisantes, elles exigent néanmoins un pilotage et une organisation sans faille des ressources, ce qui est possible lorsque l’ensemble de la pile est non seulement convergent, mais également administré à partir d’un cadre unique englobant à la fois les infrastructures physiques et virtuelles.

De plus, pour conserver un catalogue de services diversifié, les DSI ne souhaitent pas « s’enfermer » dans un modèle mono-fabricant sur tout ou partie des couches de leur infrastructure.

Par conséquent, un des enjeux des fabricants de solutions d’infrastructures convergentes reste à gérer la combinaison de différentes solutions (physiques ou virtuelles) de plusieurs fabricants pour mieux répondre aux attentes réelles des hébergeurs et des entreprises disposant de salles hétérogènes.

Accélérer les déploiements mais à quel prix ?

En gestion des infrastructures, la convergence n’est plus seulement une possibilité technologique mais devient un véritable facteur de productivité. Le but ultime des solutions d’infrastructures convergentes est d’aboutir à un système unifié et géré depuis un point central ; une sorte d’ « appliance d’infrastructure » qui serait à la fois scalable et interchangeable. À terme, cette rationalisation permettra de répondre à des besoins de performance économique et de réactivité des outils informatiques.

Néanmoins, telle qu’elle est envisagée actuellement par les grands fabricants, la rapidité opérationnelle de ces infrastructures se fait au détriment de l’ouverture du SI et de son agilité. Sur le long terme, les limitations de ce type de solutions pourraient impacter l’évolutivité du SI et son adaptabilité à des besoins futurs.

Par ailleurs, les retours d’expériences montrent des difficultés dans la définition du partage de responsabilité entre les équipes des silos techniques traditionnels. Ces solutions demandant donc à revoir les organisations pour les aligner aux fonctionnalités fournies.

Pour conclure, la transition vers la convergence de l’infrastructure implique d’avoir des besoins très homogènes en technologie sans pour autant vouloir recourir aux offres cloud. De plus, une migration vers une infrastructure convergente doit être réalisée avec précaution en s’assurant de la réversibilité de la migration d’une part et de l’évolutivité de la solution d’autre part pour éviter les écueils des systèmes « fermés » (mainframes par exemple).

Cet article Infrastructures convergentes : stratégie du futur ou retour vers le passé ? est apparu en premier sur RiskInsight.

Une relation MOA/MOE qui montre ses limites

Force est de constater qu’aujourd’hui, la relation MOA/MOE dans les projets n’est pas au beau fixe. Certains métiers préfèrent en effet travailler directement avec la MOE pour garantir une meilleure réactivité et éviter des fonctionnements en mode « passe-plat ». La séparation MOA/MOE entraîne finalement une dilution des responsabilités sur les projets et des difficultés de partage des priorités : un package bancal qui ne permet pas une mobilisation globale efficace. Enfin, ces dispositifs se révèlent inefficaces pour gérer la transversalité entre plusieurs contributeurs. Ils sont également sources de rupture dans les processus projets par les trop nombreux allers-retours qu’ils engendrent.

Par ailleurs, le niveau de structuration de la MOA est proportionnel au niveau d’importance du SI dans l’entreprise. La relation MOA/MOE montre ainsi ses limites dans des secteurs où le SI a une position clé tel que l’assurance ou encore la banque.

Une agilité clé du succès

La complexité de la relation MOA/MOE tient à deux éléments clés : les enjeux métiers et la nature du SI.

Au sein d’une entreprise, les métiers qui ont un enjeu de réactivité important (time to market faible), d’agilité ou d’innovation (multiplication des lancements de produits), auront besoin d’une forte proximité entre la MOE et les métiers. Limiter le nombre d’acteurs au sein des projets parait de ce fait pertinent.

La nature du SI constitue également un facteur d’influence de la relation entre métiers/MOA/MOE. En effet, la fonction MOA est indispensable pour des SI développés en mode « sur mesure » pour les métiers de façon à garantir la prise en compte des spécificités de ces derniers. Pour des SI de type web et surtout de type ERP, une forte proximité entre les métiers et la MOE sera ainsi nécessaire pour optimiser les opérations de paramétrage.

Contrairement à ce que l’on pourrait penser, le couple MOA/MOE doit se définir au niveau de chaque projet et non de la DSI dans son ensemble pour être au plus près des enjeux métiers et tenir compte des natures de SI à faire évoluer.

Réinjecter de l’innovation dans la gouvernance des projets

Au-delà de la « frontière » MOA/MOE, c’est la gouvernance des projets dans sa globalité qui doit être revue.

Il est temps de troquer les habitudes du fonctionnement en cycle en V contre de nouvelles méthodes projets et de nouveaux modes de travail. L’introduction des méthodes agiles ou de développements rapides doit venir enrichir les méthodes projets existantes et être déployée de façon pragmatique en fonction des besoins des métiers et des natures de SI considérés. Par ailleurs, des solutions « multi-canal » demandent à la fois une vision transverse du SI mais également des structures de pilotage avec des responsabilités claires.

Au sein d’un projet, les modes de fonctionnement doivent également être revus pour favoriser la collaboration entre MOA/MOE : par exemple travailler en mode « plateau projet », co-construire  des livrables clés, etc.

Le SI, à l’image du développement des ERP et des progiciels, ne serait-il finalement pas en train de structurer de plus en plus les processus métiers et d’inverser la relation entre les DSI et les métiers ? S’il n’est qu’une seule chose à retenir, c’est que la relation MOA/MOE doit l’anticiper et se réinventer : intégrer plus de flexibilité et d’agilité pour toujours mieux servir ses métiers. Gagner plus d’efficacité dans le delivery projets ne devra néanmoins pas masquer les optimisations nécessaires entre MOA et MOE sur la gestion des priorités.

Cet article MOA/MOE : un couple efficace ? est apparu en premier sur RiskInsight.

En quoi investir dans la fonction architecture est aujourd’hui clé ?

La tendance des entreprises à s’appuyer et dépendre toujours plus des outils informatiques entraîne une complexité et une criticité croissantes du SI. Il est devenu indispensable pour la DSI d’en assurer une maîtrise globale, pour en garantir l’efficacité et l’agilité. Dans ce cadre,  la fonction Architecture a  un rôle central à jouer pour garantir cette maîtrise : elle a pour ambition d’améliorer la cohérence du SI et son alignement avec la stratégie de l’entreprise. Rôle clé qui se traduit notamment par une optimisation des processus métiers, une amélioration de la qualité des données, une meilleure maîtrise du SI par la DSI et une meilleure appropriation du SI par les métiers.

Concrètement, quelles sont les armes de l’architecture pour répondre à cet enjeu de maîtrise du SI ?

En premier lieu, je dirais que la fonction architecture a pour ambition de rendre agile le SI. En contribuant à la mise en place de composants réutilisables (techniques ou fonctionnels) et au développement de services d’infrastructure urbanisés, l’architecte  permet le développement rapide de nouvelles fonctionnalités dans le SI. Le SI peut ainsi s’adapter plus rapidement aux changements stratégiques et organisationnels, et la DSI devient  davantage proactive vis-à-vis des métiers.

Parallèlement, l’architecte œuvre à la rationalisation des composants du SI. Il est en effet  essentiel autant que possible de standardiser le  patrimoine applicatif et les flux d’échanges, de mutualiser les applications et les infrastructures et enfin d’augmenter le taux de réutilisation des composants du SI…

Enfin, la fonction architecture permet à l’entreprise d’avoir une vision d’ensemble et prospective du SI, propice à la fois à engendrer des économies substantielles dans les projets (diminution de la complexité des projets, réduction des délais conception/réalisation, réduction des coûts d’exploitation…) mais également indispensable pour réduire les risques (obsolescence des composants par exemple).

Est-ce facile de mesurer les apports de l’architecture ?

Non, et c’est là le souci. La maturité des entreprises est relativement faible en matière de pilotage des apports de la fonction architecture. En moyenne, les entreprises ne mesurent que 3 ou 4 indicateurs.

Déterminer les indicateurs adaptés aux enjeux et au contexte de l’entreprise n’est d’ailleurs pas forcément évident. Quelques règles s’appliquent néanmoins systématiquement :

• Les indicateurs doivent évoluer en fonction de la maturité de la fonction architecture : inutile de mesurer « tous » les indicateurs imaginables !
• Les différentes parties prenantes (DSI et métiers) doivent s’accorder sur les modalités de mise en place et le sens des indicateurs.
• Plus un indicateur est simple, meilleure sera son appropriation. Un indicateur trop compliqué à calculer ne sera pas suivi dans le temps.
• La représentation graphique facilite la communication et donc la prise de décision : n’hésitez pas à utiliser des graphiques facilement compréhensibles.
• La mesure des indicateurs doit faire partie d’un processus d’amélioration. Ce qui importe n’est pas tant la valorisation de l’indicateur mais son évolution dans le temps.

L’architecture, comme de nombreuses fonctions transverses de l’entreprise, est contrainte de légitimer son action pour être pertinente. La communication d’indicateurs appropriés constitue un levier indéniable.

Cet article L’architecture : l’urgence de mesurer son apport ! est apparu en premier sur RiskInsight.

LGA (Lise Gasnier) : Le Big Data a une dimension “métier” évidente : pour les entreprises, le défi est d’identifier les opportunités de business offertes par leurs gisements de données. Déjà, des “business cases” montrent la faisabilité et l’intérêt d’exploiter des données jusqu’alors “non valorisées”. Il devient possible d’en extraire une information utile pour mieux connaître sa clientèle, optimiser son marketing, détecter et prévenir des fraudes, analyser son image sur les réseaux sociaux et la valoriser, optimiser ses processus…

En s’inspirant des initiatives innovantes de leurs secteurs, les entreprises pourraient initier la réflexion “Big Data” autour de 2 questions basiques :

• De quelles informations avons-nous besoin pour accroître notre efficacité et innover ?
• Quelles sont les données sous ou inexploitées à notre disposition?

Le Big data invite les métiers à plus de liberté, plus d’audace dans leurs réponses.

Dans ce domaine comme dans les autres, répondre à la première question et exprimer des besoins précis prend du temps. C’est, de plus, une question à poser en continu. D’évidence, les objectifs métiers exigeront de produire sans cesse de nouvelles analyses, sur des données déjà traitées (donc les “ré-analyser”) ou non, avec des sources et formats inédits.

Pour répondre à la seconde question, les métiers doivent connaître les sources de données à leur disposition et savoir interpréter les données brutes, pour en saisir la pertinence et en extraire l’information utile. Sur ce terrain technique, il est évidemment souhaitable que la DSI les accompagne. Elle doit par conséquent démontrer sa maîtrise des données du SI, au-delà de la “zone de confiance” des données gérées dans les systèmes de base de données traditionnels de l’entreprise.

MMI (Mathieu Millet) : Pour la DSI, tout l’enjeu va donc être de pouvoir traiter la volumétrie et l’hétérogénéité des données pour ouvrir le champ des possibles aux métiers. Pour anticiper des besoins que les métiers ne savent pas exprimer aujourd’hui, elle doit se doter d’une architecture permettant d’emblée de collecter, stocker et analyser “plus” et “plus varié”. C’est bien d’une architecture agile que les métiers ont besoin.

Une approche initiale serait d’imaginer ce que serait son système Big Data en proposant quelques cas d’usage sur un « échantillon » représentatif de données, à la fois structurées (comme celle que l’on trouve dans les entrepôts de données) et semi-/non-structurées (logs d’applications, messages sur les réseaux sociaux, documents bureautiques, utilisation des données issues de l’Open Data…). Cette “promotion” du service permettrait ainsi à la DSI de présenter aux métiers la valeur ajoutée de ces données et d’anticiper un changement profond de son infrastructure. Nous l’avons vu : les technologies sous-jacentes sont innovantes et pointues. La DSI a tout intérêt à emprunter la pente douce de sa montée en compétence sur le “Big Data” ; surtout que les compétences sur le marché sont peu nombreuses et qu’aujourd’hui, une prise en main technologique est nécessaire.

L’autre axe de travail serait d’initier un dialogue avec les métiers pour mettre en commun leurs données, historiquement réparties et cloisonnées, dont la duplication entre différentes applications sera de facto très difficilement réalisable.

LGA : Quelle que soit l’hypothèse de travail, il sera évidemment nécessaire d’établir un dialogue constructif entre les métiers et la DSI afin d’assurer la réussite d’un tel projet d’envergure.

Lire aussi les articles :

Qu’est-ce que le Big Data

Quel est le paysage technologique du Big Data

Cet article Comment faire face à l’émergence du phénomène Big Data ? est apparu en premier sur RiskInsight.

Freiner la machine, mais juste quand il faut

Anticiper c’est d’abord détecter le plus en amont possible les signaux faibles de contraction d’activité : affaires décalées dans le temps, difficultés de concurrents, baisse du taux de réussite commerciale…. L’objectif c’est de freiner la machine juste quand il faut, mais pas trop tôt non plus en se basant sur le seul principe de précaution. C’est donc le moment de renforcer les « capteurs avancés » dont l’entreprise dispose pour se piloter, en mobilisant plus largement les équipes sur la détection de ces signaux faibles, et d’améliorer les modes de reporting et de décision. Les technologies collaboratives peuvent grandement aider à la mise en place de ces moyens.

Ne pas stopper la machine, la laisser tourner, même si c’est au ralenti

Anticiper, c’est aussi ne pas rater le moment de la sortie de crise. Les indicateurs avancés évoqués plus haut sont là aussi pour anticiper les signes de reprise et les opportunités à saisir. Ensuite, il faut faire redémarrer la machine très rapidement pour être les premiers à bénéficier de l’embellie. L’expérience nous montre que freiner une entreprise en marche, c’est complexe et long, même si le levier des budgets permet de « passer le message » assez rapidement. En revanche, remettre tout le monde en mouvement est beaucoup plus lourd et beaucoup plus laborieux. Nous pouvons faire le parallèle avec les usines dans le secteur de la chimie, de la métallurgie ou du raffinage du pétrole : arrêter une usine prend plusieurs jours, voire plusieurs semaines, de même que pour la redémarrer. Il vaut donc souvent mieux la laisser tourner, à régime réduit certes, mais la laisser tourner tout de même pour savoir redémarrer très vite dès que possible.

En profiter pour améliorer les performances de la machine

Enfin, anticiper, c’est aussi profiter des périodes de contraction d’activité pour améliorer les performances de la machine. L’idée, c’est de l’alimenter avec des actions de fond que l’on a tendance à reporter en période faste et qui permettront d’être plus performant demain : supprimer les lourdeurs de fonctionnement, simplifier les processus, supprimer les couches d’organisation inutiles, transformer les modes de managements en renforçant l’autonomie et la proximité avec le management… Autant d’actions pour sortir plus léger et plus agile de la période d’incertitude.

Cet article ANTICIPATION – Anticiper pour réussir la sortie de crise ! est apparu en premier sur RiskInsight.