出差在連雲港，簡單說說由項目引起的

       流程在百科的解釋是多個人員、多個活動有序的組合。它關心的是誰做了什麼事，產生了什麼結果，傳遞了什麼資訊給誰。在我的第一條流程中涉及三種角色（平台使用者、程式管理工程師、處室負責人），有五個以上使用者參與的活動，在流程的末端還會依據條件調用其他流程。

       實現之初最耗人的是從關於我這條流程的需求文檔中挖掘出實現此流程所需的資訊和理解IBM內部的架構（Cairngorm的一個代替品），同高需求的人員是接受流程之處不可或缺的一步，要反覆從他們口中擷取軟體的真實模樣、實現的真實思路。

       搞開發需求明朗後再去動手開發，否則需要很大程度上的反攻，當然為了理解，不阻止做lab哦。瞭解架構和系統架構需要些時日，來了十幾天，大概對怎麼使用此系統所有架構和架構有所熟悉了。

       什麼是軟體架構，軟體架構師又要做些什麼呢，在此引言。

      “軟體架構代表了系統的組織圖。這包括將系統分解為不同的部分、界定它們之間的串連、確定它們之間的交換器制、並且為後續的設計提供指導性的原則”——三個火槍手

       ”一個軟體系統的架構師是一個要擔負起軟體系統的定義、架構的實現、系統的實施、系統架構演化和系統演化的人。換句話說，是一個要為系統整個生命週期負責的人。”

       當然來到這發現好多做架構的，你可不要認為都是做軟體架構的，在不同場合可能會遇到不同的架構師——解決方案架構師、系統架構師、軟體架構師、企業架構師、首席架構師、Java架構師、微軟架構師及.NET架構師等等。

       當然來到這聽說IBM有很多架構師是不懂開發技術的，但我認為軟體架構師是一定是要從開發人員走來的，要有開發大專案管理大項目的經驗。

       當然我們在設計軟體的時候，也許會使用一個通用的架構，會買另一家公司的工具，但是如《No Silver Bullets》一書所言——世上沒有萬能的解藥，很多時候我們使用通用的架構（如J2EE、CORBA等）或架構是不能解決或不能最合適的解決我們的問題的，作為一個架構師應該自己動手解決問題。

      現在這個項目組的架構師，是精通Flex的，他做的架構和代替Cairngorm架構雖然目前還不能很好的理解，但是至少這些是我看到了一個架構師在努力為一個項目思考，而不是現套現搬。當然在項目中不使用已成熟的產品或工具也是不明智的，如此項目使用到了JPA項目等。

         最後再胡亂說幾句，但莫一笑置之。

         程式要要敢於大膽猜測，仔細調實驗證，要不斷最佳化代碼

         架構師要做的包括保證項目編程風格的可控性，提升團隊開發效率，保證需求變更的可調性

         客戶的需求是時常變化的，而且隨著開發的深入，客戶的需求可能會爆炸式的增長。原定的需求是也許是一個桃子，但當把桃子做的差不多時，客戶可能會突然感覺到自己原來要的是西瓜。

         要做最主要的事情，看清哪個是甲方最急切需要的.

         大項目很難一下都上線.