Planning For The Next 10 Years: Strawman

[(PeteCresswell)]

One of the MS Access apps I've developed started out as a
bare-bones data repository to hold facts about a single bond
fund.

Scope creep and double-digit growth in the client's business
over the last year has nudged it into being a full-blown trading
system used by a half-dozen traders and three analysts serving
two funds.

Now they're talking about it serving "thousands" of funds -
probably still for a relatively-small, localized group of
traders/analysts. Tens of users, but not hundreds.

A couple of the other apps aren't far behind.

For both the very near future and for the next 10 years the
clients have several concerns:
-------------------------------------------------------------
1) Response Time. These guys are overworked and under paid.
Two-second response time is not going to cut it when they
start having to process beau coups transactions. One-second
isn't either. I've put some time into tuning this thing,
and it performs well when run single-user on C: sub-second
response time on everything I've measured.

But over the LAN, even single-user, it's unacceptable for
heavy use.

2) Scalability. More data, more users - but tens of users,
not hundreds.

3) A "real" Back End. Justly or not, IT spits on JET
and pressure to move to SQL Server will continue;
regardless of which platform is more appropriate for
the immediate situation.

4) Deployment/Accessibility. Wifi cards are here and in
use. MS Office comes out with new releases... maybe
not breaking old Access apps... but definitely requiring
some intervention/hand holding.

5) Continued Development. MS Access people are sort of
a specialty niche in the IT world. OTOH everybody
seems to know/do .NET and/or VB6.
-------------------------------------------------------------



Here's the skeleton of the spiel I'm working on.

I'd appreciate some comments before I commit to it with the
clients.
-------------------------------------------------------------
1) Response Time: Move to Citrix ASAP. It's a no-brainer.
Guaranteed improvement. The bigger and badder the box,
the better the response time.... and these guys will be
happy to spring for the biggest and baddest if it'll
deliver the goods.

Moving to SQL Server *might* speed it up a little, OTOH,
it might slow it down.

Citrix ASAP.


2) Scalability: Migrate to SQL Server in due time, but don't
rush it.

Horses for courses.

JET is a VW Passat. SQL Server is a two-axle dump truck.

At some time they'll hit the crossover point, but nobody sb
in a rush to haul 250 lbs of sand in a two-axle dump truck.

In moving to SQL Sever tables and stored procedures
understand that:

- The move will cost between 1/3 and 1/2 the total man
hours it took to develop the application in the first
place

- Ad-hoc changes will become a fond memory, and
turnaround time on data structure changes will
be significantly greater.

- Care and feeding will become an ongoing need/expense.

- Your group will now be dependent on the SQL Server
administration group rather than having one
over-caffeinated person at their beck and call
whose only response to the command "Jump!"
is "How high?"


3) A "Real" Back End. Ditto #2.


4) Deployment/Accessibility: Citrix will address that
100%: anybody with a web browser can now run the
app - even people on MacIntoshes and those running
Linux.

Citrix ASAP.


5) Continued Development: Even though VB6 is probably more
appropriate in the technical sense - considering local
users and deployment via Citrix - it seems to me like
.NET *might* be a better choice bco the wider availability
of expertise.

Seems probable that at some point, VB6 will become enough
of an antique that they'll migrate to .NET in spite just to
have people readily available who are familiar with the
development environment.

Might as well avoid that second conversion effort by going
to .NET in the fist place.

I'm thinking me and/or a guy I've been working with farming
it out screen-by-screen to somebody in, say, Bangalore.

We'd have the best specs: a running example.... and
plenty live test data for parallel testing.

OTOH, it seems like .NET could introduce a bottleneck
with it's XML data transfers that would hold back
potential gains via Citrix. Truth? Fiction?
-------------------------------------------------------------


Finally, if they go for the Citrix bit, I plan to say that:
-------------------------------------------------------------
1) We want our own box. Still administered by the Citrix
group, but dedicated to us. If we want bigger and badder,
we pony up and the box gets bigger and badder - but nobody
else uses it.

2) We need extensive hand-holding. If you took everything I
know about Citrix, rolled it into a ball, and set it on the
edge of a razor blade; it would look like a golf ball in
the middle of the New Jersey Turnpike.

There's no way that just giving us a box will work.
We have to have expert and detailed support for the move.
-------------------------------------------------------------


That's my story.

Should I stick to it?

 

[David W. Fenton]

That's my story.

Should I stick to it?

