在軟體設計開發的過程中經常會看到，很多所謂的架構討論實際上只是在討論某種技術。在很多人的概念裡面，架構和技術實際上是等同的。學會了幾種技術，就認為自己是架構師了，甚至是學習的技術越多，就覺得自己的水平越高。這樣實際上是對自己很不負責任的。要知道任何技術都是為了解決某種問題而存在的，學會了技術，並不代表自己能夠解決問題，這一點非常的重要。學會的技術的多少，所帶來的差別只是自己解決問題的手段多了罷了。但是手段多了就一定是好事嗎？ 很多時候，學習的技術越多，越不知道採用哪種技術好，所謂「亂花漸欲迷人眼」。
還有另一種很普遍的觀點：技術人普遍看不起業務，認為技術更高階，而業務太低端，並且業務往往喜歡給技術挖坑。業務則覺得技術眼光高，但是實際解決不了問題，總是理解有偏差，但是又無可奈何，因為自己不會。
本篇文章嘗試從這裡入手，分析一下這三個概念到底有什麼關係，我們應該怎麼處理業務、技術還有架構的關係。
什麼是技術
當我們一無所有，或者什麼都不會的時候，這個時候實際上是沒有技術的。就好比人類在最早期，什麼都得用自己的雙手來幹活。一旦我們在日常生活中無意間發現某些規律的時候，我們就可以通過創造條件，讓這個規律重複的發生。通過人為創造條件，讓指定的規律按照人類的意願發生，這就是技術。比如取火，最早人類只能靠打雷等自然現象產生火。
取火其實就是乙個業務目標，要解決的是人類自己的問題，這就是業務，實際就是人類的利益。這個時候人類沒有生火的技術，只能靠不斷的加木材，保持火不熄滅。後來人們發現了鑽木取火：只要用乙個幹的木棍，在另乙個乾木表面快速的轉動，就可以生火。這個辦法讓人類可以自行創造火源，就產生了鑽木取火的技術。
但是雙手快速轉動木棍鑽木取火，並不是所有人都能夠做得到的，需要很多力量和速度，對人的要求太高。為了解決快速轉動的問題，就有人採用弓弦來提公升木棍轉動的速度。
通過上述內容得出：
業務目標是為了取火，鑽木取火這個技術的出現解決了這個問題。鑽木取火的效率不高，影響了業務（取火）的效率，就有了進一步改進的動機，改進轉動木棍的方式，產生了弓弦轉動木棍的技術。
技術與架構，以及與業務之間的關係
技術總是在人類解決對業務的要求不斷提高的情況下產生，目的也是為了獲取更大更好的利益。所以：
技術是為了解決業務的問題而產生的，沒有了業務，技術就沒有了存在的前提。所以技術與技術之間，有兩種關係：有了更好的技術，效率更差的技術，就會慢慢的被淘汰，消失，一切都遵從人類的利益訴求–也就是業務。有人會問，不用鑽木取火了，但是弓弦加速轉動木棍還可以用啊？沒錯，因為弓弦轉動木棍這個技術，不是來生火的，是用來加速木棍轉動的，所解決的問題不一樣。但是兩種不同的技術，合理結合起來，會更好更有效率的解決業務問題。
在解決同乙個業務問題的前提下，更高效，更低成本的技術，會淘汰低效，高成本的技術。這是人類利益訴求所決定的。當關係2發生的時候，這個地方必定會形成乙個切分，新技術會通過某種方式和原有的技術連線在一起形成乙個整體，讓這個新的技術可以和原有技術共同工作，使得原有的技術可以用更高的效率解決問題。因為要解決的主要問題（生火）並沒有發生改變，分拆所形成的是乙個樹狀的結構。一般剛開始解決根本問題的技術（鑽木取火）的效率是比較低的，只是把不可能變成了可能（從這一點上來說，技術才是業務的enabler）。然後就會有提高效率的需求出現，要求改進這個技術。這個技術的低效率部分就會被其他人（或者技術發明人自己）加以改進，這部分就會形成新的技術。
按照前面的架構定義，這個時候其實已經產生了架構。也就是說，一般是先有技術，才會有架構。這些其他技術（弓弦拉動木棍），是從直接解決問題的初始主要技術中分拆出來形成的，並通過樹狀結構和主要技術（鑽木取火）組合在一起。在解決主要問題（生火）之後，再開始逐漸的分拆為更為細粒度的技術（弓弦轉木棍）。
而這個細粒度的技術（弓弦轉動木棍）往往不會和業務的主要目標（生火）發生直接的關係。不同的技術，通過樹狀結構，組合在一起，形成了乙個完整的架構解決方案，共同完成業務的目標。這就是技術，業務和架構之間的關係。很多人把這個過程稱為架構的進化，其實更合適的是把這個過程稱為技術的進步所導致的新的架構分拆，因為這個過程內在的動力，更多的是來自技術對解決業務問題的解決。
技術人員和業務人員的關係
為什麼技術人員總是和業務人員發生衝突呢？這是因為技術人員很多時候關心的技術，和業務的主要目標往往不是直接對應的，業務也是負責某一部分的業務，也不是和業務的主要目標直接對應的，都是樹的分支節點（上文已經解釋了為何會發生這種情況）。只有直接解決業務問題的那個技術（或業務）–樹的根節點–會和業務直接相關。所以一旦產生衝突，一般必須兩個根節點（一般都是領導）碰面才能解決問題，就是這個原因–他們都知道業務主要目標。這也是為什麼下層無法理解上層，而上層都喜歡下軍令狀，要求下層執行。人只有盡量去理解上層的問題才能做下層的分拆。
在軟體行業，這個根節點技術就是軟體。這也是為什麼架構師要認識什麼叫軟體，軟體解決誰的問題，什麼問題，軟體本身又是怎麼分拆的，才能夠更好的組合不同的技術，完成業務的目標。而軟體裡面和業務直接相關的，只有business domain這一部分。
用人來打比方，business domain相當於人的大腦，而service，repository，glue code等部分所採用的技術，全部都是計算機自己領域的技術，都是為了能夠讓程式跑起來，相當於人的四肢。我們大部分開發人員的工作主要專注於四肢部分。我們真正應該投入的是大腦部分。因為大腦能夠決定四肢長什麼樣，而不是反過來。很多架構師、技術人員主要專注於計算機相關的技術，忽略了業務本身，甚至看不起業務，這也是為什麼技術總是和業務衝突的原因。
架構師應該承擔起解決業務問題的這個角色來，專注於business domain和軟體本身的架構，讓技術人員致力於為業務在計算機中跑起來而努力。只有把這兩者很好的結合起來，才能更好地完成業務的目標，才會讓軟體更好地服務於大家。最終一定會得到乙個很好的軟體架構，令軟體開發團隊和業務部門都能夠很好地開展工作並降低成本。
重新發明輪子
當現有已經存在很多技術，而這些技術卻和我們所要解決的問題並不是那麼直接對應的時候，我們就需要有意識的組織和識別不同的技術，來實現業務的目標。這個時候組織的方式有很多種，其中成本最低的方法就是按照要達成的目的和當前的問題，從上到下進行架構分拆。分拆出來的更細粒度的問題，分解到不同的人來進行解決，就形成了業務架構和組織架構。解決這些問題就需要組合很多不同的技術，那麼應該採用哪些技術？還是自己重頭實現乙個？自己實現乙個—這就是很多人所謂的重新發明輪子。以下試著分析一下：
當技術所提供的能力遠遠超過需要解決的問題時，往往掌握技術和維護技術會成為瓶頸。因為越複雜的技術，成本越高。如果自己實現乙個僅僅是解決當前問題的方案，可能成本反而更低。這也是為什麼很多大型的網際網路公司不斷地開源出來自己的技術的原因。而這些技術對於我們來說是否適用？他們原本是用來解決誰的問題的？什麼問題？如果不清楚這些，就冒然採用，可能會導致更高的成本。所以，準確識別採用什麼技術的能力，也是架構師所要具備的能力之一。考慮的主要因素也是長期的成本和收益。當技術所提供的能力和我們所要解決的問題部分匹配時，還是要看成本。比如當我們需要乙個錘子的時候，手邊正好沒有，但是卻有乙隻高跟鞋，勉強也可以替代錘子。但是長期來看，這麼用不划算，因為高跟鞋的**比錘子高很多，耐用性差很多，維護成本也高很多。
業務 技術和架構
這兩天準備要接手天津商行的專案。但是在接手的過程中，對整個專案的理解卻是非常的困難。最大的問題，就是對業務的不理解。天津商行的這個專案不大，核心的業務就是日結，及其圍繞在日結之周圍的一些相關業務。其實也並不是特別的複雜，但是轉來轉去，開賬閉賬，憑證科目什麼的，的確對乙個財務的門外漢是異常的頭痛。雖然...
論技術 業務和商業的關係
大家都在it網際網路行業工作，不知道思考過這個問題沒有，那就是技術 業務和商業的關係。我們在平時的工作中，難免會遇到以下類似問題 1 先進的技術很多，為什麼我們不在公司成立的時候就使用最新的技術呢？2 目前我們的業務都是老的技術架構，老架構不夠靈活，臃腫，我們是否引入新的技術架構呢？以及何時引入？3...
業務架構 資訊架構 技術架構三位一體
客戶天天打 要修改產品功能，簡單的乙個需求可能要做乙個月。產品越改越笨重，為了趕工期bug越來越多。頭疼！產品從初級版到現在已經四個年頭，相關的程式設計師來去換了三批，在補丁上打補丁是常有的事，很多功能只是開了個頭，換個專案經理就被遺忘。我們總是害怕客戶在這個產品上提出新的需求，只要客戶還用得過去，...