デジタル変革による最大の影響の 1 つは、アプリケーション開発への混乱です。 歴史的に、アプリ開発への新しいアーキテクチャの導入は、それが本格的に始まり主流として採用されるまでに数年かかるのが一般的です。 業界全体を席巻する傾向のあるアプリケーション アーキテクチャは、最終的には事実上の標準になります。 1990 年代半ばから後半にかけて、J2EE がゆっくりと、しかし確実に 3 層 Web アプリケーション開発の「エンタープライズ標準」になったときに、そのことが起こりました。
現在、「定着」して新しい標準となる運命にあるアーキテクチャは、クラウド ネイティブです。 これらのコンテナベースのマイクロサービス アーキテクチャは、あらゆる業界の新しい開発プロジェクトで急速に主流になりつつあります。 多数のアプリケーションがデプロイされ運用されている Kubernetes の成功は、この最新のアプリ アーキテクチャが今後も定着することを示しています。 当社の調査によると、少なくとも半数の組織がデジタル変革のために「新しいアーキテクチャ」を模索しています。
現在、これは組織が「近代化」の道を歩んでいることを意味すると解釈されることが多いです。 そして私たち(業界)は、近代化について非常に一般的な(そして漠然とした)言葉で語る傾向があります。 あたかも組織が魔法の杖を振るだけで、すべてのアプリケーションがこの新しいモデルに基づいて構築されるようになります。
現実には、組織がアプリケーションを最新化する方法はたくさんあります。 リファクタリングのアプローチを追求しているのは一部(37%)のみです。 リファクタリングの方法は数多くありますが、最も人気のあるアプローチの 1 つが Red Green Refactor です。 ただし、準備的なリファクタリングや、選択できる抽象化ベースのオプションなど、他の方法もあります。 ほとんどはコードの簡素化に基づいています。 言い換えれば、アプリケーションの書き換えを、より中断の少ない方法で行うことに大きく依存しています。
しかし、完全な書き直しが近代化のための最善の戦略となる場合もあります。 一般的に、既存のレガシー アプリケーションを完全に書き直す作業は、最も熱心なデジタル変革推進者でさえも躊躇させるほどの大きな作業になる可能性があります。 しかし、場合によっては大幅な節約につながることもあります。
連邦政府機関がアプリケーション ポートフォリオを最新化するために採用したアプローチについて考えてみましょう。 アジャイル手法への移行を義務付けられて運営されているこの機関では、従来のウォーターフォール方式でアプリケーションを開発するための特別な許可が必要でした。 さて、私がコーディングしていた頃はウォーターフォールが主流の方法論だったので、確かに古いものです。 同庁は、まず自らのポートフォリオを理解し、各アプリケーションの必要性を合理化することが最善の出発点であると判断しました。
その監査中に、約 6,000 個のアプリケーションのうち、同じ基本的な資産管理タスクを実行するアプリケーションが 200 個近く見つかりました。 基本的なビジネス機能に変更が必要になり、200 個のアプリケーションすべてを変更する必要があると想像してください。
同じビジネス機能を開発、テスト、展開するには、開発者とオペレーターに多大な時間と労力がかかります。
同局は、資産を追跡するために局全体で使用できる単一のマイクロサービスに 200 個のアプリケーションすべてを置き換えることで近代化することを決定しました。 アジャイル手法を使用して開発され、最新の環境で運用されているため、独自の個人的なプライベート アプリケーションに依存していたすべての機能のニーズに対応できるように拡張できます。
すべての近代化の取り組みがリファクタリングに重点を置いているわけではありません。 アプリケーション ポートフォリオ全体にとっての近代化の意味を戦略的に検討することで、大きなビジネス上の利点が得られます。 多くの組織、特に何十年も運営されている組織では、同じポートフォリオの問題、つまり重複に悩まされる可能性があります。 組織再編、買収、合併、経営陣の変更により、アプリケーションの重複が簡単に発生する可能性があります。
近代化戦略の一環としてアプリケーションの監査と合理化を実施することは、あらゆる組織にとってメリットになります。 何百ものアプリケーションがあるが、そのうちのいくつかだけが必要な場合もあります。 この種の戦略により、リーダーは新しいアーキテクチャで開発されたまったく新しいアプリケーションを正当化し、アプリの冗長性とそのような状況で発生するコストを排除できます。