合格架構師的目標管理

「一個系統的架構，作到如何才能算好呢？」明眼人都能看出，這個問題就是問系統架構的目標。其實這個話題已經和不少人討論過。一個很是簡單的開頭，結果卻多是千篇一概的答案。

「將系統作到可維護、可擴展、可延伸等等...那麼這個系統就不錯了。」

這個答案是一個典型的程序員式的目標管理。能夠看出，這是一個很是完美的目標。但我要說，這不是真正的目標。若是你正在做爲一個架構師，在架構一個新的系統。我想問問你，你會如何描述你的目標呢？

我問過不少人，不少人，都是相似與上面的回答。

要回答這個問題，首先要回答架構這個工做要作什麼？我想不少人都願意贊成下面的說法：

1. 架構=高層次設計
2. 設計=權衡
3. 權衡=問題>>方案1>方案2>方案n=問題+選中的方案

說白了，設計就是肯定方案、選擇方案的過程。

那麼，咱們架構要作得好，

1. 明確咱們須要解決的問題列表。
2. 針對問題，列出可能的解決方案列表。必定要多於一個方案。不然不是設計，而只是解決問題。

是的，到了這裏，咱們就能夠回答一開始的問題，一個系統的架構作得好，就是咱們問題的解決效果作得好。固然了，這裏面的問題包括功能性需求，也包括非功能性需求，特別是非功能性需求這部分對於架構影響更大。

所謂架構得好，就是方案設計到位，方案選擇合理！若是咱們要開一個架構評審會，咱們評審會的重點也必定是在這裏。

之前我參加過不少架構評審會，可是到最好，都是在聽架構師講解UML的類圖結構。固然了，這與國內設計方面的階段有關，不少人對於UML的理解還不徹底。但這顯然有不少弊病。特別是評審的人，並不能保障對系統業務的理解，因此對於類圖不是很感冒，最多對UML的繪圖技巧提出一些建議而已，反而忽略了架構自己重點的評審。這種評審會是沒有意義的。

再回過頭來說，架構師也只有搞清楚本身的設計重點，工做也纔能有的放矢。這永遠比那些盲目最求完美系統更能解決問題。一個好的目標管理，會讓架構師至少在工做安排上作到合格。

有人問我，所謂的問題+方案的目標描述，是否是隻是「可維護性、可擴展性等等」的目標細化？從語言上講，確實有這個關係。但我強烈反對這種認知，這是一個徹底不一樣的出發點，一個關注的本身的取向，一個關注的是問題取向。不一樣的出發點，也表明了架構師的架構意願。

由於架構師，就是自身判斷能力的運用者。而架構意願在其中起了很是大的做用。所以，要作一個合格的架構師，就要從嚴格要求本身的架構意願開始！