ブラウンフィールド（ソフトウェア開発）
 |
ブラウンフィールド開発とは、情報技術業界で一般的に用いられる用語で、既存の（レガシー）ソフトウェアアプリケーション／システムが隣接した状況において、新しいソフトウェアシステムの開発と導入が必要となる問題領域を指す。この用語は、2008年にホプキンスとジェンキンスによって導入された[ 1 ] 。これは、新しいソフトウェアアーキテクチャは、既存の稼働中のソフトウェアを考慮し、共存させる必要があることを意味する。
現代の土木工学では、ブラウンフィールドとは、危険物質、汚染物質、または汚染物質の存在または潜在的存在によって、拡張、再開発、または再利用が複雑になる可能性がある土地を意味します。
ブラウンフィールド開発は、従来のソフトウェアエンジニアリングの手法に多くの改善を加えます。これらの手法では、ソフトウェア開発の設計段階から実装段階まで、対象環境が「白紙」、つまり「タブラ・ラサ」、あるいは「グリーンフィールド」であることが前提とされてきました。ブラウンフィールド開発は、こうした伝統をさらに発展させ、構築するシステムのコンテキスト（ローカルな環境）をあらゆる開発作業に組み込むことを重視します。そのためには、構築中のソリューションの周辺にあるシステム、サービス、データに関する詳細な知識が求められます。
環境の複雑さへの対処
既存のビジネス環境とIT環境を、競争力のある最新の統合アーキテクチャへと確実に再構築することは容易ではありません。ビジネス環境とIT環境の複雑さは40年間、ほとんど抑制されないまま蓄積され、変更にかかるコストはますます増大しています。その理由は以下のとおりです。
- 環境の複雑さは、多くの場合、レガシーコードに表れています。レガシースキルの不足は、保守と統合のコストを押し上げています。
- 既存の複雑な環境は、関連するビジネス機能の運用上の合理性を考慮した段階的に再構築する必要があります。これらの段階では、既存の複雑さが認識されていないため、潜在的な段階的な変更を理解し、設計することが非常に困難になり、システムの全面的な置き換えというリスクの高い選択を迫られることがよくあります。
- 加速開発手法の進化により、企業は最新のレガシーシステムを抱え込むことになりました。複雑なJavaおよび.NETアプリケーションは、古いCOBOLアプリケーションと同様の多くの問題を抱えています。
その結果、新しいビジネス機能を開発するための労力は、価値を提供することよりも、既存の複雑なシステムとビジネス環境を理解し、統合することに費やされる割合が増えています。
Brownfieldは、 OMG標準のモデル/パターン駆動型アプローチを根本から覆します。概念モデルから始めてプラットフォーム固有のモデルやコード生成へと落とし込む従来のアプローチではなく、Brownfieldはコードやその他の既存の成果物を収集することから始め、パターンを用いてアーキテクチャ層とビジネス層へと形式的に抽象化します。
標準的なグリーンフィールド手法を組み合わせて、望ましいビジネスターゲットを定義します。この「中間点を合わせる」手法は他の開発手法でも馴染み深いものですが、形式的抽象化を広範に活用し、発見と生成の両方にパターンを使用する点は斬新です。
すべてのブラウンフィールドツールの基盤となる概念アーキテクチャはVITAと呼ばれています。VITAは、ビュー（Views）、インベントリ（Inventory）、変換（Transformation）、アーティファクト（Artifacts）の頭文字をとっています。VITAアーキテクチャでは、対象領域の問題定義は、ビューと呼ばれる、独立した（ただし関連性のある）ネイティブな知識の「ヘッドフル（headfull）」として維持されます。ビューの最大のメリットは、ほぼあらゆる正式なツールをベースとできることです。ブラウンフィールドは、問題領域に単一のツールや言語を強制するものではありません。つまり、ヘッドフルはネイティブの形式とツールで維持され続けるというのが、基本的な考え方です。
ネイティブビューは統合され、単一のインベントリにリンクされます。このインベントリは、一連の変換機能と組み合わせて使用され、ソリューションに必要なアーティファクトを生成します。
現在、ビューは、 UML、XMLソース、DDL、スプレッドシートなどのさまざまなソースからインポートできます。IBMの Analysis and Renovation Catalyst ツールは、形式文法と抽象構文ツリーを使用することでこの機能をさらに強化し、ほぼすべてのプログラムを解析してビューにトークン化し、インベントリに含めることができるようにしました。
このアプローチで使用される検出、再設計、生成、テストのサイクルの急速な循環性は、より多くの制約が判明し、ソリューション アーキテクチャが洗練されるにつれて、ソリューションの論理的定義と物理的定義を反復的に洗練できることを意味します。
反復的なブラウンフィールド開発により、論理アーキテクチャと物理アーキテクチャを段階的に改良し、アプローチ全体にわたって段階的にテストを実施できるため、開発の加速、ソリューション品質の向上、そして欠陥除去コストの削減につながります。また、ブラウンフィールドはソリューションドキュメントの生成にも活用でき、常に最新の状態を保ち、様々な視点から見て一貫性を保つことができます。
Brownfield処理によって作成されるインベントリは、相互に関連した多次元セマンティックネットワークであるため、非常に複雑になる可能性があります。インベントリ内の知識レベルは非常に細かく、非常に詳細で、相互に関連している可能性があります。しかし、このような情報は理解が難しく、コミュニケーションの障壁となる可能性があります。Brownfieldは、職人の推測によって概念を抽象化し、インベントリ内の既知のパターンを使用して高レベルの関係性を抽出・推論することで、この問題を解決します。
形式的抽象化により、インベントリの複雑さは、より単純でありながら本質的に正確な表現に変換され、問題領域を理解する必要がある人々が容易に利用できるようになります。これらの抽象化されたインベントリモデルは、Second Lifeなどのツールで多層アーキテクチャ表現を自動的にレンダリングするために使用できます。
このような視覚化により、複雑な情報を世界中の複数の人がリアルタイムで共有し、体験することが可能になります。これにより、理解が深まり、チームとしての一体感が高まります。
参照
参考文献
- ^ Sommerville, Ian (2012).ソフトウェアエンジニアリング(PDF). ミュンヘン: EMPT Tech . p. 75. ISBN 978-3-86894-099-2。
