技術文件很多，每種文件都有各自的目的。其中和架構師關係最密切的、甚至架構師應該親自寫的文件是技術***與技術路線圖，這兩份文件是本次文章的重點。
技術***
white *****衍生自white book（***），一般也稱為***，但是內容更濃縮、更精華。white *****通常合起來寫為white*****。
技術***（technical white *****）是官方正式的報告指南，風格介於技術**和商業雜誌文章之間，用來描述大問題和技術解決方案。技術***是常用的技術營銷的手段之一，它的目的是幫助讀者了解技術、做出決策。技術***通常是以pdf檔案格式存在，10頁左右的篇幅最恰當。
技術發明者（或擁有者）才能發表技術***。例如，支付寶可以發表「總督系統」技術***（我正在研發的一套cep系統），但不可以發表spring框架技術***。支付寶計畫走向開放，未來可能會提供開放api，那時候就可以對外推出技術***。
技術***是「技術營銷」的檔案，適合cto、技術總監、技術專家之類的高層決策人士閱讀，讓他們通過「大局觀」的方式了解整個技術概況。技術***的重點在於讓讀者深刻理解採用此技術將為他們帶來多大的利益。
編寫技術***要把握以下重點：
1. 技術***代表官方，所以敘述風格必須具有權威性；
2. 良好的技術***通常會附上許多方塊圖，將技術內部的結構表達清楚，並說明和外部的關係；
3. 如果無法使用示意圖時，盡量使用bullet point；
4. 技術***一定要把握重點，不可以長篇大論；
5. 技術***一定要有高技術含量，雞毛蒜皮的瑣碎細節一概不提；
6. 以讀者的利益為敘述核心，而非以技術本身的先進或自身的利益為敘述核心。
上面的第6點是大部分技術***的毛病所在，需要特別解釋。技術***不應該淪為自言自語、自吹自捧，而是應該從「顧客第一」的角度分析讀者有什麼問題，需要什麼樣的技術，而我們的技術可能是一項不錯的解決方案，因為我們是如何如何做到的。
我建議的技術***編寫框架如下：
摘要（約中文三百字的摘要）
簡介（what、why、how等）
技術說明（架構等）
summary（總結）
文件的法律宣告
技術路線圖
討論完技術***，接下來看技術路線圖（technology roadmap）。
想要到達某個目標，可能不是一蹴而就的事，需要有路線規劃，讓大家一目了然地知道近期、中期、遠期的目標，這就是roadmap（路線圖）。roadmap也可以寫成road map。
roadmap應用相當廣泛：兩岸想統一，需要roadmap；支付寶想要創造100倍的業績，需要business roadmap。如果過程涉及技術，那麼這就是technology roadmap。只有新產品、新興技術、相當複雜的產品可以有technology roadmap。如果僅是對產品做小改進，根本不需要technology roadmap。
技術路線圖有三個主要用途：
隨著軟體產業越來越成熟，產品經理（product manager）也變成必備的職位。產品經理要負責整個開發過程的管理，在此過程中，制定產品路線可以幫助軟體產品經理規劃與分配資源。
制定技術路線圖分三個階段：
1. 第一階段：初步行動；
2. 第二階段：技術路線圖開發；
3. 第三階段：後續行動。
可以看出第一階段是準備，第二階段是重點，第三階段是後續跟蹤修改。
在第一階段（初步行動），關鍵決策者發現他們有乙個問題需要解決，而需要乙份技術路線圖來幫助他們解決此問題，他們要這樣做：
1.1 滿足根本條件；
1.2 賦予領導權威或地位；
1.3 定義技術路線範圍和邊界。
在步驟1.1中，條件包含技術路線圖所需、來自組織不同部門（營銷、開發、戰略等部門）的輸入，這些部門有著不同的計畫區間（planning horizon）和不同的看事情角度。如果條件不滿足，則要採取行動來滿足條件。條件都滿足了，才能繼續下乙個步驟。
步驟1.2的意思是：技術路線圖的建立牽涉到時間和各種資源，必須要有堅定的領導權威。領導權威必須來自參與者之一，由參與者之一賦予領導權威或地位。讓組織驅動此過程，並使用此路線圖來進行資源分配的決策。
在步驟1.3中，指定好路線圖的環境背景。一家公司應該要有清晰的願景（vision），且技術路線圖應該要能清楚地支援此願景。如果願景不存在，那麼應該先發展出乙個願景，並清晰地描述它。當做到這一點，路線圖的邊界與範圍就能夠被定義出來。此外，還要設定好計畫區間和詳細程度。
完成了第一階段的初步行動，接下來就可以進行第二階段，真正把技術路線圖開發出來。第二階段可以分成七個步驟，下面依次描述。
2.1 找出路線圖焦點的產品：在本步驟中，找出共通的產品需求，且所有的參與者對此達成共識。讓所有的人都能接受此步驟相當重要。如果有不確定的地方，可以採用場景規劃（scenario-based planning）的方式，找出共通的產品需求；
2.2 找出關鍵的系統需求以及它們的目標：一旦決定好，這些需求要被設定路線，然後關鍵的系統需求就可以被辨識出來。關鍵的系統需求為技術路線圖提供整體的框架。這裡的需求可以有一些目標（例如高穩定性、低成本）；
2.3 指定主要的技術領域：想實現此關鍵的系統需求，有一些相關的領域。對於每個技術領域而言，有一些技術在其中。技術領域包括分布式資料庫、網路、系統開發、財務會計等；
2.4 指定技術者和他們的目標：在此步驟中，來自步驟2.2的關鍵系統需求會被轉換成某技術領域中具有目標的技術驅動者（technology driver）。這些驅動者會影響那些技術方案被選用。驅動者依賴於技術領域，但是與「技術如何因應系統需求」有關；
2.5 找出技術方案與它們的時間線：此時技術驅動者和它們的目標已經被指定好，且「滿足目標的技術方案」應該也被指定好。對於每個技術方案，都應該估計出乙個時間線，說明它會如何成型，以符合技術驅動者的目標。某些特定的狀況下，要考慮到時間。電子商務或軟體開發的區間通常會比較短；
2.6 建議應該採用的技術方案：因為不同技術方案的成本、時間線等條件可能不同，所以要從中做選擇。在這個步驟，要根據目標做取捨（例如：效能比成本重要）；
2.7 建議技術路線圖報告：此時技術路線圖已經完成。技術路線報告包含五個部分的內容（當然，此報告也可以包含其他額外的資訊）：
完成了2.1~2.7的七個步驟，技術路線圖就已經開發出來了。軟體開發出來並不代表結束，還需要後續的測試、運營、維護等。同理，技術路線圖開發出來之後（第二階段），還需要後續的動作（第三階段）。
第三階段大致分為三個步驟：
3.1 討論和驗證路線圖：路線圖需要被批評、驗證、採用；
3.2 制訂乙個執行計畫：要依據技術路線圖設計出乙個計畫；
3.3 審查和更新：要週期性的審查並更新。
總結 本系列文章共四篇，到此已經完全結束。通過本系列文章，希望喚醒大家對技術文件的重視。
技術寫作的經驗培養、技術文件體系的建立，都是需要時間的。身為乙個技術人員，如果你認為你正在做的技術是有價值的，你就應該為它建立技術文件，儘管一開始會覺得寫作很難、也沒足夠的時間進行寫作。公司更應該領悟到，如果沒有技術文件，一旦人員更替、新員工加入，或者需要對外推廣時，都會遇到相當多的困難。從今天起，讓我們開始重視技術寫作能力的培養與技術文件體系的建立。
作者簡介：
蔡學鏞，台灣台南人，畢業於台灣清華大學computer science研究所，現任阿里巴巴支付寶架構師，負責新系統的開發。
作為大資料行業架構師，最重要的是什麼？
最重要的是什麼？這是乙個價值觀的問題，也是做所有事情要解決的最核心問題。作為大資料行業的架構師，最重要是什麼？效能 規模 穩定 高效。所有的一切，無論是web層 邏輯層 還是資料層，所有的設計方案必須是圍繞 效能 規模 穩定 高效 這個終極目標。web層技術選型，傳統的有struts springm...
轉 架構師的行為準則（一）
最近看了一本書 軟體架構師應該知道的97件事 本來並沒對它抱有太多期望和興趣，畢竟這種講大道理的書不可能帶來什麼實際收穫，但看的過程中被裡面中肯實在的建議給吸引，對於我這種在走向架構師這條路上常常迷失方向的人，實在是雪中送炭。讀完後，決定選擇其中對我有觸動的條目，加上實際工作中的感悟，形成一套自認為...
轉 架構師的行為準則（四）
原則大於個人口味 很多架構師都有著豐富的經驗和個人風格，以至於在平常工作中常以個人口味作為決策的依據，對於普通的開發人員也許是可行的，我們鼓勵大家有個人特色，但架構師更應該依據原則辦事，需要維護和遵守一套大家公認的原則，以此作為判斷是非的工具 從 可行走骨架 開始 敏捷管理崇尚盡早整合，在架構設計這...