某天和朋友吃飯正好聊到這個話題。作為架構師或者做技術的人，在開發軟體時，我們基本上就是在扮演上帝的角色：我們不但要創建出一個個的程式，還要讓這些程式能夠脫離我們在硬體上獨立執行，以便為這個程式所服務的群體提供服務。當這個程式出現問題甚至bug的時候，我們還得扮演牧師的角色去修復這些問題。這不正是一個程式的社會嗎？ 和人類社會的演變何其相似！那麼我們自然也能夠拿人類演變的歷史來指導軟體開發工作，以避免再經歷一次像人類演變發展那麼痛苦的過程了。由此我們也可以看出，架構師和程式設計師們都在扮演著多麼重要的角色，如果還在解決自己的問題，怎麼扮演好上帝這個角色？

在軟體設計開發的過程中經常會看到，很多所謂的架構討論實際上只是在討論某種技術。在很多人的概念裡面，架構和技術實際上是等同的。學會了幾種技術，就認為自己是架構師了，甚至是學習的技術越多，就覺得自己的水平越高。這樣實際上是對自己很不負責任的。要知道任何技術都是為了解決某種問題而存在的，學會了技術，並不代表自己能夠解決問題，這一點非常的重要。學會的技術的多少，所帶來的差別只是自己解決問題的手段多了罷了。但是手段多了就一定是好事嗎？ 很多時候，學習的技術越多，越不知道採用哪種技術好，所謂“亂花漸欲迷人眼"。

還有另一種很普遍的觀點：技術人普遍看不起業務，認為技術更高階，而業務太低端，並且業務往往喜歡給技術挖坑。業務則覺得技術眼光高，但是實際解決不了問題，總是理解有偏差，但是又無可奈何，因為自己不會。

本篇文章嘗試從這裡入手，分析一下這三個概念到底有什麼關係，我們應該怎麼處理業務、技術還有架構的關係。

什麼是技術

當我們一無所有，或者什麼都不會的時候，這個時候實際上是沒有技術的。就好比人類在最早期，什麼都得用自己的雙手來幹活。一旦我們在日常生活中無意間發現某些規律的時候，我們就可以通過創造條件，讓這個規律重複的發生。通過人為創造條件，讓指定的規律按照人類的意願發生，這就是技術。

比如取火，最早人類只能靠打雷等自然現象產生火。取火其實就是一個業務目標，要解決的是人類自己的問題，這就是業務，實際就是人類的利益。這個時候人類沒有生火的技術，只能靠不斷的加木材，保持火不熄滅。後來人們發現了鑽木取火：只要用一個乾的木棍，在另一個幹木表面快速的轉動，就可以生火。這個辦法讓人類可以自行創造火源，就產生了鑽木取火的技術。

但是雙手快速轉動木棍鑽木取火，並不是所有人都能夠做得到的，需要很多力量和速度，對人的要求太高。為了解決快速轉動的問題，就有人採用弓弦來提升木棍轉動的速度。

也就是說：

業務目標是為了取火，鑽木取火這個技術的出現解決了這個問題。鑽木取火的效率不高，影響了業務（取火）的效率，就有了進一步改進的動機，改進轉動木棍的方式，產生了弓弦轉動木棍的技術。技術與架構，以及與業務之間的關係

技術總是在人類解決對業務的要求不斷提高的情況下產生，目的也是為了獲取更大更好的利益。所以：

技術是為了解決業務的問題而產生的，沒有了業務，技術就沒有了存在的前提。有了更好的技術，效率更差的技術，就會慢慢的被淘汰，消失，一切都遵從人類的利益訴求——也就是業務。有人會問，不用鑽木取火了，但是弓弦加速轉動木棍還可以用啊？ 沒錯，因為弓弦轉動木棍這個技術，不是來生火的，是用來加速木棍轉動的，所解決的問題不一樣。但是兩種不同的技術，合理結合起來，會更好更有效率的解決業務問題。

所以技術與技術之間，有兩種關係：

在解決同一個業務問題的前提下，更高效，更低成本的技術，會淘汰低效，高成本的技術。這是人類利益訴求所決定的。一般剛開始解決根本問題的技術（鑽木取火）的效率是比較低的，只是把不可能變成了可能（從這一點上來說，技術才是業務的enabler）。然後就會有提高效率的需求出現，要求改進這個技術。這個技術的低效率部分就會被其他人（或者技術發明人自己）加以改進，這部分就會形成新的技術。

當關系2發生的時候，這個地方必定會形成一個切分，新技術會通過某種方式和原有的技術連線在一起形成一個整體，讓這個新的技術可以和原有技術共同工作，使得原有的技術可以用更高的效率解決問題。因為要解決的主要問題（生火）並沒有發生改變，分拆所形成的是一個樹狀的結構。

