Roger Jennings on Access/Sharepoint

#1

http://www.quepublishing.com/article...aspx?p=1606238

I was very dismayed reading this article, is it makes it pretty
clear that in-house hosting of your Sharepoint server with Access
Services to support browser-based Access apps is something only
large companies will be able to afford, because the pricing and
licensing for the Enterprise version is very, very steep.

The alternative is hosted Sharepoint/Access Services, and the costs
don't seem terribly high.

It seems to me that the pricing is upside-down. Big enterprises
don't want to deploy Access apps in the browser -- they will build
their own .NET apps, browser-based or not, because they have the
expertise to do that, and adding the capabilities of Sharepoint 2010
does not really save them money (because of the 64-bit requirements
of Sharepoint Server 2010, it could vastly increase those costs for
organizations with legacy hardware).

The features of Access 2010 used in conjunction with Sharepoint 2010
seem to me to be most compelling for small businesses, but the
market segmentation of the product makes it entirely
cost-prohibitive for medium-size and small businesses.

I don't know if I could sell clients on hosted Sharepoint/Access. I
have been able to sell clients on hosted Exchange, and it's been
very successful, but that's just a variation on the model of having
your email hosted by someone else, so it's not a paradigmatic
change. Having your flagship database applications hosted outside
your local LAN seems to me to be a big leap, and a hard sell.

So, in general, the whole marketing strategy seems to have been set
up to insure that the whole things fails to attract the target user
population, i.e., small and medium-sized businesses.

Thoughts?

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#2

David W. Fenton wrote:

Quote:

http://www.quepublishing.com/article...aspx?p=1606238

I was very dismayed reading this article, is it makes it pretty
clear that in-house hosting of your Sharepoint server with Access
Services to support browser-based Access apps is something only
large companies will be able to afford, because the pricing and
licensing for the Enterprise version is very, very steep.

The alternative is hosted Sharepoint/Access Services, and the costs
don't seem terribly high.

It seems to me that the pricing is upside-down. Big enterprises
don't want to deploy Access apps in the browser -- they will build
their own .NET apps, browser-based or not, because they have the
expertise to do that, and adding the capabilities of Sharepoint 2010
does not really save them money (because of the 64-bit requirements
of Sharepoint Server 2010, it could vastly increase those costs for
organizations with legacy hardware).

The features of Access 2010 used in conjunction with Sharepoint 2010
seem to me to be most compelling for small businesses, but the
market segmentation of the product makes it entirely
cost-prohibitive for medium-size and small businesses.

I don't know if I could sell clients on hosted Sharepoint/Access. I
have been able to sell clients on hosted Exchange, and it's been
very successful, but that's just a variation on the model of having
your email hosted by someone else, so it's not a paradigmatic
change. Having your flagship database applications hosted outside
your local LAN seems to me to be a big leap, and a hard sell.

So, in general, the whole marketing strategy seems to have been set
up to insure that the whole things fails to attract the target user
population, i.e., small and medium-sized businesses.

Thoughts?

Everything you said. All I would add is that most corporate IT departments
will not deploy anything Access-based no matter what MS does to it.

#3

David W. Fenton wrote:

Quote:

http://www.quepublishing.com/article...aspx?p=1606238

I was very dismayed reading this article, is it makes it pretty
clear that in-house hosting of your Sharepoint server with Access
Services to support browser-based Access apps is something only
large companies will be able to afford, because the pricing and
licensing for the Enterprise version is very, very steep.

The alternative is hosted Sharepoint/Access Services, and the costs
don't seem terribly high.

It seems to me that the pricing is upside-down. Big enterprises
don't want to deploy Access apps in the browser -- they will build
their own .NET apps, browser-based or not, because they have the
expertise to do that, and adding the capabilities of Sharepoint 2010
does not really save them money (because of the 64-bit requirements
of Sharepoint Server 2010, it could vastly increase those costs for
organizations with legacy hardware).

The features of Access 2010 used in conjunction with Sharepoint 2010
seem to me to be most compelling for small businesses, but the
market segmentation of the product makes it entirely
cost-prohibitive for medium-size and small businesses.

