Java EE勉強会

BSA / Like Installation, Only Worse

BSA

Like Installation, Only Worse †

 

11章でインストールはユーザに苦痛を与えることについて述べたが、

 

アップグレードはそれに追加して新たな苦痛を与える

 

アップグレードへの不安 †

 

筆者のキャリアで扱ったアップグレードの苦痛については下記になる。

 

再作業への苦痛 †

 
  • アップグレードは多くの場合下記を必要とする。
  • ユーザ、システム管理者、IT人事部に対してシステムや依存する実装の再作業を要求する。
  • 再作業はいろんな形式があるものの、通常核となるのはどうシステムが他のシステムをインテグレーションされているかにかかっている。
     
    例：諸官庁でのデータを扱うシステムを開発した時のこと
  • あまりよくないカスタマーマネージメントのひどいケースでは、 役所は利用者に配布するデータフォーマットの変更を時折、役所自身で行っていて、 破壊されたコードを直す作業を筆者達が再作業していた。
  • これが起こった時、筆者達は事業の継続のために、様々なソフトウェアを素早く、大慌てで書き直す必要があった。
  • 役所はこれらの変更が役所が設立する前からあることを知っていた。
  • 苦痛とコストは筆者の会社やそれらのデータに依存する他の会社にきた。
  • 最小化と危機の回避はできたが、役所は筆者達よりももっと単純に考えていた。
  • どんなに少なくとも、役所は筆者に変更に対する注意喚起をして欲しかった。
 

アップグレードへの波紋 †

 
  • アップグレードの波紋とは、開発者に対して安定したシステムのコンポネントの変更を強制する一つだ。
  • この影響はハードウェアの変更（さらなる課金、もっと早いプロセッサー、空きディスク容量など）やソフトウェアの変更（新しいOS、異なるバージョンのDLL)の範囲に及ぶ。
  • アップグレードの波紋は、ソフトウェアのアップグレードや新規機能が義務付けた変更時かキーとなるベンダーが開発者にインライセンステクノロジーのアップグレードを強制する場合に起こる。
  • アップグレードの波紋は現実的な技術的な苦痛部分となる。
  • もし開発者がインライセンステクノロジーを使うことになっている場合は、製品の将来のベースが一つまたは複数のインライセンステクノロジーによることになる。
  • 多くの状況ではアップグレードの波紋は他の選択肢がないだろう。
  • 開発者ができることはアップグレードのの苦痛をできるだけ少なくすることだろう
  • アップグレードに関連する依存性をしっかり定義することだ。
  • さらなる構成をサポートすることを減らすためにマトリックスペインを単純化することでアップグレードの波紋を使うことができる。
 

データ移行 †

 
  • あるバージョンのシステムで作成されたデータは次のバージョンでフルに使用されるためには、ある種の変更を必要とすることがよくある。
  • 新規機能は明示的に新たなスキーマを必要とするし、アップグレードプロセスはユーザに対して、簡単に古いスキーマから新しいスキーマへ移動ができるように設計されていないといけない。
  • データの移行は他方向であるかもしれないことを忘れていけない。
  • バージョンN+1のユーザがバージョンNのユーザが作成したデータを使ってデータを作成するかもしれない。
  • 異なる目的でのこの動作を行うツールは、アプリケーションや永続ストレージに基づいている。
  • PC向けにパッケージされたソフトウェアでは、データは基本的にファイルに保存される。
  • このケースではフォーマット間の変換をかける機能を提供する必要がある。
  • バージョンN+1とバージョンNに移動させる場合に、失われる機能をきちんと定義すべきだ。
     
  • エンタープライズクラスのソフトウェアでは、主要なデータはリレーショナルデータベースに保存され、バージョン間でデータを移行するための特別なツールを提供する必要があることを意味する。
  • アップグレードの場合、データは一つの操作で変換されることが多い。
  • 変換の場合、データは一つの操作で行われるか、システムが動作するための様々な機能として、要求するかもしれない。
     
    筆者の友人、ロン・ルンドは下記を指摘している。
  • 良くデザインされたスキーマデザインは、リリース間のデータ移行の作業を劇的に減少させる。ゴールはほとんど変更されないか、一旦作成されたら変更すべきでないスキーマを、よく変更されるかもしれないものから分離すること。
     
    例：多量のトランザクションベースアプリケーション
  • このようなアプリケーションの場合、トランザクションデータがアップグレードされることはまれで、スキーマデザインにおいてトランザクションデータをトランザクションではないデータから分離することが継続的なデータ移行の作業の軽減を図ることができる。
     

