上上個星期，應國防某單位要求，希望由我們利用 EA(Enterprise Archiect) UML 工具，藉由一個案例，來展示在順應 DoDAF 規格下，如何從架構規劃、到依循每一個包括 Operation 與 System View 的設計圖，以及又該如何導出到實作，尤以後者，對他們很困擾，一直不知道該如何將 DoDAF 設計與實作順利地橋接在一起。

其實原來是上個月初過去介紹的是 EA 的 UML 工具，因為 EA 其中一個 Plugin 產品，稱為 MDG for DoDAF-MODAF，兩者的搭配，應用的是 UML Profile 機制，可以充分完整支援 DoDAF 1.5 的設計規格。 說真的，工具沒啥好介紹的，況且席間諸多長官與教授們問最多的問題就是有沒有 "自動化" 的機制，可以從某一個 View 的設計圖，自動轉化到另外一個 View 的設計圖。這個... 我總覺得他們研究的方向會不會有問題？ 我只能反問：1. 如果規則明確，例如 OV-2(作業節點連結) 轉 OV-5(作業活動流程)有很明確轉換規格的話，那麼工具當然可以支援。 (可想而知的答案是，當然沒有那種必然明確的規則) 2.能不能轉到程式碼？ 這些我都覺得都不是問題耶，前提是有沒有那種確定的規則？ 有趣的是，他們用來比較 EA UML 工具的是另一套 T牌、要價 100 萬的工具，也沒有支援他們 "心目中" 的自動化啊。 所以我開玩笑的說，好吧，把那個 T牌與 EA (EA+DoDAF Plugin 才 1萬初頭)的差價，用來委託我們開發那個自動化的 Transform 機制，保證可以幫你們生的出來，不過前提是要能給我們明確的轉換規則。 :-)

我可不會想賺工具的錢啦，要能懂得設計符合 DoDAF 架構規格的系統，要具備的是軟體設計基礎功夫的底子；要能有整體性的架構觀，要知道什麼時候該封裝、什麼時候該打開，分析系統的內部；要懂得如何把一個看起來好像很大的系統(關於系統的定義，可不一定指軟體系統，在這種大格局下，包括企業單位，都可能是一個系統)，該如何大題小作；又懂得那個時候該具焦在某一個焦點上，然後小題大作。 這一種整體性的設計思維，正是架構規劃與設計箇中的竅門之所在。

我想要傳達的是，我們可以協助國防某單位，如何具備能具有規劃 DoDAF 架構設計的技能(Skill)，與相關軟體設計的基礎功夫，以及所該具有的技術實作能力。當然就是以顧問輔導與教育訓練為主，如果可以的話，規劃成一個外包的專案更是好，然後從實作的過程中帶著學習，作中學的效果會更好的。 不過前提是，我們總是要能先證明我們懂得如何規劃這類超大格局符合 DoDAF 規格的系統，一般當然就是出個題目了，這一向是我個人最為意願的了，比較容易在短時間內取得雙方之間彼此的信賴與共識；也比較現實，會就會，不會的話早一點出局，最不囉唆了。 喔，還有，這是繼我十餘年前從志願役中尉預官退伍後，再一次能回到軍中，為國效勞的好機會呢，哈。

由於國防某單位最近忙了些，等了幾星期，還是沒拿出案例讓我們來演練，所以只好我們團隊內部自行構思一個與軍事相關的案例。 所以呢，這個案例是沒有與軍事任何單位有關連(正因如此，才能拿出來公開分享)，完全是充滿想像；也沒有軍事專家的協助，所以需求必然是謬誤百出。不過這也不是什麼困擾，因為我們要做的是如何能捕捉出 DoDAF 的架構規劃與橋接到實做階段的那個精髓之所在。只要未來能有軍事領域專家的協助，那麼就很容易可以調整修正，來符合正確的需求了。

整整花了四天的時間，投入了約 2.3 個人力，以一個我們所想像創造出來的案例，也算是規劃了一個類似 C4ISR(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) 的聯合作戰指揮系統，透過偵測與防衛系統，發現到敵人即將進軍來襲時，是如何即時協同陸、海、空三軍暨後勤補給中心，來達成防衛作戰的目標。 包括了 Operation、System View 共約 17 張設計圖、再加上利用 .NET 程式碼來模擬諸多系統間的即時互動(透過 Web-Service)。 喔，甚至連那個表達 OV-1 的概念視圖，都還是請美工畫出來的呢，效果十足！ 老實說，個人對我們團隊能在如此短的時間內，就能規劃出如此大的架構格局，甚至還產出程式碼來驗證架構的完整性。藉此而能解開 DoDAF 這個算是軍中資訊人員們的 "潘朵拉密盒"，可說是成就感十足，也算頗引以為傲。

