ブラウンフィールド(ソフトウェア開発)

author
0 minutes, 12 seconds Read

既存のビジネスおよびIT環境を、競争力のある最新の統合アーキテクチャに確実に再構築することは、自明なことではありません。 ビジネスおよび IT 環境の複雑さは、40 年間ほとんど抑制されることなく蓄積され、変更にはこれまで以上に費用がかかります。 その理由は、以下の通りです。

  • 環境の複雑さは、しばしばレガシー コードで表現されます。 1374>
  • 既存の複雑な環境は、関連するビジネス機能にとって運用上意味のあるフェーズでリエンジニアリングする必要があります。 これらのフェーズでは、既存の複雑さへの無知から、潜在的な漸進的変更を理解し設計することが困難なため、しばしばシステムの大規模でリスクの高い交換が行われます。 複雑な Java や .NET アプリケーションには、古い COBOL アプリケーションと同じ問題が多くあります。

その結果、新しいビジネス機能の開発努力のうち、価値を提供するよりも、既存の複雑なシステムやビジネス環境の理解と統合に費やされる割合が増えてきています。 プロジェクト全体の労力の最大 75% が、新しい機能ではなく、ソフトウェアの統合や移行に費やされていることが確認されています。 Standish Group の CHAOS 調査では、過去 20 年間に IT プロジェクトの成功率が全体的に向上していることが確認されていますが、2006 年においても、大規模 IT プロジェクトは成功するよりも失敗することの方が多いのです。 このような環境でのエンジニアリングは、産業用地や汚染された土地の再開発における建設業界の懸念と多くの類似点があります。 このような環境は、危険と予期せぬ複雑さに満ちており、再開発にはリスクと費用がかかる傾向があります。

大規模なプロジェクトの失敗の根源は、新しい機能や新しいシステムの特性の複雑さではなく、(「神話的人間月間」で確認したように)全体の要件の理解とコミュニケーションにあるのです。 成功するためには、要件には、既存のビジネスとITの制約を正確かつ徹底的に理解することが必要である。 現在の「グリーンフィールド」ツールと手法は、このような複雑性を本質的に無視した、初期の、非公式で、しばしば不正確な抽象化を使用しています。 早期の、不十分な情報による抽象化は通常間違っており、構築の後半に発見されることが多いため、遅延、高価な手直し、さらには開発の失敗という結果になります。 Brownfield 指向のアプローチは、既存の複雑性を受け入れ、可能な限り段階的、漸進的な変更を可能にするなど、全体のソリューション エンジニアリング プロセスを確実に加速するために使用されます。 概念的モデルから始めてプラットフォーム固有のモデルやコード生成に至る従来のアプローチではなく、Brownfield はコードや他の既存の成果物を採取することから始め、パターンを使用してアーキテクチャおよびビジネス層に向かって正式に抽象化します。

Brownfield 開発プロセスの概要

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

すべてのブラウンフィールド ツールの基本概念アーキテクチャは、VITA として知られています。 VITA は、Views、Inventory、Transformation、Artifacts の頭文字をとったものです。 VITA アーキテクチャでは、ターゲット スペースの問題定義は、Views として知られている知識の別々のネイティブな「headfulls」 (関連はあるが) として維持することができます。 Viewの主な利点は、ほとんどすべての形式的なツールに基づくことができることです。 Brownfield では、問題空間に単一のツールや言語を押し付けることはありません。中心的な信条は、ヘッドフルはそのネイティブな形式とツールで維持し続けるということです。

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

反復的なブラウンフィールド開発では、論理的および物理的アーキテクチャを徐々に洗練させ、アプローチ全体に対して段階的なテストを行うことができ、結果として開発の加速、ソリューション品質の向上、および欠陥除去のコスト削減が実現します。 Brownfield は、ソリューション ドキュメントの生成にも使用でき、常に最新で異なる視点からの一貫性を確保します。

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

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

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

Similar Posts

コメントを残す

メールアドレスが公開されることはありません。