稍微解釋一下：我希望用DotNetNuke不但可以做Internet的東西，而且也可以做Intranet的業務；從目前的情況來看，一般來說，Intranet的業務邏輯可能比Internet的業務邏輯要稍微復雜一點——當然，這並不是確定的事情。在這方面做了一些探索，希望將之分享出來。
對於DotNetNuke來說，已經有了“安全角色”，“安全角色”在DotNetNuke中非常重要，是用來控制頁面和模塊權限非常重要的概念，在我們的系統中，安全角色和權限，形成了一個權限矩陣，通過這個矩陣，我們可以方便的控制權限。
（通過安全角色，我們擴展了模塊的權限，從而使權限更加豐富）
當然，由於Administrators這個組對所有的權限都有默認允許的，所以有的時候會給我們帶來一點困惑，不過，和這種方式給我們帶來的好處相比，困惑是微不足道的。
安全角色，對我來說，理解為更高級別的用戶分組，這種分組，是為了更好的控制系統級的權限的。但是，對於我們一般的 Intranet應用，比如一個內部辦公系統來說，只有這種分組還是不夠的，必須要有一個組織架構的概念，所以，下面這幾章，我們將來講解一下，如何通過 DotNetNuke來增加一個組織架構。
組織架構，一方面是用來將人員進行更有效的分組，另一方面，也是為了進行數據級的控制（而不是頁面級和模塊級）。
下圖就是一個組織架構的例子：
其實，基本上只要是做過Intranet應用的朋友，應該都會接觸過組織架構，我們這裡的組織架構，相對來說，也是最傳統的組織架構：無限分級、支持部門、組別、可以排序、可以進行人員調整等等。無非是將我們一而貫之的組織架構引入到DotNetNuke中而已，除此之外，別無新鮮。
對於我來說，引入組織架構，是為了在進行業務審批的流轉的時候，可以更方便，比如，可以出現如下圖的流轉界面：
如果在上圖中，下拉列表中出現的不是一個這樣的組織架構，而是DotNetNuke的安全角色的話……，我個人覺得會非常混亂，而且，系統級的權限，和數據級的權限混合在一起，使整個系統非常混亂，我不喜歡。
關於這個組織架構的模塊，我一度想將之做成單獨的模塊（也就是DotNetNuke4.8.X版本之後，在安裝某個模塊的時候，可以檢測另一個模塊是否存在，以及版本是否正確，如果不存在依賴的模塊的話，則新模塊可以不允許安裝），可是，最終，我還是將之打包成了一個統一的模塊。我個人並不喜歡這樣，如果有時間的話，我仍然會將之獨立拆分出來，作為一個獨立的模塊；或者，如果可能的話，作為網站管理下面的一個管理模塊，這樣，才更正規一些。
下面的章節，我們來介紹，如何在DotNetNuke框架下將這個模塊實現出來。
