對那些明白軟件架構很好，卻不知道如何將其引入項目的人而言，有一個比較常見的問題：
「我理解對軟件架構的需要，但我們的團隊沒有時間實施，因為大家都忙於為項目編碼。話雖如此，我們沒有一致的解決問題的方法，諸如此類。我們的經理也不會給我們時間做架構。做架構，就沒法編碼。該怎麼引入架構？」
為了理解軟件架構對主動思考的需要，有幾個問題值得一問。
1.缺乏軟件架構造成了哪些問題？
2.缺乏軟件架構在將來可能造成哪些問題？
3.這些問題是否有引發更多嚴重的後果（比如失去聲望、業務、客戶、收入，等等）的風險？
4.哪些事已經做錯了？
有一件事我會告訴剛接觸架構角色的人們，他們確實需要專門花一些時間在架構工作（大局的事務）上，但要與日常開發工作之間找到一個平衡。如果你所有時間都用來編碼，就做不了架構。另一方面，「軟件架構」花太多時間意味著你沒寫什麼代碼，可我們都知道漂亮的圖表對最終用戶毫無用處！
「我們該如何引入軟件架構」這類問題沒有一個簡單的答案，因為它要求軟件團隊改變工作方式，只有當你完全瞭解團隊的情況，才有可能。一般來講，團隊改變工作方式大致可以分為兩類。
1.被動型 ：大多數團隊只會在情況變糟的時候改變工作方式。換句話說，當且僅當有誘因時，他們才會改變。誘因可能是失敗的系統部署過程中的任何事，或者嚴重系統故障之類的事情。在這種情況下，他們知道有些事不太對，可能因為管理層讓他們日子不好過，他們也知道必須有所行動，改變這種狀況。可惜，這種方式在軟件行業裡佔了大多數。
2.主動型 ：有些團隊則積極地改進工作方式。即使沒有發生什麼壞事，他們也能看到改進的空間，防止陷入上面提到的狀況。諷刺的是，這些團隊往往很優秀，並不需要改變，但他們非常清楚持續改進帶來的好處。
回到原來的問題，團隊確實想花一些時間在架構上，但並沒有得到管理層的認可。也許管理層並沒有清楚認識到這樣做的好處或者不這樣做的後果。無論怎樣，團隊都沒有得到期望的結果。每當我自己處於這種情況時，我會採取以下兩種方法之一。
1.以非常清晰和簡潔的方式陳述當前的狀況，如果不做出改變，會有哪些問題、風險和後果。通常你會向主要決策者、項目資助人或管理層陳述這些內容。一旦他們瞭解了風險，就能夠判斷，是否值得為降低風險付出改變行為所需的精力。這要求很嫻熟的技巧，有時候也未必被接受，特別是剛接觸到一個你覺得不正常的團隊。
2.以身作則，發現並解決問題，包括缺乏技術文檔、解決問題的方法不一致、架構層過多、不一致的組件配置等。有時候，在所有人瞭解付出精力得到的回報之前，最初改變的種子就要到位，有點像大多數人第一次看到自動化單元測試時的反應。
每種方法都有各自適用的情況，這取決於很多因素。回到原來的問題，有可能使用了最合適的方法，但要麼消息很弱，要麼管理層不認為值得花這個錢去降低沒有專門「架構時間」的風險。對於這種情況，我會以積極主動、以身作則的姿態引入軟件架構。只要找到並修復一個問題（比如多種配置方法，沒有高層次文檔，混亂的組件結構，等等）。我不是說要放下工具停工幾個星期，因為我們都知道，想要說服管理層同意花三個月來重構太困難了。我的意思是，分解問題逐個擊破，一步步改變處境。每天花幾分鐘在這類任務上，在你意識到之前，可能已經有所改觀了。「請求原諒比得到許可更容易」。