モジュール性は，優れたプロセスのどれにおいても重要な要素だ。ほとんどの企業は，自らのアプリケーション構造を考慮せず，ただアジャイルプロセスに従っている。このようなアジャイルへの取り組みでは，期待した十分なビジネスメリットを享受することは適わない。基盤とするエンティティ，すなわち組織やソフトウェア製品がモジュール化構造を持って初めて，アジャイルを実現することができるのだ。
Paremusの創業者でCEOのRichard Nicholson氏は，Javaのモジュール化に関するオープンな業界標準のOSGiを取り上げた技術白書の中で，モジュール化構造とアジャイルの関連について，次のように説明している。
エンティティが“アジャイル”であるためには，高度なモジュール構造を備えていなければなりません。ですから，“アジャイルビジネスシステムを構築するにはどうすればよいのですか？”という質問は，“高度にモジュール化されたビジネスシステムを構築するにはどうすればよいのですか？”というように書き換える必要があります。
ビジネスユニットとサービスプロバイダの数が増加すれば，構成要素の数や，それら要素間の内部依存性も増加する。これをチェックせずに放置すれば，通常は構成要素の数よりも内部依存性の方がはるかに早く増加するので，構造はますます複雑になる。
従ってアジャイルシステムでは，次のような特徴を顕示する必要がある。
- 階層構造: 下位レイヤの提供するコンポーネントで構成された階層内の各レイヤ。
- 抽象化: 各レイヤに含まれるコンポーネントの動作を，そのレイヤに対して定義された要件と機能として公開する。
- 分離: 強力なアイソレーションにより，レイヤ内のコンポーネントの内部構造が各レイヤ内に隠ぺいされていることを保証する。
- 自己記述: 各レイヤ内のコンポーネント間の関係が自己記述的であること。例えば，公開された要件と機能として依存関係が記述されている。
- 変更の影響: セマンティックなバージョン管理によって，依存関係における変更の影響が説明可能であること。
Gartnerのリサーチディレクタを務めるKirk Knoernschild氏は，自身の著書“Java Application Architecture”の中で，アジャイルとモジュール構造性の関連性を検討した結果として，“中間層の欠如”という問題を指摘した。結論としては，従来のJavaアプリケーションのアーキテクチャには重要な構造的レイヤが欠如している，というものだ。モジュール性の観点から見れば，最も粒度の粗い位置に存在するのが従来型サービスであり，最も粒度の細かい位置にあるものがJavaパッケージとクラスである。しかしながら，その中間にあたるものが存在しない。
OSGiでは，Javaで必要とされているモジュール構造フレームワークを，OSGi Allianceのオープンな業界標準に基づいて提供することによって，この問題に直接的に対処しようとしている。
- OSGiバンドルは，Javaパッケージの要件と機能を単位とする依存性を表現する。これにより，あるOSGiバンドルが別の代替品で置き換え可能かどうか，第三者が簡単に確認できる。
- OSGiバンドルでは，セマンティックバージョニングを採用する。これにより，OSGiバンドルの変更が利用者に対して潜在的に破壊性を持つかどうか，第三者が簡単に確認できる。
このもうひとつ上の構造階層として，OSGiではµServiceも提供している。µServiceは，実行時の動的検索と相互結合が可能な軽量サービスである。このOSGiのサービスは，同一JVM内に配置することも，あるいはOSGiのリモートサービス仕様の実装を通じて，IPネットワークで分離されたJVM間に分散して配置することも可能だ。
Richardは，OSGiバンドルをスクラムとかんばんに対応させて，次のように説明している。
大規模でモノシリックなコードベースにスクラムを適用するのは困難ですが，対照的に，高度にモジュール化され，多くの自己記述から構成された，分離強度の高いOSGiバンドルは，スクラムの概念にうまくマッチします。
かんばんの概念は，高度にモジュール化され，多くの自己記述から構成された，分離強度の高いコードベースに自然にマッピングされます。具体的に言うと，かんばんのWIPプロセスの考え方は，積極的に働きかけるOSGiバンドルのサブセットにぴったり一致するのです。従って，かんばんのプルを基本とした流量は，OSGiバンドルの変更/リリースの粒度をより詳細にするためにマッピングすることができます。かんばんのプルベースの流量が自然に増加するように，OSGiバンドルがWIP状態への滞留時間も相対的に短くなります。