アイデンティティ管理ビッグバン
この記事は https://docs.evolveum.com/iam/myths/idm-big-bang/ の翻訳です。
要件を集め、分析し、アーキテクチャを作り、詳細を設計 し、実装し、test し、導入する。 これらすべてを1つの elegant で効率的で一貫したプロジェクトとして実行する。 これが正しいプロジェクトの進め方です。 これがアイデンティティ管理ソリューションを導入する方法です。 これこそが唯一専門家な方法です。
実際には、そうではありません。 それは失敗の処方箋です。しかも非常に高価な失敗です。
繰り返される歴史
この 分析・設計・実装 方法は、実は Waterfall モデル と呼ばれる、よく知られたソフトウェア 開発手法です。 1970年代という早い時期に最初に文書化されたにもかかわらず、現在でも使われています。 それは elegant で、簡単で、理解しやすいものです。 問題は、この方法が根本的に flawed であることです。 単に機能しません。 プロジェクトの初期フェーズ におけるどんな小さな問題も後続フェーズ で増幅され、この 方法論 にはそれに対処する 修正 機構がありません。 この手法は20世紀のソフトウェアプロジェクトにおける膨大な数の failure の原因でした。 Software エンジニアはこれをよく知っており、合理的なソフトウェア エンジニア なら、もはや waterfall 手法を自発的に使うことはありません。 それはずっと以前に 反復的かつ漸進的な開発手法 に置き換えられました。
Waterfall 手法は flawed であり、ソフトウェア エンジニアはそれを捨てました。 しかし industry の他の分野ではまだそれが使われています。 ベストプラクティスとして推奨されることさえあります。 これは単純に正気ではありません。
アイデンティティ管理ウォーターフォール
この方法の何が正確に問題なのでしょうか。 一見するとアイデンティティ管理プロジェクトによく合っているように見えます。 手順ごとで見てみましょう。
要件: 自分が何を必要としているのかを正確に知っている人に会ったことがありますか。 自分が何を 欲しい かではなく、本当に何を 必要 としているかです。 アイデンティティ管理は要件が特に曖昧な分野の1つです。 既存プロセスは通常、人間の judgement に基づいています。「申請が 良さそう なら承認する」「適切な 識別子を入力する」といったものです。 そのようなプロセスは formalize が非常に困難です。 顧客はまた、必要でない機能、たとえばプロセス "X" の100% 自動化を欲しがり、本当に必要な 側面、可視性、信頼性、整合性などを軽視しがちです。
分析: アイデンティティ管理ソリューションが導入される前は、データとプロセスは通常手作業で処理されています。 人間は objective judgement が非常に苦手で、特にデータ品質に関してはそうです。 人間はデータ集合の誤りを簡単に見落とし、手作業でデータを処理するときには無意識に修正してしまいます。 しかし machine はそれができません。 データ集合のどんな誤りもプロジェクトに大きな 遅延 を引き起こす可能性があります。 さらに悪いことに、異なるシステムのデータが machine によって分析され、適切に相関付けd されるまでは、すべての誤りを見ることはほぼ不可能です。 さらに、分析のために提供される 入力データには通常、大きな欠落 があります。 たとえばシステム管理者は各アカウント属性の正確な意味を知らないことが多く、忙しすぎる、または回答する気がないため、まったく返答しないこともあります。 結論として、分析フェーズ はプロジェクトの多くの 重大な障害を見落とす可能性が高いです。
Design: 私たち エンジニアは、自分の知的能力を過大評価しがちです。 悲しい事実として、複雑システムを最初の試みで 完璧に設計 できる人は、おそらく世界に1人もいません。 誰もが誤りを犯します。 さらに悪いことに、この流れは最初から仕組まれています。 古いことわざに garbage in, garbage out があります。 設計は要件と分析に基づきます。 分析にすでに大きな ギャップと不正確さが含まれているため、設計が正しくなる可能性はほぼゼロです。
実装: システムは 設計どおりに実装されます。 Design が正しかった可能性は極めて低いため、実装は flawed になる運命です。 さらに悪いのは、分析と design の小さな誤りが実装中に大きく増幅されることです。 Design 仕様化の1 paragraph にある単純な誤りが、簡単に何千行もの無駄なコードを意味することがあります。 膨大なお金が無駄になります。 しかし、まだ誰もそれに気づきません。 開発環境ではすべてが問題なく動作します。
Testing: Waterfall モデルでの テスト には、悪い方法と、もっと悪い方法の2つがあります。 悪い テスト は、実装済みシステムが 必要とments を満たすかどうかを verify することです。 しかし要件はしばしば非常に曖昧で、簡単には formalize できないため、この テスト はソリューション品質についてほとんど何も教えてくれません。 要件を テスト シナリオに変換するのは常に非常に難しいため、別の方法が使われます。 ここでさらに悪くなります。テスト シナリオは design に基づきます。 したがって、システムが 設計どおりに実装されたかどうかが verify されます。 これはシステム品質についてほとんど何も示しません。 設計は間違っていました。私たちはそれを知っています。そしてシステムは 設計どおりに実装されました。 すべての テスト が pass したとしても、それは実装が design と同じくらい良いことを示すだけです。つまり、すべて間違っています。
導入: この 段階 では誰もが成功、applause、大きな party を期待します。 しかし実際には、developed システムが現実と出会う初めての瞬間です。 これは気持ちのよい出会いではありません。 すべての小さな誤りは大きく増幅され、結果は単に機能しません。 ここで全員が panic します。 システム acceptance の minimum 要件をどうにか満たすために問題は急いで修正されます。 Deadline は missed し、予算は blown し、マネージャーは混乱します。
これらすべてには通常少なくとも1年、場合によっては2〜3年かかります。 多くの文書、図、プロジェクト計画、会議議事録、その他の非常に高価だがほとんど意味のないな文書が生成されます。 しかし最終結果は、ほぼ例外なく、非常に高価で劣ったアイデンティティ管理ソリューションです。そもそも動けば、ですが。
解決策
ソリューションは、ソフトウェア エンジニアing で機能したものと同じです。反復的かつ漸進的な開発手法 です。 アイデンティティ管理ソリューションを1つの巨大プロジェクトで導入しようとしてはいけません。 労力をいくつかの イテレーション に分割します。 各 イテレーション は数か月を超えるべきではありません。 各 イテレーション には、すべての活動、つまり少しの要件分析、少しの design、実装、テスト、導入を含めるべきです。 最初のイテレーションは自然に "文書" に焦点が寄る傾向がありますが、プロトタイピングとテストも含めるべきです。 最後の イテレーション は テスト と導入により 重点を置きますが、必要に応じて design の一部を再考できる 人員 も利用可能であるべきです。 各 イテレーション が tangible なものをもって終わり、理論、つまり文書を実装、つまりコードと現実、つまり導入に向き合わせることが重要です。 これが、誤りを早期に特定し、後続フェーズ で増幅しないための方法です。
アイデンティティ管理導入はプロジェクトではなく、プログラム です。 Start はありますが、end はありません。 それは ongoing、iterative、incremental な活動です。 本当に "done" になることはありません。 アイデンティティ管理は購入でき、"done" にできると装っても、何の良いこともありません。 現実を認め、それに適応する方がはるかに良いです。 アイデンティティ管理、特にアイデンティティガバナンスは、常に evolving するものです。 それは業務の標準の部分として組み込まれなければなりません。
反復的かつ漸進的な手法を core 原則として採用した 方法論 があります。 Evolveum が開発した "First 手順" 方法論 は、midPoint プラットフォーム を incremental かつ 反復的に導入するための推奨です。 この方法は比較的新しいものですが、すでに何度も有効性を証明しています。 MidPoint のために設計されたものですが、合理的なアイデンティティ管理プラットフォームであれば適用できます。
費用と効果
各 イテレーション における追加の development、テスト、導入活動は高価に見えるかもしれません。 しかしそれは相対的です。 ウォーターフォールベースの方法で単に無駄になる作業よりは、はるかに安価です。 この方法が ウォーターフォール導入フェーズ によって引き起こされる 混乱と深刻な損害 を避けるという事実だけでも、まさに priceless です。
Iterative と incremental 手法は waterfall-based 手法よりはるかに優れています。 それについて疑いはありません。 しかし業務関連のな欠点が1つあります。Commercial アイデンティティ管理システムは高価です。 費用はプロジェクトの 初期 に集中します。ライセンス、サポート、SaaS サブスクリプション などです。 この費用はかなり高いです。 したがってアイデンティティ管理プロジェクトは、この費用を正当化する substantial 効果をもたらす必要があります。 そうでなければ return on 投資 (ROI) calculation はうまくいかず、プロジェクトは承認されません。 短いプロジェクトで巨大な効果をもたらすのは現実的ではありません。 したがって commercial アイデンティティ管理製品を含む導入プロジェクトは、巨大で長いものになる必要があり、通常かなりリスクの高いです。
オープンソースアイデンティティ管理製品では、これはまったく異なります。 オープンソース 製品には巨大な初期費用が ありません。 Licensing 費用はなく、サポート費用はプロジェクトの rollout に合わせて徐々に scale できます。 製品を試し始めるだけのために、高価なライセンスや SaaS サブスクリプション を購入する必要はありません。 そのためオープンソースソフトウェアは、適切なソリューションを段階的に開発するための、小さな iterative アイデンティティ管理プロジェクトの series を可能にします。 プロジェクトの費用はゆっくり段階的に増え、結果がもたらす効果に比例します。 Financial リスクと technological リスクの両方が大幅に低減されます。 これは顧客必要性に合い、変化する要件に適応でき、なおかつ経済的に現実的な、良い IGA プログラム の処方箋です。