作者：門西蒂西·卡斯珀（MncedisiKasper）
應用程序的支持和維護永遠都不應該是事後才考慮的事情。由於應用程序超過80%的生命週期都是在維護上，在設計時就應該多多關注支持（support）和維護（maintenance）的問題。忽略這一點，你將會驚恐萬分地注視着寄予厚望的應用程序停止工作，宛如失控的野獸，跌入恐怖的死亡深淵，成爲你架構師生涯中無法抹去的敗績。
設計應用程序時，大多數架構師主要站在開發人員的角度思考，他們手上有IDE和調試器。當問題出現時，高度熟練的軟件工程師會進行調試來發現錯誤。由於架構師大多出身於開發人員，而非系統管理員，他們很容易會按這種思路來考慮問題。不幸的是，開發人員和支持人員擁有的技能不同，就像開發/測試環境和生產環境有截然不同的目的一樣。
下面列舉了系統管理員會遇到的一些問題：
- 系統管理員不能重新提交請求消息來重現問題。在生產環境中，也不能對“線上”數據庫重發資金交易來查看何處出了問題。
- 一旦應用程序進入了生產環境，修復錯誤的壓力來自於客戶和管理人員，不是項目經理和測試團隊，而憤怒的總裁將意味着更大的威脅。
- 一旦投入使用，就沒有調試器可用了。
- 一旦投入使用，部署工作就需要進行計劃安排和協調的。無法把生產環境中的應用程序停幾分鐘，來測試錯誤修復的情況。
- 生產環境中的日誌記錄級別要比開發環境中的低得多。
如果支持規劃存在此種缺陷，就會出現下面這些症狀：
- 大多數問題都需要開發人員的參與。
- 開發團隊和支持團隊之間的關係很疏離沉悶，開發人員認爲支持團隊不懂技術。
- 支持團隊討厭新的應用程序。
- 架構師和開發團隊在生產環境上花了很多時間。
- 經常把重啓應用程序當作一種解決問題的辦法。
- 管理員總是在救火，他們永遠都沒有時間把系統調整到合適狀態。
爲了確保應用程序脫離開發人員之手後能成功運行，應該做到：
- 理解開發人員和支持人員確實擁有不同的技能。用
- 在項目中儘可能早的引入支持負責人。
- 將支持負責人作爲團隊的核心成員之一。
- 讓支持負責人蔘與規劃應用程序的支持。
如此設計，則技術支持人員的學習曲線是最小的。可追溯性（Traceability）、審計和日誌記錄至關重要，當系統管理員很開心時，大家都會開心（尤其是老闆）。