在軟體行業，架構是非常重要的，架構一詞很早就出現了，它最早源於建築，它的英文是architecture，定義為architecture (latin architectura, from the greek ἀρχιτέκτων arkhitekton"architect"， from ἀρχι- "chief" and τέκτων "builder") is both the process and the product of planning, designing, and constructing buildings and other physical structures。雖然這個詞的解釋很明顯，但是每個人對這個詞的看法都不同，都有自己的理解。
簡單的來說吧，架構的出現是為了提高效率，使1+1>2。架構也就是分工，每個人做自己擅長的事情，最後再有機的結合在一起，達到人們所需要的，所希望的。架構是人類發展過程中，由懵懵懂懂的，被動的去認識這個世界，變成主動的去認識，並以更高的效率去改造這個世界的方法。
架構就是根據所需要解決的問題，對目標系統的邊界進行界定，並對目標系統按照某乙個原則進行切分，便於不同的角色進行自己的任務，使各個部分可以一塊進行儉省時間。各個模組又要有所聯絡，最後在每個模組完成時進行合理有機的結合。
認識概念是理解架構的基礎。架構實際上解決的是人的問題，概念是人們認識這個世界的基礎，也是用來溝通的手段，何為「相」？就是人們提到乙個詞就會在腦海中浮現出來的形狀。
識別問題也是架構的重要的部分。架構實際上是解決人的問題，所以找到問題是架構的最重要的部分。識別問題的最大乙個前提就是要搞清楚：是誰的問題。這個問題搞清楚了，就好辦了。問題的主體是很重要的。
認清楚了問題之後，就是架構的切分。切分就是利益的調整，我們要非常的清楚，所有的切分調整，都是對相關人的利益的調整。為什麼這麼說呢，因為維護自己的利益，是每個人的本性，是在骨子裡面的，我們不能逃避這一點。當人們認識到要主動的去切分乙個系統的時候，毫無疑問，我們不能忘掉利益這個原動力。所有的切分決策都不能夠違背這一點，這是大方向。
架構是軟體行業中很重要的部分，那麼軟體是什麼呢。軟體的歷史，實際上可以說是用機器模擬人的歷史。不管大家（包括在這個歷史過程中的參與者）有沒有意識到，我們都有意無意的在計算機上模仿人類的行為。隨著軟體的規模的變大，做好乙個軟體也變得越來越難了。早期的程式設計師寫程式，主要是為了幫助自己研究課題。這些程式設計師熟練了之後，提高了自己的生產力，並發現還可以幫助別人寫程式，慢慢軟體就變成了乙個獨立的行業。程式從早期由乙個人完成，也逐漸變成了由很多不同角色的人共同合作來完成。以下討論的前提，都是基於幫助別人寫程式，多人合作的基礎上的。結論對於單人為自己寫程式也適用。軟體的主要目的，還是把人類的生活模擬化，提供更低成本，高效率的新的生活。從這個角度來看，軟體主要依賴的還是人類的生活知識。軟體更多的是扮演乙個cost center，這也是為什麼會出現很多的軟體代工。
軟體工程師是實現這個模擬過程的關鍵人物，他必須先理解人是怎麼在日常生活中完成工作的，才能夠很好的把這些工作在計算機中模擬出來。可是軟體工程師需要學習大量的計算機語言和計算機知識，還需要學習各行各業的專業知識。如同前面描述的架構的定義，軟體架構的出現也是同樣的。一開始是懵懵懂懂的去寫軟體，後來慢慢的就有意識的去切分，演變成了不同的架構。這個背後的動力也是一樣的，就是提公升參與的人的利益，降低成本。導火索也是軟體工程師的任務太重，我們需要把很多任務作拆分出來。拆分的原則也是一樣的，如何讓權責一致。同樣，這個拆分也是需要組織架構的調整，來保證架構的落地。
軟體架構到底要解決什麼問題：1.業務問題，具體的現實生活狀態下，沒有軟體的時候，所解決的問題的主體是誰，解決的是什麼問題，是如何解決，如何運作的？2.計算機問題：如何現實用軟體模擬，軟體是否支援擴充套件等等。
要成為架構師，必須要超越這個恐懼才能夠看清楚，我們要解決的是別人的問題，不是自己完成工作的問題。因為僅僅是完成了自己的工作，也並不一定就解決了別人的問題。如果別人的問題沒有解決——即使我們認為自己的工作完成了——我們的工作實際也沒完成，因為我們工作是否完成，是別人說了算的，不是我們自己。
架構師是要去平衡別人的利益，甚至會調整別人的利益的。一旦架構師是全心全意的為別人的利益服務，自然而然的架構師就擁有了強有力的影響力，肯定會是乙個leader。但是只是民意上的leader是沒有用的，不能完全發揮架構師的能量。架構師必須是乙個組織的領導人，有權利調動這個組織的架構，才能夠更好的發揮架構師的作用，更好的把利益的調整落到實處。
在開發軟體時，我們基本上就是在扮演上帝的角色：我們不但要建立出乙個個的程式，還要讓這些程式能夠脫離我們在硬體上獨立執行，以便為這個程式所服務的群體提供服務。當這個程式出現問題甚至bug的時候，我們還得扮演牧師的角色去修復這些問題。技術，業務和架構之間的關係要理清楚。技術總是在人類解決對業務的要求不斷提高的情況下產生，目的也是為了獲取更大更好的利益，技術有兩種關係，1，把不可能變成可能。2.把低速變為高速。當關係1發生的時候，這個地方必定會形成乙個切分，新技術會通過某種方式和原有的技術連線在一起形成乙個整體，讓這個新的技術可以和原有技術共同工作，使得原有的技術可以用更高的效率解決問題。不同的技術，通過樹狀結構，組合在一起，形成了乙個完整的架構解決方案，共同完成業務的目標。這就是技術，業務和架構之間的關係。
看了這幾篇部落格收貨很大，值得去認真思考反覆理解。
架構漫談讀後感
應老師的推薦閱讀了由資深架構師王概凱 kevin 執筆的系列專欄 架構漫談 9篇文章遞進地講述了 討論什麼是架構 怎樣做好架構 軟體架構如何落地 如何寫好程式等問題，文章生動形象多次舉通俗的例子讓本來生澀的知識變得更加容易理解，感觸頗多。對這系列文章印象的較深的一點是 一直在挖掘一些本質的東西，對一...
架構漫談讀後感
花了一周的時間利用課餘的閒散時間，總算看完了王概凱的架構漫談，這九篇部落格從相對全面的角度對架構進行了概述。自己也對架構有了更深一層的認識。感覺作者在部落格裡提到的對架構的理解對我們初學者來講幫助其實很大。架構其實就是根據要解決的問題，對目標系統的邊界進行界定，然後對目標系統按某個原則進行切分，接著...
架構漫談讀後感
這學期新開設了軟體體系架構這門課，學這門課之前架構漫談的九篇部落格進行了閱讀，對這門課以及架構設計進行了初步的認識與了解。通過對這幾篇部落格的閱讀，首先需要明白什麼是架構，在最早期，每個人有自己的生活方式，人與人之間相互獨立，不相往來，隨著慢慢的發展，男女共同生活，也就出現了各自的分工，有的人做這個...