そしてそれは、レガシー資産管理

Share

|

問題を話し合うための遺産を引き上げる基本的なご質問については、どのように情報システム（は）組織の使用の最適化をit （情報技術）のビジネスです。 レガシーアプリケーションを表示する代わりに、純粋に技術的な用語、マネージャー見てプロセスを生成する必要があり、これらのアプリケーションにそのような方法で問題をしています。 この視点にシフトする必要がレガシー問題を理解されるべきで、大きなビジネスコンテキスト内します。

実際には、大型の縮図があるのは、単に経済的な勢力だ。 今日の企業は努力して作成され急激な変化に対応する柔軟性があり、モジュラーことができるビジネスプロセスを素早く実装やreengineered 、必要に応じています。 このような種類のプロセスをサポートし、組織が動いては、伝統的なトランザクション処理を超えて新たな分野の急速な発展して展開すると、クライアント/サーバーのアーキテクチャです。 しかし、その場合には、関数は、単にシステムを実行しようとすることを学ぶ新技術の開発を、それは大きなチャレンジ行方不明です。

ものの新興技術のようなオブジェクトは、クライアント/サーバー、インターネットにエキサイティングな機会をもたらす新しいタイプのビジネスソリューションを作成し、それはレガシーシステムの主要な鍵を保持して将来の成功を収めた。 レガシーアプリケーションは、資源を支配する、何兆ドルもの投資を表し、現在の主要な障害物の半分以上がリエンジニアリング努力します。 多くの場合、組織自体がレガシー問題は、メインフレームにつながれているプロセスと旧世界の急激な変化の時を迎えています。 ビジネスの変化と技術の変化より速く速く課題はマネージャーを統合するビジネス主導の開発をレガシーな視点、プロセス、アプリケーション、およびインフラます。

レガシー挑戦

最近の見積もりによると、現在のインストールベースのミッションクリティカルなアプリケーションをご希望のレガシーコスト$ 3兆を交換します。 これらの支出の大きさのため、そして自分たちのビジネスに与える影響は、慎重に移動しなければ組織はまだ決定的にします。 基本的なレガシーシステムの維持にも莫大な費用のお金は、ほんのわずかしか離れマネージャーの予算を非常に重要な新しいアプリケーションです。

これらの費用は、今後の圧力を強めるためには、 3つの主な理由：まず、社長が投資したとの情報技術は、長年にわたって結果に関する説明責任を要求し; 2つ目は、予算の増加に限定されてきたため、インフレ率のほとんどは、最近の過去;そして3つ目は、ますます競争の世界では、企業のコスト削減の需要継続して、よりよい投資からの収益をすべての事業セグメントします。 その結果、いくつかの課題に直面するのは、団体名：

-少なくとも8 0％の大半が費やされる予算は、レガシーシステム上で、新たな開発のための左残減少します。 それと同時に、それぞれの新しいアプリケーションは、より複雑な、より多くの原価計算を開発し、維持します。

-ため、焦点の遺産の多くは、メンテナンスが修正され、マイナーの強化、大惨事を防ぐと、レガシー投資を迅速に限界効用逓減点に達する：各ドルの追加購入のメリット少なくなり、特にドルの費用を比較したときのそれぞれの新たなソリューションビジネスに問題があります。

-技術の変化のペースの加速を意味しシステムが使われたときより速く技術が増えていた彼らは安定している。

-過ぎる努力して支出を根本的には、レガシーシステム以外の付加価値;調査によると、 5 0％以上の献身的な努力を理解するには、レガシーアプリケーションの再試験そして、アプリケーションの変更後にします。

-集中的な努力の結果として、従来のアプリケーションを変更する前に、約2 5％の時間を費やした遺産をテストします。 もっと知的、計画的、集中的なアプローチとすべき十分なテストをより少ない労力で提供します。

-今年の新しいアプリケーションが来年の遺産で、通常は増加して、インストールベースのレガシーシステムを維持する必要があります。

