|
'The Electronic
Newsletter For Users
Volume X #14 |
IN THIS ISSUE: |
|
|
You are receiving this e-mail
because you asked for it, either because you have requested information
about our products and services and given us your e-mail address (Thanks!)
or because you are a current customer of ours (Double Thanks!)
TO UNSUBSCRIBE, MAKE
SUGGESTIONS or to CHANGE ADDRESS: Send a message to:
webmaster@suntowersystems.com |
||
SAFE/X Tip: Locate
Insider!
Another in the
long list of 'little things mean a lot' improvements is the right click pop up
menu for the Locator. Right clicking brings a pop up menu with a Locate Inside
option. When you click this, your locator filters based on your entry being
anywhere inside the column you're searching for.
Since examples are everything, let's take the Customer Browse. Click on the Name column to sort by Name. The column is surrounded in brackets. Now type 'COM' in the Locator and press the tab key. The browse is re-drawn
Without Locate Inside Option
NAME
Comcast Cable
Comdex Solutions, Inc
Companion Graphics, Inc
Complete Cleaning Services, Inc.
...but with the Locate Inside Option checked...
NAME
Accomplished Designers, Inc.
Bendix Competitive Painting
Comcast Cable
Comdex Solutions, Inc
Companion Graphics, Inc
Complete Cleaning Services, Inc.
E-com Services Of Redmond
Greater Seattle Chamber Of Commerce
...
..
.
The column is still sorted in Name order, but with the Locate Inside option checked, any company with the string 'com' anywhere in their name will be displayed. This can be invaluable when you have numerous customers with ambiguous naming conventions (ie. is your customer 'Dr. Stephen Casey' or 'Stephen Casey, MD'?)
Note that this option only works for strings. It has no effect on numeric or date columns. Also, be aware that using the Locate Inside option can be a bit taxing if your database is large or your server a bit long in the tooth (as you might guess, this option requires a lot more from the database server to do it's magic.)
Til Next Time!
Ollie Tip:
Time Out!
One thing that
often doesn't get discussed until after the install is how to handle users who
leave their Ollie sessions. Remember that when a user has any web application
running, this is taking up resources on your server... even if the user is away
from their desk for lunch (or gone for the day!) Since there is no way to force
users to 'exit' a web application, all web servers have systems in place to
automatically shut down a user's session after a period of inactivity. Without
this timeout, sessions would soon build up until the server crashed.
The flip side of a time out is a session memory. When a user logs back in and after being out, what information is retained from the prior session? Should their shopping cart remain as it was or must they start over? Should various preferences have been saved?
These are important considerations and there may not be a one size fits all answer. So Ollie has several ways to manage timeouts and session memory either at the global level or by customer.
Total Session Time (Customer Specific) This sets the maximum amount of time for a session. The default is 1 hour. The user has one hour with their web browser open. If they work on a transaction for thirty minutes, then go to lunch and come back forty five minutes later, their session has timed out.
Session Inactivity Timeout (Customer Specific) The default is 30 minutes. This sets the amount of time before the session times out from inactivity. In the above example, if the user had rushed back to her desk after a half hour, the session would still have timed out--but for a different reason; because she had exceeded the inactivity timer.
Session Memory (Customer Specific) This determines what happens to unsubmitted transactions in case of a timeout. In other words, if the user's session ends with items left in the shopping cart, what should be done? The default is to leave the transactions in place for 24 hours.
Now, there is also an timeout feature built into your web server (if you're on Windows Server, this is IIS) which is specific to each web site. It's defaults are much more stringent than Ollie's. In fact, a typical Windows IIS session will timeout in 900 seconds (15 minutes). If you find sessions timing out way too fast, check with your network administrator before calling us as this is likely the culprit.
THERE'S A REASON WE'RE GIVING YOU A TIMEOUT
We strongly urge you to
not get carried away and try to adjust our defaults. Almost the first
question we get with regard to Ollie setup is 'how to disable these darned
timeouts'. Don't do it. We've gotten complaints that we're 'mean' about it. Or
that we shouldn't even 'have' timeouts. In order to mollify your users, you will
be sorely tempted to increase all these timeouts to essentially 'forever' but
this almost guarantees slow performance and ultimately, server crashes.
Remember: this is the web; not an in-house application. Each user session is
borrowing power from your server. That's just the way it is. You can increase
server capacity, but in the beginning at least, it's far cheaper to simply
educate your users.
The good news is that your end users are already used to the concept of timeouts if they have bought anything on the internet using big shopping sites like Amazon or Wal-Mart.com. All big sites have to limit their session times in order to provide smooth performance. It is usually only users that have no experience with the web and only 'always available' in-house applications that will grouse a bit. These users can be mollified by simply acquainting them with other users who have internet savvy and thus can verify independently that 'dems da rules'.
Til Next Time!
Ciaran's
Corner: Do You Trust The Cloud?
According to
pundits, the trend is to move all data and applications out of your office and
into 'the cloud'. The cloud being the internet, of course. The acronym for this
(everything needs an acronym right?) is Software as a Service (SaaS).
Microsoft's stock price seems to move all over the place depending on how well
they report they are doing in getting SaaS applications ready to go. So clearly
their investors seem to think it's a big deal. But is an all web-based set of
applications what you need? In Simple Accounting terms, SaaS shows up as
WebSAFE... our completely browser-based version of SAFE.
First of all, there is a lot to be said for the cloud. We've spent years developing WebSAFE because:
It gives you the ability to compute anything, anywhere there is a web browser.
It can reduce your hardware requirements. (Note I said can and not does. More on this in a moment.)
It can significantly reduce your maintenance and training requirements. (Again, there's that word can.)
Wow. Sounds pretty good to me! But before we start tossing out our PCs, let's make a quick check of some details.
We spend a lot of time and effort getting our in-house networks to be reliable. SaAS doesn't take this responsibility away. We still have to make sure that our computers can get to the web efficiently. So basic network setup is still there for both in-office and home/remote users. And most users are not ready for 'dumb terminals' so those PCs on their desks probably aren't going away either. Hmmm... So far no savings. But let's move upstream to the server. With 'the cloud' we can get rid of all those hot, heavy and expensive servers right?
Well, maybe. At this point, it's time to get out the spreadsheet and crunch some numbers. I'm going to assume that the SaaS application(s) have everything we could ever need so there is no need to think outside the offerings of the vendor. You will sign a contract for a monthly service fee---much like a cable TV operator. So long as you like their channels (and their 'menus' of choices) all is well. But what happens if they don't offer everything a la carte? Again, thinking like your cable company, many SaaS contracts require you to purchase 'bundles' of applications. Ahhh... but what they hey? It's still 'cheap', right? Sure. You get a constantly upgraded and maintained product for a low monthly fee. That never ends.
Since you're purchasing a service and the data never resides at your office, a few questions should pop up at this point which us geeks will refer to as Flexibility, QoS, Performance, Persistence, Security and TCO.
Flexibility means, how well does the application fit you. It may be cheaper than prices at Wal-Mart and have more features than a Rolls Royce, but look hard at how well all those features apply to what you do. Many features may not be of direct benefit to you no matter how impressive they appear. Also, if there are features that you need (specific to our business) that are MIA, ask about their policy on modifications. Can mods be done? If so, how expensive are they? Some vendors offer really low basic service, but charge an arm and a leg for any and all mods. They can only make money by either: a) forcing everyone into a 'vanilla' configuration or b) charging a lot for mods they know most users will need.
Quality of Service means, what's the 'up time'? For better or worse, when you run your own server, you control the up time. For example, if there's a power outage and you have generators, you're still in business, even if the internet outside your building is down. If you use SaAS you're depending on not only your own internal network, but your ISP and then your SaAS vendor. So it's important to get some stats from the SaAS vendor on their up time performance and then factor in your ISP and your own in-house network's reliability.
Persistence means, 'will my data be there when I want it'. With an in-house system like SAFE, you know where your data is. And you have access to that data, basically forever. When you move your data to 'the cloud', your data is off somewhere else. This is sort of like having your money in a bank. It's yours, and you have access to it any time you want, but it's not in your physical possession. So question then becomes, what happens in five years? Will your SaaS provider be around five or ten years from now? If they did go out of business, what plan do they have in place to get you your data? And if they got you your data but their application was dead, how would you work with that data... is the data in an open format or in a proprietary format? A few years ago, Google started a paid video download service that we used a lot. Then they dropped it. Since they dubbed it a 'beta program', no harm, no foul right? Well, not to those of us who had been using it for a couple of years. Refunds on our 99 cent videos (which seemed like such a great deal at the time!) didn't make up for not being able to view those videos ever again.
Performance is something that has kind of been forgotten in recent years. Simply put, how fast do certain tasks run? Again, this is something over which you have a certain amount of control in your office. Need more speed? More RAM! More CPUs! More Gigabytes! On the web, performance has several components: your PC, your ISP's connection speed (and their QoS) as well as your SaaS vendor's servers. It's important to be able to test the SaaS vendor's site over several days because, while performance may be good on the tenth of the month, it may well drag a lot when you and ten thousand other businesses are performing the same month end procedures! As good as broadband is getting, there is nothing like an in-house application running on your LAN for good ol' speed. (Old DOS guy remark: Remember back when all applications opened instantly?)
Security is easy enough to understand with all the recent stories of hackers breaking into major banks. Why do hackers go for these large sites and not so much your small business? Because, as Dillinger famously said, 'that's where the money is'. Your small business ain't much of a target for crime rings, but aggregated with hundreds and thousands of other businesses under a SaaS vendor's site? Yum, yum! So check their security policies and any fine print about 'sharing data' (Hidden in the fine print of some SaaS agreements is their right to share at least 'some' of your data for 'marketing purposes'. Really. I am not making this up.)
If the above paragraph sounds like 'scare tactics' on my part, please look at the business world five years ago. There was still a 'big three' in Detroit. The all-knowing 'Google' wasn't yet a publicly traded corporation. Things do change. So when you move to 'the cloud' you need to have a way to move back (or to another 'cloud') because as we all know, having your money in a bank (or you data in a cloud) is useless if the bank closes it's doors. And to date? Unlike banking customers, there's no FDIC for users of SaaS.
SAAS BUZZ KILL?
Am I against SaaS?
No. Again, we make a significant portion of our revenue from it. However, like
many buzzwords in the littered history of computing, it's not quite the panacea
it's being made out to be. You have to look at the Total Cost Of Ownership (TCO).
Can it save you money? Sure, if you fit into it's plan. But it's important to
look past the 'low monthly fee' and factor in some not so tangible parameters
such as:
Tweakability. How much you will need to adapt to it? Or how much it will cost to adapt it to your needs?
Up time
Security
Long term availability
Since these are sometimes hard to quantify you may skip past them and see only the low monthly price of an SaaS product, but my advice is, 'don't do it!' Think hard about what you are giving up when you move to a seemingly cheaper 'cloud'. For me, there is something comforting about having a self-contained application and it's data. We've been around for 23 years which should inspire at least some confidence in our longevity. But even if we are suddenly taken away (Rapture, CIA, earthquake, whatever....)? You've still got your application. You aren't dependent on the wire.
To me the cloud is like moving from an 'ownership' model which implies a great measure of 'control' to a 'rental' where you really have to feel comfortable with your landlord because you're going to be depending on them for a lot more things. Sure, the things you have to do when you own your own home are sometimes a pain, but still, they're your pain. I think that about sums it up.
Til Next Time!
Ciarān Marron
Technical Support Manager
cm@suntowersystems.com
End of E-News From The Suntower, Volume X #14
