[Japanese Only] RestかSOAPか

f. y. i.
3.8 Web 2.0時代のWebServices 〜SOAP/REST使い分けの指針
（非常にわかりやすくまとまっています）

以下は個人的な見解で恐縮ですが、
取り出そうとするデータの構造が、階層構造(ファイルサーバみたいな)に
なっているのであれば、URL表記で取り出せるRestが効果的だと思います。

ただ、データがリレーショナルDB内にある場合は、URLとリソースを
対応させるのは、大変そうな気もします。こういうケースだと、SOAPの方が
向いているように思います。

企業向けの情報システムの場合、データはリレーショナルDBに入っている
ことが多いので、SOAPの方が基本的には利用機会が多いのではないかと
思います。携帯でWebサイトを見るときに、画像データを取り出せるWeb
サービスを作るのであれば、Restが向いているかもしれません。

どちらも単なるツールなので、適材適所に使えばよく、ドグマのように
のめりこむものではないと思います。

ロジカル・シンキング、どうやって使うの？

MECEするには時間が足りない

MECEの概念はよくわかるのですが、実際の仕事で、関連する情報を網羅的に整理することは、まず不可能だと思います。支払われる対価に対して、時間が足りません。

どこかで線を引くわけですが、線引きの基準が難しいですね。とりあえず、その場のプレゼンで突っ込まれないレベルで線を引けば、その場は切り抜けられるかもしれません。しかし、それだとただのその場しのぎですよね。

「情報が不足している中で、いかに妥当な判断を下していくべきか」というノウハウの方が、実際には価値が高いのではないかと思います。恐らく職種や業界に依存したノウハウになるので、汎用性は低く、ビジネススクールでは教えにくいかもしれませんが。

ロジックツリーも時間が足りない

ロジックツリーなるFTAのような木構造を作るらしいのですが、ツリーを作る上で因果関係を見出さなくてはなりません。

相関関係のように、比較的容易に発見できる関係ならまだしも、因果関係の証明はかなり困難です。直感的に発見するのでしょうか？ほとんどエスパーになることを要求されているように見えます。


ずばぬけて頭が良い人なら、情報を短時間ですべて収集し、因果関係を一瞬で見抜けるのかもしれませんが、私には少なくとも無理そうです。経験的にわかっている主要因と因果関係を頼りにする方が、確実性が高いように思います。

帰納的によりすぎるのもよくないので、こういった休みのときに、演繹的なアプローチを勉強します。しかし、ロジカル・シンキングは前提に無理があり、実際の仕事に取り入れることは難しいように感じました。広く世界で使われているんだろうか？・・・その場合、どうやって活用しているのか、興味があります。

あまりBPMに関係ないエントリですが、ちょっと気になったので。。

Now Arrived! BPMN Method & Style 2nd Edition

3年前に読んだ1st と比較しながら、年内には内容を把握したいですね！
・・・いままさにBPMNを描いて仕事をしていますが、なかなか完全な方法に着地できません。
まだまだ、いろいろと考えながらやりぬきたいです。

Automated Process Discovery

f. y. i.
Automated Process Discovery : Fujitsu Global

Interesting approach. I guess it is particularly good for ABC.
However I am afraid we can find not business processes but system processes with it.
Often, top-down processes definition will be also needed, I think.

[Only Japanese] Constraints of Fabless and Enterprise IT Systems ファブレスの条件と企業向けITシステム

あまりBPMに特化しない内容ですが…

半導体など、製造業で見られるファブレス(fabless)という概念があります。

■ファブレス

企業向けITシステムの言葉に翻訳すると、いわゆる上流工程（構想立案〜要件定義〜基本設計など）に特化して、下流工程などは外注して済ませる業務の形態と説明できると思います。

こういった、企業が工程ごとに特化する現象は、他の業種（建設業とか）でも、しばしば見ることができます。

企業向けITシステムの世界では、一時期（いまも？）、オフショア開発という形態が流行しました。これは、下流工程を中国など日本よりも人件費が安い国に外注することで、コストを圧縮する手法です。もともと、企業向けITシステムというのは利益率がそれほど高くない仕事です。パッケージ導入など原価を下げる手法の一つとして、オフショア開発が挙がっていました。オフショア開発は原価を下げられる一方で、それなりのリスクもある手法でした。日本での業務をファブレスと考えると、オフショアした業務はファウンドリ(foundry)と言えるかもしれません。

