「一枚岩」から「レイヤとコンポーネント」に切り分ける
このような環境の変化に対応するために、企業のコラボレーション基盤はどうあるべきなのだろうか。
吉田氏が挙げるキーワードのひとつは、「インタオペラビリティ（相互運用性）の向上」だ。Notesを含めた他のソリューションも併存する異種混在の環境を是とし、維持するためにはどうすればいいのかというのが、今後の情報系のシステムアーキテクチャを考える上で重要な課題となっているという。
その実現には、コラボレーション基盤を一枚岩で考えるのではなく、「表示」（ポータル、検索）、「機能」（メール／グループウェア、アプリケーション）、「基盤」（ディレクトリ）の各レイヤを分離しておくとともに、機能レイヤも「メール・グループウェア部」、「情報共有部」、「アプリケーション部」の3つのコンポーネントとして、切り分けて考えることが有効だという（図2）。特定ベンダーの戦略に囲い込まれず、ビジネスや技術の環境変化に柔軟に対応していくためには極めて重要な視点だ。
図2：企業のコラボレーション基盤を3レイヤに分割し、機能レイヤを3コンポーネントに切り分けて考える（出典：リアルコム、画像をクリックすると拡大表示します）また吉田氏は、現在、Notesの管理コストが上昇しているのも、機能レイヤが一枚岩なためにサービスレベルの差別化が図られていないことに一因があると分析する。「メール・グループウェア部／情報共有部と、アプリケーション部を切り離すことで、厳重に管理すべきところとそうでない部分とを分けて考えることができ、コスト配分の最適化を図ることが、相互運用性では重要なポイントとなる」（吉田氏）
アプリケーションの開発戦略をどう位置づけるか
相互運用性を高めるにあたって、旧来のNotesユーザーは一度現状をクリアにし、コンポーネントの切り分けや、ガバナンスを効かせるための標準化を考える必要があるという。
例えば、最も移行が困難と思われる、複雑なロジックが含まれる巨大なDBを抱えたアプリケーションは残し、メール・グループウェア部、情報共有部は別のツールに切り替えるといった判断や、R4.x、R5.xなどからバージョンアップする場合、将来同様な問題が発生しないよう、機能の切り分けが可能な8.x以降のバージョンを選択する方法などがある。
また、ID認証やACLグループ設定などを行う基盤レイヤについては、Notes以外のソリューションにも適用できるよう統一化する必要がある。
ただ、その際に問題となるのはNotesの最大のメリットである「EUC」をどう位置づけるかだ。Notesの開発生産性の高さが、現在においても他に類を見ない優れたものであることについては、多くのベンダー、ユーザーが認めるところ。その点では、Javaや.NETも及ばないというのが共通した意見だ。
吉田氏も、「アプリケーション部については、Notesが良いのか、.NET Frameworkが良いのか、Javaが良いのか、一概に言えない。これは、企業の開発戦略に大きく関わる問題であり、その戦略に応じて選択されるべきだ」と述べる。