これらの課題は、管理者がいくつか隠されているためです。 マネージャーの悪循環を断ち切る必要があり、ますます大きくなるまだ骨折してインストールベースのドライブまで毎年恒例の大規模なメンテナンス費用です。 新しいシステムの資金援助を受けなければならないことで生産性の上昇や、コスト削減というより小規模の蓄積を増やし、企業の資本投入します。 業務リエンジニアリングのように多くの努力は、すぐには変換さなければならない自己資金調達します。

資産ポートフォリオ管理のそれ

昨日の連続的なアプローチを計画、これで十分な機能を提供しては長いリードタイムがビジネスの目的を満たす、存在しません、今日の急速に変化するビジネスの世界です。 ドライブを変更するもののビジネスプロセスの統合と技術、無駄な通信が原因となるのは、ビジネス戦略との格差を広げるの配達を続行します。 エンジンのように大きな変化が、それはどのような戦略的な可能性を再定義を取得するとのさらなるビジネスプロセスごとに埋め込まれ、電子商取引を含め、コンピュータ統合生産、投資プログラムトレーディング、およびサプライチェーンの最適化します。 したがって、将来のことを必要とするビジネス戦略とプロセスホリスティック理解します。

対照的に、多くのレガシーシステムは、いくつかのエピソードの決定については、暫定的な、そして慣性支出のパターンに閉じ込められました。 これらの傾向に対応し、管理職は、レガシーシステムを評価すべきで、多くの地域と同じように売上高は、人事、または企業イメージが評価されます。 それを見て資産としてのビジネスマネージャは、リソースを提供し、 2つの主要な評価基準：

1 。 効果的な方法については、特定のシステムまたはスイートのアプリケーションがビジネスの目的をサポートしますか？

2 。 どのように効率的には、システムのタスクを実行するのをサポートしますか？

このオリエンテーション一組の重要なポイントをハイライトします。 第一に、ビジネスおよび技術的な視点の両方を評価するために必要なポートフォリオます。 ビジネスの目的は、ビジネスプロセスから派生し進化戦略と進化し、この困難なプロセスをすることができます。 マップに反対することは、資産の評価を使用すると、これらの目標を設定し、統計情報を総合します。 第二に、ポートフォリオを検討しなければならない、有意義な作品だ。 個別の要素を組み合わせるポートフォリオのようなパズルをサポートするための重要なプロセスやビジネスエリアにします。 にもかかわらず個別に表示される可能性の貴重な要素は、全体のビジネスの結果にかなり弱いかもしれない重大な欠点のためには、さまざまな方法では、部品の相性がします。

次に、この評価の結果は、マップ内のグリッドと呼ばれる4rポートフォリオマトリックス評価します。

この4rポートフォリオ評価マトリックス

評価マトリックスの4rポートフォリオの4つのカテゴリに含まれるアクションを提案-の4つのr s-ガイド決定しています。 並べ替え資産のポートフォリオの削減を分化の大きさは、従来の戦略に問題があるとの格差を征服します。 管理者は、相対的な大きさを理解し、サイズ、およびそれぞれのアプリケーションへの投資を獲得するガイド将来の行動を洞察しています。

カテゴリ1 ：低ビジネス価値、低コスト技術的条件;アクション：引退します。システムの機能を実行した場合は不十分疑わしい値は、なぜそれが実行されたのですか？ これらのシステムでは、これを構成する約25 ％は、北米ベースの遺産は、優れた候補者は、早期退職や良性を無視します。 もししなければならない状態で生かされることは、検討すべきではマネージャーをインストールするグラフィカルユーザーインターフェースの上で画面の文字をベースにしています。 他のオプションを選択システムの改善が、しかし、正当化することができない場合にのみコストでのビジネスの結果です。

カテゴリ2 ：低ビジネス価値、高技術的条件;アクション：見直す

再評価すべき理由は、マネージャーのための高性能システムは、ほとんどのビジネスのために貢献します。 これらのシステムでは、約5 ％のみで、インストールベース、かもしれませんが正当化されているケースを十分に確保するためのアクションです。 また、以上の時間を正当化する時代遅れとなる可能性があります。 その他の場合は、ロールアウトれた可能性がmishandledます。 管理者は、これらの資産の移動を検討すべきで、より多くの重要なアプリケーションの場合には、まだビジネス価値を提供する能力があるとすれば退職金を段階的にはありません。

