If you're providing any kind of services dealing with sensitive information, do not hesitate to use SSL (accept nothing less , even if the underlying network is using IPSec, like it should).

Also, guard sensitive data with your life (do a search here on perlmonks about ideas for securing credit card data, i'll find a link and put it here)

Also, backup!
as in have a few backup machines (a replicated database server, as well as a backup app server -- some kind of load balancing is best)
as well as make lots of backups (got data? back it up! do it often! keep it secure!).

Set it up now, fine tune it, so in the future, when the company blows up, all you have to do is buy a few more machines, configure them, and all is well.

I listened to some yahoo dude give a presentation on DBIx::DWIW, and one of the features of the module is if a database server goes down (unreachable for an x period of time), the application automagically switches a backup database server (well if you provide one of course ).

In this particular case, the database of choice was mysql, with replication set up, so after one database goes down, another was made a master (there can be only one, it's the only db you write to), and the other backups kept replicating off of it. All session data was being saved in the database, so the user might notice an error message saying reload, after which at most he might need to re-imput at most a single page of data (if he's filling out a form for example, thus saving the user grief, cool ey ;)

That is gooood strategy
• detect failures (machine gone down)
• switch to backup
• notify admin
• do not blow up, never blow up (sounds good, endusers like it)

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! ** The Third rule of perl club is a statement of fact: pod is sexy.

I havn't attended the School of Hard Knocks WRT intranets (or at least intrawebs). However, one thing to remember: Never authenticate based on what wire you're sitting on. By this I mean that you should never assume somebody is a legitimate number of your compony because they've established an Ethernet connection on your local network. I say this because of two reasons. First off, there's network jacks in the waiting room that you hadn't noticed behind that fake shrub. Secondly, there will be a day when that "wire" is a RF frequency.

Always authenticate before you give out any data you wouldn't give to anybody who came up to your reciptionist (or local eqiv) and asked.

Well what do you need to do with it? An intranet is a very loosely-defined entity -- in the simple case you might just have a firewall, hub/router, and some networked machines. Or you might require internal Web servers, database servers, print servers. Do you need to have applications running and communicating via some RPC mechanism? Do you require particular parts of the intranet to be exposed in a restricted manner to the public?

What sorts of projects will you be developing in .NET? If the project is not well-defined then I really do not envy you prototyping on that platform. Unless you've got some clear specs on what this thing is supposed to be capable of, I strongly recommend prototyping in Perl or Python, or at the very least on a platform that the developers already know, perhaps J2EE if these are enterprise types. (I guess I'm assuming that there aren't yet legions of .NET experts out there. I may be wrong.) The point though is that expectations are going to be fluid at least for a while, and you don't want your development tools themselves to be a hindrance, which is common with the more stodgy languages.

Finally, progressively ramp up your spending on hardware as the network's purpose becomes better defined and expectations rise. Don't go out and buy expensive servers before the project goes live, because you may find they don't do what you need or aren't where you want them to be. For example, a company I worked for a couple years ago went bust in part due to asinine spending policies such as purchasing superhigh-powered servers for a prototype e-commerce app that easily could have run off a normal desktop.

Bitter experince warning

Unfortunately, the term "intranet" has...

• become synonymous with "internal internet".
• gained a certain cachet or vogue with corporate media types.
• become a "thing to have" as and of itself.

What's unfortunate about this is that it has become, like so many other terms overloaded into the Corp::Media::Lexicon Class, a wooly, nebulous term that noone can quite put a handle on. Examples:

The company that commisioned Sachii & Sachii (or similar entity) to 'improve their corporate image'.

After much money and many surveys, the advice was

"Put pictures of puppies and 'groups of nice people in picturesque locations' in the Corporate brochures.

and "Oh! Add a vision statement". -- The company made sanitary wares!

Customer facing? Something to do with Feng-shui? An office where all the desks face windows?

Transparent? You mean that our customers can see through our hype?

Unless your company still requires the use of sneakernet for file transfer, or has an internal snailmail system for delivering inter-office memo's, the chances are that your company all ready has an "intranet". Of course, I realise that the term has much greater connotations that 'internal network', but the point I'm making in my own clumsy way is that an intranet as and of itself is not a 'thing to have'.

It is a piece or set of hardware and infrastructure that, when managed properly, can aid the company bottom line by improving the availability and timely dissemination of useful information.

Every word and phrase in that (rather stupid) sentence is important.

• It is a piece or set of hardware and infrastructure...

  This is the what.

  Essentially it is hardware. The main distinguishing factor is that it exploits the availability of a 'browser on every desktop' to obviate the need to write custom clients for every different networked application that is written.

• ...can aid the company bottom line...

  This is the why.

  Too many times, it has become a 'must have' item on the BoD's annual shopping list for no other reason that it's felt "we should have one". Unless there is at least notionally, some financial benefit to having one, it is likely to do the company more harm than good. It will never generate revenue, but there should be some demonstrable financial benefit from having one. Saying that it will save client development costs on company client server and/or MIS applications isn't good enough, unless there are some planned and they have passed a cost/benefit analysis.

  If it ain't a source, its a sink.

  Don't be the guy responsible when the sink flows faster than the source, you won't like it.

• ...by improving the availability and timely dissemination of useful information.

  Don't under-estimate the propensisty of companies of almost any size to generate prodigious amounts of data and for the producing departmental heads to believe that their data is 'required reading'.

  Data is not information.

  The cost of converting data to information is typically 3-10 times the cost producing or gathering it. You'd be amazed at the amount of time people will spend manually or programmically prettifying their local data for use on the intranet. Everyone and his dog will want to become a FrontPage guru.

  The higher up the corporate ladder the source of the information, the less likely the need for widespread availabilty but the more likely the unjustified desire to see that information disseminated. And the harder it will be to say no.

  If you can, try and get the BoD's or whomever the decision makers are, to agree to an abstract definition of types of information (and what constitutes "information") that should be made available and sustained on the intranet.

  Also, try and get pre-agreement that whomever (departmentally) is responsible for requesting that information be made available via the intranet, regardless of whether they are the producers of the raw data, is also responsible, in departmental financial terms, for the conversion, maintainance and verification of that information.

  That will reduce the demands from some departments, that other departments make their data available this way, without justifying the cost/benefit to themselves.

• ...when managed properly...

  Like all corporate projects, the key here is for the authority to go hand-in-hand with the responsibility. That means financial responsibility as well as the "who-screwed-up" kind. It's very easy for internal, non-profit departments, and their budgets, to be abused on mill of unreasonable demands and expectations. If the requesting departments have to pay for the things that they demand, even if only in internal funny-money terms, then they are much more likely to consider those demands and the costs of them more carefully.

  You can have it if you pay for it is a pretty good regulator. Just don't be tempted to

  1. accept more than you can chew in order to grow your department...there be dragnets there.
  2. to overprice the more mundane projects that come your way in the hope they will disappear, that will lead to the requesting departments "doing their own thing", which is never good, especially if they do it better than you:).