圖 1、 利用 EA-DoDAF 開發的 SV-1 設計圖

所完成的案例在上上星期至國防某單位的 Seminar 展示效果相當不錯！ 在座許多高級長官以及教授們在會後的許多問題透過我們的解說，也算能得到合理的解釋。也讓許多中、上尉的資訊官們，見識到我們是如何從某一些 View 再轉到微觀(Micro)的實做階段。 由於沒有軍事機密等的問題存在(案例全都是想像的)，所以到是可以藉由公開發表這一個案例，除了展示是如何實現 DoDAF 規格，並大概解釋一下每一個 View 的 精要(essential)設計意涵為何，同時也算是藉由此，來看看這種偏多個節點(Node)、多個資訊系統是如何做架構規劃的。

對了，還是要簡單說明一下 DoDAF/MoDAF 架構框架到底是幹什麼呢？ DoDAF(Department of Defense Architecture Framework) 是美國國防部、MoDAF(UK Ministry of Defence Architectural Framework) 則是大英國協軍方的規格。 其目的旨在規範承包包括武器、資訊技術系統等的外包廠商，透過多個層次的角度(Multiple Views)，能夠以標準化、一致性，來組織包括企業架構(Enterprise Architect)，以及系統架構(System Architecture，這裡意指資訊系統)，而能有具標準、一致性、多層次的設計視圖與文件等符合軍事要求的規格。 DoDAF/MoDAF (因為國軍主要仍以美軍的規範為主，所以整個架構規格，均以 DoDAF 為主，但其實兩者的規格差不多)的規格是公開的，可以自由下載來研究參考的，下列鍊結提供了這些規格的說明與下載位置：
　o DoDAF Wiki。
　o MODAF Wiki。
　o DoDAF 1.5 Volume 1(pdf)。
　o DoDAF 1.5 Volume 2(pdf)。
　o DoDAF 1.5 Volume 3(pdf)。
　o DoDAF 1.0 Deskbook。

至於關於如何使用 MDG for DoDAF/MoDAF Plugin (前提是要先安裝 EA UML Tool)，參考 這裡。
安裝完這個 Plugin 的好處是可以看到完整的 DoDAF 案例。(雖然我覺得裡面有些視圖的設計不太正確，但還是需要參考這個工具所提供的案例，才能知道如何使用 EA 工具來規劃設計。)

圖 2、 EA-DoDAF 所提供的 DoDAF 樣版(Template)

DoDAF 主要包括了兩個大層次： Operation View and System View。 Operation View 包括從 OV-1 到 OV-7； System View 包括從 SV-1 到 SV-11。 在我們所演練的案例內的設計產出擷取部分精要的設計視圖，參考下面兩個表。

我想爾後就會針對我們所設計每一個 View 的設計視圖，來簡單地說明該視圖的設計意涵為何。 另外，我們並沒有表達 TV (Technical View)，主因在於這個 View 幾乎都只是表達技術規格的詳細文件報告而已。

對啦，一個有趣的問題可以思考看看。參考一下底下這張是給指揮官層級看的概念視圖(OV-1, Conceptual View)。考驗一下，作為一個架構師(Architect)，看到這張圖的時候，是否可以腦海中馬上浮現，可以如何以 UML 2.0 規格中的那一張設計圖來設計表達呢？ (提示一下，即使從如此大的概念視圖，也要能看得出你要規劃的系統那個整體(Whole)是什麼？ 誰會觸發這個系統的反應？ 這個系統有無外部系統的支援？ 系統內部的組成主要結構元素為何？ )

圖 3、 EA-DoDAF 範例中的 OV-1 概念視圖