按照前面的架構定義，這個時候其實已經產生了架構。也就是說，一般是先有技術，才會有架構。這些其他技術（弓弦拉動木棍），是從直接解決問題的初始主要技術中分拆出來形成的，並通過樹狀結構和主要技術（鑽木取火）組合在一起。在解決主要問題（生火）之後，再開始逐漸的分拆為更為細粒度的技術（弓弦轉木棍）。

而這個細粒度的技術（弓弦轉動木棍）往往不會和業務的主要目標（生火）發生直接的關係。不同的技術，通過樹狀結構，組合在一起，形成了一個完整的架構解決方案，共同完成業務的目標。這就是技術，業務和架構之間的關係。很多人把這個過程稱為架構的進化，我更願意把這個過程稱為技術的進步所導致的新的架構分拆，因為這個過程內在的動力，更多的是來自技術對業務問題的解決。

技術人員和業務人員的關係

為什麼技術人員總是和業務人員發生衝突呢？ 這是因為技術人員很多時候關心的技術，和業務的主要目標往往不是直接對應的，業務也是負責某一部分的業務，也不是和業務的主要目標直接對應的，都是樹的分支節點（上文已經解釋了為何會發生這種情況）。只有直接解決業務問題的那個技術（或業務）—— 樹的根節點 —— 會和業務直接相關。所以一旦產生衝突，一般必須兩個根節點（一般都是領導）碰面才能解決問題，就是這個原因——他們都知道業務主要目標。這也是為什麼下層無法理解上層，而上層都喜歡下軍令狀，要求下層執行。人只有儘量去理解上層的問題才能做下層的分拆。

在軟體行業，這個根節點技術就是軟體。這也是為什麼架構師要認識什麼叫軟體，軟體解決誰的問題，什麼問題，軟體本身又是怎麼分拆的，才能夠更好的組合不同的技術，完成業務的目標。而軟體裡面和業務直接相關的，只有Business Domain這一部分。

用人來打比方，Business Domain相當於人的大腦，而Service，Repository，Glue Code等部分所採用的技術，全部都是計算機自己領域的技術，都是為了能夠讓程式跑起來，相當於人的四肢。我們大部分開發人員的工作主要專注於四肢部分。我們真正應該投入的是大腦部分。因為大腦能夠決定四肢長什麼樣，而不是反過來。很多架構師、技術人員主要專注於計算機相關的技術，忽略了業務本身，甚至看不起業務，這也是為什麼技術總是和業務衝突的原因。

架構師應該承擔起解決業務問題的這個角色來，專注於Business Domain和軟體本身的架構，讓技術人員致力於為業務在計算機中跑起來而努力。只有把這兩者很好的結合起來，才能更好地完成業務的目標，才會讓軟體更好地服務於大家。最終一定會得到一個很好的軟體架構，令軟體開發團隊和業務部門都能夠很好地開展工作並降低成本。

重新發明輪子

當現有已經存在很多技術，而這些技術卻和我們所要解決的問題並不是那麼直接對應的時候，我們就需要有意識的組織和識別不同的技術，來實現業務的目標。這個時候組織的方式有很多種，其中成本最低的方法就是按照要達成的目的和當前的問題，從上到下進行架構分拆。分拆出來的更細粒度的問題，分解到不同的人來進行解決，就形成了業務架構和組織架構。解決這些問題就需要組合很多不同的技術，那麼應該採用哪些技術？還是自己重頭實現一個？ 自己實現一個——這就是很多人所謂的重新發明輪子。以下試著分析一下：

當技術所解決的問題和分拆出來要解決的問題，完全匹配的時候，這是最完美的。比如需要提供web要訪問的service，很多MVC的framework就可以很好的滿足這一點。而這個時候如果非要自己實現一個，很有可能就是重新發明輪子。當技術所提供的能力遠遠超過需要解決的問題時，往往掌握技術和維護技術會成為瓶頸。因為越複雜的技術，成本越高。如果自己實現一個僅僅是解決當前問題的方案，可能成本反而更低。這也是為什麼很多大型的網際網路公司不斷地開源出來自己的技術的原因。而這些技術對於我們來說是否適用？他們原本是用來解決誰的問題的？什麼問題？如果不清楚這些，就冒然採用，可能會導致更高的成本。當技術所提供的能力和我們所要解決的問題部分匹配時，還是要看成本。比如當我們需要一個錘子的時候，手邊正好沒有，但是卻有一隻高跟鞋，勉強也可以替代錘子。但是長期來看，這麼用不划算，因為高跟鞋的價格比錘子高很多，耐用性差很多，維護成本也高很多。

所以，準確識別採用什麼技術的能力，也是架構師所要具備的能力之一。考慮的主要因素也是長期的成本和收益。