【パターンフレームワークとは】
パターンを選択するとパターンの構造が展開されます。パターン構造の中で、処理ロジックの部分（ブロック）を処理部品の組み合わせで組立てます。誰が開発しても同じ構造のプログラムとなりますので、品質の担保と保守性の向上が担保されます。また、基本的にはJava言語そのものを習得する必要はありません。

【処理ロジックの部品に関して】
標準部品として予め準備されている部品は、全ての仕様とソースコードが開示されていますので、個別に修正した新規部品を作成することが出来ますし、全く独自の個別部品を開発することも出来ます。これらの部品群を蓄積することによって、企業の業種業態に適したライブラリ資産を蓄積していくこが出来ます。

【パターンタイプごとに詳細設計書のフォーマット・テンプレートを準備】
プログラムの処理パターン・タイプごとに詳細設計書のフォーマットを準備していますので、設計者はテンプレートに沿って設計作業を進めていくことが出来ます。
これによって、誰が設計しても一定のロジック構造となる為、プログラム開発工程での仕様把握の簡素化が図れると同時に理解齟齬のGAPを解消することが出来ます。
そして最終的には、保守・運用工程での属人性の排除が期待できます。

【リビルドとリライト・リホストの垣根がなくなる？】
Parallel Frameが前提とする構造化設計は、新規開発プロジェクトで有効であるばかりではなく、大型汎用機上のレガシーマイグレーションに際しても非常に有効な方式です。
なぜならば、この構造化設計の考え方そのものは、大型汎用機上でのバッチプログラム設計の定石とも言えるものである為、既存の仕様書（場合によってはソースコード）から容易に展開させることが可能だからです。

■新製品Parallel Frame　開発の背景
当社は数多くの基幹系システムオープン化プロジェクトを手掛けて参りましたが、それらのプロジェクトの多くの局面で「大量データを一括処理するバッチプログラム」の問題を見て来ました。
この問題に対処する為、基本的な製品構想から製品リリースまで5年間を費やして「Parallel Frame」の開発に取り組んで参りました。

■一般的なバッチ対策
膨大な本数となっていた既存のバッチプログラムですが、実際に処理ロジックを含むものは半分以下となりますし、多くの基幹系オープン化プロジェクトでは「可能な限りオンラインリアルタイム処理」を指向する為、既存汎用機上の多くのバッチプログラムは不要になります。
このような理由で、実際にバッチプログラムとして作成する必要があるものは、本数としては激減しますし、実際に開発が必要となるバッチプログラムに関しても、その多くは帳票出力用のCSVファイルの作成といった小さく単純なプログラムが多くなりますのでPL/SQLのような言語で比較的簡単に実現することが出来ます。

■どうしても残るクリティカルなバッチ処理
このような一般的な状況の中で、それでも残ってしまうバッチプログラムの本数が非常に多い場合や、扱うデータ量の多い業種・業態によっては、クリティカルなバッチ処理ロジックや性能の問題が大きく障害となっているケースが多々あります。
●開発標準化の側面での問題　=>　バッチ開発に対しての設計・実装の標準化が確立されていない。
●処理性能の側面での問題　=>　Javaなどのオブジェクト指向言語で開発したプログラムの処理速度の障害