The Invisible Database

In my last post, I wrote about failure, and in particular I observed that you have to fail many times to find something that works. The absolute next thing to observe however is that once you find something that doesn’t fail; you have to nurture it along. Run with it!

David Meerman Scott, in his New Rules of Marketing and PR book had this comment:

Create a number of campaigns and see what hits, then nurture the winners along.

[Pg 96]

Here on the SQL Anywhere team, we have tried very hard to keep our environment open to experimentation, and the possibility of failure. The number of ideas experiments that have failed is large, but so is the number of successes. The products and features we have today grew out of these many experiments:

• the SQL Anywhere database server itself was a result of an experiment in providing a reliable data centric application to one of our customers.
• the idea that 100’s of databases could synchronize in a disconnected fashion grew out of an experiment we shared with one of our first database customers and become our SQL Remote technology
• the idea of a transactional database on a handheld seemed absurd at the time, but we experimented, and created our UltraLite database, initially for the Palm Pilot

The failures are harder to list, because they happen every day, and then *poof* they disappear, as the development team moves to another approach to solve the problem at hand. Usually, the problem being worked on is an attempt to find a solution to a customer problem or need. Rather than accept that the problem can’t be solved, the team simply tries again.

Here on the SQL Anywhere team, a great many of us enjoy working with our customers because we learn so much from them. We especially appreciate talking with customers who are willing to share with us the various ways they have attempted to solve their problems.

ps. I acknowledge that I have been silent for longer than usual. I must admit that I have struggled a bit as of late with exactly what to comment about on this blog that isn’t confidential, and yet still is interesting. Over the last couple months, I have been heavily involved with several specific partners on a number of projects, and very little of it was available for public comment. In numerous discussions with my colleague Glenn Paulley about this, he has provided much needed motivation and inspiration, and for that I thank him.

Last week, I had the opportunity to hear Jim Estill speak at a breakfast presentation hosted by Communitech, our local technology association. Jim writes a popular blog on Time Leadership. In his talk he described why he uses the term “Leadership” rather than “Time Management”. Leadership indicates that you are in charge, and choosing to do the important things, rather than simply managing your time.

In his presentation, Jim outlined his Ten Keys to Success:

• It’s the little things.
• Have successful Habits
• Fail Often, Fail Fast, Fail Cheap
• Know Yourself: What is your unique strength
• Set a pace you can maintain forever
• Be Frugal
• Welcome and Embrace Change
• Manage your risk
• Be a time Management Fanatic
• Embrace Technology

Having a list of keys to success reminded me of the list by Tom Peters: “100 Ways to Succeed”, which is currently much larger than 100 items!

His most recent addition is number 157:

“Excellence = People first, second, third. And fourth. (And fifth and sixth and seventh.)”

In Tom’s blog, immediately prior to number 157, he commented on failure:

“He who tries the most stuff wins. Failures are not to be tolerated, they are to be celebrated.”

Doesn’t this sound similar to Jim’s 3rd rule?

“Fail Fast, Fail Often, Fail Cheaply”

Here on the SQL Anywhere front, we keep trying a variety of things to increase the number of people who know about SQL Anywhere, but I sometimes feel that we are too afraid of the failure described by both Jim and Tom. To counteract this tendency, I am going to challenge myself and members of our team to try a dozen things over the next week that might fail.

One of the blogs I subscribe to is the New Rules blog by Kevin Kelly. In his own words:

“This is a blog version of a book of mine first published in 1998. I am re-issuing it (two posts per week) unaltered on its 10th anniversary.”

A week or so ago, the post was titled: Move technology to invisibility. Here is a short excerpt:

“Since the measure of a technology’s success is how invisible it becomes, the best long-term strategy is to develop products and services that can be ignored.”

As the author of a blog with the title “Invisible Database”, I couldn’t ignore this statement. We believe that SQL Anywhere is the best embedded database for applications that require a transactional database with data integrity guarantees. Many of our partners use SQL Anywhere invisibly inside their product. Their own customers and users don’t even realize there is a database server at all. Many partner and customer stories are posted on our web site. Intuit, MICROS Systems, and Cerner BeyondNow are just a three of more than 100 of these stories.