I think you're underselling Access as a long-term front end. I see
no reason whatsoever to redevelop on another platform.

 

[Rick Brandt]

In moving to SQL Sever tables and stored procedures
understand that:

- The move will cost between 1/3 and 1/2 the total man
hours it took to develop the application in the first
place

- Ad-hoc changes will become a fond memory, and
turnaround time on data structure changes will
be significantly greater.

- Care and feeding will become an ongoing need/expense.

I have never found any of these to be true with a SQL Server back end.

 

[(PeteCresswell)]

Per David W. Fenton:

I think you're underselling Access as a long-term front end. I see
no reason whatsoever to redevelop on another platform.

That would certainly be my lowest priority.

But I see three considerations (NB I did not say "self-sufficient
reasons to do it")...-)
---------------------------------------------------------------
1) New releases of Office. Every time a new version gets
pushed out, somebody has to be on the case to make sure
the application still functions. To the technically
knowledgeable, small change.... but if the users click an
icon and the app doesn't start, that's a big deal to them.

2) Ongoing expertise. Seems like .NET expertise is almost a
commodity anymore. Certainly just about every developer
in the client's IT department is proficient. MS Access,
OTOH, for all it's advantages, is not (in my experience)
understood by IT organizations. It's sort of a specialty
skill. Good for me... but not so good for the client
in the long run once I hit the lottery and elope to Maui
with Miss Something-Or-Other.

3) WiFI/WAN/Internet. Personally, I consider this bogus
in light of Citrix. Brave words from somebody who knows
nada about the product except that I've seen in work with
a couple of apps and I liked what I saw..... But if somebody
wants this app tb available over a WAN, over the Internet, or
even to laptops connecting to the LAN with WiFi cards - and
it's not available via Citrix or some functional equivalent -
then that's going tb a problem that my (extremely limited)
knowledge of .NET suggests will go away if the app is
running as a .NET app with XML going back-and-forth and
all that...
---------------------------------------------------------------


I would tell anybody, anywhere that MS Access as a front end is
often very much under-rated. It offers rapid development
turnaround like nothing else, and as long as everybody's
running the right version of MS Office (with Access installed)
deployment is a snap.... What could be easier than
dragging/dropping a single icon onto somebody's desktop?

 

[David W. Fenton]

Per David W. Fenton:

That would certainly be my lowest priority.

But I see three considerations (NB I did not say "self-sufficient
reasons to do it")...-)
---------------------------------------------------------------
1) New releases of Office. Every time a new version gets
pushed out, somebody has to be on the case to make sure
the application still functions. To the technically
knowledgeable, small change.... but if the users click an
icon and the app doesn't start, that's a big deal to them.

This has been a relatively minor problem since A2K, in my
experience. The only apps I've had that cause problems in newer
versions of Access are A97 apps crossing the A2K line, to A2K2, A2K3
or A2K7 (though I've not had any of the latter, as none of my
clients are using any part of Office 2007).

2) Ongoing expertise. Seems like .NET expertise is almost a
commodity anymore. Certainly just about every developer
in the client's IT department is proficient.

I find that a really doubtful assertion. Maybe each developer is
"proficient" in some aspect of .NET development, but that doesn't
mean they know what they are doing in designing a front end for a
database application.

Finding a good developer is more important than the development
platform, seems to me. Developers are simply not interchangeable, as
so many would like you to believe.

MS Access,
OTOH, for all it's advantages, is not (in my experience)
understood by IT organizations. It's sort of a specialty
skill. Good for me... but not so good for the client
in the long run once I hit the lottery and elope to Maui
with Miss Something-Or-Other.

I think you vastly overrate the competence of those listing .NET on
their resumes. And the cost and difficulty of redeveloping in it.

3) WiFI/WAN/Internet. Personally, I consider this bogus
in light of Citrix.

Or any non-Jet back end. Again, as with so many of the supposed
"weaknesses" of Access, it's really only the Jet database engine
that has the vulnerabilities that the IT "experts" latch onto to
criticize Access. And Jet is not appropriate for all situations, but
Access allows you the choice, out of the box. And makes it pretty
darned transparent to switch between them.

 

[(PeteCresswell)]

Per David W. Fenton:

Good for me... but not so good for the client

I think you vastly overrate the competence of those listing .NET on
their resumes. And the cost and difficulty of redeveloping in it.

But hopefully not the chances of my hitting the lottery.... -)