老實說，在我試用過眾多時間管理的工具中，無論是 GTD-based or not，Desktop or Web-based。我還是覺得，FranklinCovey 的 PlanPlus 是目前個人心目中的首選工具。 那為何我不使用它？ 一來我覺得該產品有些小貴，從早期只是紙本的萬用手冊開始，就比一般的萬用手冊貴上數倍許多，這讓我挺反感的，貴上一些代表著創意智慧財產的象徵不為過，但若是貴上數倍，那是暴利，說難聽點是在坑錢，而不是旨在推廣理念了； 再來我已不使用 Outlook 了，況且它與 Outlook 的整合仍有些 Bug 存在，而該公司的軟體開發技術能力看來不佳，推出 Patch 或新版本等，總是慢吞吞的。雖然它有另外一套 Standalone 版本，但同時也是一套完整的 PIM (Personal Information Management) 軟體，這我不要，我只需要時間管理所需要的機制即可，因為 PIM 中關於聯絡人資訊、行事曆與電子郵件等，我已轉為使用 Google Gmail 的工作環境了，簡單方便、可攜性佳，也不需要作備份等管理工作，好處多多。自然，我也就希望 時間管理工具 的選用是以 Web-based 的形式呈現的。

我會以為，時間管理只有兩個最基本的元素： 行事曆 (Calendar)與工作 (Task)。 再怎麼功能強、複雜的時間管理工具，都不會脫離出這兩個最基本的元素。 行事曆讓你可以看到與規劃何時有 Meeting，以及要做的事情；而工作項目 (Task Item)則是讓你寫下要做的事情，何時要完成，以及優先順序等。 一般而言，執行力強的人，總是能把所寫下工作項目整理成的清單 (List)一一的給完成。 喔，這突然讓我想到，我所看過執行能力最強的是誰呢？ "海綿寶寶"，沒錯，就是他！ 我在卡通上起碼看過三集以上，海綿寶寶把要做的工作，從上到下寫在一張好長好長的清單。例如，他要辦 "狂歡派對"，就把派對前需要準備的項目、要邀請的人、哪些人什麼時候要講什麼話，甚至哪個時間要安排讀報紙的冷笑話等．．．，他就是一絲不苟地一一地去完成清單上的項目工作，行動力與精力之充沛，可真的是驚人呢。

畢竟那是卡通，一般人總是沒有那麼好的精力，從上到下、Top-Down 的方式，去完成好長一串清單上的工作，所以我們會希望能以 "有效率" 的方式來處理工作。 那個 "有效率"，我曾說過，不只是懂得做事的技巧外，還要能分辦出，什麼是 "有價值" 的事情。我是覺得， 優先處理 "有價值" 的工作，比懂得 "有效率" 地運用技巧來處理工作還要來得重要。 而什麼是 "有價值" 的工作，這就與每一個人所認知的價值觀，以及對目標的規劃設定等有其關連。 所以價值觀、目標，中、短期的專案 (Project)等，是可以引導所要做的事情的方向上。自然你就會瞭解什麼樣性質的工作，會是在你心目中佔有優先權比重較高，需要優先處理的。

所以，工作事項會被組織，會分類，可以排定優先權順序與預計完成的期限等。 再則，諸多工作事項可能會有關連的，例如專案，它可能會區分為多個工作項目，而每一個工作項目也可能是專案，包含更細部性的工作項目．．．，如此的延伸與關連，而形成一種樹狀的結構。 我在當初評估時間管理工具時，正是因為考量到此，所以花了很多時間尋找能適切處理好樹狀結構的工具軟體。 正因如此， "Remember the Milk" 一開始雖然是我最優先評估的工具，但因為沒有樹狀結構，所以棄而不用； GTD Life 介紹的一篇： 推薦四個在線任務管理網站。 其中如 TODOIST, iPrioritize 是有支援樹狀結構的工作項目，但總覺得繁瑣了些，介面操作就是有那種不是味道的感覺。 說到味道，又讓我回想起那個牛奶，竟然在國外網站諸多網友的評鑑中， "Remember the Milk"，是 on-line 最佳的 GTD 工具網站。 我挺驚訝的，感覺功能如此的陽春，怎麼評價如此高？ 再深入去研究使用，以及著實看了很多國外網友們的使用心得分享 (參考此篇：Get Organized with Remember the Milk)，才發現到真的簡單就是美！ 下面我就來分享一下，我是如何利用 "Google Calendar" 與 "Remember the Milk" ，來達成個人在時間管理的規劃與執行。

