Is Cloud Computing worth it?

In my last post I related that in eWeek magazine (Oct 13, 2008), Jason Brooks asks "Does OpenOffice.org Still Matter?" He's wondering if, given on-line suites, if OpenOffice.org will matter in the future. Yesterday I addressed the quality of the software, but today I'd like to look at the on-line software concept and whether Software-as-a-service (SaaS or "cloud computing") advantages outweigh the drawbacks.

With "fat" clients like OpenOffice.org, Jason relates three "pain points":

1. the need to install an office suite on every machine,
   
2. the tendency of office suites to "strand" documents on the machine on which it's created, and
   
3. the difficulty of configuring a network share.

Working backwards, we see that 3. Configuring a network share isn't any more difficult than signing up for Google Docs; 2. Once you've configured the network share, your documents aren't stranded; and 1. Shares work for the Office software as well as the files, so the software doesn't have to be installed on every machine... IF you've chosen the right software, like OpenOffice.org

It appears that people -- even knowledgeable people like Jason -- have forgotten that file servers can be application servers as well. In fact, installing software onto a shared drive was standard practice in small business until very recently. This hasn't been helped by Microsoft's tendency to write software that "hook" into your machine's operating system through multiple Registry entries (sometimes dozens of them). They've forgotten that in large part these Registry hooks are unnecessary. Consider if you will that PortableApps distributes an OpenOffice.org that can be placed on a USB key and carried with you.

The 800lb. gorilla that Jason doesn't mention is the ability to access those cloud computing apps like Google Docs from anywhere outside of your network. The answer to this commonly quoted "advantage" is that LogMeIn.com provides remote access via browser to your entire desktop: better tools, your own environment, and tools and capabilities that simply do not exist "in the cloud." GotoMyPC offers similar service. And, having secure, brokered connections, remote access is a better solution than cloud computing.

Taking all of these factors into account, it's not surprising that I don't think much of the supposed "pain points" of fat client software. Frankly, for me they don't exist. I can do better, and do.

Everything that I've mentioned here about OpenOffice.org applies to other "fat" clients like Lotus Notes (and thus VIC CRM). And since I've mentioned that term a couple of times, I'll explain it.

Why is your client "Fat"? There are as many different ways of computing as there are programmers, but typically we can split them into a few broad categories. Thin client - This was the first computing model, and it still dominates the mainframe world. All the computing is done on a big computer somewhere else, and each user has a terminal that simply consists of a display and input devices. Fat client - Files might be stored locally or somewhere else, but all of the computing for each user is done on his own computer. Client-Server - Some of the computing is done on your machine, and some is done on a central computer elsewhere. Then there are some nuances... for instance, "Web 2.0" is more of a smart thin client than client-server."SAAS" and "cloud computing" are really the same thing, distinguished (if at all) by the method of payment. Service-oriented architecture ("SOA") is a form of client-server. The boundaries are often confused when the people who've invented these new terminologies refuse to see them as variations of existing themes.

As you can see from the definitions, a "fat client" isn't really fat in the sense of "wasteful"... it's big because all of the computing is localized. Perhaps a better term is "robust". And that's what we're looking at here... the difference between a robust piece of software that can leverage all of the power of that 2GHz monster you have on your desk or on your lap, and whatever functionality can be delivered through your browser. The difference is notable, even with Web 2.0... Google Docs doesn't match OpenOffice.org, and Gmail doesn't match Lotus Notes and VIC. Ask yourself if it makes sense that Dell is selling you that monster of a machine just so you can use a browser.

The Economic Argument:
Dana Blankenhorn pointed out some days ago in his article "Open source is about belief in code" that Open Source is survivable:

Even if an open source enterprise should go belly-up its code should survive. That code can be enhanced, it can be forked, it can be turned into another business, perhaps with another business model, down the road.

He concludes his post with "Open source was made for times like this. You don’t have to believe in it. Just use it." Obviously, this is in the context of the current economic downturn (which seems to be turning back up as of yesterday), and it's potent advice.

It's also applicable to our current discussion about "cloud computing".

Why? Because I haven't just been burned by proprietary vendors who no longer produce drivers and the like... I have been burned more often by both start-ups and supposedly established companies that no longer offer the on-line services that they once did. I'm not alone, either. And having a well-established, well-heeled company providing the service is no guarantee of continued availability. Famously, Wal-Mart has simply thrown all of your DRM'ed music purchases away.

I've "bought" hosted technical reference books only to see the "publisher" go belly-up on zero notice and I've lost access to the materials. I've used hosted remote access software only to see it die. I've seen WebFTP hosts come and go. I've seen services get bought by larger companies and "improved", "enhanced", and "transformed" by the new parent until they are no longer useful at all.

