Its a question that a lot of people are trying to
answer at the moment - or variations on a theme.

As a bit of background I work as an Information management  consultant for a
software development company  which has been involved in building an
enterprise knowledge management system over the Microsoft platform (SQL 2000
at the core). I principally work on business analysis and information
modelling, although I'm quite familiar with MS technologies in this area.

They key thing is: What do you mean by "document management"? Do you mean
check-in, check-out version control/approval of documents (along the lines
of a "library metaphor") or do you mean simple access to documents within
your organisation? If its the former then:

1. Exchange Public Folders are highly inappropriate.
2. A Corporate Intranet would most likely become an unmaneagable sink for
documents - and would not solve the problem of information retrieval, much
less deliver a stable environment for real document  management.

Neither are true DM systems. If you give me a secure mail address - I'll
send you a very large  document which explains DM properly and is ideal for
answering some of the issues you have raised. Its probably the best thing I
have come across in this area.

In my opinion (and its only that), SPS is a very good low-end DM system. One
of its great advantages is that it integrates well with the Office desktop
platform. This is generally what is meant by the term "integrated document
management". Ideally, your organisation needs XP on the desktop to get the
best out of either SPS or team  Services, as I was told by someone with MS
that the development team on Tahoe finished too late to integrate seamlessly
with Office 2000. However, Office 2000 is fine for DM services via SPS
(although you'll have he overhead of installing client components throughout
the organisation).

As you point out SPS v. 1.0 is not that scaleable. Its major problems here
are: (a) the dashboard engine is slow (mainly because of the ASP model) when
you have a significant number of users hitting a box. Estimates vary but
people say you can only reliable run 300 users off it. I have a good
independent evaluation of DD performance which again I can send to you if
you give me a mail address. (b) The back-up and recovery is problematic in
SPS 1.0 and replication is non-existant. Where this really hurts is in
constructing a unified information model for the organisation - i.e. it
doesn't really scale to the enterprise (although for enterprise search its
Ok-to-good). By this I mean that in a typical large-to-medium size
organisation you might well have to construct a number of separate
workspaces (with varying information models) across different boxes. This
means that SPS will not be consistent for information retrieval using
anything other than full-text index (which has definite limitations on large
document collections).

So it very much depends on whether your deployment  of a DM system is aimed
at a large organisation which is distributed. For this, you need to plan the
deployement issues around SPS VERY carefully to get the best value out of
it. However, in general as a standalone point-DM solution at the
departmental/divisonal level I think SPS is a very cost effective solution
(with the proviso that you don't have to rush out and buy Windows 2000 and
Office 2000/XP licenses). It certainly beats the hell out of the heavyweight
DM systems out there (who shall remain nameless, but they know who they
are!), as a functional system.

I'm afraid on Team Services I'm not that familiar, so can't really comment.
But as I understand  it this is really intended as a specific point solution
for teams.

A few additional comments:

1. MS Search is improving rapidly, and in SPS is a vast improvement on
earlier versions (i.e. Index Server, et al.). MS really have put  some effort
into this (and again I can mail you some information on the origins of
this). I happen to know that there is a book detailing MS Search which is
scheduled to come out fairly soon which really delves into this bit of the
MS platform. MS Search within SPS solves the old chesnut of information
retrieval "umms and aahhs" vis-a-vis the "magic bullet" of the well-known
probablistic search engine (which again shall remain nameless, but is NOT as
good as it claims to be). I'm also very interested in MS Search's ability to
use a taxonomy in query expansion, and want to test this.


2. I'm working on devising an information model for SPS at the moment,
just to test (a) auto-categorisation (which could be a massively useful
feature of SPS in an information rich environment; and (b) to see what the
limitations of using a decent model are within SPS. However, I think its
certainly adequate, and one of the things  I like about SPS is its ability to
provide multiples views (i.e. web  folders and dashboard) to navigate to
information. This alone will help  users to find the ifnormation they are
looking for. In additon, the security model is adequate.

3. Finally, according to MS they are working on the scaleability of SPS
for r.2. Its one of their design goals for the next version. I'm also very
interested in its ability to use  a taxonomy in query expansion, and want to
testt his as well.

I know this dosn't answer your question entirely, but I think you might need
to define the shape and size of your organisation a little better in your
mail so its possible to envisage the business requirement.

This is a great summary and I would appreciate it if you could send me a
copy of your DM document  to the email address below.

With regard to your comments, I agree whole-heartedly with your summary
and would like to make a few comments.

We have used SPS as a DM tool (check in, check out and authorise) for a
large international financial organisation and have managed to get
around some of the limitations by creating multiple workspaces (one for
each division within the organisation) and using the SDK to create ASP
pages instead of using the dashboard. The result is that the user
interface is much faster (up to four times faster), but you lose the
benefit of multiple views. In our case, speed was more important and
the client only wanted a single view for all users, so this was not
really an issue.

The real issue for us has been DR and load balancing. We generally tend
to use  a Cisco load balancer to front our sites, and in the case of SPS
this has proved to be impossible because of the fact that you cannot
replicate the SPS information store. Roll on SPS 2!

The other issue is one of security. If you intend to use SPS across
multiple organisations in multiple locations / countries (which we are
doing), it is an administrative nightmare to create and manage user
accounts. We are currently working on integrating a third party
security product  in light of this, but Peter should be aware of this if
he is planning to do a roll-out across multiple domains.

We are also working on tests for auto-categorisation and I would be
interested in your findings.

To add to the discussion

1.
a. SPS is used for Central corporate  Portal with document  Management,
Search, web  part and workspace
b. STS is used for Team or Departmental Site, customization is mostly done
with FrontPage XP and document management  and search is very limited. SPS
and STS are product  that complement each other. Look at Microsoft to
integrate those product more tightly in future version. For instance at our
company, we developed web part in SPS that access STS info, for instance STS
is great to build a department calendar or tasks list where SPS doesn't
provide functionality  out of the box.
c. Public Folder is not a good solution,
d. Corporate Intranet, well SPS and STS can be viewed as a corporate
Intranet. Don't try to build your own, SPS and STS will give you the
plumbing and infrastructure you need.

2. If you are thinking of a small deployment  10-100 users STS is great,
don't try to use  it for a corporate intranet  as it might not scale past 1000
users. But search is limited  to content in the Team Site, where SPS can
crawl and index pretty much anything you want

3. SPS scalability is an issue, at the present time your are limited to ONE
server to server  workspace, indexing (which is very intensive) can be split
to multiple server, but workspace can only be housed on ONE server. There is
currently no way to replicate  content or use load balancing. Microsoft is
working on this for next release.
One alternative is to split workspace logically in your enterprise. For
instance, you can build multiple SPS server hierarchically and split content
between those. Check
<www.microsoft.com/.../overviewWP.asp
for
more detail on SPS/STS integration