<< 育成型のソフトウェア | main | InfoQ と エンタープライズアプリケーション >>

エンタープライズアプリケーションとは?

いろいろなエンタープライズ


ソフトウェアの世界では、いろいろ目に付きますね。

J2EE
エンタープライズエディション
EAA
エンタープライズアプリケーションアーキテクチャ
EIP
エンタープライズインテグレーションパターン
ESB
エンタープライズサービスバス


私は、自分の専門分野は、ソフトウェアシステムの中でも、エンタープライズ分野、であると自負している。

マーチン・ファウラー、かく語りき


著書、PoEAA ( エンタープライズアプリケーションアーキテクチャ ) の「はじめに」で、マーチンファウラーは、エンタープライズアプリケーションの意味を説明している。
明確に定義できないし、人によって使い方がいろいろある、あいまいな言葉。
私としては、このマーチンファウラーの説明が、いちばんしっくり来ている。

最初の段落の以下の2点にすべてが要約されている。
  • 複雑なデータに対処する
  • (論理的とはいいがたい)ビジネスルール


エンタープライズアプリケーションの関心事は、「データ」と「ビジネスルール」というわけだ。

永続データ、たくさんのデータ、同時データアクセス


データの問題を、三つの視点から、とりあげている。

永続性


ビジネスは、情報の記録と保管は、基本中の基本。アプリケーションソフトウェアを入れ替えても、既存のデータは「移行」して使い続ける。

たくさんのデータ


ビジネスで扱うデータは、どんどん増えている。なんでもかんでも、電子化・デジタル化の時代。
インターネット時代では、顧客のワンクリックまで、記録して、永続化する。
こういう膨大なデータを効率良く扱うのがエンタープライズアプリケーションの、重要な関心事。

同時データアクセス


これも、ネットワーク時代になって、加速している問題。
同じデータに多くの人が同時にアクセスする。同じデータを同時に書き換えることも起きる。
これをどうやって、うまくさばくか?

RDBMS と SQL


永続化、大量データ、同時アクセスを実現する技術としては、いまのところ、RDBMS と SQL が基本の技術。
RDBMS/SQLの使った、良い実践とはなにか? 良い設計とは? 良いアーキテクチャとは?
これが、エンタープライズアプリケーションの重要な関心事の一つ。

多くのユーザインタフェース画面


エンタープライズアプリケーションとは、極端に単純化すると、データベースを、CRUDするもの、と定義できる。

データの種類や量が多いということは、CRUDのための画面も多いということ。
また、いろいろなビジネス上のルールがあるために、ユーザによって、「できる・できない」「見える・見えない」を変えなきゃいけない。
Web アプリケーションを顧客に使ってもらうとなると、顧客ごとに、さらに、カストマイズした画面が欲しくなる。

検索フォーム・一覧・入力フォーム。基本はきまりきった単純な形式しかないのに、とにかく画面数が膨れ上がる。
どうやって、これを簡単に開発するか?
変更要求があったときに、どうやって、安全・確実に変更を適用するか?

電子メールというユーザインタフェースもいろいろ必要。
携帯電話や、PDA 用も。

画面の爆発です。
でも、ユーザにとっては、画面こそ、画面だけが、システム。
ここが、がんばりどころとなるわけだ。

バッチ


バッチ処理も忘れちゃいけいない。
ビジネスでは、日、週、月、四半期、半期、年度、というサイクル構造(=バッチ処理のタイミング)は、強固な枠組です。

他のエンタープライズアプリケーションと統合


あちこちで、爆発的に、ビジネスデータの電子化が進んでいる。
それも、同時多発ゲリラのように、さまざまなデータ形式、実装技術でやまほどエンタープライズアプリケーションが作られている。

社内だけでもたいへんなのに、最近は、ネットワークのおかげで、社外とのシステム連携も、日常的な課題になってきた。
ビジネス活動とは、人と人、組織と組織の相互作用。だから、ビジネスの道具である、エンタープライズアプリケーションも、他のアプリケーションとの連携・相互作用が必然。

しかし、...。
実装技術、データ形式、通信プロトコル。ハードルがやまほどありますね。
見ず知らずの開発チームと共同作業なんていうハードルもある。

概念の不一致


でも、統合の一番の難敵は、それぞれのシステムの「データ」の考え方が違うこと。

ビジネスルールは、いつも変化している。ある時点で造ったアプリケーションとデータは、その時点のビジネスルールの「スナップショット」を反映しているだけ。
社内システムといえども、アプリケーションごと、データベースごとに、異なる考え方を実装したもの。

他社のシステムとの連携ともなれば、根本のビジネスの考え方・決め事がまるで違っているのがあたりまえ。

ビジネスパーソン同士でも、いろいろなすり合わせを行い、契約書や合意書をやまほど積み上げていく。
でも、人同士だと、まだ融通が効く。

エンタープライズアプリケーションという融通の効かないモノ同士の連携は悪夢に近い。
昔のビジネスルール、部分的なビジネスルールを、がちがちに、変更不能な状態に組み込んでしまった「ソフトウェア」(どこが柔らかいんだ!)。

ビジネスロジック


これは、パラドックスです。

ビジネスロジックとは、ロジカルではない。

関係者があつまれば、だいたいの約束事は把握できるけど、緻密に、論理的にくみ立てられたものではない。
ヒアリングすれば、誰も説明できないルールがでてくるのは、みなさんご存知の通りです。

唯一の真実は、「ビジネスロジックは変更される」こと。

どんなにがんばって、その時点でなんとか整理したビジネスルールを実装しても、それは、たんなるスナップショットであり、ある一面のビューにすぎない。

実装してテストしている間に、業務の現場では、別のルールがいつのまにか常識になりつつある。

だから、どうする


格闘すべきテーマは、単純といえば単純。

最初に書いたように、
  • 複雑なデータに対処する
  • (論理的とはいいがたい)変化し続けるビジネスルール


この2点を効果的に実装する、実践的な技術、良い実践ノウハウ。これが、エンタープライズアプリケーションを造るエンジニアのもっとも重要な関心事であり、スキル。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
    123
45678910
11121314151617
18192021222324
252627282930 
<< June 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM