ソフトウェアサプライチェーンのモデルの構築

ソフトウェア開発バリューストリームの標準的な描写は、コーディングで始まり、本番環境のコードで終わります。「ビジネス」で始まり「顧客」で終わるDevOps図をよく目にします。ただし、この描写は、企業規模でのソフトウェア配信の複雑さを正確に反映していません。

一歩後退すると、顧客へのソフトウェアの提供に関連するアクティビティがさらに多く見られますが、これらのアクティビティを管理するための現在のアプローチは、本番モデルではなくサービス提供フレームワークに根ざしています。そのため、単一のエンドツーエンドシステムとして関係するすべてのアクティビティを接続するわけではありません。

他の製品業界で使用されているモデルはサプライチェーンモデルであり、そのモデルをソフトウェア配信に適用することで、DevOpsを超えてソフトウェア配信「システム」の理解を深め、最適化の方法に関する新しい洞察を得ることができます。

サプライチェーンとは何ですか?

サプライチェーンは、すべての生産活動と非生産活動を単一のシステムとして調整できるという考えから始まります。サプライチェーン管理は、実際にはサプライチェーン管理の1つの側面にすぎない場合(重要な側面ではありますが)、単に「サプライヤー管理」であると誤解されることがよくあります。

すべての製品およびサービス事業にはサプライチェーンがあり、関連する活動とサプライチェーンシステムに対するそれらの相対的な重要性は異なります。ただし、これらのアクティビティを単一のシステムとして調整することにより、パーツの合計よりも大きな価値が得られ、その価値を利害関係者に効率的に提供できるというのが基本的な考え方です。

次のアクティビティは、すべてのサプライチェーンの重要な側面のほんの一部ですが、ソフトウェアの場合、それらは一意に実行されます。

計画

従来のサプライチェーンでは、計画活動には、資産の調整とプロセスのフローの最適化が含まれ、材料の供給と製品の需要のバランスを取ります。ソフトウェアサプライチェーンでは、その調整には、最も必要とされる製品機能のために適切なコードが開発されていることを確認することが含まれます。大規模な場合、数百のアプリケーションと数千のソフトウェア開発者がいるため、これは記念碑的な取り組みです。

計画活動の範囲は、多くの場合、既存のdevopsモデルによって最小限に抑えられます。したがって、DevOpsを最も必要とする大企業が、計画を長く複雑にする法的、規制、契約、および顧客の義務に対処しなければならないのは、いくぶん皮肉なことです。計画へのサプライチェーンアプローチには、関連する多くの異なる計画の役割と分野の間のインターフェースを最適化することが含まれ、重要な成功要因はそれらを効果的に統合できることです。

一方では、企業の開発を導くアジャイル手法は、多くの場合、ウォーターフォールプロセス内で実行されます。財政計画サイクルから逃れることができる企業はほとんどなく、アジャイルプロセスにはそれらのサイクルと矛盾する抽象化が含まれている可能性があります。たとえば、スプリントが会計四半期の境界に合わない場合があります。アジャイルを使用する開発プロセスとウォーターフォールを使用する非生産活動の間のコミュニケーションと接続の欠如は、ビジネス全体の無駄と非効率につながる可能性があります。

一方、エンタープライズ製品の計画には、常に広範な要件管理とトレーサビリティシステムが含まれており、これはソフトウェア製品でも同じです。要件管理は、ユーザーの生死を意味する可能性のある医療機器用のソフトウェアが開発される可能性があるヘルスケアなど、規制の厳しい業界では特に重要です。要件管理には特殊なツールと方法論が含まれ、開発ライフサイクル全体で実装の忠実度と品質を追跡する機能は、エンタープライズソフトウェア製品にとって重要な場合があります。   

ソーシング

従来のサプライチェーンでは、コンポーネントの調達には、サプライヤーとの関係の管理と部品および材料の調達戦略の開発が含まれます。ソフトウェアもソースコンポーネントに大きく依存しています。Sonatypeによる最近の調査によると、現在、オープンソースがソフトウェア製品の大部分を占めています。最新のアプリケーションのコードの80〜90%はオープンソースコンポーネントからのものです。そして、これらのコンポーネントは、独自の管理上の課題を生み出します。