Yesterday, on my drive to the office I heard the following joke on the radio:

“You don’t have to floss all your teeth…..just the ones you want to keep.”

What does it say about me, that within 5 seconds, I had transformed this into a joke about data backup?

“You don’t have to backup all your data…..only the data you want to keep.”

Here is a link to a recent whitepaper about the importance of backup with SQL Anywhere.

I can’t take credit for the joke, and I didn’t catch the source if it was mentioned on the air.

Approximately 1 month ago, Glenn Paulley, my colleague here at iAnywhere handed me a pre-publication copy of an upcoming book entitled, “The Principles of Product Development Flow”, by Donald G. Reinertsen [1]. Glenn has mentioned the book a couple of times on his blog, most recently, just today. Over the last month, I started reading the book, and have now read enough of the book to decide that I will finish it. This is not a decision that I took lightly, as I currently have a “want to read” stack of over 20 books. However, after reading the first 2 chapters, I am sold. There is a lot of excellent content in this book, and I want to finish it. So far I have read Chapter 1: “The Principles of Flow” and Chapter 2: “The Economic View”. My plan now is to blog about some of my thoughts on the book as I read it, in a sort of ongoing review.

The bulk of the content in the book is organized into 175 key principles, separated into 8 major themes:

• Economics
• Queues
• Variability
• Batch Size
• Work In Process Constraints
• Cadence, Synchronization and Flow Control
• Fast Feedback
• Decentralized Control

[Read more →]

I heard an interesting phrase a couple of days ago from one of our partner account reps: “I am trying hard to be a duck!”

When I quizzed the rep about it’s meaning, I was told to think about how a duck looks when it is swimming across the water. On the surface, it is very calm and in control, but under the surface, there was a lot of action.

I enjoy a good metaphor, and often use them when trying to explain complex information because when used appropriately, they can cause people to have that “Ah HA!” moment, when they finally understand something for the first time. I like this metaphor because it can be used to explain several things I encounter in a normal business day:

• Good managers, who inspire others with their confidence and control, yet are very active under the surface making sure that everything is unfolding according to their vision.
• The SQL Anywhere Server, which works behind the scenes of our partner’s applications, managing the application’s data, without the requirement for user intervention.
• The many people who work behind the scenes to get our products out the door.

My goal for this week: be a duck!

Today, February 19, 2009, marks the first international trip by US President Barack Obama, since he became US President in January. He is scheduled to be in Ottawa for a total of 6 hours after he lands at 10:30 a.m., most of it in meetings with Canadian Prime Minister Stephen Harper.

One may question why he is coming at all, if for only such a short time. Of course, during their meetings, Obama and Harper will talk about all sorts of critical issues such as the economy, trade, the environment and the war in Afghanistan. These are all vitally important issues, and I am sure they could have been discussed in any number of ways without a trip.

The real reason for the trip of course is to “look each other in the eyes.” Last night, during the CTV newscast, Craig Oliver, Chief Political Correspondent had this to say:

You cannot underestimate the importance of the physical connection. The subtleties, the nuances of meaning between each other, the building of trustworthiness or not, that can only be done, not in phone calls, not in teleconferences, but only looking each other in the eye, and sizing each other up.

I couldn’t have said it better myself.

In today’s economy, there seems to be an increase in the desire to avoid all travel, and conduct business over the phone, via email, or using a social networking site. I am a big believer in the power that the use of technology has to radically transform many interactions between people. I also believe however, that face-to-face contact is still useful, and when used correctly can have a HUGE impact.

Several examples this week have reinforced my belief that people crave personal relationships, and that a face-to-face discussion is still one of the most powerful ways to create and strengthen those relationships.

Example 1:
On Monday evening I had the opportunity to have dinner with one of our long time partners. During dinner, he spent at least 10 solid minutes looking me right in the eyes describing a particular frustration with Sybase that he is dealing with. I got it. Let me say to him right now, “I get it.”

While I can’t wave a magic wand and solve all the problems, I am trying. I may not be able to solve these problems though. But even if I don’t, I do know this: our face to face dinner has strengthened our relationship and improved customer loyalty.

