A Programmer's Guide to Starting a Software Company and Building an Enterprise Application - Article 1

Introduction

This is the first in a series of columns in which I will tell you how I started SplendidCRM Software, Inc. I hope my entrepreneurial experience will inspire you as creating a company can be a wonderful adventure.

Article 1

I started SplendidCRM Software four years ago when I was between jobs (in other words, I was out of work). I was bored all day and was looking for something challenging to do. I read the latest trade journals, which included an announcement about SugarCRM, a new, open-source application. Since SugarCRM was an enterprise application and I was an enterprise developer; I immediately thought to myself, "I can do that, and it is a good match”.

The way I approach these kinds of projects is to assume that my efforts will not be wasted. Even if my software generates no revenue, I am certain to enhance my skill set, become a better developer, and become a more valuable employee for any future employer.

With SplendidCRM Software, the best part was that all of the application design was already done. Also, as long as I followed the terms of the original open-source agreement, I was free to use the existing artwork in my implementation. I did not have to think about the details of the product; I simply had to apply all of the skills that I had learned over my career as an enterprise-software developer.

By selecting a CRM, I had a really good feeling that there still were plenty of software challenges. By way of example, an enterprise company usually has offices all around the world. Its employees live in different time zones, speak different languages, and use different currencies. Most important, they all access the same CRM and all want the experience to be localized. Therefore, an enterprise product needs to:

1. support multiple databases
2. support multiple platforms
3. support multiple languages, and
4. support multiple currencies

On top of these four challenges for a global enterprise, the resulting system would need to be fast.

Let me repeat myself. I am an enterprise developer, so I selected an existing enterprise solution and set out to create an identical solution. If you are a games developer, consider creating a game. You don't have to design a new game; instead, just find an interesting, existing game and try to duplicate it. Chances are that in the process of creating an identical game, you will learn something new. In my case, SplendidCRM is not different in functionality from SugarCRM, but it is different in technology and I believe that it has a much better software design. I learned so many new techniques that I will have to save them for future articles.

I was lucky in that SugarCRM was developed using the LAMP stack and my skills were and still are with the Microsoft stack. In the end, each product - each based upon a different stack - behaved the same, but focused upon a completely different audience. Whereas a LAMP stack product would most likely be selected by a company with an investment in Linux servers, a Microsoft stack product would most likely be selected by a company with an investment in Windows servers.

The web is filled with these kinds of opportunities. For example, DotNetNuke is a Microsoft.NET-based web application that was partially inspired by another open-source, content-management system. Alfresco is a relatively new, open-source, content-management product that is just waiting to be re-implemented in .NET. There must be a lot of these types of opportunities out there.

With the economy down, a lot of people -- including programmers – are out of work. If you are currently out of work, I suggest that you take your free time to start a new project. With SplendidCRM Software, I did no market analysis and I did not research competitors. I simply started to create a similar product. (Fortune-500 companies do this all the time; for example, Chrysler invented the mini-van, which was so successful that, in a few short years, all the major car manufacturers started to produce mini vans.)

When you are out of work, you certainly need to spend time looking for a job. Being realistic, you are not going to look for work 8 hours a day, 5 days a week. Spend an hour or two every day looking for work, but then make certain that you spend the remaining time doing something that is productive, new, and enhances your skills.

The goal of this series of articles is to inspire programmers. In order to keep programmers interested in the series, I will include in each article a technical section that describes how or why I have applied a specific design strategy in SplendidCRM.

Use of GUIDs

SplendidCRM relies heavily on the use of GUIDs (Globally-Unique Identifiers) as its primary keys. I was introduced to the GUID more than 15 years ago while developing COM interfaces for Windows 95 applications, and I have been hooked ever since. A GUID is a 16-byte array that is typically formatted as a 36-character string.

When you have been developing enterprise applications for a while, you quickly realize the benefits of using GUIDs as primary keys, as opposed to integer primary keys. While it is true that an integer-only key takes only four bytes of storage, the difference between 16 and 4 bytes is insignificant in most applications today. (Read this.)

What is more important is that an ID can be assigned a globally unique meaning without there ever being a reason to reuse the ID. Integers do not have the same luxury. When integers are used as primary keys, it becomes difficult to determine what the value means. For example, is 2077 a customer number, an account number, a case number, or a bug number? It was interesting to see SugarCRM 1.0 start with integer, primary keys. Clearly the initial developers and architects of SugarCRM did not have experience with the development of enterprise applications; otherwise they would have used GUIDs from day one. (Read this.)

One of the best reasons to use GUIDs as primary keys is that data can be imported without having to re-key. You don't realize how important this is until you have to combine and validate two databases, each containing 50,000 records.

Once you adopt the GUID, you must treat it like a religion. And one sin that you should never commit is to place a non-GUID value inside an ID field. We saw this first hand with SugarCRM. Clearly they were not followers of the religion because they -- to this day -- mix GUIDs in the Team ID field. Heresy!

Imagine that two companies are merging and each has a CRM. If both use integer primary keys, then the merge would be painful because, for example, each system could have an account with an ID of 12345. To make matters worse, the same account ID could be referenced in 1000 locations within each CRM. Not only would the merge process need to replace the ID of 12345 by a GUID, but the process would also need to search and replace the 1000 references to the new GUID.

We experienced this problem first hand when a customer requested that we to migrate their SugarCRM database to SplendidCRM. SplendidCRM was specifically designed with a near-identical database schema in order to make this kind of migration simple. However, the use of non-GUIDs in ID fields required additional work. As part of the migration process, we had to scan every ID field in every table in the entire database and convert all integer keys to GUID keys. We also had to re-key the Teams table because the clever folks at SugarCRM saw fit to place the prefix “private” in the ID field.

To be fair, it is not SugarCRM’s job to ensure that it is easy for others to steal customers away, but I do not think that is what they had in mind with their flawed design. I conclude here that SugarCRM developers do not fully believe in the religion of GUIDs.

I now come to an end of our brief introduction to GUIDs. I have a whole series of articles -- of which this is the first -- planned.

History

• 25^th May, 2009: Initial post