カテゴリ3 ：ビジネス価値の高い、低コスト技術的条件;アクション：再開発レガシーシステムの約半数がこの範疇に入るました。 これらのシステムが必要かもしれませ飽食;しかし、まだビジネスに依存しています。 マネージャは、すべき努力を維持するビジネスをサポートし、資産価値を維持し、適切な場所に機能を向上させる-すべてのコストを低減します。 これは多くの点で、例えば、業務システムからのビジネスルールを抽出し、発展途上値

ベースのケースをサポートするための行動を交換する、または戦略を開発するための新しい機能を代替次第に古い。

カテゴリ4 ：高いビジネス価値、高技術的条件;アクション：更新

約20 ％を占めレガシーシステムは、この理想的な状態で提供する有形資産の価値とビジネスの技術的条件が良いです。 それは不幸なスタートを切っ真実をしているほとんどのアプリケーションをターゲットとしたが、この象限または開始以来、この象限に落ちていたのだ。 組織の使命は、これらのシステムについての資産価値を維持することを前方に移動させることによって、ビジネスとしての目標や技術の変化します。

評価の後、マネージャーは、先を見ることができ、当面のを確認し、問題があるとしてレガシーシステム製品の根本原因です。 レガシーアプリケーションを表示するというよりもろいと冗長性、機能が移動することができ、これらの耐用年数を延長するレガシー資産ます。 アドレス指定され、これらの問題の原因-技術的な問題がないことが多く-マネージャーが移動するのを防ぐことができあまりにも急速に低下させる価値のビジネスおよび技術的な条件を経験しているほとんどのアプリケーションです。

institutionalizingポートフォリオ管理

すべての福利厚生のため、ポートフォリオの1つとして評価されません配達時にイベントを永続的上昇した。 これを識別しなければマネージャーは、いくつかの改善の機会を速やかに基づいて行動する、以上の時間に1回限りの評価を急速に低下建築shelfwareます。 その代わりに、ポートフォリオ評価しなければならないプロセスの最初のステップでは、こうすることで、ポートフォリオマネジャーの管理を継続して再評価されて資産との間の結合のビジネスのニーズに進化しています。 の寿命は、現在の技術のうちのほんの少しして、メインフレーム;評価を期待し、 3カ年計画をドライブにつながる必然的に高まるとの関連性についての質問には、失望感の高まりの効果をします。

井戸の構造を評価すべきポートフォリオの下地を作るために、この継続的な管理アプローチします。 に加えて、 4rプロフィール、その他の重要な質問をして評価すべきアドレス：

-どうすればエンドユーザーには、正式にサポートソリューションとの相互作用か？

-どうすれば現在の資産をサポートして根本的な目標とビジネスプロセスのか？

-と開発への移行は、どのようなアプローチは、各アプリケーションのポートフォリオのですか？

-どのような条件や投資のライフサイクルは、各アプリケーションの姿勢ですか？

-とはどのようなアプリケーションの技術基盤の戦略が合っているか？

-その支出の焦点は、どこに置けば？

これらの質問に答えるの基礎を提供するための新機能とは関係が揃って、その付近のビジネス目標のビジネスパートナーです。 ポートフォリオの評価になるための最初のステップに根本的な変化から離れて、前のパターンによっては機能のリクエストに応答し、ストリームと関連経費の要求を駆動されるまたは既存のシステムの変更を提案します。 その代わりに、あらためてビルドに向けての管理機能は、進化の一連の資産のことです。 この新しいアプローチでは、

マネジャーは反対の状態に変更することを評価する資産およびビジネスプロセスをサポートしています。