Interestingly enough, I think that a major contributor to our partner’s frustrations are a result of a lack of personal interactions, where some people rely too much on email, and don’t spend enough time actually talking to people. In this case, I am almost certain that the severity of the issues today would have been lessened with some judicious personal interaction.

Example 2:
On Tuesday afternoon, I had a phone call from the Director of Engineering from one of our OEM partners. We are working with them on distribution terms for one of their new products to bundle SQL Anywhere. After meeting with him face to face a couple weeks ago, he knew me, and felt comfortable enough to by-pass our sales team and call me directly to ask about a couple engineering related points of the proposal. In a 3 minute phone call, we cleared up a couple key points, something that would have been much harder had we not talked face to face at their office.

One of my jobs on the SQL Anywhere engineering team is to monitor our use of all third party and open source software. I have discussed previously (here and here) the approach we use internally to track its use, and the fact that we do not include any third party code that is licensed under the GPL.

One of our engineering challenges is to interface with other software components that are licensed under GPL or similar licenses. These include various languages such as Ruby, Python and Perl. It also includes many various utilities that very often will exist on systems such as Linux. The most recent example is a utility called “connectd”. Interfacing with these tools presents a challenge because our current business model calls for the SQL Anywhere code to remain proprietary.

In all these cases, the quickest way to interface SQL Anywhere with them would be to write an interface module, linking in the GPL libraries along with our own proprietary libraries. The problem arises because this act would have a very high probability of “infecting” our proprietary code with GPL licensing requirements. (See figure 1)

To solve this problem, we have adopted a different approach (see figure 2). Rather than create a single module, we created a proprietary module that implements a well defined interface that can be loaded dynamically, or called via a web-service call. We then implemented a second module that links in the GPL code, and uses the well-defined interface to make requests of SQL Anywhere. We license the second module under the GPL, and make it’s source code available to everyone. We include the second module on our own installation, as well as at the appropriate community site. For example, our Ruby driver is available on RubyForge.

Using this approach, where we create a well-defined boundary between proprietary code, and GPL code, has allowed us to actively support various GPL components, while not forcing changes in our business model.

I do have to give this disclaimer: I am not a lawyer. These are only my opinions and should not be taken as legal advice. Because the Free Software Foundation is active in their defense of the GPL, you should get your own legal opinion to avoid any potential issues.

In a recent blog post by Tom Peters , he outlined his 120 “Essential Innovation Tactics.” Numbers 17 and 18 below have resonated with me. I believe that it is necessary to interact with a wide variety of different opinions and viewpoints to drive innovation.

17. Hang out/”We are what we eat” We are what we eat/We are who we co-habit with, and variants thereof are of infinite importance to the effective innovator. Managing “the hang-out factor” is of the utmost strategic importance—and usually an under-tended lever.

18. Hang out/Basic axiom. Hang out with weird—get more weird. Hang out with dull—get more dull.

Get the complete list here.

Over the last couple weeks, I have taken explicit actions to interact with as many different groups as possible. Two weeks ago, I was in California visiting with 3 different long time partners. I also took the opportunity to meet with some internal folks in our office in Dublin.

On Friday, I attended the weekly seminar by the University of Waterloo Database Research Group with my colleague Glenn Paulley. Glenn mentioned the seminar by
UW graduate student Umar Farooq Minhas in his blog here. He spoke about the REMUS research project [1] by several University of British Columbia researchers, where they modified the XEN virtualization system to provide high-availability without expensive hardware. Umar and his PhD supervisor, Ashraf Aboulnaga are investigating the implications of this approach with database servers.

Today, I am sitting in an empty office in our sales department, and have spent most of the day helping our sales folks on different sales opportunities and answering their many questions.

I spent some time yesterday with our product marketing manager, and today I joined our PM team over lunch for a Food-for-Thought put on by Eric Farrar talking about a database project on the web built using the Map / Reduce approach.

I plan to continue to mix up my interactions with different groups, and will look to profit by this experience.

[1] Brendan Cully, Geoffrey Lefebvre, Dutch Meyer, Mike Feeley, Norm Hutchinson, and Andrew Warfield (April 2008). Remus: high availability via asynchronous virtual machine replication. In Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation, San Francisco, California, pp. 161–174. ISBN 111-999-5555-22-1.