在中國的同行中經常看到：要么不重視軟件架構，要么過分重視乃至捧為天書。如果要是碰到一個不懂技術的項目經理強行推行新技術有會有何種效果呢？
其實在做系統架構時，有時候會常常忽略以下幾點：
1：軟件的架構在大的方向上是固定的。
這種固定依據某些基本固定的軟件模式（包括設計模式、編碼模式或者某些特定的約定）來強化和固定。這使得軟件開發在某種程度上具有某些可以明顯看得到的風格，這個風格被整個的項目貫穿和堅持，這樣當我們進入通常可怕的維護或者調整的時候，我們不會害怕我們在很多種不同的實現中常常迷失了方向。
2：軟件的架構在具體的應用中可以適度的可控靈活。
毫無疑問，軟件設計開發不可能沒有例外，在某種程度上保留一些適度的靈活時必要的。一方面，它符合軟件開發的實際；一方面，適度的可控靈活體現了一種對實現者的尊重和信任。然而，如何實現可控的靈活呢？通常，我認為可以考慮有限種類的設計選擇并通過有色彩的圖形來表明這種可選擇性。但即便如此，設計者很重要的要考慮這些不同選擇之間的關系，以及這些選擇和整體設計的兼容性，這個時候，面向接口的設計和適度的“粘合”設計是必要的。
3：架構設計的支撐。
架構設計通常會涉及到一些支撐設計，這些設計和實現水準直接的體現了系統的最有價值的部分，更細的劃分我們應該可以看到性能和結構相關的部分，以及必要的基礎類。通常，作為設計人員，我們應該能夠設計并實現系統的性能、結構、擴展、粘合等部分的工作，這部分的工作通常不應該離開設計人員的控制和把握，這些代碼的書寫或者至少積極的關注是設計人員必要的素質：我們不應該讓更多的看到我們無法寫出代碼來（我也反對沒有分工什么都做的設計人員！），實際上，這是軟件最困難也是最有樂趣的地方。特別是在測試結果中發現這些設計實現帶來的性能的極大提高的時候是非常有成就感的事情。至于基礎類，應該是盡可能的減少依賴和耦合的。架構設計的支撐要盡可能的對客戶程序員隱藏不必要的中間細節，對基礎類要盡量簡單、穩定并真正需要。
通常，新興的技術會用在架構設計的支撐設計里面并被封裝以隱藏具體的實現，而通盤應用新興技術的風險是巨大的，并且對人員的獲得也是問題。有些技術是可以提供替代技術的，一些新興的技術實現也是可以參考的（但未必采用她的實現）。要記住軟件開發是需要速度、質量、可維護而不是技術表演，這個度應該由分析設計人員負責任的來把握。
4：面向業務還是面向頁面的。
也許這種說法會招致一些人的反對，認為自然而然的應該是前者，然而，實際的情況是，我們常常看到打著業務的幌子實現為面向頁面的系統，原因很簡單：后者更加的“簡單”并似乎有更少的代碼和工作量。這在某種程度上是對的。然而，區分這兩種不同的設計是必要的，盡管你也可能使用了MVC2的架構，但你可以做出面向頁面的設計的。觀察我們的軟件開發，最先提交的代碼未必是最少的代價的代碼：我們常常可以發現一些項目總是在那些不起眼的地方不斷的“修改”，我們的程序員因此好像很忙，但對我們的項目對公司來說這是糟糕的不必要開銷。因此，考慮這兩種可能的情況，在做出選擇之前加以思考是必要的。
5：用團隊和別人的眼光考慮問題。
實際上，每個項目都是有所差異的，特別是人的差異。很糟糕的是，我們通常不得不面對人力資源的極大壓力，特別是這些人之間常常都沒有共事的經驗也就是常常是臨時組成的，而這些人員也通常也缺乏一個軟件開發的基本共識：對標準的遵從哪怕是最簡單的Java編碼規范和對自己提交的產品的簡單備注和測試都是缺乏的而通常又沒有達到代碼就是文檔的水準。在這個時候，用團隊和別人的眼光考慮問題就是必要的，這實際上就是取技術上的“交集”，也就是走簡單的路線。如果沒有選擇的時候，培訓工作就是非常必要的。
用團隊和別人的眼光考慮問題也會有其它的問題，特別是當項目壓力如進度壓力等來臨的時候或者項目成員根本不考慮公司整體和長期利益的時候，這個問題很突出，有時候作為分析設計人員你甚至很難解決，特別是你面臨剛才我所提到的“沒有Java開發實際經驗甚至缺乏軟件開發經驗的項目經理試圖控制技術的時候”更加如此。
軟件架構的設計說起來簡單，也可以說起來復雜，然而，如何把事情做到簡單并且把其中的針對性能、分層、粘合、擴展等處理好，并提供可控的靈活性不是容易的。通常，只有多一些經驗和教訓并能夠在軟件代碼上加以實現核心的才可能成為好的分析設計人員。