I don't know if I could sell clients on hosted Sharepoint/Access. I
have been able to sell clients on hosted Exchange, and it's been
very successful, but that's just a variation on the model of having
your email hosted by someone else, so it's not a paradigmatic
change. Having your flagship database applications hosted outside
your local LAN seems to me to be a big leap, and a hard sell.

So, in general, the whole marketing strategy seems to have been set
up to insure that the whole things fails to attract the target user
population, i.e., small and medium-sized businesses.

Thoughts?

It will be a hard sell. If you want to share anything with vendors or

customers they will need a Sharepoint license to your site. With
hosting, that will be about $7.50 per user. It would be useful for a
company that is located in NYC and another in LA to share some common
info between a few users. Applications would certainly be limited in
scope. Can you imagine a simple timecard program with 400 employees?
That'd be about 3K per month or 36K a year for the app. What company
would want to pay 36K for a timecard program?

I saw a very good app done in ASP.Net yesterday. It took several
develpers and a couple of years to do it. I will grant it was slick,
but I'm sure you'd want somebody offshore to do it due to cost of
development.

The concept of publishing an app to the web sounds nice. It simply
appears to be cost crushing to any small business.

#4

Personally, I don't see the point in Access in Sharepoint and to be
honest I really never have. If it's a web app, then use one of the
many tools available to build a web application to a shared (with
Access) hosted database somewhere. If it's not a web app, just multi-
user, then Access is a great front-end to most shared back-end
databases (SQL, mySQL, ect). If it's a database that has local tables
and still shared.... Get a new developer who what they're doing! (A
"Shared" Access front-end is *always* a bad idea.)