それ自体の評価を表し、高レベルの計画の発展のために資産;非常に高いレベルで、それは概念的なアーキテクチャのための法人です。 並行して、関連性の高い計画では、この高レベルのモデルが見つかりました市の計画や建設に使用されます。 適応できるように、無形の性質から生じるコンピューティングは、ビジネスプロセス、ポートフォリオ戦略、技術インフラ、およびすべてのコードが簡単な検査と同等の基本的な建設計画と規律のモデル（例えば、ゾーニング計画、インフラストラクチャの計画、設計承認、さまざまなよければ、コードの検査、およびメンテナンスの規制）します。 典型的なのは、どのような機能が足りないの規律をその過程で、市の企画部の役割は、規制を継続的に維持し、保守します。

ハイブリッドコンピューティングを調整する

狭く表示するには、いくつかの団体の遺産を専門用語で、主に挑戦します。 これらの回のハイブリッドコンピューティング、ナビゲートする必要がありマネジャーの間では、大幅に対照的な世界観：対リレーショナル階層は、柔軟性の厳格な対、対オブジェクトベースの手続きは、対集中分散、オープン対クローズされます。 この日は、 1つのパラダイムが消えたのは、ペースを加速すると、ビジネスや技術の変化に応じ必要な機能は、複数のアーキテクチャ、言語、およびプラットフォームです。 これに対し、企業が成功するまでの見直しの基本的なアプローチを統合、組織の計画値をレガシー資産からの回復、そして包括的移行戦略を考案しました。

見直し統合

レガシーoverintegrationの典型的なビジネスアプリケーションのサイズが増加した驚異的な5400 ％の開始以降、 1980年代にします。 ミッションクリティカルなアプリケーションの典型的な統合に成長を含め120万行のコード-一緒に組み立てられた架線何だと思いました2 0種類のアプリケーション1 5年前にします。 これらの数値によってもたらされる課題の開始を説明するレガシーoverintegrationます。

スパゲティコード-優性に挑戦1 5〜 2 0年前-に置き換えられてきたスパゲティ統合します。 現在の多くの機会を多くのアーキテクチャでやりたい放題のアプリケーション間の相互作用、プログラム、コード、およびデータます。 構造化プログラミング-広く受け入れ前進するスパゲティコード-いくつかの教訓をスパゲティの統合を提供します。 タイトな結束力を強調すること（ ie 、非常に関連の機能を維持する）と疎結合（ ie 、最小限の間の接続機能）します。

残念なことに、ほとんどの場合、スパゲティの統合と共有統合データベース、その逆は真である。 レガシーアプリケーションは、通常緩んでの結束を特徴とする、などのロジック製品の機能および顧客データの編集を振りかけを通じて数多くのプログラムやアプリケーションです。 両方のアプリケーションを共有するデータベースには、しっかりと結合し、データベースの冗長性、およびインターフェイスのファイルを介してやりたい放題の間の相互作用の数えきれない多くの分野でのプログラムです。 コンポーネントアーキテクチャコンポーネントアーキテクチャのシフトを交換共有データを統合し、制御カップリングタイトな凝集-多くの共通点を慣行していたオブジェクト指向の設計と分析。 これらのアーキテクチャシフト

焦点を標準的なインターフェイスと建設ガイドラインをご覧ください。 加えて、通信メカニズムに基づいて、使用するコンポーネントを補完する、伝統的なアプリケーションやデータに焦点を合わせるました。 このようなコンポーネントアーキテクチャを使用したアイテムとしてデスクトップの統合、ソフトウェアのメッセージバスで、リモートデータへのアクセス、およびデータの倉庫として積み木を支援するアプリケーションの標準的なインターフェイスを通じて協力します。

このアイデアは、コンポーネントを容易に理解できる面での新製品開発することも可能レガシーアプリケーションに適用されます。 いくつかの団体が現在、これらのアプリケーションを表示することができるコンポーネントとして再利用できる新製品開発に組み込まれたオブジェクト指向のテクニックを使用します。 建物はコンポーネントベースのメッセージ駆動アーキテクチャでは、専門家が使用することができ、さまざまなテクニックを中心に急落を避けるためにレガシーシステムと、新しいレベルの複雑さを余儀なくされます。 これらの技術の多くは現在定評になるように、次のセクションに値を回復と移行戦略を議論します。