データの保持・維持 †

 
  • 古いデータは滅多に削除されない。古いデータはいくつかの会社のポリシーによって保持される。このようなポリシーの理由は特定の法的要求を満たすためのものであったりする、例えば税法のようなもの。
  • 顧客がデータの適切なアーカイブコピーの生成を必要する場合か開発者がアップグレードのあとに3年から7年どこでもアーカイブコピーをアクセスできるように確保する必要があるかもしれない。
 

証明 †

 
  • 特にエンタープライズクラスのソフトウェアシステムのアップグレードの場合、 本番環境として稼働を始める前に、厳密に顧客の内部で定義された証明に合格しないといけないだろう。
  • このプロセスは通常少なくとも1ヶ月から2ヶ月かもっと長く時間をとることがある、それはエンタープライスクラスのソフトウェアが年に1度2度以上にアップグレードされることは非常にまれだからだ。
     

新しいAPI †

 
  • 新しいAPIは特別な再作業の形でカスタマーのニーズを注意深く管理しなければならない。
  • APIを変更することは様々な苦痛をうむし、通常結果的にアップグレードが遅延するだろう。
  • 皆が心配することは、新しいAPIができる限り苦痛を避けることがベストであること。
  • APIマネージメントについては8章で述べている。
     

コラム：一旦統合したら、アップグレードしない †

 
  • 長い稼働時間のあと、変更と新しい APIを追加することになった。
  • 多くの顧客にとっては影響がないものだったが、調査によって、ごく少数の重要な顧客が大きな影響を受けることがわかった。
  • それは古いAPIを利用するシステムインテグレーションを行っていたためだった。
  • 開発チームは新旧のAPI間の差異を吸収するレイヤーを実装したが、古いAPIは削除ができなかった。
  • 多くの顧客は新規機能へのメリットからアップグレードを検討するが、使用しているシステムは驚くほど長く稼働することを考えないといけない。
     

新規機能 †

 
  • 顧客は最新リリースの新規機能を学ぶことを興奮するかもしれないが、それをどう使うか学ぶことには興奮しないかもしれない。
  • 学習には時間の労力が必要だ。
     
  • 振る舞いを変えることが求められている。
  • 顧客の規模とアップグレードの規模に依存して、新規機能の学習コストは顧客に対してアップグレードのキャンセルや、延期の動機となることもある。
     

手がつけられないシステム †

 
  • アプリケーションが真にミッションクリティカルであるに限らず、ユーザにとってアップグレードプロセスは不可能に思えるものだ。
  • これは不便性の最小である、デスクトップアプリケーションのアップグレードから、もっとも不便性の最大であるOSのアップデートや、完全に許容できないリスクとして、CRMのアップグレードや利益を生むシステムなどがある。
     

システムのリバート †

  • 変更管理の規約の重要性やミッションクリティカルなアプリケーションは常にアップグレードがうまくいかない場合に前のバージョンにどう戻すかを定義しなければならない。
  • 製品のアーキテクチャはリバートを簡単にするか、とても危険なものとするか・・
  • 通常多くの妥協したステップとしては全体のプロセスが失敗した場合のフォローをしなければならない。
  • このステップを動作させ、変更管理のために、顧客の苦痛が起こる。
  • アップグレードそれぞれのステップを細かく理解することは、アップグレードをシンプルにするチャンスだ。
     

コラム：アップグレードの苦痛は異なるもの †

アップグレードの苦痛を和らげるのは、システムのアップグレードのリスクマネージメントにかかっている。

 
 

担当者のつぶやき †

みんなの突っ込み †


Menu