私はファブレスについて、積年の疑問を持っています。ファブレスという概念は理解できるものの、この手法を使うと、下流工程のノウハウが吸収できず、「一昔前の」下流工程の技術を前提とした形でしか、上流工程の専業は成り立たないと思うのです。

私の個人的な知人に、ファブレスという形態で仕事をしている方がいます。この方に聞いてみた結果も、「あくまで下流工程は枯れきった技術しか使わず、上流工程は意匠またはユーザーの利用シーンに関するアイデアで勝負する」というものでした。

下流工程の技術革新が起こらないか、あるいは既存の改良にとどまるのであれば、ファブレスという考え方も有りかもしれません。しかしながら、企業向けITシステムの世界では、全工程を通して既存の手法を改良するアプローチが、しばしば登場します。企業向けITシステムにおいて、ファブレスという形で勝負するのは、それなりにリスクが高いのではないでしょうか。

この積年の疑問を、解決したい。

BPMgeek

f. y. i.
BPMgeek


■近況
　BPMで忙しい！うれしいような、疲れるような。。

What is Loose Coupling in SOA?

I was often confused when I heard Loose Coupling in the context of SOA.
"What is Loose Coupling which you use?"

I think there are at least three major contexts of Loose Coupling.

#1 It means a low dependencies among business applications or entities. it will be achieved by the domain decomposition.
(Data Architecture)

#2 It means a low dependencies among program codes or classes and objects. it will be achieved by the separation of concern and the object oriented programming.
(Application Architecture)

#3 It means an asynchronous integration among systems. it will be achieved by the message queueing technology.
(Infrastructure Architecture)


I guess there are a lot of other contexts such as a cloud computing or design technique for re-run, idempotent...
Don't be so difficult. Please let me know Loose Coupling which you mean.

EPCとBPMNの違い - What is the difference between EPC(EPK) and BPMN, in Japanese.

f. y. i.
[BPMN] BPMN Method & Style ― 所感その１
BPMN Method and Style
EPC vs. BPMN - the perfect flamewar

EPCとBPMNの大きな違いは、そのカバー範囲です。
　EPCは業務プロセスと、その周辺情報を整理するために、複数のモデルを伴って利用されます。
　BPMNは、業務プロセスの文書化、自動化、定点観測をするために、それ単体で利用されます。

BPMNには、下記のような特徴があります。
　BPMNの適用領域は、業務の運用的な側面（オペレーション）です。言い換えると、業務の定形的な部分が対象です。
　BPMNはITシステム化を前提とすることができるため、より厳密な記述をすることが可能です。
　（一方で、厳密さを追求すると、回路図のような記述となり、可読性は低下します）


適材適所で、使っていきたいですね。。

We Can Study SOA in ARIS

f. y. i.
Modelling Method Extension for Service-Oriented Business Process Management

Excellent thesis!

BPMN 2.0 Conversation and Choreography Diagram

A while ago, I thought that I know BPMN 2.0 because I had read BPMN Method and Style.
Sorry, it was not enough. BPMN 2.0 has more very good ideas such as Conversation Diagram and Choreography Diagram.
This entry describes my expression about these two diagrams.

* An overview of both Conversation Diagram and Choreography Diagram is confirmable in ARIS Community.
See Learning BPMN 2 - Which models are available in BPMN?


1. Conversation Diagram

The concept of Conversation Diagram is good. However, I was deeply impressed from the relationship between Conversation Diagram and Collaboration Diagram.

* This great relationship is described in Merging Collaboration and Conversation, slide 6 and 7.

It provides more useful structure of business processes. We can make structures from not only activities (sub-process) but also orchestrations. I think it is very strong feature to achieve BPM solution.


2. Choreography Diagram

I think it is a retro feature. We can use it like BPEL with Collaboration Diagram.

* This interesting example is described in BPMN 2.0 Modeler for Visio, page 3.

BPEL like diagram is different from BPMN Collaboration Diagram. However, I guess the diagram will be easier for IT engineers because it shows interactions between people and BPM system. In BPMN Collaboration Diagram, there is no participant who named BPMS. I am usually afraid that BPM Collaboration Diagram is easier for business users but perplexing for IT engineers.


There is always more to learn about BPM. Thanks.