10 choses à éviter pour les DSI avec les plates-formes à haute productivité

Les entreprises exigent des développeurs qu'ils livrent plus d'applications que jamais et pour cela, ils ont besoin d'outils et de plates-formes leur permettant de répondre à leurs attentes. Une plate-forme à haute productivité et à code réduit est une solution viable pour accélérer le développement tout en donnant aux développeurs le contrôle dont ils ont besoin pour faire de leur mieux. Mais avec tout le bruit sur le marché, par où commencer? Dans cet article, Mark Troester résout la situation avec une tactique unique – ce que ne doit pas faire .

Les plates-formes de développement d'applications à haute productivité / code bas gagnent en popularité, avec l'idéal [ étant une plate-forme cloud sans serveur qui intègre des infrastructures frontales open source avec un back-end à code réduit permettant des intégrations prêtes à l'emploi avec des systèmes d'entreprise et hérités. Lorsque vous envisagez une solution, voici dix points essentiels à éviter avec prudence:

1. Ne laissez pas les catégories industrielles restreindre votre choix technologique

Les choix technologiques se sont accélérés à un rythme vertigineux – trop rapide pour les catégories statiques. Certaines catégories sont définies de manière trop étroite, certaines se chevauchent, alors que la communauté des analystes n’est souvent pas d’accord sur les définitions et la portée. Toutes ces catégories de l’industrie peuvent constituer une bonne source de référence, mais l’important est de bien comprendre vos propres besoins technologiques et commerciaux. En outre, considérez tous vos besoins de manière holistique. Par exemple, ne considérez pas le Web et le mobile séparément, ni le nouveau développement par rapport à la modernisation séparément, ni les efforts de votre système de gestion de contenu isolés de votre développement. Si vous adoptez cette approche, alors la recherche de l’industrie peut être très utile.

2. Ne vous fiez pas aux outils propriétaires ou aux ressources de développement rares

Ce deuxième point peut sembler évident compte tenu de l’open source, des normes de l’industrie et des incidences financières de l’utilisation de développeurs de niche à prix élevé par rapport aux talents abordables et nombreux. Mais ce n'est pas parce qu'un fournisseur de plate-forme encourage l'utilisation de langages standard qu'il ne dispose pas d'un processus de développement exclusif.

Les développeurs ont besoin de transparence. Ne choisissez donc pas une solution masquant ou implémentant la mise en oeuvre. Difficile pour les développeurs d’interagir avec le code. Pensez également aux outils dont vous disposez aujourd'hui et à la manière dont le code faible s'intégrera à vos investissements existants – la dernière chose dont vous avez besoin est d'ajouter un silo perpendiculaire à vos pratiques actuelles.

Enfin, n'ayez pas une vision en tunnel. sur un seul aspect de l’environnement de développement – considérons l’ensemble du cycle de vie, l’ensemble de la chaîne d’outils, etc.

3. Ne contrariez pas vos développeurs

Les plates-formes à code bas évoluent pour accroître la productivité des développeurs, mais la confusion règne entre les plates-formes à code faible destinées aux développeurs professionnels rationalisant et simplifiant leur travail, et les plates-formes sans code destinées aux "citoyens". développeurs », ce qui leur permet de créer des applications fonctionnelles mais limitées sans avoir à écrire de code.

Comme l’a écrit un développeur à propos des plateformes sans code dans un sondage Progress, il est difficile de faire confiance aux boîtes noires. étaient la sécurité, le manque de flexibilité, la compatibilité avec les POC et les problèmes de personnalisation.

Plutôt que de forcer les développeurs à utiliser des systèmes propriétaires et rigides, capitalisez sur leurs compétences existantes. JavaScript peut être une solution puissante, car il reste la langue la mieux classée dans de nombreux sondages auprès des développeurs. De plus, JavaScript vous permet de tirer parti des mêmes compétences sur les deux fronts, ce qui vous donne plus d'options quant à l'utilisation de vos ressources.

Lorsqu'on leur a demandé quels outils ils utilisaient dans une enquête récente auprès des développeurs mobiles, 45% ont indiqué que Node.js et 65% ont noté une forme d'angulaire ou de vue. La beauté de ces frameworks réside dans le fait qu’ils sont communs et standard, ils rendent les développeurs très productifs, ils facilitent la réutilisation sur différents canaux numériques et sont tous construits sur JavaScript.

4. Ne confiez pas le développement à l'entreprise

Il existe un cas d'utilisation limité pour le «développeur de citoyens» sans code. Par exemple, supposons que vous soyez un grand magasin Lotus Notes ou en créant des applications avec PowerBuilder ou Microsoft Access, vous vouliez de nouvelles ressources métier pour remplacer des expériences obsolètes. Mais vous devez être honnête lorsque vous évaluez comment et à quelle fréquence votre organisation peut utiliser des développeurs citoyens: je n'ai encore rencontré aucun dirigeant d'entreprise qui souhaite réaffecter ses propres ressources rares à la création d'applications.

La ​​meilleure approche consiste à: rendez vos développeurs professionnels plus productifs et permettez aux utilisateurs métier de participer plus efficacement au processus de développement. Sollicitez leurs commentaires sur les exigences, les efforts rapides d’assistance, la communication et la collaboration efficaces. N'essayez pas de les transformer en développeurs d'applications sans code.

5. Ne vous contentez pas d’une expérience mobile hybride

La conception réactive est devenue la norme dans tous les nouveaux efforts Web, c’est donc l’un des moyens d’atteindre la mobilité. Mais parfois, une expérience Web réactive ne suffit pas et doit être complétée par une application mobile. Voyons les options:

• Développez des applications natives pour iOS et Android avec Swift, Objective C ou Java. C’est formidable pour les entreprises qui peuvent se permettre deux équipes de développement différentes, mais la plupart ne le peuvent pas.
• Adoptez une approche hybride en utilisant Cordova ou PhoneGap, un mécanisme basé sur un conteneur qui repose sur une WebView d’exécution pour interagir avec les API mobiles natives. Bien que cela simplifie les efforts de développement, il introduit des problèmes de performances et de convivialité qui se traduisent par de mauvaises notations des applications mobiles.

Les utilisateurs s'attendent à des expériences de style consommateur, ce qui exclut l'utilisation d'une approche hybride obsolète.

Une option à prendre en compte, qui exploite vos ressources JavaScript existantes sont des technologies JavaScript natives telles que NativeScript et React Native.

Les deux sont en open source, vous permettant de créer des applications véritablement natives qui interagissent directement avec les API iOS et Android. Vous avez toujours accès, aucune tierce partie n’attend de mettre à jour le conteneur WebView pour les nouvelles versions de système d’exploitation mobile, et vous bénéficiez d’une prise en charge «jour zéro» avec des performances et une apparence natives, le tout avec une base de code unique. Et si vous utilisez Angular, Vue ou TypeScript, vous obtenez une réutilisation du code pour vos efforts Web et mobiles.

6. Ne commencez pas avec une fondation technologique héritée

Lors de l’exploration de solutions fournies par des éditeurs de logiciels, la dernière chose à laquelle vous vous attendez est de lancer une nouvelle initiative sur une architecture héritée. Beaucoup d'entre vous ne considèrent peut-être pas la technologie des serveurs d'applications comme un investissement traditionnel, ce qui peut prêter à confusion parce que certaines de ces technologies traditionnelles ont été conteneurisées à l'aide de Docker et de Kubernetes.

Lors d'une récente conférence Gartner, Anne Thomas a expliqué comment elle gérait Nombre de demandes de clients de la part de clients qui souhaitent quitter WebSphere ou WebLogic afin d’obtenir de meilleures conditions de licence avec RedHat. Son conseil est le suivant: «Pourquoi échanger une architecture monolithique contre une autre? Envisagez de passer directement à des fonctions éphémères ou sans serveur, ainsi qu'à des microservices plus durables. 'Elle n'impliquait pas que vous refactorisiez à 100% dès le départ, mais qu'elle implémentait une architecture qui vous permette une transition dans le temps, par rapport à une approche monolithique "lift and shift".

Les monolithes ne sont pas uniquement des applications mainframe ou mainframe, ce qui est aussi moderne que les fichiers EAR et WAR monolithiques, ce qui vous permet de voir à quel point la conteneurisation de ces applications vous fournit valeur. Même si cela facilite le déploiement ou le passage d’un environnement à l’autre, vous ne pouvez toujours pas gérer les travaux de développement, de test et de production pour un monolith, sans la possibilité de développer, tester, déployer et mettre à l’échelle des composants individuellement. C’est une distinction cruciale si vous devez soutenir des objectifs d’agilité commerciale.

Enfin, pourquoi choisir une approche qui vous place immédiatement dans un cours de refactorisation uniquement pour supporter les mises à niveau forcées d’un fournisseur travaillant à la résorption de sa dette technique? Cela n’a aucun sens quand il existe des alternatives reposant sur des modèles plus modernes.

7. Ne négligez pas les services principaux et l'intégration

Bien que les outils frontaux soient extrêmement importants, ne sous-estimez pas les efforts nécessaires pour intégrer ces nouvelles expériences numériques à vos données, systèmes et autorisations d'entreprise.

Systèmes d'entreprise existants ne convient pas aux charges de travail mobiles ou multicanaux modernes. Ils pourraient être surchargés, ce qui pourrait mettre en péril vos systèmes principaux critiques ou simplement ne pas répondre aux exigences de temps de réponse ou être accessibles pour vos efforts de mobilité.

Vous pouvez résoudre ce problème avec une approche d’architecture qui vous permet mettre en cache intelligemment les données d'entreprise à l'aide d'un cache à plusieurs niveaux, à savoir des données gérées par des services backend modernes, ainsi que des données mises en cache sur le client, ce qui vous permet également de bénéficier d'une prise en charge hors ligne. C’est possible de le faire aujourd’hui en utilisant une approche basée sur la configuration à code faible.

8. N'oubliez pas de considérer le code faible comme une option de modernisation

Nous souhaitons tous tirer parti de nos investissements existants et consacrer le plus de temps possible au développement à la fourniture de nouvelles fonctionnalités, au lieu de consacrer du temps à la maintenance et à la refactorisation.

Pour augmenter la valeur de vos investissements actuels, vous devez fournir une assistance mobile hors ligne à vos systèmes existants.

Au-delà de l’intégration système, c’est la modernisation ciblée. Par exemple, vous pouvez avoir une application volumineuse qui est devenue difficile à manier avec le temps. Analysez-le pour identifier laquelle de ses fonctions est plus largement utilisée. Vous pouvez tirer parti de cette fonctionnalité pour la transformer en fonctionnalités pouvant être utilisées par de nouvelles charges de travail, avec une API moderne. Si vous élargissez vos exigences en matière d'intégration afin de réfléchir plus largement à la manière dont une plate-forme peut prendre en charge une approche progressive et progressive de la modernisation, cela vous mènera probablement à une approche sans serveur et basée sur microservices reposant sur des API standard.

9. Ne considérez pas les efforts d'IoT, d'intelligence artificielle et d'analyse comme des silos

L'agenda des responsables informatiques est également centré sur l'IdO, l'apprentissage automatique, l'IA et l'analyse. Il peut être plus simple de faire des choix technologiques de manière autonome, mais cela peut conduire à des silos. Bien que vous puissiez traiter les efforts des pilotes ou des laboratoires en vase clos, le fait de traiter ces technologies de manière indépendante peut avoir des effets dévastateurs sur votre organisation lorsque vous songez à la production ou à long terme. La première chose à considérer est que l'IA peut contribuer à de nombreuses initiatives numériques, que vous utilisiez des services d'apprentissage automatique disponibles dans le commerce pour la reconnaissance d'images, la synthèse vocale, l'analyse des sentiments ou pour améliorer votre taux de conversion marketing. offres dans le cadre de vos efforts de gestion de contenu, ou si vous utilisez des résultats prédictifs pour piloter un processus d’entreprise.

Le chat est un gros problème pour le moment, mais il existe un risque de contrecoup contre les expériences de chat si elles rappellent aux gens «l’enfer du système de répondeur». . ”Cela se produit lorsque les robots s'appuient sur les développeurs et les concepteurs pour identifier puis coder chaque flux de conversation possible à l'aide d'arbres de décision complexes. Ici, la combinaison de deux technologies donne d’excellents résultats: l’apprentissage en conversation et en machine. Au lieu de coder chaque chemin, utilisez l'apprentissage automatique pour former le bot. Cela élimine non seulement la nécessité de rédiger un code volumineux, mais permet également aux professionnels de l'entreprise de former le bot comme s'ils formaient une personne, libérant ainsi des ressources de développement.

Pensez également à la manière dont vos développeurs peuvent participer efficacement à l'analyse. efforts. Les développeurs ne sont pas des scientifiques de données, mais plus ils comprennent les bases, mieux ils peuvent tirer parti des résultats prédictifs.

Si vos développeurs connaissent un peu les techniques d'analyse, il deviendra naturel qu'ils intègrent des résultats prédictifs dans vos applications. Imaginez un scénario de service sur le terrain dans lequel une prévision concernant le temps d'indisponibilité ou l'optimisation est intégrée dans vos applications mobiles et qui déclenche l'action d'un technicien sur le terrain, intégrée à votre système de gestion de tickets, qui informe les ventes des conséquences potentielles pour un client clé.

dix. N'oubliez pas les considérations architecturales futures

Pour les considérations architecturales futures, supposons que nous voulions étendre notre scénario d'utilisation des services sur le terrain afin de gérer les éléments d'inventaire ou de chaîne logistique à l'aide d'un grand livre distribué, afin de garantir la compatibilité de toutes les actions et de tous les acteurs.

Imaginez que vous alliez au-delà de simples scénarios de RA pour que votre technicien interagisse par conversation ou par conversation afin de résoudre le problème ou pour être complètement immergé à l’aide de la technologie de RA qui guide l’action corrective. Les possibilités sont infinies si vous commencez avec la bonne architecture.

Et bien que ce ne soit peut-être pas aussi séduisant que le cas d'utilisation précédent, il est essentiel de réfléchir aux différents modèles d'architecture nécessaires au traitement des données IoT, par exemple. Par exemple, une architecture qui gère les événements à l'aide d'une approche native au cloud, par opposition aux fonctionnalités d'événement qui sont boulonnées à une architecture existante.

Les progrès réalisés dans le domaine des microapps sont à surveiller. Nous connaissons tous les problèmes associés à plusieurs applications, et nous associons généralement cela au comportement du consommateur: combien de jeux ou d'applications vos enfants ont-ils sur leur téléphone? Mais il est également extrêmement difficile pour les employés de travailler avec différentes applications mobiles dans leur environnement – applications de vente et de marketing, applications de ressources humaines, applications de reporting des dépenses, sans parler de différents clients de messagerie.

Imaginez un seul conteneur d'applications mobiles pour les employés, téléchargé et installé une fois. Ce conteneur d’application (à ne pas confondre avec une WebView hybride) est alimenté par des cartes d’application basées sur les responsabilités de l’employé. Celles-ci sont personnalisées et personnalisées selon un paradigme événementiel, dans lequel les agents autonomes peuvent agir en leur nom pour minimiser les perturbations et leur permettre de se concentrer sur la création de valeur et de différenciation que seul un humain peut offrir.

En savoir plus

Progress réinvente les plates-formes d'applications hautement productives / à code réduit pour aider les développeurs et les architectes à fournir l'innovation applicative nécessaire pour faire face à la concurrence dans un monde numérique. Pour en savoir plus sur la manière dont nous procédons.

N'hésitez pas à regarder un webinaire gratuit dans lequel je vais plonger plus profondément dans tout ce que j'ai mentionné ci-dessus. Je fournirai également des recommandations pratiques concernant les microservices et fonctions sans serveur, le développement en pile complète, NoOps, la modernisation, la prise en charge des conteneurs, le déploiement en cloud hybride, etc. Head ici pour regarder maintenant .