根據維基百科的定義，『負責』是對自己的承諾，『當責』是對別人的承諾。
所以當責比負責更具深度、廣度，唯有實施當責，把對的事情做對，才能既有效果又有效率。
最近我們部門要新增一個特定的程式功能，因此小主管指派幾個人開始看新雲端架構的東西，並要求做出Demo好讓他報告。
但問題就在這！
本部門主要負責的是開發應用軟體；雲端架構的東西是由另外的部門負責。只因為架構部門的人力不足，所以這責任就落在我們應用部門的身上了。
在正常的情況下，應該是由架構部門去把新的架構做好，而我們應用程式無須任何更動，就能直接使用該功能。
因為架構層面的東西不若應用軟體，還要考量硬體設備、網路拓撲、使用者帳戶管理、流量控制、收費機制、容錯與備援等要素。這些關鍵因素早就在原先雲端架構中行之有年，應用部門自然也不懂得如何考量這些要點，只會單純的Coding做出個會動的程式，僅是個可以動的玩具，是不可能拿來做商業用途。
再者，一旦新架構出現問題，首先被砲轟的也一定是我們部門，畢竟程式是我們寫的。架構部門大可以袖手旁觀，就算想幫忙也幫不上。
問題回到根本，是一開始就不該讓做應該軟體的人來著手做新的架構。所謂『術業有專攻』，架構層的東西就該由架構部門去建置，箇中奧妙他們是瞭如指掌。而軟體部門就專注在應該軟體開發上，無須在意架構怎麼改。這才是達到軟體架構的『層層展開、層層負責』。正如物件導向裡所說的『封裝』，使用者不需要了解它背後架構是怎麼做，只要知道怎麼用就行了。
人力不足不是藉口，大主管應該想辦法補齊架構部門該有的資源，而不是如此挖東牆來補西牆。事情有人做，只是『負責』；要讓對的人做對的事，才是『當責』。
