Les DSI et les responsables informatiques adorent et détestent cela lorsque les termes techniques se répandent dans les médias et que les dirigeants en font une nomenclature trop utilisée. D'un côté, nous aimons le jargon bien compris, car il établit un contexte avec les dirigeants d'entreprise autour de la nécessité d'investir dans les nouvelles technologies, de changer les processus opérationnels, de mieux comprendre les technologies émergentes ou d'innover dans des domaines concurrentiels. D'autre part, certains termes techniques deviennent excessivement généralisés et finalement obsolètes au point où ils peuvent facilement détourner des moyens plus matures et progressifs de gérer et de gagner avec la technologie.
Après avoir pris la parole lors de nombreux événements cette année et rencontré des centaines de technologies. dirigeants, j’ai testé les sentiments généraux sur quels termes et concepts sont datés et quelles idées les remplacent. Nous avons également discuté de la façon dont ces concepts obsolètes peuvent condamner et faire dérailler les programmes de transformation numérique.
1. L'informatique bimodale a évolué pour devenir une culture DevOps
Gartner a introduit l'informatique bimodale en 2014 afin de permettre aux entreprises de gérer la vitesse et l'agilité des nouvelles technologies et le développement d'applications (mode 2) par rapport à la stabilité, la conformité et la fiabilité. systèmes d'entreprise à grande échelle demandés (mode 1.)
L'informatique bimodale aurait peut-être été une transition nécessaire pour les grandes organisations informatiques afin de mieux offrir de nouvelles expériences client et de commencer à adopter des pratiques agiles. Mais beaucoup ont vite compris que la perturbation numérique ne laissait aucune place au traitement bimodal et qu’il était une recette du désastre . Les entreprises qui ont réussi la transition vers l'informatique bimodale se sont vite rendues compte qu'il n'était pas suffisant de mener à bien la transformation et qu'elles avaient du mal à rester démoralisées en raison du blocage des plates-formes de support du mode 1.
Les organisations progressistes qui doivent aligner la livraison agile avec la stabilité opérationnelle choisissent de mature développe les pratiques et la culture . Des pratiques telles que l'automatisation des tests CI / CD et de surveillance centralisée garantissent le déploiement fiable des applications et la résolution rapide des incidents. Cette approche unifie mieux l’informatique dans un ensemble moderne de principes reposant sur des pratiques agiles, la fiabilité du site et l’automatisation plutôt que sur l’informatique bimodale qui divise l’informatique en deux modèles opérationnels.
2. Lift and shift contesté par les architectures et l’économie du nuage
Migration vers le nuage sans repenser les architectures d’applications et régler le problème de la dette technique peut sembler attrayante pour les DSI qui doivent atteindre rapidement l’agilité de l’infrastructure du nuage et réaliser des économies de coûts potentielles. De nombreux DSI pris en charge par les fournisseurs de cloud et les intégrateurs de systèmes tentent d'adopter des stratégies de levage et de déplacement avec la conviction que les charges de travail existantes peuvent être migrées rapidement vers le cloud, puis restructurées sur une période plus longue.
Mais cette stratégie est mûr avec des obstacles et des risques en fonction de la topologie du réseau, de la sécurité et de la dette technique inhérentes aux applications héritées et aux fournisseurs de cloud public comme AWS suggèrent de reconsidérer cette approche . Les DSI peuvent également constater que les applications existantes exécutées sur des systèmes à grande échelle connectés à de grandes baies de stockage peuvent coûter plus cher et avoir des résultats plus médiocres en cas de migration vers des architectures cloud équivalentes.
Le cloud computing offre de réels avantages, mais beaucoup ne sont réalisables qu’après la réarchitecture des applications et de l’infrastructure et l’automatisation de la configuration du système. Les DSI doivent envisager plusieurs chemins pour devenir optimisés pour le cloud, car une stratégie de transfert et de transfert peut être coûteuse et prendre beaucoup plus de temps que prévu.
3. La planification en cascade remplacée par une planification agile et continue
Alors que de nombreuses organisations ont adopté le développement agile et ont peut-être étendu la pratique à plusieurs équipes, la planification stratégique à long terme reste souvent guidée par le CFO et alignée sur les cycles de reporting financier. Les budgets sont soumis chaque année et la plupart des DSI doivent rendre compte des progrès réalisés et des résultats attendus tous les trimestres et parfois plus fréquemment.
C’est l’un des principaux écarts entre l’informatique numérique qui transforme l’activité et les priorités qui sont ajustées de manière itérative en fonction du retour des clients et du marché. Ce fossé entre héritage et pensée agile peut créer un dysfonctionnement organisationnel important lorsque les responsables informatiques tentent de redéfinir les arriérés agiles avec les cycles et les exigences en matière de rapports financiers.
L'alignement est possible et doit être réduit à . transformation agile large où la planification est une pratique continue et continue. La planification agile est un processus que je détaille dans mon livre Driving Digital qui oblige les équipes agiles à planifier les fonctionnalités et à écrire des histoires à chaque sprint en parallèle de leur travail, complétant des histoires et réalisant des publications épanouissantes. Lorsque les DSI acquièrent des pratiques de planification et établissent des outils de reporting, ils parviennent à une prévision plus fiable, capable de communiquer plus facilement l'état requis par les cycles de reporting financier.
4. La construction par opposition à l'achat est remplacée par des architectures à code faible
De nombreuses organisations continuent de débattre du «construction par rapport à l'achat» lorsqu'elles investissent dans de nouvelles applications métier. Le paradigme a quelque peu évolué, de nombreuses entreprises envisageant également les options SaaS même si nombre de ces plates-formes sont hautement configurables. De même, la création d'applications présente des nuances de gris, car la plupart des logiciels propriétaires sont développés à l'aide d'une combinaison de cadres et de bibliothèques open source et commerciaux.
Il existe néanmoins un motif intermédiaire souvent négligé, à savoir code bas, pas de code. et des plates-formes de développement citoyen qui permettent aux entreprises de développer des applications métier exclusives, des intégrations de données, des tableaux de bord analytiques et des expériences mobiles sans avoir à assumer les complexités du développement logiciel de niveau inférieur. Ces plates-formes permettent non seulement une livraison rapide des applications, mais elles génèrent souvent des applications plus faciles à gérer et à ouvrir pouvant être créées et étendues avec des développeurs moins qualifiés ou des utilisateurs professionnels dotés de compétences en technologie.
5. Le mobile d'abord primé sur les API et les microservices
Lorsque l'usage du mobile est devenu courant, les magasins d'applications ont fourni des mécanismes pour distribuer des applications mobiles aux utilisateurs finaux, et les plates-formes de gestion des périphériques mobiles permettent aux services informatiques de sécuriser les périphériques mobiles. De nombreux développeurs et concepteurs ont déclaré développer applications pour mobile d'abord et Web seconde . Cela a poussé les développeurs de logiciels à optimiser l'expérience utilisateur des applications pour des écrans plus petits, des périphériques à bande passante réduite et une navigation simplifiée, car l'utilisation des applications mobiles surpassait les expériences Web sur le Web .
C'était en 2014 et aujourd'hui, les organisations doit optimiser les applications pour plusieurs dispositifs et expériences et peut le faire en utilisant une multitude d'approches et de plateformes de développement. Mais l'hypothèse sous-jacente est que les développeurs ont déjà construit des API et idéalement des microservices. Les API permettent non seulement le développement d'applications spécifiques à un périphérique, à un workflow ou à un utilisateur, mais également une intégration d'applications et de données. Les développeurs et les concepteurs privilégiant le mobile d’abord sans API d’architecture peuvent confiner leurs organisations dans un nouvel héritage d’applications monolithiques.
Lire les feuilles de thé et savoir quand faire pivoter les pratiques informatiques
L’une des choses les plus difficiles à déterminer pour les responsables informatiques est savoir quels paradigmes sont essentiels, pour combien de temps, et que faire des investissements développés sur des constructions héritées. Si votre organisation a développé une application mobile réussie sur une architecture monolithique, à quel moment sa refactorisation pour fournir des API fournit-elle une valeur commerciale? Le DSI devrait-il chercher à passer de pratiques obsolètes telles que la gestion de projet en cascade et l'informatique bimodale à des méthodes agiles et à la culture développée? Quand faut-il considérer les plates-formes basses au lieu d'adopter des pratiques de développement logiciel normalisées?
La technologie évolue rapidement et des industries entières sont perturbées. La réponse simple est que le statu quo n’est plus une option pour la plupart des entreprises.
Cet article est publié dans le cadre du réseau des contributeurs IDG. Vous souhaitez vous inscrire?