サポート期間は長いとうれしい
アーキテクチャを選定する立場としては、採用する技術の賞味期限、つまりはサポート期間は大変重要な要素になります。
当然のことながら、なるべくならサポート期間が長い方が好ましいケースが多いです。大規模なプロジェクトでソースをゴリゴリ書いている真っ最中でサポート期限が来てしまうと変更点の洗い出し、動作確認、ソースや設定の見直し、規約やガイドラインの更新＆開発メンバーへの周知、と本来はやらなくてよい（将来いずれ発生してしまうのだが）追加作業がてんこ盛りで発生してしまいます。
1年に2回更新が必要なシステムより、2年に1回更新すればよいシステムのほうが対応コストが安いと説明しやすいというメリット？もあります。
長いサポート期間は常に正義なのか
では、常に最長のサポート期間が見込めるバージョン・プロダクトを選定するべきなのでしょうか？
ここでコードの製造からリリースまでの期間が半年程度のプロジェクトを想定してみます。
サポート期間が半年のケース
遅くともリリースから3～5ヶ月程度でバージョンアップが発生すると想定されます。この時期であれば、初期のバグ対応や細かいエンハンスなどでリリースも活発と想定されるので、バージョンアップに対応できるリソース（人、対象プロダクトへの知識、テスト環境など）がまだ生きているので対応は容易いと思われます。
もちろん、ある程度バグの発生が落ち着いていることが前提条件ではありますがw
サポート期間が2年のケース
1～1.5年後にバージョンアップが発生することが想定されます。定期的なメンテナンスが行える体制が維持されていればよいのですが、構築メンバーの離散、プロジェクト資料の散逸（資料の陳腐化もよくある問題ですね）などが起きていることもしばしばあります。バージョンアップまでの期間が長いということは、対応しなければならない差分もまた多くなることを意味します。そのとき、アーキテクトが残ってくれていればよいのですが、一般的なシステムインテグレーションプロジェクトでは難しいでしょう。
そのため、バージョンアップが発生するまでの期間、アーキテクチャを理解してるメンバーを如何にして維持していくのか、あるいは維持しやすい枯れたシンプルなアーキテクチャを選択するなど、ヒト・モノ・カネの観点でプロジェクト開始当初（アーキテクチャを決める段階）に対策を検討しておく必要があります。
例えば一つの手段として、式年遷宮のようにメンバーや記憶が散逸する前に伝えていくために、比較的短いサポート期間を利用して定期的にアップデートのイベントを発生させるというのも現実的な手段として検討してもよいのではないかと思います。
上記の話は、システムインテグレーションプロジェクトを想定としていますが、自社サービス・プロダクトにおいても同じような課題は発生するでしょう。
サポート期間が長いからと油断は禁物
突如としてセキュリティホールが見つかり、対応に右往左往するのは稀によくあることなので、やっぱり体制の維持コストはプロジェクト初めにネゴっておきましょう。
まとめ
- サポート期間は技術選定における要素の一つ
- 基本的には長期のサポート期間をもつ製品、バージョンを選択する
- プロジェクト完了後の保守体制を考慮した選定が必要となる