コンポーネントアーキテクチャへの移行をサポートする2つの具体的なコミットメントも-リユース、保守-その資産の価値を高めることです。 再利用の増加、資産の価値を将来の開発コストを削減します。 値を増加させることによって、資産の保全性を進化するビジネスとして変更されます。 両方のコストを大幅に削減する集中投資を少なく、より柔軟な資産です。 制御アプリケーションを破り、標準的なコンポーネントとしては、重要なことは、保守を再利用します。

レガシー資産から値を回復

レガシーアプリケーションのビジネス価値は計り知れない庫、たとえその値が非常に困難な搾取することができます。 値として分類することができ、 3つの主要分野の1つに落ちる：データ、処理ロジック、ビジネスルールとします。

幸いなことに、新たな戦略、技術、およびツールが台頭しましょうマネージャーとそのスタッフは、設計し直す、再調整、共存する、または既存のアプリケーションから値を抽出します。 これらのアプローチもレガシー資産の近くに移動してアーキテクチャの新製品開発の根底にしています。

レガシー資産の移行のための戦略

いくつかの基本的なテクニックについては今の新興の基礎としての値を回復するハイブリッド環境でプログラムします。 次のセクションで説明するとして、ほとんどのアプリケーションで、これらの戦術に頼っている大規模な破壊を小さくコンポーネントのリエンジニアリングや、その後の再調整してください。

-リバースエンジニアリング-を提起する自動ツールのヘルプシステムをより高いレベルの抽象化され、例えば、システムの仕様や要件を得るモデルから既存のコードとデータです。 この手法が新たな基準を作成するためのコードを組み込んだ機能強化と将来の再生を有効にします。 また、伝統的なメンテナンスを容易に向上させる開発者のシステムを理解しています。

-パッケージ（ i e、コンポーネント） -標準co ts（商用既製）のようなパッケージワープロ、スプレッドシート、ワークフローエンジン、およびグラフィックスライブラリのための重要コンポーネントハイブリッドソリューションを提供することができます。

-コンポーネント-レガシーシステムや遺産分割を細分化プログラムでは、スタッフのコンポーネントを交換するシステムを段階的に廃止するかを一度に1つです。 いくつかのコードを解析ツールのヘルプこのタスクは、しかし、概念のモジュールとコミットメントを再利用するよりももっと重要なことは、特定のツールです。

-リストラや合理化-掃除既存のコードの冗長性を排除され、 i n stituting基準、構造の改善、およびドキュメントの更新を簡単に維持強化します。 この最初のステップでは、頻繁にレガシー戦略だ。

-変換や再集結-レガシーアプリケーションを移動するには再集結-手つかず-方面のクライアント/サーバプラットフォームです。 このアプローチの約束だけでなく潜在的にも低いコストで、複数のアプリケーションコンポーネントを有効にもっとシームレスに統合され、ビジネスユーザー向けのソリューションです。

-建築レイヤ-さまざまな層を分離して、アプリケーションのコンポーネントなど、プレゼンテーション/ユーザーインターフェース、アプリケーションロジック、データへのアクセスレベル、および通信します。

-w rappering-ラッパを作成するソフトウェアのコンポーネントをカプセル化とモジュール方式の遺産を有効にしてコミュニケーションをo b jectorientedコンポーネントと共存します。 サーバーの機能により、従来のオブジェクト指向のコードを送受信したメッセージです。 このように、 wrapperingポジションレガシーコードを提供する継続的価値とは、将来の再利用されるシステムです。

-フォワード再生-自動再生するコードに基づいて開発者用ツールのヘルプ更新というより高いレベルの抽象概念を変更してコードを直接入力します。 この手法リバースエンジニアリング後に使用されるかもしれない場合、またはオリジナルのシステムを開発したコードを生成します。

-サラウンド-追加機能やデータを作成するコンポーネントの周りのレガシーシステムでは、しかし、システム自体を変更せずに、できるように段階的に廃止されるコンポーネントの遺産として、周辺のコンポーネントsu pplantレガシー機能します。

-データウェアハウス-で囲んで、新しい機能を置く戦略の前には、レガシーシステムとの統合デスクトップレベルでは、倉庫の背後にレガシーアプリケーションのデータを統合しています。

