ブラウンフィールド（ソフトウェア開発）

ブラウンフィールド開発とは、情報技術業界で一般的に使用される用語で、既存の (レガシー) ソフトウェア アプリケーション/システムがすぐそばにある状態で、新しいソフトウェアシステムの開発と導入を必要とする問題領域を表します。これは、新しいソフトウェア アーキテクチャでは、すでに導入されているライブ ソフトウェアを考慮し、共存する必要があることを意味します。

現代の土木工学において、ブラウンフィールドとは、有害物質、汚染物質、または汚染物質の存在または潜在的存在によって、拡張、再開発、または再利用が困難になる可能性のある土地を意味します。

ブラウンフィールド開発は、従来のソフトウェア エンジニアリング手法にいくつかの改善を加えます。これらは従来、ソフトウェア開発の設計および実装フェーズ全体を通じて、「白紙」、つまり「タブラ ラサ」または「グリーンフィールド ランド」のターゲット環境を想定しています。ブラウンフィールドは、作成されるシステムのコンテキスト (ローカル ランドスケープ) があらゆる開発作業に考慮されることを主張することで、このような伝統を拡張します。これには、構築中のソリューションのすぐ近くにあるシステム、サービス、およびデータに関する詳細な知識が必要です。

既存のビジネス環境と IT 環境を、競争力のある最新の統合アーキテクチャに確実に再構築することは、簡単ではありません。ビジネス環境と IT 環境の複雑さは、40 年間にわたってほとんど抑制されずに蓄積され、変更にかかるコストはますます高くなっています。その理由は次のとおりです。

• 環境の複雑さは、多くの場合、レガシー コードで表現されます。レガシー スキルの不足により、メンテナンスと統合のコストが上昇しています。
• 既存の複雑な環境は、関連するビジネス機能の運用上意味のある段階に再設計する必要があります。これらの段階では、多くの場合、システムの全面的なリスクの高い置き換えがデフォルトになります。これは、既存の複雑さを認識していないため、潜在的な段階的な変更を理解して設計することが非常に困難であることを意味します。
• 加速開発手法により、企業には最新のレガシー システムが残されています。複雑なJavaおよび.NETアプリケーションには、古いCOBOLアプリケーションと同じ問題が数多くあります。

その結果、新しいビジネス機能を開発するための労力は、価値の提供ではなく、既存の複雑なシステムとビジネス環境を理解して統合することに費やされる割合が増えています。プロジェクト全体の労力の最大 75% が、新しい機能ではなくソフトウェアの統合と移行に費やされていることが^{[誰によって]}観察されています。^{[引用が必要]}

IT 業界全体としては、クライアントにこのような大規模な変更を提供する成功率が低いです。Standish Groupの CHAOS 調査では、過去 20 年間の IT プロジェクト提供の成功率の全体的な向上を追跡していますが、2006 年でさえ、大規模な IT プロジェクトは成功よりも失敗の方が多かったです。このような環境におけるエンジニアリングの変更は、建設業界が工業地帯や汚染された敷地を再開発する際の懸念と多くの類似点があります。これらの敷地は危険や予期せぬ複雑さに満ちており、再開発にはリスクと費用がかかる傾向があります。IT 環境の複雑さが蓄積された結果、これらの敷地は「ブラウンフィールド」になっています。

大規模プロジェクトの失敗の根本原因は、新機能や新しいシステム特性の複雑さではなく、全体的な要件に対する私たち^{[誰の？ ]の理解と伝達です (} 「人月の神話」で特定されているように)。成功するには、要件には、既存のビジネスと IT の制約に対する正確で徹底した理解が含まれている必要があります。現在の「グリーンフィールド」ツールと方法では、初期段階で非公式で不正確な抽象化が使用されることが多く、本質的にはそのような複雑さが無視されています。初期の情報不足による抽象化は通常間違っており、構築の最終段階で発見されることが多く、遅延、高価なやり直し、さらには開発の失敗につながります。ブラウンフィールド指向のアプローチは、既存の複雑さを受け入れ、可能な限り段階的かつ段階的な変更を可能にするなど、全体的なソリューション エンジニアリング プロセスを確実に加速するために使用されます。