まず、コンポーネントの品質を決定する方法を決定するのは難しい場合があり、消費可能性、テスト、ドキュメント、コミュニティ、サポート、テクノロジーのトレンドなどの決定に影響を与える多くの要因があります。コンポーネントを選択するための明確な戦略とアプローチを持つことが不可欠です。

第二に、オープンソースコンポーネントの数が急増しているため、それらすべてを効果的に管理するためにそれらすべてが何を許可されているかを知ることさえも課題です。製品マネージャーとエンジニアは、ライセンスの懸念とセキュリティの問題に細心の注意を払う必要があります。オープンソースコンポーネントの状態は、新しい脆弱性が発見され、メンテナが知的財産戦略を変更するにつれて、毎日変化する可能性があります。また、顧客は自分が受け取っているものを正確に知りたいと考えています。多くの大企業は、箱に入っているものを説明する商品の請求書がないとソフトウェアを購入しません。これらすべてのオープンソースの問題を管理することは、ソフトウェア製品開発の中核的な側面です。

分布

ソフトウェアを顧客の手に渡すには、展開、配布、統合、再販業者など、あらゆる種類のパートナーの複雑なWebが必要になる場合があります。あらゆる種類の契約:OEM、ライセンス、NDA、RFP。あらゆる種類の会議:デモ、PoC、プレゼンテーション。などなど。

これらの関係は、ソフトウェア配信プロセスの入力、出力、さらにはステップとして機能します。これらの関係のいずれかの状態は、開発活動に直接影響を与える可能性があります。それらを綿密に管理し、実行中の作業に接続しないと、非常に具体的な無駄が発生します。

静かに機会を失った見込み客に叙事詩を提供したり、1か月前に契約をキャンセルしたパートナーに機能を展開したりすることを想像してみてください。これは、ソフトウェアがビジネスのバリューストリームから独立して配信される場合、つまりソフトウェア配信機能がサプライチェーンにリンクされていない場合に定期的に発生します。

DevOpsパイプラインは、作業が実行されているパートナーシップ、合意、および目標と密接に関連している必要があります。コードは追跡可能であり、ストーリーから要件、CRMの顧客レコードに至るまで、すべてソフトウェア配信をサプライチェーンのように扱い、統合戦略を実行することでリンクできます。

代わりに、特定の契約に対して実行されているすべての進行中のアクティビティ、または新しい顧客向けに計画されているすべての機能(これは、ソフトウェアサプライチェーン管理の結果です)を、ライフサイクル全体にわたる可視性とトレーサビリティで明らかにできることを想像してみてください。

ツール

従来の製造ツールはダイカッティングマシンと熱処理オーブンで構成されている場合がありますが、ソフトウェアサプライチェーンには、ソフトウェア配信のさまざまな段階を管理するために使用されるツールのクラス(ALMツール、ライフサイクルツール、またはdevopsツールと呼ばれる)が含まれます。 。

これらのツールを管理するための戦略は、ソフトウェア開発ツールへの技術的および知的投資が莫大で非常に影響力があるため、従来のアプローチとは大きく異なります。このタイプのツールも急速に進化し、高度に断片化されています。今日のジェンキンスは、昨年のハドソンになります。組織は、適応する柔軟性を維持しながら、チームに必要なものを提供する、弾力性がありながらモジュール式のツールスタックを持つように配置する必要があります。

さらに、ツールチェーンを切断することはできません。必要な場所の知識を得るために、バリューチェーン全体で情報をアップストリームとダウンストリームに戻す必要があります。統合の観点からもこの領域を検討することが重要です。特定のレイヤーでのアクティビティを、周囲のサポートするサプライチェーン管理アクティビティにどのように接続できますか?

結論

ビジネスは歴史的にテクノロジー管理を収益を生み出すビジネスラインから分離し、サービスの提供に沿った価値と目的によって推進される一連のサポート活動として扱ってきました。しかし、ソフトウェアで定義された世界では、そのビジネスモデルはもはや適合しません。

ソフトウェア配信機能は、従来定義されていたサポートスペースから移動し、すべての主要な収益を生み出す活動を定義するようになりました。

したがって、モデルを本番システムとして再考し、バリューストリームアクティビティ全体の複雑さの関係をキャプチャするモデルに移行する必要があります。サプライチェーンはその考え方を体現しており、ソフトウェア製品の生産が進化するにつれて、このモデルは確実に成熟するでしょう。