-維持強化-としては、組織のセクションを変換して説明するが、メイン開業医は、伝統的なアプローチを見直し、進化の遺産の資産管理の分野においても維持強化します。

-新しい開発-最良の慣行の能力成熟度モデルと評価ヘルプ進路を決めると良い結果を新しいアプリケーションの開発における生産性の向上します。

-パッケージを交換する-ソフトウェアパッケージを頻繁に交換するレガシーシステムでは、特に、もしそれが使用されn o ndifferentiatingの基本的なアプリケーションをサポートします。 cotsアプリケーションパッケージに使用される可能性もあるサラウンドアプローチします。

-アウトソーシング：長期的または暫定-ため、費用対効果の高いことが可能な状況の下で権利を識別するタスクとを明確に定義

アウトソーシングには、管理者が検討すべきoutsourcersの強化、再開発、または交換の段階で、戦略の遺産です。

これらの技術は確かに移行しないスタンドアロン型のメカニズムをします。 の間で重複するだけでなく、さまざまなテクニックがありますが、それらは互いに相互作用するにももっと細かく調整結果を生成します。 管理者は、慎重にすべきは、与えられた状況を評価する手法の一環としてプロジェクト全体の計画をします。

形質転換は、組織

一度は組織がコミットしてシステムを開発する建築士のコンポーネントでは、タスクマネージャの顔に変換する方法は、それ自体のやりとりを行いレガシーポートフォリオ機能します。 は、管理職が相対的に停滞したため、予算は、急速に改善しなければならない自己資金調達します。 このような改善の結果から5つのソース：

1 。 より良いビジネスパートナーとの間には、コミュニティの3 。 より良いスキル、プラクティス、ツール、および技術の開発者のレベル5します。 継続は力の強化

変換は、ユーザーの需要を管理する組織を中心に、レガシーシステムの進化、およびリソースがします。 を受け入れる傾向があるが、組織としての行動をさらに別のレガシーに挑戦するというより古い経営再建のアプローチと仮定します。 この機能は、設計し直す必要があり、根本的に考え直す自体は同じようにし、多くの組織がビジネスプロセスリエンジニアリングします。

経営陣は、伝統的には、重要な技術に焦点を合わせた変更を引き起こす作業プロセス、スキル、と理解されるまでに彼らはreshaped遅れました。 このような変化の例としては、最近のクライアント/サーバ技術、オブジェクト指向、マルチメディアとします。 変換の基本的な問題は、しかし、般的に関連して受け入れられた慣行や信条-言い換えると、文化の内には、それ自体をします。

文化的な変化は

クラフトベースの開発は、まだ多くの活動が実施されるのは、文化の産業革命に相当するクラフトです。 メソッドは、個人情報やunstandardized 、民間の知識confers電力、容易ではありません、成功か失敗か判別します。 最悪の場合は、風変わりな方法で書かれたコードは、従業員を留保しなければならない個人的な仕業に更新して、他の誰にも捕集たぶん他の開発者のためのシステムを理解しています。 最後に、ギルドのメンバーの中でのみ理解されるべきで、その判断される別のcraftsperson 、ためらいがちな人が共同で会員を批判します。 たとえば、正式な査読が立証さにもかかわらず、最も費用対効果の高い方法と除去コーディングエラーを防止するために、いくつかの開発者は、互いの作業を視察します。

成長する証拠死体ハイライトの重症度この問題を解決します。 最近の個人的な実験に関連していくつかのソフトウェアが見つかりましたプログラマの生産では、少なくとも5年以上の経験を注入1000回あたりの欠陥数百行のコードで、最悪の場合、以上の1100人です。

基本的な動きの質を意味してレッスンを受ける費用は、これらすべての欠陥を見つけて、再加工しなければならない膨大なします。 ほとんどの専門家は認識していないし、問題の規模で、ほとんどの組織は、統計情報を計測することが欠如しています。 さらに驚くべきことは、検索結果の改善を使用してから3か月後の個人的な統計情報：プログラマの人と同じ注入1000回あたりの欠陥数百人の行のコードの品質向上に配信されてから5 〜 10の要因です。

