SOA（サービス指向アーキテクチャ）に基づくシステム構築を容易にするため，日立製作所はこれまでのSOAシステム構築経験から得た設計・構築ノウハウを体系化し，「リファレンスアーキテクチャ」「適用ガイド」として提供し始めた。これらの狙いと効果を，同社ネットワークソフトウェア本部 林 重年担当本部長に聞いた。
日立製作所は，SOAベースの統合システム構築基盤「Cosminexus」の新バージョンに合わせて，SOAシステムの構築ノウハウを体系化し，提供を始めました。ITベンダーとして，そこまで踏み込む狙いは。
 |
| 林 重年 氏 日立製作所 ソフトウェア事業部ネットワークソフトウェア本部 担当本部長 |
ITベンダーの役割は，ユーザー企業が立案した戦略の実行プロセスをいかにシステムに実装するかということです。従来は基盤製品の提供にとどまっていましたが，今後はそこから外へ踏み出すべき時期だと感じています。
最近，経営スピードを高める業務プロセス改革のニーズが高まっており，業務の効率化などを実現するため，部門横断的なシステムの構築が増えてきています。これを受けて，複数のシステムを横串で刺して，連携動作させる実装がよく採られていると思います。
しかし，もともと個別最適をしてきたシステム同士をつなげるには，開発や運用の面でどうしても余計な工数が生じてしまいます。また，IT資産全体の最適化を考慮せずに開発を行ってしまうと，将来多大なメンテナンス・コストがかかってしまうだけではなく，変化に即応することができず，結果的にビジネスの足を引っ張ることになりかねません。こうした背景のため，業務プロセスの改革に向けたIT資産の再構築においては，システムの全体最適化を前提として取り組む必要があると感じるわけです。
問題は，全体最適なシステムを構築するにはノウハウが必要なことです。全体最適なシステムは，個々の製品の機能だけで実現できるものではありません。求められる要件に対して最適なアーキテクチャを採用し，それに最適な製品群を選択して効率よく組み合わせる，実装段階までを通して考えなければなりません。
そこで，当社の構築ノウハウを体系化した「リファレンスアーキテクチャ」「適用ガイド」というドキュメントをユーザー企業やSIパートナーの皆様に提供し，システムの設計・構築のお手伝いをしようと考えたわけです。
これらのドキュメントは，ユーザー企業と一緒にSOAベースのシステムを構築した際の経験に基づいています。構築の現場では，実装上の課題にいくつも直面しましたが，それらへの対処法を踏まえて知見を整理しています。
具体的に，どのような課題に直面したのですか。
SOAの考え方が広まり始めたころ，よく受けた相談というか誤解は，サービスの呼び出しやフローを制御する業務プロセス記述言語「BPEL（Business Process Execution Language）」に関することでした。多くのユーザー企業は，BPELを使えばどんな業務プロセスも記述できると考えていました。
しかし，BPELではうまく記述できないプロセスが結構あります。例えば，ある業務プロセスの途中でタスクを前工程に差し戻すとか，1度は承認して次工程に進んだタスクを引き戻すなどの処理です。人間系の業務処理としては当たり前のことですが，ストレートスルー型のプロセスを想定したBPELで記述しようとすると，かなり煩雑になってしまいます。BPELの記述が煩雑になれば，変更にも手間がかかり柔軟性や拡張性が低下してしまいます。
上記のような業務処理は，無理してBPELを使おうとせず，ワークフロー管理ソフトをベースに設計したほうがいいのです。要は適材適所なのですが，BPELで統一することにこだわり，実現したい業務課題に適したシステム・パターンを見出すのに結構な時間がかかることもありました。
もう1つ，ユーザー企業がよく直面する課題として，データレイヤーの統合があります。データベースを統合できると運用も楽になるでしょうが，アプリケーションへの影響も大きく，実現には時間がかかります。
しかし，業務課題を伺うと，データレイヤーでの統合ではなく，アプリケーションをプロセスのレイヤーで統合する方が効率的だったりします。場合によっては，ユーザー・インタフェース（画面）のレイヤーで統合した方が，利用者の効率も改善され，メリットが大きいこともありました。
こうした課題の解決例が「リファレンスアーキテクチャ」なのですね。
 |
そうです。「リファレンスアーキテクチャ」は，ユーザーの課題や要件に対してベストプラクティスとなるような，SOAベースの“システム・パターン”を定義したものです。
例えば『部門業務はシステム化されているが，エンドユーザーは複数部門のシステムを同時に利用している。その際，使い分けの手間や作業ミスが発生している』という課題があったとしましょう。リファレンスアーキテクチャでは，解決したいこと，やりたいことを起点に，適切なアーキテクチャを選び出せるようにしています。この例ではシステム間で高度な連携処理が不要なため，「ワンストップサービス」と呼ぶパターンを推奨しています。複数システムの画面部分だけを連携させ，画面上でデータを自動的に受け渡せるアーキテクチャです。
このアーキテクチャで必要となるミドルウエア群も，「フロントエンド」「サービス」「サービス統合」などのレイヤーごとに示しています。
実はシステム設計の現場では，前述のような結論を導き出すまでに数カ月を要したりすることもありました。リファレンスアーキテクチャは，設計者に選択可能なパターンを示すことで，システム設計工程を30～50％短縮できるとみています。リファレンスアーキテクチャは，（1）プロセス統合，（2）インタフェース統合，（3）情報統合，（4）サービス構築という4分野について，現時点で約25パターンを用意しました。これからも順次拡充していく考えです。
アーキテクチャを決めた後の設計作業はどうするのですか。
リファレンスアーキテクチャのシステム・パターンごとに，「適用ガイド」を用意しています。詳細な設計ノウハウはこちらを参照してもらうことになります。適用ガイドには主に2種類の解説が含まれます。
1つはSOAの設計に関するもので，システム・パターンに基づくシステム設計の解説をはじめ，「サイジング・性能設計」「運用・信頼性設計」といった設計ガイドを用意しました。サイジングについては，必要なCPU数やメモリー・サイズなどを自動的に算出できる見積もりシートも提供しています。
もう1つは「環境セットアップ」「アプリケーション開発手順」「トラブルシューティング」など構築段階のノウハウ解説です。無用な試行錯誤を減らし，開発生産性を高められるでしょう。
リファレンスアーキテクチャと適用ガイドは，ともに（1）アプリケーションをより速く開発すること，（2）各種サービスを柔軟に組み合わせられること，（3）システム全体を統合運用すること――を共通の目標としています。同時リリースする統合システム構築基盤Cosminexusとの組み合わせで，失敗のリスクが小さく，効率的なシステム構築ができると期待しています。