You need applications. One or more applications that would benefit in terms of availability, reduction in cost, or some other way, from the presence of an intranet, before you need the intranet itself. Ie. It's no good saying if we had an intranet we could do this or that. It really should be:

We have this existing use or application of data that needs to be re-written and would benefit from wider use and would be cheaper if we leveraged the web browser for the interface.

or

We have one or more MIS projects that have passed cost/benefit analysis and we could utilise a web interface to minimised development costs and provide universal coverage.

If you are the guy who neck is on the line if the project fails, it is important to make sure that those holding the purse strings are aware of the potential costs as well as the benefits. And that they don't see it as some magic bullet or corporate band-aid for some other ill (real or perceived). That pretty much means that you need to spell this out up front, in writing or in public, and that way (depite my loathing of the phrase) manage their expectations.

In my experience, more IT projects are percieved as failures because they didn't live up to unrealistic expectations, than because they failed to deliver on some technical specification, or went over time or budget.

It's a fine balancing act. Good luck.

Treat an intranet site the same as you would an internet site. Everything that you're read about building internet sites applies equally to intranets. The only difference is content.

Update: And banner ads. You'll get really unpopular if you use banner ads on an intranet.

Quothe dws:

Treat an intranet site the same as you would an internet site

With all due respect, I don't think this is correct; if it is correct, it's in a very subtle way that many people will miss (no sarcasm intended*). I've spent a long time designing intranets, and I like them. Here are a few major differences intranets and regular web sites:
1. On an intranet, you can assume greater user expertise with the interface (especially if you do some training). Your target audience is going to use the intranet regularly for their entire stay at the company. This means you can create a denser interface that doesn't hold people by the hand as much as some web sites have to.
2. Flipside, on an intranet the user's time isn't just money, it's your money. Every usability or information design mistake you make will cost your company money the second it goes live as users try (and fail) to find the information they need.
3. You don't have to market to your intranet users. This rule starts to bend at the enterprise level, but for 250 people it holds true. You don't need to put nearly as much screen real estate or graphical effort into branding as on a public web site. You've already sold these people - they work with you - so you can get right down to the nitty-gritty (e.g. finding information) faster.
4. On an intranet, you know exactly how much time you have to spend on accessibility or region-specific issues (e.g. languages). Chances are you know if one of your co-workers is blind, or can't read English. You can make a truly informed decision, something not possible on the web where you're at best playing with averages.
5. Likewise for client support. How many of your users use Lynx? Or Netscape 4? Is the company standardized on Mozilla? By knowing up-front exactly which platforms you have to support you'll save huge amounts of time debugging cross-browser issues.
6. Web sites don't typically allow their users to post primary content, but intranets should, so you must standardize heavily. Don't let it turn into a ransom note of 250 different styles. Don't even allow for the possibility of someone breaking your standards for information structure - that's a huge usability hit.
Lastly, have fun with it. Intranets, like web sites, have personalities, or voices. Your users will be more engaged if they feel like it's their intranet, not just something created by a faceless geek or marketroid.