I wonder however, if some of the "big" web players (such as Rackspace)
who are now offering Sharepoint to their customers are behind this
"push" for Access on Sharepoint. These sort of companies really don't
(and don't want to) understand what databases are all about. They are
all about "the bottom line" and would rather be able to say that
"_All_ of Microsoft Office" is available on their Sharepoint servers
then qualify it to just some applications.

#5

Rick Brandt <rickbrandt2 (AT) hotmail (DOT) com> wrote in
news:i474sn$e1h$1 (AT) news (DOT) eternal-september.org:

Quote:

All I would add is that most corporate IT departments
will not deploy anything Access-based no matter what MS does to
it.

This is the thing that makes it seem to me that the whole marketing
strategy is doomed for failure. Access has a terrible reputation
(completely undeserved) among the people who make the purchasing
decisions in large IT organizations. They aren't going to give
Access a second look because they never gave it a FIRST look (if
they had, they wouldn't be against it).

Does anyone know if there are any plans to package Sharepoint with
Access Services in the Small Business Server edition? That would be
the right way to do this, seems to me, and would definitely get the
product into the hands of the clients I have who could most benefit
from it.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#6

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:h_WdnaXTk7ZB_vrRnZ2dnUVZ_u2dnZ2d (AT) earthlink (DOT) com:

Quote:

The concept of publishing an app to the web sounds nice. It
simply appears to be cost crushing to any small business.

This is precisely my point -- the new features don't scale to large
enterprises license-wise, and are prohibitively expense for small
businesses.

So, what's the market?

Absent a Small Business Server including Sharepoint with Access
Services, I think it unlikely this bandwagon is going to be boarded
by any significant number of Access developers (and the medium-sized
and small businesses they mostly work for).

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#7

Chuck Grimsby <cgatgoo (AT) gmail (DOT) com> wrote in
news:7a5a1c9a-4bab-4429-8c9c-e007978f6209 (AT) z28g2000yqh (DOT) googlegroups.co
m:

Quote:

Personally, I don't see the point in Access in Sharepoint and to
be honest I really never have. If it's a web app, then use one of
the many tools available to build a web application to a shared
(with Access) hosted database somewhere.

Uh, have you been paying attention at all to how an Access web app
with Sharepoint Access Services actually work? It's substantially
easier to develope than, say, an ASP-based app. It brings the RAD
capabilities of Access for building desktop apps to the sphere of
browser-based apps.

Of course, it does this at the expense of enormous dependencies on
Sharepoint and limitations in what you can put in your Access app,
but it's no less the case that you have those dependencies and
limitations if you go with an ASP-based app or build it on LAMP, or
whatever.

[]

Quote:

I wonder however, if some of the "big" web players (such as
Rackspace) who are now offering Sharepoint to their customers are
behind this "push" for Access on Sharepoint.

I'm pretty sure they aren't offering Access Services, only vanilla
Sharepoint.

Quote:

These sort of companies really don't
(and don't want to) understand what databases are all about. They
are all about "the bottom line" and would rather be able to say
that "_All_ of Microsoft Office" is available on their Sharepoint
servers then qualify it to just some applications.

In general, I don't think Sharepoint *requires* them to know
anything about databases in order to provide the service. So far as
I can tell, the issue that's blocking them from offering the service
is licensing costs.

And I don't quite understand your point about them not understanding
databases, since they offer SQL Server and MySQL and PostgreSQL
already. They don't provide any support for those -- it's up to you
to know how to use them properly -- so I don't see how Sharepoint
would change that at all.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#8

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote in
news:%_0ao.49979$F%7.49913 (AT) newsfe10 (DOT) iad:

Quote:

I just don't see how the new capabilities address that at all.
Sharepoint Services don't magically convert an badly-designed
Access app into a good one.

I'm not try to make the claim that it helps badly-designed access
applications, but it does help management of them.

At the end of the day it's simply addresses the issue of who has
the latest copy of the document, and is it being centrally managed
and backed up.

I just don't see this as the main reason big iron shops hate Access,
and I simply don't see it as enough to cause them to give Access a
second look.

Secondly, you get the management part of this without Access
Services, right? That is, my understanding is that you don't need
Access Services except for web apps -- if you're just using
Sharepoint to manage the Access app distribution, that's part of
plain old Sharepoint.

Am I wrong on that?

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#9

"David W. Fenton" <NoEmail (AT) SeeSignature (DOT) invalid> wrote

Quote:

At the end of the day it's simply addresses the issue of who has
the latest copy of the document, and is it being centrally managed
and backed up.

I just don't see this as the main reason big iron shops hate Access,
and I simply don't see it as enough to cause them to give Access a
second look.

Well, it is certainly one reason. And, by using web based applciatons, they
certanly get rid of the wifi and bandwith hog issues. So, there is several
things in this pot of soup that does help the access case.

Quote:

Secondly, you get the management part of this without Access
Services, right? That is, my understanding is that you don't need
Access Services except for web apps -- if you're just using
Sharepoint to manage the Access app distribution, that's part of
plain old Sharepoint.

For the auto sync of the client application on startup, yes, you do need
access web services.

Thus, for the syncing of forms, or when you just change a report or query,
you need access web services. It essentially distills out every bit and part
(exactly like source code control add in does). That whole mess of separate
bits and parts is saved on the SharePoint site (behind the scenes). Thus
when any users goes to the access web site to get the client application,
then the whole mess is then distilled back into a single access database on
the client end (there is evena new file extension for this type of
application.

So, the concept of a published Access application is important here. When
changes are made to forms/reports etc, then ONLY the updated parts are
pulled down to anyone who has a copy of this published application. This
pull down occurs when they launch the client application. The push up part
is done when you hit the publish changes option. So this concept of a
published access database is very much reliant on access web services.
While standard SharePoint manages check in/ check out of documents like
word, managing ms-access in this single file mode fashion would amount to
single user use of that mdb file. Standard sharepoint would not detect that
the front end been changed and download those parts, you thus need Access
web services to do this distilling of parts in and out of access.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

#10

Albert D. Kallal wrote:

Quote:

For the auto sync of the client application on startup, yes, you do need
access web services.

Thus, for the syncing of forms, or when you just change a report or query,
you need access web services. It essentially distills out every bit and
part (exactly like source code control add in does). That whole mess of
separate
bits and parts is saved on the SharePoint site (behind the scenes). Thus
when any users goes to the access web site to get the client application,
then the whole mess is then distilled back into a single access database
on the client end (there is evena new file extension for this type of
application.

A simple automated update system or even doing something as crude as copying
the entire front end file from a master copy every time a user opens it
takes only a few seconds on modern networks. The idea that only the new
bits and pieces are pulled down for updates is no big savings in my opinion.

It's "cool and slick and all that", but I see nothing dramatic about the
capability. The fact that this capability requires an additional service
(at additional cost) makes it a net loser to me.