Sean Wallbridge
Note, this isn’t a technical discussion. I’m not going to go deep into discussions about web applications vs. managed paths, SSL, etc. when scaling up or out. I simply wanted to share how we named our SharePoint web applications and subsequently became the same advice we give our clients.
So here we go. First off, I’m talking about the URL your users connect to, to get to the web servers in your SharePoint farm (still often referred to as WFE’s but factually incorrect these days.
E.g. Here’s ours: https://go.itgroove.ca
Why Go?
- It’s short – less to type, helps with keeping URL’s shorter (that can sometimes be a factor in some environments with firewalls, etc.)
- Simple – easy to remember, easy to type, easy to explain
- Organic – it can be used in a sentence … “it’s the place you go, to find your stuff”
- Sassy – it’s easy to brand … example below:
Common Names to Avoid?
- SharePoint: for the love of God or Allah, don’t call it http://SharePoint. What if you change platforms one day (though seriously, who would leave SharePoint? ;). And if you have some open source religious zealots, they will refuse to use it just by the name of it. And, sadly, there are folks out there that don’t like SharePoint due to past experiences … Not because the platform failed but because it was implemented poorly.
- Intranet: SharePoint can be so much more than an Intranet so why confuse those who connect to it or stunt it’s potential?
- Portal: see Intranet
- ServerName: Seriously? Whenever you see this, you can count on the fact that SharePoint was installed in demo/standalone mode … You can count on other stuff being poorly thought out as well. Try load balancing with this name as well 🙂
Good Names
So, I like “go” and a number of our clients have adopted this (along with “my” when scaling out ups/my sites). But that doesn’t mean other names aren’t possible. When planning your web application names, think about the following:
- Keep it short: lengths of URL’s can matter so the shorter the better
- Keep it generic: don’t stunt the potential of the framework/platform with the name
- Seek out a personality: something that logo’s well. You need to “sell” the platform to your users, so a sassy logo/personality goes a long way to introducing something new/flashy/hot
- Get permission/feedback: it’s not a lot of fun going back and updating documentation, system settings, etc., if a name you chose was not cool with management or your project stakeholders