I don't think you can in good conscience base a business on dependence on "the cloud" and the companies that provide SaaS. To borrow a phrase from Cory Doctorow, these institutions "are as solid and permanent as Commodore, Atari, the Soviet Union, the American credit system and the Roman Empire. "

Sure, go ahead and use on-line services where it makes sense, but don't depend upon them, no matter how good they look. If you're an individual you should know more than one way to skin a cat. Know about VNC as well as GoToMyPC or LogMeIn. You should know about portable, standards-based formats. You should know about software that uses them.

If you're running a business, you should be hosting your own critical services rather than depending upon somebody else to do this for you. Open Source, Exchange, or Notes/Domino are all viable options for doing this. Now, obviously, there are limits and compromises made on the basis of cost and ability. For instance, a web-based business may typically choose a host. But if they're smart they will retain frequent backups of their code and data in case they need to migrate. However, when you're crafting your compromises you should remember that under no circumstances should highly sensitive or mission critical data be entrusted to "the cloud".

If you do purchase hosted services, your disaster recovery planning must absolutely include the contingency of that company going under at short notice. And you must absolutely have a recovery plan that doesn't depend on legal action to get back online. Have you been mirroring your data? Is it transportable to another service? Can you host the service yourself? Not theoretically... I mean really host it yourself, and at short notice, without esoteric knowledge and without lawyers bitchin' (You know how they love to do that).

You need to be able to answer "yes" to every single one of those questions. Otherwise, your business model depends on prayer alone. Because, barring the direct intervention of a merciful God, you will eventually lose your company to your betters in the marketplace.

So my argument is that -- on economic grounds; on disaster preparedness grounds; on the grounds of capability and flexibility -- robust "fat" clients are here for the long term and make much more sense than computing in "the cloud".

OpenOffice.org 3 is Released.

OpenOffice.org 3 has been released. It's fast it's sweet, get it. You may have to wait your turn... the demand is so great that the servers have crashed. Here's the message that mailing list members received:

All,

We must apologize. OpenOffice.org 3.0 is proving immensely,
staggeringly popular. And our site is down as a result. While we fix
things, we urge you to be patient and try again later on tonight,
tomorrow, this week. It will still be there.

Oh, by popular, we mean it: figure hundreds of thousands of users,
mostly Windows users, but also Mac OS X and Linux and Solaris users,
all trying to download it all at once.....

Cheers, and thanks for your patience,
Louis

Nevertheless, I was able to download it without much trouble (the website is severely truncated, though... just links to the software).

The installation itself was quick, as is the software. One nice bit I hadn't noticed before is the ability to save to Aportisdoc (.pdb) format for the Palm. My test document opened up just fine in my Palm eReader.

One thing I'm still wishing for is a greater selection of and more flexibility of the shapes in the Draw tool. If they would take this up to the level of, say, SmartDraw version 5 I'd be much happier.

---

In today's eWeek (written well before the release), Jason Brooks asks "Does OpenOffice.org Still Matter?" He's wondering if, given on-line suites, if OpenOffice.org will matter in the future. He also makes this observation:

"When I think back on my Linux desktop circa 2002, OpenOffice.org is probably the least improved, least innovative and slowest moving major component of the lot."

With all due respect to Jason, this statement is just silly. OpenOffice.org is the least improved because it was a damned good application to start with. You must remember that OpenOffice.org was not a from-the-ground-up effort. It was based on StarOffice, which whas already at version 5 by the time the OpenOffice.org project was started. Five versions, count 'em. When you start close to the top, improvement is incremental.

Also you must remember that Office software is a commodity, and it has been for a very long time. Microsoft Office hasn't much changed in terms of basic functionality since before the turn of the century. Microsoft Office 97 is still perfectly fine for many, many users. OpenOffice.org is much, much better, and compares favorably, feature-wise, with the latest Microsoft Office software.

