Wednesday, 16 January 2008

BPM, A Peel Of SOA And The CIO Filter Syndrome

Jim Sinur kicks an open door and expresses the current general ideas around BPM and SOA in "What is the Nature of the BPM/SOA Codependence?"

I think in many ways the views expressed in that post are too limited and I'll sketch where I would like to see a broader vision. Since the tenor of the post is very representative for todays generally accepted viewpoint, I'll discuss that general viewpoint, even when it goes a bit outside this post of Jim.

In the BPM section, he describes that a human task that doesn't require a lot of thinking can be considered a candidate for automation:
There is another class of work that revolves around human activity where the knowledge level is not as intense and revolves around workflow-like activities. This work has also eluded automation at the level that a service would be needed.
The fact that the word 'service' is used bothers me. As if there no other forms of automation then a service. This particular phrase is an example of a broader mistake that I see with business level people talking about software. Their view seems to be limited to BPM and SOA only.

This is what I would call the CIO level filter. The CIO level filter only lets those parts of software development pass that can be understood by business people. BPM and SOA, but also rules fit into that category. Executable business processes and executable rules are in essence pieces of software. These languages try to create a representation that are understandable by non technical people. That is how they should be treated. All too often, non technical people tend to forget about the software nature of executable business processes and executable rule bases and discuss them in the plain english interpretation.

I believe many BPM folks miss insight on general application development to talk about software architectures. In my opinion, applications are developed in silos. Connectivity between application silos is enhanced with the typical SOA, WSDL, WS-* armoury. But BPM is much broader applicable then only on top of services.

There are many forms of process languages. Some of them like BPEL are only targetted at the services level. Others like jPDL are targetted to be used inside application development. So my point is that business processes, in the business sense of the word, translate over many layers of the software architecture, not only the services layer. Some business processes might be implemented on the services level only, in which case BPEL is a good candidate. While other business processes might be implemented as part of a Java application, in which case jPDL is a better option. Other business processes might be easier to implement in plain Java code.

Executable process languages come in different flavours and different habitats. The choice of executable process language should be a technical one. A company can manage their business processes better and more agile by leaving the choice for the process language to the technical team. All too often I see situations where the technology is selected upfront.

On Jim's SOA part, there is another occurence of what I would call the CIO filter syndrome:
The power of the SOA architectural approach is that it enables autonomous subsystems to be assembled into entities (SOA applications / processes ) that can be as cohesive externally as applications built with older architectural approaches (classic components, modularization, or object-oriented paradigm).

The benefit of SOAs over these older approaches is increased agility and greater tolerance for change throughout the life cycle of a system, especially compared with a system that assumes tight coupling and homogeneity across the subsystems.

I agree with the message that an SOA is all about increasing connectivity between loosely coupled components. The interoperability of WS-* infrastructure that is available today helps to simplify and speed up the connectivity problem. But that doesn't take away the applications at the end of the connectivity need to be build and developed. When building applications, tight coupling is a blessing. Without typesafety and refactoring, application development would take considerably longer. Without synchronous method invocations as in Java, applications would run infinitely slower.

So it's not new versus old. It's loosely coupled versus tightly coupled, knowing that inside an application silo, tightly coupling has great advantages. So I think that application development is as relevant as it was before, the only thing that was added recently is a set of standard technologies with which you can easily put a peel of SOA around your applications.

This still leaves the difficult task of the software architect to define what functionality is build in which application and what interfaces will be exposed to the SOA connectivity layer.

In summary, the CIO filter syndrome is that non technical business people try to come to conclusions about software architectures by only looking at the languages and parts of the architecture that they understand. Try to avoid it :-)

1 comment:

  1. 1
    秋天賞楓何處去酒店經紀,安排韓國旅遊有獨到心得的寶馬旅行社表示 酒店打工,秋遊韓國的重點就是美食、溫泉、還有雪嶽山美麗秋景。位於江原道 酒店兼差束草、襄陽、麟蹄一帶的雪嶽山,是韓國最早楓葉轉紅的地方,也由於雪嶽山一年四季都有奇岩絕璧 酒店兼職
    、溪谷瀑布等美景,吸引了許多觀光客前來旅遊。一到 酒店工作秋天,以雪嶽山的最高峰~大青峰(1,708公尺)為首,雪嶽山各主要登山路線沿途的楓葉把山染 酒店上班成一片紅色的圖畫,美不勝收。

    標榜「全程無自費」,相當受旅客歡 寒假打工迎,而且價格相當平易近人,只要14500元即可成行。另外還有全程五星酒店、海陸空版的「戀戀秋濟^海陸空濟州4日」 暑假打工,同樣獨家全程無自費!緊張刺激360度噴射快艇(價值韓幣25000元)、飛天熱氣球(價值韓幣25000元) 酒店PT、海水溫泉汗蒸幕(價值韓幣8000元) 禮服酒店等,海、陸、空讓您玩的盡興也只要13900元!現在就去體驗韓國秋天的美景吧~

    驚險摩托車秀HAPPY TOWN 兼差價值韓幣12000元):表演者以機車為主,靈活的玩弄, 打工全世界只有兩組特技人員能做的高難度表演,在一個小時的演出中還有空中飛人﹑民俗雜技和大車輪 台北酒店經紀等表演,保證讓您大呼過隱,不虛此行喝花酒 特技令人嘖嘖稱奇。而享譽全球的國寶級亂打秀(價值韓幣45000元),是韓國人獨創的敲擊樂表演,故事的場景是發生在廚房中,因此所謂的樂器就是就地以鍋碗等廚房交際應酬 用具敲 打出澎湃的節奏。在沒有冷場的過程裡,不需要語言您就可以清楚知道劇情粉味的發展,台上演員還會與台下觀眾互動演出,整場歡笑不斷。

    去過的旅客都津津樂道的酒店喝酒韓文化生活體驗營」,讓您親手體驗泡菜製作,穿著傳統韓服更能體驗韓國婦女的優雅!另外,精緻好吃的韓國美食當然也不能 酒店不嚐:鮑魚太極人蔘雞、長壽麵、、黑毛豬烤肉、還有獨家特色餐「?花魚定食+五花肉+鐵板馬肉+?料」「生猛海鮮大餐」等等讓人食指大動。酒店經紀酒店經紀酒店兼差酒店打工酒店上班酒店經紀酒店小姐酒店打工酒店兼差 酒店工作> 彩妝指甲彩繪口紅彩妝馬甲美白