エンジニアリングの時代に移動して管理する必要の遺産の大半は、組織を動かすソフトウェアの開発とメンテナンス作業をしてからクラフトエンジニアリングの年齢です。 工学的なアプローチでは、パフォーマンスの基準を共有するには、転送、より多くのパターンの仕事をされた整然とし、コンポーネントの再利用はinterchangedとします。

このモードでの思考を表すために劇的な変化を心の中にあるのは、組織の設定は、ソフトウェア工学の観点に反対して、広くすることができます。 障害者を育成するようには、マネージャが認識されるのは、組織の必要性を再発明する方法や優先順位を変更するに基づき、文化エンジニアリングします。

管理プロセスの変更

既存のシステムにはほとんど変更を非常に非効率的な方法で処理され;彼らの約4倍を取る限り、変更前の新製品開発中です。 組織は、ビジネスユニットに対応する圧力を頻繁にしてその場しのぎの解決しようとします。 複雑なシステムおよびソフトウェア開発者が日常的に入力を行うマイナー修正（しばしばいわゆるストリームを生成する方法を修正したエラーの修正が完了する前に仕事を）します。 次に進むために別のタスクをせずに彼らの記録を残していたものです。 オリジナルのデザインの整合性の概念は、ドキュメント、システム自体の実装と、急速に低下し、その場しのぎの手直しを繰り返した電子瘢痕組織を構築するようにします。 このようなシステムを維持するには必然的に困難であると理解します。

またしても、いくつかの組織が根本的に見直して、インストールベースのアプローチを扱うことにより、より多くのようなパッケージソフトウェアです。これは、変更のご要望は、合理化および管理します。 これらの団体が交代してその場しのぎのサイクルを反復アプローチの強化を実現し、次の重要なメリット：

-彼らを得る広い視野に立って、一連の細部の変更を行います。

-彼らに抵抗する高価な需要を調整してビジネス上の利益のほとんどを提供します。

-彼らの保守的なアプローチをより効率的に開発するために彼らを減らすの5 0％を維持して時間を費やしたが、現在のアプリケーションを理解します。

-ワークショップなどの高度な技術を使用して、ビジネスプロセスのレビュー、およびプロトタイピングする権利を確認して問題が解決しました。

-彼らを保護する設計との整合性のマニュアルをご覧ください。

このアプローチを通じて、ビジネスパートナーとは、はるかに大きなレベルのコントロールを行使すると住所の実際のビジネスや技術的な問題だ。 正式な監視団体または変更審査委員会に参加するビジネスプロセスの所有者には、スポンサーおよびポートフォリオマネジャーます。 理事会の焦点を維持する長距離（ビルトの周り4rポートフォリオ評価）と接触を避けているのに巻き込まれる日常業務の変化を要求します。 理事会の承認を必要と明らかに大幅な変更が、さらにいくつかの少ないマイナー適応を受けると正式に精査修正します。 すべての予定を変更するには、いくつかの質問に対する回答を：

-では、何度要請し、元のデザインを変更すると互換性ですか？

-では、どの程度の変更が必要ですか？

-どのくらいの変化を向上させるシステムですか？ 利益を正当化するのは費用がかかりますか は、戦略計画の変更に対応してますか？

-は、予算の範囲内での制限を変更するか？

-どのように重要な変更は、他に比べて、受注残か？ -どのように実現されるまもなく回収ビジネスですか？

-そこでの組み合わせを変更して規模の経済をまたはその他の相乗効果を生成しますか？

後にこれらの質問の回答は、組織の変更を分類し、グループの緊急性の要求されるビジネス上の利益と、審査のプロセスを確立するとのスケジュールの優先順位に変更され、費用対効果は、全体の遺産の妥当性や戦略だ。 緊急の課題-など、これらのシステム障害に関連付けられている-は、より迅速に実行する際に、システムが豊富なドキュメントと熟練の人がご利用いただけます。 小規模な変更がない場合には、強力なビジネスグループで実施されると、保守プロセスを最適化する計画リリースします。