The bottom line here is that OpenOffice.org matters very much (and I'll elaborate on that in my next post) and version 3 especially so. Try it out.

Using VIC: Managing Calls

"Out of the box" VIC CRM is geared toward the worker who spends most of his time in front of the computer and on the phone. When you create a new JournalEntry the default JournalEntry type is always "Phone Call". The rationale here is simple: when you receive a phone call you need to be able to start documenting it as soon as possible, with no delays at all. Other systems require you to gather some information about the contact before you get to the call record, but VIC does not.

Once you're in the JournalEntry you can add the contact information from your Index (or you can post "ad hoc" contact information), and you can change the type to any of the others supported by the Journal: Phone Call, Meeting, Conference, Product Demo, Service Call, Task, To-Do, or Trade Show. You can also edit the categories, assign it to a Project task, or update Contact information, as the info comes up and as you have time.

There are a number of different ways that we can initiate a Phone Call JournalEntry. The first is simply to click on "JournalEntry" on the "Create" tab of the navigator pane. This creates the blank JournalEntry and you add the name. If you're in any view that contains contact information you can click on the "Dial" action button. This gives you the Dial dialog, which will let you select the phone number and create the JournalEntry at the same time.

The document can also track the duration of the call. Just click "Now" next to the end time when marking it complete. The important thing here is that the body of the JournalEntry is immediately accessible.

Sometimes you want to follow up an email with a phone call (or meeting). In the email, pull down the Tools action menu, then select Convert to JournalEntry. This will create a JournalEntry which you can then schedule. This will include all of the contact information from the email, as well as the body of the email for reference.

---

Tech stuff:

I've been asked how to implement the dialer generally in Notes. To do it you would need Domino Designer. I have only tested this in Windows, though it should work on Linux under WINE if TAPI32.dll is provided. It relies on the Microsoft Telephony API, which is provided by any of a number of TAPI clients. What's difficult is finding a utility that does only TAPI phone dialing, and doesn't try to hand you Yet Another AddressBook as well. One that really fits the bill is Jacek Koslowski's Dial Engine Pro. It's unobtrusive and does exactly the job required. If you don't want to spend money then the there's the Windows Phone Dialer (dialer.exe) that's distributed with Windows XP. VIC will use the Windows dialer if nothing else is in place, so dialing always works on this platform.

If you're using Notes without other modifications, then the change would need to be made to the Addressbook. You would put the script into a script library (for instance, mine is in a library I called "CratchitTAPILibrary"), then you'd add an action button to the Contact form that would include the following LotusScript:

Use "CratchitTAPILibrary" ' or whatever you've called your script library
success=fDialNumber(doc.OfficePhoneNumber(0), doc.FullName(0))

If you have trouble following these instructions then I'd recommend a good basic book on programming in LotusScript. Amazon.com has a good selection. Another invaluable resource is the LotusScript to C API Programming Guide by Normunds Kalnberzins.

Here's the whole script. Yes, it is this easy:

Declare Function tapiRequestMakeCall Lib "TAPI32.DLL" (Byval DestAdress$, Byval AppName$, Byval CalledParty$, Byval Comment$) As Long


Function fDialNumber(cPhoneNumber As String,cCalledPartyName As String) As Integer
Dim nReturnCode As Long
Dim cApp As String ' What are we using to call?
Dim cComment As String ' whatever you want.

REM replace this stuff with values for your app.
cApp = "VIC CRM"
cComment = "Lift your handset now."

fDialNumber = tapiRequestMakeCall(cPhoneNumber,cApp,cCalledPartyName,cComment)
If fDialNumber <> 0 Then
' there's no point in making this robust,
' since the Microsoft phone dialer will give you
' detailed status on the screen.
Print "Call failed!"
End If
End Function

Using VIC: from Project to Sale

In my last Using VIC post, I described how to use Projects to manage complicated groups of tasks. These can be generic projects of the sort you'd use Microsoft Project for; or Sales oriented methodologies to help you manage a sale from working the lead to closing the contract. I also promised I'd show you how to turn the Project into a Sales Order and an Invoice.

Remember that a Sales Project includes a Products tab that allows you to put together a wish list of products. This helps you estimate the value of the potential sale. When it comes time to complete the sale you may want to turn this list directly into a Sales Order to reduce the amount of typing you can do. In VIC, this couldn't be easier. You simply select the Project in one of the Views or open it, then pull down the "Create" action menu, then select "Sale".

That's it. All of the customer and product information will be included in the new Sales Order. You should edit the pricing to make sure the taxes are calculated properly (at a minimum, just edit then resave the prices). When the Sales Order is approved, you can turn it into an Invoice with one click (while the Sales Order is open for editing, just select "Make Invoice"). By default, any project is turned into a Sale. However, you can save that sale as an Estimate (a quote) by clicking "Make Estimate").

I'm tempted to end the post there, because we've pretty much accomplished the task. But let's take some time to look a little more closely at the Sales database.

VIC Sales is not, not, not an accounting package. It does generate sales orders and it does generate invoices; but these features are basically there because I've been largely dissatisfied with the general state of open source accounting packages for small business. I'll resist the urge to rant about the reasons here, but the ironic outcome is that VIC Sales, poor as it is, is a placeholder for the accounting system that I'd like to use, but which nobody yet produces.

VIC Sales was originally conceived as a place to simply list, in a convenient form, the major sales we've made to each customer. That allows us to measure sales performance and get some reports. If there were an open source accounting package that I actually liked, I would code a link to that to simply import the data from accounting. If you're adapting VIC CRM for your company, I recommend that's what you do... have an interface to pull in your sales info from your accounting system. The reason for this is that VIC allows you to have Categories and additional metadata that your accounting system may not have; and because the people who need the reports may not have access to your accounting system. Since not everybody is going to have an accounting system or want to modify VIC, I've included the ability to create and edit rudimentary Sales Orders and Invoices here. A small consultancy may be able to manage with just VIC CRM or VIC + Quickbooks/GNUCash/TurboCash. A lone consultant or salesman can certainly do so.

I'm going try to scare you off first. Here are reasons to not use VIC CRM for accounting:

1. There is no audit trail.
2. The method of calculating taxes stinks.
3. No General Ledger, Purchase orders, or Accounts Payable.
4. Accounts receivable is rudimentary.
5. There is no audit trail.
6. There is no proper breakdown by accounting period. VIC displays a view by calendar year and month, but that's about it.
7. There is no audit trail.
8. It conforms to no generally accepted accounting principles.

That said, there are plenty of small businesses that generate invoices using Microsoft Excel templates. If your business is one of those, you'll probably find VIC Sales to be a big step up. And I can think of some fairly good reasons to use it for generating invoices and then just entering the summary information into QuickBooks.

First, VIC keeps the entire sales process in one interface. Your Product and Sales brochures in the VIC Library form your inventory; so if you keep those current for sales, they're also current for billing. That works in reverse as well. If you keep your inventory straight, then your sales materials will never be out of date.

Also, VIC CRM does a "stupid pet trick" that no accounting package I know of can do... it can treat your Calendar entries as if they were inventory! It's a bit like Time Billing, only easy. Here's what happens: say you're consulting. You've made several phone calls on behalf of a customer and perhaps you've made a couple of site visits. You've documented the activities in your VIC Journal and you've checked the "Billable" checkbox for each. The VIC Index contains a bill rate for this customer. When you create a Sale for this custimer, then you can add products from the VIC Journal instead of the products file. The inventory list displayed will be all unbilled JournalEntries for that customer. When you add it to the Sale, VIC will calculate the charge based on the actual duration of the activity as documented in the Journal, times the bill rate. No more estimating how much work you've done. VIC knows. Doing this will mark the original JournalEntry as "billed" and it will link that JournalEntry to the Sale or Invoice. That way, as you browse your Journal you can immediately see the invoice that included that JournalEntry as a line item.

If you're like me, sometimes you do work and purposely don't bill for it. Or you may have a customer on a support contract. If so, I recommend that you still generate an Invoice. The reason is simple: If you don't bill for services the customer has little idea of the value of the services he's receiving from you. But with VIC you can list every single moment you've spent on that customer's account. Discount it 100% so that you're sending a zero-balance bill (the line items will still show the value), and include a comment regarding professional courtesy or referencing their support contract. Even if you don't do this periodically, the ability to do this can be invaluable when it's time to renew the support contract. The sales pitch boils down to "here's what you would have spent this year without a contract..." and the customer can easily make his decision.

VIC Sales lends itself easily to workflow. There's no particular workflow built-in (this is the sort of thing that differs from company to company, so it's a custom feature), but VIC Launch contains a dashboard that lets you work as if it is. The Financials dashboard is split into four quadrants. The left side represents potential income; the right side represents income owed to you. So the four quadrants are as follows:

