先拋開技術層面的問題，作為一個Architect，首重的目的在於商業目的(Business Goal)，我認為處理任何事物都該講求目標、原則、方法，最後是取捨，所以就從這樣的幾個關鍵點來談談：
- Goal
在做產品或專案的初期，我們會收到來自四面八方的意見與困擾，訴求著期望新的產品或專案能帶來哪些新的利益與更高的價值，所以三不五時可能會看到或聽到一堆由新技術、新領域的名詞，從而雜亂無章的堆疊出一個大怪物，然後你每天就是看著老闆不斷的催促或質問你的分析有盲點，客戶認為你看半天看不出個所以然來，然後陷入一段非常痛苦的掙扎，自己明明投入了很多的時間跟精力去追求這些新技術，翻遍所有的Tech forum, news, conference，然後還是不知所措。很顯然的我在任職的初期就是遇到這樣的困境!!!
反過來看待，這麼多的期望與不著邊際的需求，我們該真正去尋求並諮詢的是，真實的商業目的是什麼，其他的多種需要(尤其是UX, non-functional這類容易失焦的)都先給拋開在一邊，先確切知道所要進行的目標並且確保應該帶來的效益之後，才開始去尋求解決方案的組合，然後一邊找，一邊納入UX, non-functional 的限制來提供 選擇做取捨，並且不要依個人的喜好來做選擇，要知道Architect 其實是個說書人(Story teller)，我的腳色是提供一組到多組的可能性選擇，並且搭配著各種基於現實與限制的條件所存在著，提供優缺點的陳述，但必須盡可能客觀，如此，方案的提供才能不落入工程師背景的偏頗，在這個選擇的出發點上，Architect本身就是站在CEO的角度在觀看這個架構是否真能符合商業利益的 !!!
- Principal
再來，去衡量評斷是否採用哪個產品或方案時，不能毫無章法的瘋狂google，然後一直去找別人寫過的文章去看結論就採用(當然，有人寫過的評論也是值得參考的，但不能是唯一的依歸)，舉個我早前的例子，HTML 5 JS game engine，一找下去滿坑滿谷多到你數不清，若沒有個評估的準則，那就算是花一個月來找恐怕也不會有結論的，依此我回歸到架構評估的幾個準則上來談，Scalability, Maintainability, Availability, Re-Usability, Functionality 等等幾個大關鍵，尤其必須得滿足Functionality，而這又通常會跟business goal掛勾，因此能做的選擇與考量就會更明確些。
- Methodology
老實說，方法論這一塊我還在摸索中，因為我還尚未學習如何從一整個完整的架構堆疊中，去找出一個或幾個合理的評估基準，來判定這樣的架構產出是合理的，是能完全符合Business Goal的，下一個年度會打算去找看看卡內基的CMU System Architecture Principal的資料，去看看如何用一套評估標準來為自己做下的決策衡量結果。
至於在整體架構勾勒評估完成後，後續進行的BA, SD, Coding, Testing 我想都已經有非常多的成熟方法論與實務可提供了，唯一要特別注意的事情是，如果我是Enterprise Business Architect，那麼應該就不會探討涉入過多， 那麼若我即將投入的是Project socpe Architect，那麼我就必須去制定合理的標準，讓團隊成員一起有個明確的規範一起共事，並確保過程都是可被衡量可被評斷的，過去幾年在前公司的經驗中，太多的所謂靠經驗做事情，代價就是補不完的洞，還有解不完的需求互斥。
- Trade-Off
最後，是取捨，在列出了所有的可行性評估之後，站在以企業主角度進行的建議選擇時，不能有個人私心取向，每一次的決定都是取捨，總有好壞讓人掙扎，但對於專業的Architect來說，這種掙扎不會存在，因為他的思考的方向永遠都在企業主的角度，選擇一個能夠完全符合商業利益的角度來出發，就很快的能夠排出幾個優先順序，並且能羅列出相關的限制、資源成本，最終將能給予決策團隊進行最後的選擇，這樣就不會陷入技術人對於技術本位執掌的執念的偏頗，又能滿足達成客戶期望與目的，這才是真正Architect所該帶有的本質。
沒有留言:
張貼留言