"Remember the Milk"，簡稱 RTM，是可以與 Google Calendar 整合的，所以 RTM 是沒有提供行事曆的，它完全就是專注在 "工作" 的處理上。 對於工作的分類，它提供了兩種，一種是 "清單(List)"；另一種則是 "標籤(Tag)"。 前者我以為是一種 "實體(Physical)" 的分類，Outlook 的 Folder，就是一種 "實" 的分類方式；後者我認為就是一種 "邏輯(Logical)"，也就是 "虛" 的分類，Google 在其 Gmail 上就是使用這種分類方式的。 這兩種都各有優缺點，而 RTM 則乾脆都納入，讓使用者可以依工作性質與需求來自行規劃。 也正因如此，所以反而讓 RTM 對於工作的分類上，形成了相當強大、極有彈性的功能，也同時彌補了它不支援樹狀結構的那一部份(我一直不清楚 RTM 為何不提供樹狀結構，是技術問題還是一種堅持？)，因為利用 標籤，可以取代樹狀結構的呈現。

在清單的規劃上，我完全是認同 GTD Life 這裡所提的 重新認識我們的清單 一系列文章，不是變成 GTD 工具的奴隸，而是懂得以簡御繁。清單主要只有兩個："任務清單" 與 "下一步行動(Next Action)" 清單。 而我在 RTM 的規劃上，則利用預設(且無法刪除)的 "收件匣" 當成 "任務清單"，所有雜七雜八、未經分類，甚而點子或創意性的工作項目，全給建立在該清單之內；然後我再自行新增了一個 "行動清單"，是比較與 "下一步行動" 清單同性質的，我是把是很具體，需要定下時程與優先順序的工作給放入該清單內，往往是是需要在一、兩個星期內所要執行的工作。 一般是在星期日的時候，利用 Google Calendar，以月或星期的瀏覽方式，把預定的行程給安排記錄下來。 再來就利用 RTM，把已知需要在這一星期內處理的工作—可能是從 "目標" 或 "專案", 或過濾整理後從 "收件匣(RTM 各個清單內的工作是可以複製與移動的)" 而來的，記錄寫下來，放置於 "行動清單" 內，確實排出預定完成的期限與優先順序。 再來呢，在每一天的晚上，也會規劃與調整隔日要做的工作。 而規劃的方式，我完全是 "價值導向" 的，所以一星期只排 3~6 重要的工作。再分解成較細部的工作，每天只排 1~3 件最重要的工作，每天只要先吃掉最大最醜的青蛙後，就心滿意足，而放置於收件匣的雜項工作，就可以較不具壓力，很輕鬆隨性地去處理了。

其它的算是輔助性的清單了。這裡我就規劃了 "⊗System" 清單，裡面目前只放置了一個我稱之為 "Dummy-Task" 的項目，它專門是儲存所有會用到的 "標籤表頭(Tag Header)"，這我後述會提到；另外我也建立了 "計畫" 與 "專案工作項目" 的清單，前者我是專門用來儲存屬於 "專案(主要、次要)"、"目標(Goal)" 性質的工作項目；後者則放置了 "專案"、"目標" 的子工作(Sub-Task)項目，而兩者則是以 RTM 的 標籤(Tag) 關連起來的。其實這就是模擬如樹狀結構的專案，只是 RTM 所有的工作都是平面(Flat)的，然後再以標籤給關連起來的。我還規劃了一個 "購物清單"，這其實算是多餘，當然也可以記錄在 "收件匣" 內。我只是特別去凸顯該清單內的每一個工作項目，是我要準備要敗家採購，一個一個的購物項目罷了。 總之，要怎麼分類是很有自由與彈性的，到目前為止，我也還在調整中，一旦找出最適合自己的邏輯與方法後，就可以長期作為所信賴的系統了。

"標籤(Tag)" 用在哪裡呢？ 要不是有這篇討論串： "Here Be My Tag Cloud"，我想我也不會去使用 RTM 的，原來國外的 GTD 支持者們，早已利用 RTM "標籤雲(Tag cloud)" 的機制，發展出完全可以實現 GTD 方法論的系統，真的令人嘆為觀止！ 參考下圖，就是我現在所使用的標籤雲。 在預設的 IE 瀏覽器上可是無法達成這樣的呈現，而是必須在 Firefox 瀏覽器上，先安裝 "Greasemonkey" 與 "Stylish" 這兩種的 user script，原來就是在前端的瀏覽器網頁上，利用 JavaScript 語法，來變更其 UI 的配置(Layout)。安裝完後，然後到這裡："RTM for Tag Cloud Colorize and Keep Cloud Visible"，這兩個 user script 都給全裝上。 對了，為了要美化 RTM 的頁面，可以到 userstyles.org 網站，再以 "remember the milk" 當關鍵字搜尋，可以找到許多美化 RTM 頁面的 user scripts。 我這張圖就是安裝了許多 Stylish-based 的 scripts，所以才會有如 "顯示快捷鍵"、"讓字體加大與加深"、"標籤與項目在不同行"，甚至也可以讓那隻乳牛臉頰有著可愛的紅圓點等。