1回の定期的スケジュールのアップデートやリリースを確立すると、ビジネスユーザーに頼るの組織をまとめて変更する場合は、計画を変更し、ビジネスの導入、および事業資産としてのポートフォリオを参照してからというよりも長期的な瞬間- tomoment展望します。 人員削減は時間ごとに1日を費やす可能性が浅はかな冗長性やシステムの変更を解放するために他の種類の仕事をしています。

統計情報の場合

ご希望のようにせずに、どのようなビジネスの損益声明か？ 何が野球のようにせずに、平均自責点出塁率ですか？ ほとんどの組織は、統計情報の不足で、遺産の問題は、技術的な部分だけで、方法論的な問題;典型例かもしれませんがそれによってもたらされる課題の組織文化します。

このようにすることは難しい点は、多くの団体の歴史を自分たちのプロジェクトを維持するため、見積もり、およびactuals 、他の団体はプログラムと刈り入れる配当コミットを測定します。 その結果、これらのプログラムが印象的です。 たとえば、最近の報告書を500が見つかりました団体の間で25日と30パーセント（でも最大で60 ％以上）の努力は、いくつかの組織が成功したプログラムは、統計情報に焦点を当て、 instituting是正処置をインストールしたシステム（品質クラシック条件は、これは純粋な作り直し）します。

体の成長をサポートするための統計情報は、元の組織の外では、本製品および組み込みソフトウェアのコミュニティ内でのビジネスです。 顧客は、これらの外にはこちらには戻りませんかわいそうな品質のソフトウェアです。 したがって、私tricsが最良の問題を根本的に理解され、文化的な対立内での課題は、経営者とします。 メインの問題はしっかりしている限り過去の掲載結果についての知識を見つけるのは不可能で、信頼性の評価、将来のパフォーマンスのまま手の届かないところです。 としては次のセクションを示すと、多くのカテゴリの遺産を貸す活動を正確に測定しています。

Product Measurements How many lines of code were generated, changed, reengineered? How many function points were delivered or modified? How many defects were embedded along the way and how many errors were discovered before delivery? After delivery?

How well do the products satisfy customer needs? How well does a given system add value to or enable a business process?

Process Measurements How many hours were devoted to which projects in the past 12 months? How many of those were direct, indirect, and managerial? What funds were expended where and when? How much time was spent adding value to the application? What were the cycle times? When was testing performed and how effective was it? What kind of work was being performed?

The following four categories have been suggested for maintenance work: corrective (i.e., fixing mistakes), adaptive (i.e., keeping up with external regulations and changes in technology), perfective (i.e., changing user requirements or performance), and preventive (i.e., enhancing maintainability and reliability).

Organizational Performance How well does the IS organization compare with industry standards such as the Software Engineering Institute maturity model? How does the IS organization satisfy its customers? How well is IS delivering value and responding to needs?

Once a system of metrics is in place, managing users, legacy systems, and IS people becomes more straightforward. Without metrics, management remains a matter of educated guesswork. Some of America’s most admired corporations — such as Motorola and Hewlett Packard — have recognized the urgency of the issue and are driving metrics throughout their organizations.

RECOMMENDED COURSE OF ACTION

What has come to be known as the legacy problem is not only a matter of today’s inheritance of yesterday’s assets. Tomorrow’s legacy must be considered as well. If today’s IS organizations use the same procurement and maintenance processes, handle the same customers using the same change control and architectural approaches, and then have to cope with four or five times as many technology choices, they cannot expect anything better five years down the road. One might even argue that the legacy situation of five years from now will be an order of magnitude worse than it is today.

As with any major reengineering effort, issues of politics and culture are significant. Traditional wisdom on integration has left a legacy of complexity. This inheritance must be managed in a world where the IS function no longer has the monopoly franchise on rapidly changing information technology. These challenges create the need for IS managers both to reengineer IS itself and to provide the leadership and understanding critical to rethinking perspectives and driving the change.

Legacy is not an episodic, one-time hangover from the days of the mainframe. Legacy is the ongoing challenge of leveraging evolving IS assets in the era of hybrid computing.