Is Enterprise Architecture Suitable for Small Businesses?について

InfoQの記事です。

  1. Is Enterprise Architecture Suitable for Small Businesses?

TOGAFに代表されるようなEAは大企業だけが必要なのか、中規模や小規模の企業ではどうなのか、という疑問に関する記事です。

中規模や小規模の企業がTOGAFで説明されていることを全てやっていてはビジネスが成立しないことは明らかです。 従って本当に必要なところだけをライトウェイトに取り組むのが正しい選択ということのようです。 記事の中の引用で、これくらいは、と言っている要素を再度引用すると

  • ビジネスアーキテクチャ
  • 3-5 年にわたるビジネスロードマップ
  • ポートフォリオ管理(何時どのような仕事をするかの優先度づけ)
  • 各種利用技術(インフラ、情報、他)

とあります。 ビジネスアーキテクチャにどこまで含めるのかというのが気になりますが、それは必要なものを自分で選択しなさいと言っているような気がします。 最後の項目ですが、例えばクラウドを使うということにすると、結構楽が出来るかもしれません。

    Is Enterprise Architecture Suitable for Small Businesses?について

    Apps.govについて

    昨日から話題の Apps.gov ですが、沢山のコメントや記事が出ています。 まだご存じでない方のために一つだけ引用します。

    1. Government eyes big savings with first cloud service

    実際のサイトを見れば分かりますが、政府機関向けのクラウドベースアプリケーション購入サイトといった様子です。 政府なのでセンシティブなデータばかりを扱ってるということもないはずであり、そういう部分についてクラウドベースサービスを使うのは予算削減(税金の無駄遣いを避ける)という意味で良い方策だと思います。

    日本で同じことが出来るかですが、技術的には可能ですがメニューが揃わないだろうなと思います。 それに、外部のサービスが利用できると言っても、最終的には自前の部分を含めて統合する必要があり、それなりのSI的作業も残されています。 そういえば、Salesforce.com 社の AppExchange という類似サービスがありました。 近いと言えば近いですね。

    Apps.govについて

    only one percent turned off by SOA so farについて

    ebizQの記事ですが

    1. Forrester’s Randy Heffner: only one percent turned off by SOA so far

    というのがありました。 ForresterのRandy Heffnerさんの書かれたレポートと彼との電話インタビュー(上のページから再生も可)に基づく記事です。 私にも以前Forresterのレポートを読むことが出来た時期があり、その頃の印象としてもRandyさんのSOAに関する意見は大抵納得できるものでした。 この記事の中身はタイトルが全てを語っていると思いますが、時間のある方には是非インタビューを聴いて頂きたいと思います。

    only one percent turned off by SOA so farについて

    Separation of concernsについて

    Separation of concerns という言葉があります。 Wikipediaでは次のようになっています。

    1. Separation of concerns

    複雑な系を分割し扱いやすくするための手法かもしれません。 しかし Concerns の種類はどの程度が良いのでしょうか? RM-ODP (5)、RUP (4+1=5)、UMLのダイアグラム(14種類)、Federal Enterprise Architecture の Perspectives の数(5)、と5という数字が多い(マジックナンバー?)のですが、下は静的と動的(または構造と振る舞い)の2から上はUMLの14あたりまで行くのかもしれません。

    先日このような話をネタにしてちょっと発表をしてきました。 Separation of concerns で対象物を幾つかの Concerns に対応する記述に分割したとします。 これらは独立しているようですが、所詮は同じものを別の角度から見ただけのものですから、相関があります。 例えば、建造物を作る際の設計図ですが、正面図/平面図/側面図と3方向から見た図を書きます。 建造物の屋根のてっぺんを想像すると、正面図では一番上、側面図でも一番上、平面図だと上から見たところなので図面の表面にあたる部分、というようにつながり(相関)があり、これを認識しないと建てられないのではないかと思います。 ITシステムの場合でも、記述物の間の相関を何らかの形で表現して全体としての整合性を示す必要があります。 この時に、例えばビジネスに関する関心事に基づいて仕様(モデル)を書こうとすると、実は世の中に何種類もの標準があり、ビジネスモデルには何種類ものモデリング言語が含まれる可能性があることが分かります。 ビジネスプロセスのBPMNもその一つですし、SoaMLもそうかもしれませんし、Business Motivation Modelも入ると思います。 発表の結論は次のようにしました。

    1. 一つのConcernに対応した仕様の中に複数のモデリング言語を使うことは避けられない。その仕様の中での整合性を確保するのは仕様記述者の責任として、その仕様の一部として多くの内部相関記述は含めないようにする(使用するモデリング言語の数が増えると対応出来なくなるため)
    2. 相関記述にはUMLを使う。非UML言語の場合、最適なUMLとの対応付けを模索するか、無理な場合にはコメント(Annotation)で関連付けする。

    これは前に進めるための中途半端な結論ではありますが、結論より問題意識を共有したかったということです。

    今度発表の機会があれば何かデモ出来るものにしたいと思っています。 やはり分かり易いものでないと、聞く側も話す側も疲れますから。

    Separation of concernsについて

    Web OSについて

    Web OSについてのまとまった記事がZDNetにありましたのでご紹介します。

    1. How the Web OS has begun to reshape IT and business

    これまでWeb OSというと、デスクトップにクラウド上にある別OSのウィンドウがあるというイメージのものでしたが、上に引用した記事ではWeb OSをかなり広い意味でとらえています。 まずその点にご注目下さい。

    Web OSについて

    Using the 20% of UMLについて

    UMLの利用についての興味深いブログポストをみつけました。

    1. Using the 20% of UML

    ここでは Three Amigos の一人 Ivar Jacobson さんのブログポストを参照しながら、ビジネスソフトウェアを開発する際に実際 UML の20%程度しか使わない(必要としない)という主張をしています。 次が引用しているポストです。

    1. Taking the temperature of UML

    UMLはその成り立ちから開発手法が標準の外側に置かれており、表記法とその意味付けを中心に標準化されたものです。 従ってどのような開発手法を使うかにより、どのUMLダイアグラムを中心に使うかが変わってきます。 クラス図はどのような開発手法でも使うと思いますが、Essential UMLというUMLの共通サブセットが存在するのかどうか疑問です。 しかし、何らかのUMLサブセットを取り出してそれをベースにモデリングから開発を行うことはありそうですので、現在のUML Profileのメカニズムとは異なるプロファイリングのメカニズムがあっても良いのかもしれません。

    Using the 20% of UMLについて

    Enterprise Architecture Pitfallsについて

    elemental links (Brendaさん) の enterprise architecture についての議論です。面白いのは Twitter を使ってブログを読んだ人々の反応を集め取り込んでいる点です。

    1. Enterprise Architecture Pitfalls (Crowdsourced version)

    こんなに Pitfalls があるというのは、実際のところ EA を成功させるのが容易でないと宣伝しているようで複雑な気分(今日の日本語では「微妙」?)です。読み方次第ですが。

    Enterprise Architecture Pitfallsについて