架構師要做什么？

ADMEMS矩陣，明確介紹了架構師需要思考的問題，而在這個矩陣中，做完一個架構師最需要了解的什么呢？技術？業務？都不是，最需要了解的是你的領導，其次是你的團隊成員。

如果你的領導是不懂且不放權的類型，那你的好架構要如何實現呢。如果你的團隊技術爛的一塌糊涂，又如何開發出成熟的產品？看看ADMEMS矩陣，理論上是先上后下，先左后右。而現實中，應該是先右后左，先下后上。

看了ADMEMS矩陣，最重要的就是約束，最最重要的就是開發需求對應的約束。那么架構師要如何分析這些呢。

首先分析你的領導

1，??確定他是否能清晰的分辨出團隊成員技術的高下，這個清晰很重要，要十分清晰。

2，??確定他支持你架構設計的力度，（強烈支持，還是設計的好就用不行就不用）

3，??確定他是否真的理解了架構的重要性，還是他只是為了給工作計劃戴個好看的帽子，還是兩者都有。

以上三點只要有一點不滿足你的架構基本上就很難實現，為什么是很難而不是不能呢？因為團隊成員足以彌補一些領導的能力不足。

接著分析你的團隊成員

1，??你的團隊成員能力差距是否過大。

2，??你的團隊成員能力高的和低的比例是多少。

正所謂巧婦難為無米之炊，即使你再棒，也沒辦法一個人做項目。團隊成員當然都是高手最好，如果是2：1也可以接受，如果是能力低的多，那就要看領導了，如果他不符合上面三點，那軟件開發流程就只會是和稀泥式的前進。架構與否就不那么重要了。當成員和領導都是優秀的時候，那么在分析其他需求又有何難呢?

架構設計要思考的問題

一個軟件架構師最重要的問題，就是他所設計的產品必須是滿足客戶戰略規劃的需求，能夠幫助客戶解決實際問題的。

這是理論上，或者說是書本上的知識點，現實中的變數太多。首先要考慮著三個問題，who,what,why。

Who：為誰設計？

你設計的架構是為客戶設計的嗎？你的客戶理解你的架構的重要性嗎，也許連什么是架構都不懂吧。如果你的客戶理解，那么恭喜你，你是在為客戶設計一套理想的架構。如果不理解，那么很遺憾，你并不是為你的客戶在設計，你是在為你公司的領導在設計。那么你設計的東西就需要為他們講解。記得，有時候領導比客戶更笨拙。并且他們會要求不斷解釋那些1+1=2的問題。有些架構師太久不去溫習那些基礎，只是記得1+1=2，卻忘記了如何解釋，那么很遺憾你的架構將遭到懷疑。我記得以前帶我的前行一位架構師和我說過這么一句話，“信則靈，不信則不靈”，這不是迷信，為什么呢?因為架構師要能把所有的東西都給領導和團隊成員講明白，那大家就都是架構師啦，不是架構師講不明白，是對手聽不懂啊。

What：要解決用戶的什么問題？

性能低下?結構轉換？可維護性差？領導面子？（一點不好笑，真的有公司這么做的）。

我見過一個公司，他們的產品還能運行，但改起來很難受，程序員天天抱怨。于是就請了一個架構師，目的有二，（1）修改產品結構，降低維護成本（2）使員工不要抱怨。結果當然是無疾而終了，新架構上不去，又折騰了好久。最后不愉快的離開。原因是什么呢？首先領導并不是全力支持他，這會導致什么結果呢？他必須設計出完美無缺的架構，并且擁有神一樣的講解能力，否則新架構永遠是有風險的。而現在的程序還能運行，不可能去冒這么大的風險。由于這個強力矛盾的存在，那么其他問題也就應運而生了。至于性能低下，結構轉換，可維護性差等等，這些技術層面能解決的問題就顯得不那么重要了。

Why：為什么要解決這些用戶問題？

提高用戶體驗？用戶強制要求？合理化軟件程序？為業務拓展做基礎？首先要確定，這些真的是用戶需求嗎？還是程序員們和業務們總結出來的理想建議。如果真的是從用戶那里得到的，那么恭喜你，對癥下藥，功德無量。如果不是，那就是事倍功半，褒貶不一。抑或在根本無法得到客戶需求，那么你就只能摸著石頭過河了，至于成敗，就只能謀事在人成事在天了。

結語

其實業界很多架構師都是摸著石頭過河的。又有許多架構師失敗并不是因為架構和技術，只是沒讀懂領導的心。架構師首先要分析公司的現狀，然后再設計，當然發現公司現狀根本不可能完成架構時，那就要早做準備，不要等到最后背個黑鍋離開。如果公司問題太多，新就架構根本是無稽之談，那就著手于小分區的修改，這也是個長存之道。

----------------------------------------------------------------------------------------------------

注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文鏈接！

若您覺得這篇文章還不錯，請點擊下右下角的推薦，非常感謝！