いろいろなエンタープライズ
ソフトウェアの世界では、いろいろ目に付きますね。
- J2EE
- エンタープライズエディション
- EAA
- エンタープライズアプリケーションアーキテクチャ
- EIP
- エンタープライズインテグレーションパターン
- ESB
- エンタープライズサービスバス
私は、自分の専門分野は、ソフトウェアシステムの中でも、エンタープライズ分野、であると自負している。
マーチン・ファウラー、かく語りき
著書、PoEAA ( エンタープライズアプリケーションアーキテクチャ ) の「はじめに」で、マーチンファウラーは、エンタープライズアプリケーションの意味を説明している。
明確に定義できないし、人によって使い方がいろいろある、あいまいな言葉。
私としては、このマーチンファウラーの説明が、いちばんしっくり来ている。
最初の段落の以下の2点にすべてが要約されている。
- 複雑なデータに対処する
- (論理的とはいいがたい)ビジネスルール
エンタープライズアプリケーションの関心事は、「データ」と「ビジネスルール」というわけだ。
永続データ、たくさんのデータ、同時データアクセス
データの問題を、三つの視点から、とりあげている。
永続性
ビジネスは、情報の記録と保管は、基本中の基本。アプリケーションソフトウェアを入れ替えても、既存のデータは「移行」して使い続ける。
たくさんのデータ
ビジネスで扱うデータは、どんどん増えている。なんでもかんでも、電子化・デジタル化の時代。
インターネット時代では、顧客のワンクリックまで、記録して、永続化する。
こういう膨大なデータを効率良く扱うのがエンタープライズアプリケーションの、重要な関心事。
同時データアクセス
これも、ネットワーク時代になって、加速している問題。
同じデータに多くの人が同時にアクセスする。同じデータを同時に書き換えることも起きる。
これをどうやって、うまくさばくか?
RDBMS と SQL
永続化、大量データ、同時アクセスを実現する技術としては、いまのところ、RDBMS と SQL が基本の技術。
RDBMS/SQLの使った、良い実践とはなにか? 良い設計とは? 良いアーキテクチャとは?
これが、エンタープライズアプリケーションの重要な関心事の一つ。
多くのユーザインタフェース画面
エンタープライズアプリケーションとは、極端に単純化すると、データベースを、CRUDするもの、と定義できる。
データの種類や量が多いということは、CRUDのための画面も多いということ。
また、いろいろなビジネス上のルールがあるために、ユーザによって、「できる・できない」「見える・見えない」を変えなきゃいけない。
Web アプリケーションを顧客に使ってもらうとなると、顧客ごとに、さらに、カストマイズした画面が欲しくなる。
検索フォーム・一覧・入力フォーム。基本はきまりきった単純な形式しかないのに、とにかく画面数が膨れ上がる。
どうやって、これを簡単に開発するか?
変更要求があったときに、どうやって、安全・確実に変更を適用するか?
電子メールというユーザインタフェースもいろいろ必要。
携帯電話や、PDA 用も。
画面の爆発です。
でも、ユーザにとっては、画面こそ、画面だけが、システム。
ここが、がんばりどころとなるわけだ。
バッチ
バッチ処理も忘れちゃいけいない。
ビジネスでは、日、週、月、四半期、半期、年度、というサイクル構造(=バッチ処理のタイミング)は、強固な枠組です。
他のエンタープライズアプリケーションと統合
あちこちで、爆発的に、ビジネスデータの電子化が進んでいる。
それも、同時多発ゲリラのように、さまざまなデータ形式、実装技術でやまほどエンタープライズアプリケーションが作られている。
社内だけでもたいへんなのに、最近は、ネットワークのおかげで、社外とのシステム連携も、日常的な課題になってきた。
ビジネス活動とは、人と人、組織と組織の相互作用。だから、ビジネスの道具である、エンタープライズアプリケーションも、他のアプリケーションとの連携・相互作用が必然。
しかし、...。
実装技術、データ形式、通信プロトコル。ハードルがやまほどありますね。
見ず知らずの開発チームと共同作業なんていうハードルもある。
概念の不一致
でも、統合の一番の難敵は、それぞれのシステムの「データ」の考え方が違うこと。
ビジネスルールは、いつも変化している。ある時点で造ったアプリケーションとデータは、その時点のビジネスルールの「スナップショット」を反映しているだけ。
社内システムといえども、アプリケーションごと、データベースごとに、異なる考え方を実装したもの。
他社のシステムとの連携ともなれば、根本のビジネスの考え方・決め事がまるで違っているのがあたりまえ。
ビジネスパーソン同士でも、いろいろなすり合わせを行い、契約書や合意書をやまほど積み上げていく。
でも、人同士だと、まだ融通が効く。
エンタープライズアプリケーションという融通の効かないモノ同士の連携は悪夢に近い。
昔のビジネスルール、部分的なビジネスルールを、がちがちに、変更不能な状態に組み込んでしまった「ソフトウェア」(どこが柔らかいんだ!)。
ビジネスロジック
これは、パラドックスです。
ビジネスロジックとは、ロジカルではない。
関係者があつまれば、だいたいの約束事は把握できるけど、緻密に、論理的にくみ立てられたものではない。
ヒアリングすれば、誰も説明できないルールがでてくるのは、みなさんご存知の通りです。
唯一の真実は、「ビジネスロジックは変更される」こと。
どんなにがんばって、その時点でなんとか整理したビジネスルールを実装しても、それは、たんなるスナップショットであり、ある一面のビューにすぎない。
実装してテストしている間に、業務の現場では、別のルールがいつのまにか常識になりつつある。
だから、どうする
格闘すべきテーマは、単純といえば単純。
最初に書いたように、
- 複雑なデータに対処する
- (論理的とはいいがたい)変化し続けるビジネスルール
この2点を効果的に実装する、実践的な技術、良い実践ノウハウ。これが、エンタープライズアプリケーションを造るエンジニアのもっとも重要な関心事であり、スキル。