Brownfield は、標準的なOMGモデル/パターン駆動型のアプローチを採用し、それを根本から変えます。概念モデルから始めてプラットフォーム固有のモデルとコード生成に進む従来のアプローチではなく、Brownfield はコードやその他の既存の成果物を収集することから始め、パターンを使用してアーキテクチャとビジネス層に向かって正式に抽象化します。

次に、標準的なグリーンフィールド手法を組み合わせて、望ましいビジネス ターゲットを定義します。この「中間点を合わせる」手法は他の開発方法ではよく知られていますが、形式的抽象化を広範に使用し、検出と生成の両方にパターンを使用するのは新しいことです。

すべてのブラウンフィールド ツールの基盤となる概念アーキテクチャは、VITA として知られています。VITA は、Views、Inventory、Transformation、Artifacts の略です。VITA アーキテクチャでは、ターゲット スペースの問題定義は、Views と呼ばれる個別の (ただし関連のある) ネイティブの「ヘッドフル」知識として維持できます。View の重要な利点は、ほぼすべての正式なツールをベースとできることです。ブラウンフィールドは、問題スペースに単一のツールまたは言語を強制しません。コア コンセプトは、ヘッドフルがネイティブの形式とツールで維持され続けることです。

ネイティブ ビューは 1 つのインベントリにまとめられ、リンクされます。その後、インベントリは一連の変換機能とともに使用され、ソリューションに必要な成果物が生成されます。

現在、ビューは、 UML、XMLソース、DDL、スプレッドシートなど、さまざまなソースからインポートできます。 IBMの Analysis and Renovation Catalyst ツールは、形式文法と抽象構文木を使用することでこの機能をさらに強化し、ほぼすべてのプログラムを解析してビューにトークン化し、インベントリに含めることができるようになりました。

このアプローチで使用される検出、再設計、生成、テストのサイクルの迅速な循環性は、より多くの制約が判明し、ソリューション アーキテクチャが洗練されるにつれて、ソリューションを論理的および物理的な定義の点で反復的に洗練できることを意味します。

反復的なブラウンフィールド開発により、論理的および物理的なアーキテクチャを段階的に改良し、アプローチ全体を段階的にテストできるため、開発が加速し、ソリューションの品質が向上し、欠陥の除去が安価になります。ブラウンフィールドはソリューション ドキュメントの生成にも使用でき、常に最新かつさまざまな観点から一貫性のあるドキュメントを作成できます。

Brownfield 処理によって作成されたインベントリは、相互接続された多次元セマンティック ネットワークであるため、非常に複雑になる可能性があります。インベントリ内の知識レベルは、非常に細かく、非常に詳細で、相互に関連している可能性があります。ただし、このようなことは理解しにくく、コミュニケーションの障壁となる可能性があります。Brownfield は、職人の推測によって概念を抽象化し、インベントリ内の既知のパターンを使用して、より高レベルの関係を抽出および推測することで、この問題を解決します。

形式的な抽象化により、インベントリの複雑さを、より単純で、本質的に正確な表現に変換して、問題領域を理解する必要のある人が簡単に利用できるようになります。これらの抽象化されたインベントリ モデルは、Second Lifeなどのツールで、多層アーキテクチャ表現を自動的にレンダリングするために使用できます。

このような視覚化により、複雑な情報を世界中の複数の個人がリアルタイムで共有し、体験できるようになります。これにより、理解と単一チーム意識の両方が強化されます。

• デザインパターンストラングラー、アダプタ、ブリッジ
• アジャイルソフトウェア開発
• デブセックオプス
• リファクタリング
• ホワイトボックス（ソフトウェアエンジニアリング）
• ビジネスロジック

• DeveloperWorks インタビュー: IBM Rational 5 周年を振り返る Booch、Nackman、Royce
• インタラクティブなブラウンフィールド データベース開発のための Browninfo 方法論とソフトウェア: T. Vijičić、D. Simović、A. Đukić、M. Šestić
• EPAのブラウンフィールドプログラムの概要