大約兩年前，我們的組織開始在SharePoint路徑上。在此之前，我們（開發人員）主要爲SQL後端寫了asp.net前端。現在，似乎每次有新項目出現時，我們都會被要求「製作」它適合SharePoint;而且我們已經將一些東西塞進了SharePoint，由於複雜性以及與其他技術的交互，可能應該是獨立的應用程序或Web應用程序。WSS/MOSS開發......在哪裏畫線？
我的問題是：在SharePoint和Web/Winform應用程序中開發項目的位置如何？您如何說服您的經理SharePoint可能不是特定項目的最佳解決方案？
我有點贊同你，這有時是一個棘手的問題。不過，總的來說，我同意這個陳詞濫調，你只需要以不同的方式思考一個SharePoint應用程序。如果你的數據可以被認爲是基於列表的，那麼SharePoint可能不是一個壞的開發框架。看起來表面上看起來更多的工作，但海事組織面臨的挑戰只是從一個地方轉移到另一個地方。如果您使用自定義字段模板和Web部件之類的東西，則可以相對自然地處理各種數據。您可以免費獲得SharePoint的積極方面（已經成熟的安全框架，內置搜索，站點和列表模板/定義，個性化頁面定製，yada，yada）。
我也不知你所說的「複雜性和與其他技術的相互作用」在這裏的意思，所以很難想象當SharePoint加入到混合了可能被引入的具體問題。
如果你的開發團隊是與SharePoint相對缺乏經驗，你關心質量和期限，我絕對可以知道你的意思。這不是一個簡單的學習曲線，但我認爲SharePoint產品比許多人所稱讚的更自然地可擴展。
有一點需要努力「整合」新的應用到現有池是否有數據（客戶，存貨等），將來自合併中受益任何重疊時需要考慮的。
還有的能夠備份多個應用和所有其各自的數據在一個地方的利益。
在某些情況下，在SharePoint應用程序和ASP.NET應用程序之間有第三個選項。您可以構建自定義網站和應用程序頁面並將其部署到SharePoint網站。 （Inside Windows SharePoint Services 3.0一書很好地概述瞭如何做到這一點。）這將允許您在SharePoint環境中使用ASP.Net和SQL Server（這意味着您還可以利用SharePoint安全性等）。這不像開發一個普通的ASP.Net應用程序那麼簡單，但它是一種折衷。
當然，這是排序，如果他們希望這些新的應用將SharePoint技術（列表，庫，工作流程等），而不是僅僅是「內部」的SharePoint建立了一個技術性的。
他們爲什麼要求全部進入SharePoint？
在我的經驗，這是因爲「OLE的SharePoint內部網是作爲一個偉大的門戶網站，把一切都在一起，一個信息架構下容易找到。
從組織中的應用空間的使用感知來處理問題。
只要應用程序的外觀和感覺與Intranet站點的一部分一樣，並且用戶不必考慮如何實現它（以及如何恢復），則幾乎可以採取任何體系結構決策在實現和維護時，必須爲組織提供最好的回報。當我們開始考慮從SharePoint vs其他的東西到信息架構，可發現性和可用性這些漂亮的概念時，我們決定不讓它實際在SharePoint內部，但仍然像Intranet一樣皮膚變得更容易賣。
其中一個主要的原因，你可以把在SP的應用程序是有，當你想利用積木優勢SP爲您提供：