1. Unbilled Journal Entries (upper left). These are Journal entries that are in a "complete" status and are marked as billable, but haven't been marked as billed. They represent potential revenue for which you haven't billed.
2. Open Sales Orders (lower left). These are sales orders that haven't shipped. "Shipping" in consulting can be a flexible term. I use it to represent work that has not yet been approved.
3. Invoices not sent (upper right). These are shipped, but not yet billed. Your pending action here is to print and mail invoices. I print them to PDF and email them.
4. Open sent Invoices (lower right). These are invoices for which you're awaiting payment from the customer.

Once an invoice is paid off it drops off of the Financials dashboard. Also, estimates are not displayed in the Financials dashboard (Estimates are "what ifs" and do not represent potential income). All of these dashboard views are summarized so you can see totals per customer and a grand total. And of course, with Domino Designer you can tailor them to your needs. A manager viewing this dashboard on the server will see the numbers change as the documents are processed by the sales and/or accounting staff.

So VIC Sales has a few things working in its favor. But as accounting goes, my official statement is that it might be better than nothing at all.

For robust accounting I suggest your company standardize on a real accounting package. Larger companies would do well to use VIC as a method of having the salespeople communicate sales to the accounting staff. They can then create invoices into a standardized accounting package. Customization could automate this link.

Guinea Pig Wanted.

For several years I've been distributing VIC CRM without any setup program. As a result, only hardcore bleed-yellow Lotus geeks have been able to get it to work without assistance.

Well, I'm just about finished with the VIC Installer. If you're running Notes and want to be the first kid on the block to try this out -- pre-release -- email me with "Guinea Pig" in the subject. You shouldn't have any trouble finding my contact information on Cratchit.org.

...and don't ask me why it took so long to get an installer done. For some reason I was dreading the task and was hoping somebody else would do it. Turns out, it only took a few hours once I rolled my sleeves up.