安裝了那個標籤雲的 Colorize 後，就能具下圖這樣的呈現。最重要的是利用 "標籤表頭(tag header)" 作為每一個標籤區域(section)的主題標示。 該 script 檔是設計了有 "Goal", "Major Project", "Minor Project", "Context", "Location", "Areas of Responsibility" 等。這還蠻符合 GTD-based 的表示法，目前也順應了我的需求，所以我並不需要對該 script 程式碼作修改，直接拿來用就可以了。 這些標籤表頭前述提及，我是建立了一個 "Dummy-Task"，稱之為 "¤"，並將之儲存在 "¤System" 的清單內。這個工作項目主要是設定了諸多表達表頭的標籤，例如 "+__goals"，就會在標籤雲中呈現為 "Goals(+)" 的表頭，爾後若是要標示某個工作項目在該 Goal 區域內，只要設定該工作項目的標籤為如 "+實現財富自由" 即可，依此類推，你就可以很輕易地建立哪些工作項目是屬於單一未分類的工作(不作標籤標示)，或是屬於 "目標", "專案" 性質的工作，以及該工作是在哪個地點(Location)，在什麼樣的情境(Context)下做的事情，以及是擔任什麼樣的角色(Areas of Responsibility)等。

例如，我有一個主要的專案，是關於撰寫與出版書籍的，所以我新增了一個工作項目，內容為 "[Maj_專案] 撰寫與出版軟體專業書籍"，然後主要的標籤設定是 "-寫作與出版軟體書籍"，以凸顯它是屬於 "Major Projects" 的類型，並且也可以在標籤雲該表頭的區域內看到該專案。再來我也可以設定該工作是需要在電腦前工作的，所以又設定了 "@computer" 的情境標籤。然後，我又想表達完成該專案所扮演的角色(Role)為作者，所以標籤設定為 "_writer"。 可以發現到，利用標籤的前置字符 (+, _, @, .) 等，就能讓這些工作項目有著不同的類型。 對了，"主要(Major)" 與 "次要(Minor)" 專案是如何區分呢？ 我現在是把可以具體量化、約在兩個星期內可以完成的工作，歸為 "次要的專案"；而超過兩個星期以上，約一年以內的專案，是歸為 "主要的專案"。時間再更長一點，可能長達三、五年的，就屬於為 "目標" 了。這些都不是絕對的，找出適合你自己的方法，快樂地去使用它，慢慢從過程中再去調整就可以了。另外關於目標的規劃，我反而主要不是利用標籤或樹狀型的專案，而是利用其它的工具，如 FreeMind 這類的心智圖(Mindmap)工具，這是我在先前文章已提過的。

當建立起屬於你自己的時間管理系統後，再來就是持之以恆地利用該系統做好你每天、每週，乃至於漸進持之以恆地往你所設定的目標前進。系統不是拿來作個樣子的，是要身體力行，而且要能懂得修正、調整，找出最適合你的方法，最終是協助你可以成為自己的主人的。 我是覺得，短期內(一、兩年內)的事情都很有可能需視現實的情況來調整，不會是一成不變的，這是一種務實的態度；短期的工作，是可以動態調整，視現況修正，而逐漸往所設定的目標前進。難為的是，同時間可能有多個目標，可能有財富方面的，也可能有家庭親子方面的，這就是一種如何在這些目標之間尋求 "調和之道" 的，這是需要經過不斷地嘗試與調整，更需要保持正面積極的態度，才能逐漸地前往抵達那個美好理想的 "彼岸" 。 目標是否也會改變呢？ 會的，不過那不會是輕易地說改就改，那可能是對於根本價值觀的改變上，才進而去改變你的目標的。

時間管理的要點即是：「依優先性，即何者為最重要的，與順序性，即何者先做，何者後做等等，排出你的重大目標、計畫或工作。先想著目標，然後再回頭想想辦法。」— 引述博恩‧崔西「吃了那隻青蛙」。