(*By which I mean: the cardinal rule of web design is, "Consider thy users." Appropriate consideration of intranet users will lead you to many of the differences between web sites and intranets. So by that token, yes, develop them the same way. But it's a bit of a tautology.)
--
man with no legs, inc.

Here are a few major differences intranets and regular web sites:

You raise some good points, a few of which I'll take issue with:

Your target audience is going to use the intranet regularly ... This means you can create a denser interface that doesn't hold people by the hand.

We're venturing into web applications here, and to that extent you're correct. Applications that people use on a frequent basis can have denser interfaces. And you can deploy web applications on an intranet. I consider them separate but related beasts.

You don't have to market to your intranet users.

You may not have to sell to your intranet users, but you certainly have to market to them. Marketing is about letting people know what's there, and how it's useful to them. The email you get from HR reminding you that policy manuals are available on-line is a form of marketing. A sidebar on a main portal page listing key things that are new is marketing.

By knowing up-front exactly which platforms you have to support you'll save huge amounts of time debugging cross-browser issues.

True, though there always seems to be some fanatic who insists on running Netscape 4.7. :(

Web sites don't typically allow their users to post primary content, but intranets should, so you must standardize heavily. Don't let it turn into a ransom note of 250 different styles. Don't even allow for the possibility of someone breaking your standards for information structure - that's a huge usability hit.

Let's separate the points:

First, many web sites let you post primary content. We're in one right now.

The other point is whether having one consistent architecture and style maximizes usability. I don't agree that it does. While it's tempting imagine how wonderfully consistent and usable the world (or an intranet) would be if there were centralized control over style and meta-content (information structure), these impose a substantial hurdle on getting information out. In my experience, it's more important to get information out, even if it doesn't fit into an overriding structure. For big, semi-static entities like Human Resources, a common information structure makes sense. But for dynamic teams, I'd much rather let each choose whether they want to use some common mechanism, or whether they prefer to set up their own Slash/Everything engine, or even use MoveableType. Add some variety into the gene pool, and let natural selection do its thing. Starting off with a grand design is a form of premature optimization.

At the company I work for we use a WikiWiki (specifically TWiki, a Perl implementation) as our intranet.

The advantages are that everyone can make changes, but that these are logged and can be rolled back via a version control system. Before making changes, one has to log in so changes can be traced back to the people who made them.

It is used extensively to document the projects we're working on, which is easy since TWiki allows to upload files. People seem to like working with it, so the "threshold" to documenting seems to have lowered ;-)

In my opinion, it would definitely worth having a look at it as part of a solution.

Just my 2 cents, -gjb-

When you say intranet are you talking the internal network or the web services?

If you are talking the network, then as the others have mentioned it involves gear and management tools. However, I will add security and trend analysis. Retrofitting security is a nightmare. Been there; done that. On the matter of your network trends. You can't design a network if you don't know.

You may think it is slick designing all this web stuff and yet most of your traffic turns out to be simply storage access.

No matter which side the topic is huge. Finally, hope you have a "proper" budget. It's great managment wants it, but if they aren't going to pony up the cash....