Here are some important architectural guiding principles we are following:

1. “If you cannot Split it, you cannot Scale it”. This came from a great EBay architecture presentation during a SDForum session in Palo Alto in November of 2006. (Presentation: How eBay Scales Presentation)
2. Statefullness is the enemy. This is one of the reasons why we avoid any framework that assumes states between the client and the servers. This is not to say that client cannot store some states, but rather than the client cannot assume that the server will remember them.
3. “Start simple, end simple”. In other words, “keep it simple.” However, we recognize that at some points in the design lifecycle, some components could become a little complex; the goal should be to eventually simplify them.

Principles are hard to always follow, but they are here for a reason… keeping us disciplined. So far, we are not doing too bad at following these principles, but we know we will have some work to do on the database side. The whole trick is to scale cheap…

We are following a home-grown methodology to develop our various strategies. It is referred as the VDE model, short for “Vision Direction Execution”. Each main initiative has its own VDE, and we have an overarching VDE at the company level. Obviously, this is not a new concept, but this simple taxonomy expands the scope of our vision and should facilitate better decision-making. It is also a nice way to make sure that everybody is on the same page.

Here is a quick explanation of the VDE:

• “Vision” is the ultimate goal we want to reach. In most cases, this would be couple of sentences max.
• “Direction” could be seen as the path we think we should take to reach the goal.
• “Execution” represents the steps needed to follow the Direction.

From a Sportner Service (or Product) point of view, the Vision is simple and will probably not change for a while. In short, the Vision is “to build the most vibrant social network for people who DO Sports”. Although this space might seem a little bit crowded, we think that there are some untapped opportunities.

The Vision or idea was the easy part, but finding the right path is always a leap of faith. Here are the top three options we have evaluated:

1. Build a complete “Social Portal” (to use a 90s/2007 hybrid terminology) where sports athletes could find sports partners, organize sports events and games, find sports instructors, share information on sports locations, and swap sporting goods.
2. The second option was to focus on the sports partners and sports instructors market place.
3. The third option was to keep it simple: to focus just on sports profiles and the connection with friends, target a community, and let the users drive us where they will.

The first option was the original idea; however, after conducting deeper market research, we realized that the space was a little bit (not too much) crowded (e.g. Sportsvite.com, Active.com, and Teamsnap.com) and the uptake was not very clear. Sportsvite.com is the closest to what we were planning to do. Interestingly enough, our user interface mockup , which was made before we learned about with them, looked very similar from an information architecture point of view.

Option #2 seemed to be a little bit more open; however, the potential uptake was not really clear either (at least we could not figure it out).

We decided to keep the direction simple, open, and organic. In other words, focus on a few key capabilities, release early, and grow with the community. So, Option #3 it is. “D” is now closed. Now, need to work on the “E”.

On the geeky side, here is some information about application platform choices we made. First, we have decided to write all of our server code in Java. While other development platforms sound attractive, we think that Java has come a long way from its heavy and complex days, and now offers a very complete and mature set of tools and libraries for high scale consumer applications. Find below a snapshot of our current application architecture:

From a bottom to top:

1. MySOL 5 and FileStore are used for data and file storage. At this point we are not clustering the database, and have a simple “File Segmentation” based on user ID’s. Long term, we will have to find a way to “split or cluster” the database.
2. Java 1.6: We were pretty satisfied with Java 1.5, but Java 1.6 seems to perform better, and includes Jaxb2.0. It’s also good to start your development/production cycle with the latest version.
3. Tomcat 6.x: We picked Tomcat 6.x mainly for the reason above (i.e., to start with the latest version). We do not really use any deep Servlet or JSP features at this point. So far, we have been very happy with Freemarker, and our first JSP 2.1 evaluation showed that it still did not meet some of our requirements (e.g., template in the database).
4. Hibernate 3.2: Who would not use Hibernate 3.2 when developing a database-driven application? Actually, there might be some reasons to not use it, but for now, we have determined that the cost/benefits analysis favors using it. We know we will have to optimize the SQL Statement some day. However, we also think that if we want to scale, we will have to cache, which will make the O/R performance issues not such of a bottle neck.
5. Lucene 2.x: Who would not use Lucene to provide search capabilities? There might be some reasons, but we do not know about them. We might use it for our cache strategy as well (not sure yet).
6. Jaxb2.0: This is actually part of Java1.6 now, but from an architecture standpoint, it belongs to this level. While Jaxb1.0 was a typical “EJB2.1 over-designed” library, Jaxb2.0 takes advantage of annotation to simplify a lot the marshalling and unmarshalling rules. We have not done heavy performance testing yet, but the new APIs work like a charm (no need to specify Schemas anymore!)
7. AspectJ 1.5: We are big fans of Aspect programming. However, given that it is not part of the Java language, we are using this library very cautiously, mostly to propagate Interface implementation such as CreationStamp and UpdateStamp. We are using AJDT for Eclipse, which works very well, except for a little bug which is very frustrating. Sometimes we have to clean the project to be able to compile, so it does get frustrating after a while… looking forward to Eclipse 3.3.
8. Freemarker: Freemarker is a modern template engine a little bit like Velocity but more “modular”. It is extremely extensible, and flexible, and while JSP2.1 has some nice features, Freemarker is still the most flexible and mature Java template engine that we know of.
9. Yahoo! UI: For business and usability reasons, our application will follow the common “web page model”, but it will also offer some subtle and advanced AJAX interactions. Yahoo! UI is a solid and complete AJAX framework to incrementally add dynamic behavior to your web page. At this point, we are not sure how many of the standard Yahoo! UI widgets we will be using, but we will definitely use their core libraries. At some point, we might make some more advanced components, and Adobe Flex will be a natural fit for those.

Sportner’s architecture has two main layers:

1. Universal Service Platform (AKA USP): This is not a “Universe Universal” but rather a “Sportner Universal” platform. Basically, this layer contains all of the generic parts of the system that do not have any specific connection with the given “Sportner” application. This allow us to have a clean abstraction, and to have a platform upon which we can build auxiliary applications if necessary (we started to write a “Name Finder Application” during our days of desperation).
2. The Sportner Application (AKA SPR): This is the main Sportner application on top of the USP layer. It has all of the templates and logic specific to the application.

This architecture is pretty basic. The trick is to find the right compromise between using existing libraries and building the right infrastructure. One thing that people could ask us is why we are not using Spring? The main reason is that we do not need it yet. Our first quick look at some Spring components showed us that they might be overdesigned for our needs (at least for now). Our “USP” Layer is very thin, and we are working to make it thinner. At this point, we do not really need more. Time will tell, we are open minded (at least, we try to be).

From Christophe Coenraets‘ brain. It is pretty amazing, when you think that we had been looking for a name for more than a month without success. All imaginable names were already taken; more frustrating, most of them were only being used as “parking pages.”

We were almost in the process of buying a name for over $5,000 in desperation.

Then one day, we got an IM from Christophe saying “Did you find a good name?”, “I found a name for you”, “It’s available”, “sportner.com”, “sport + partner = sportner”, …

Although Christophe gently recommended that we buy the name immediately (for $8.99) and think about it later, we, for some complex reasons relating to neuron interference, decided to wait a day or two. Not surprisingly, a day later, the name was gone. However, surprisingly, couple of days later the name was available again. We took it for $8.99 and sent a big THANK YOU email and IM to Christophe. Everybody likes the name so far (which is pretty rare).

Off the record, we are convinced it was meant to happen. There are no other explanations to Chistophe’s sudden IM, or to the very mysterious name’s resurrection.

Tips: We would like to say that www.godaddy.com has good customer service and a really great price. We used to use other more expensive services (~$30 for a domain name), because we had the feeling that by paying more we would get better support. We were wrong. Godaddy.com is cheap at $8.90 per domain name, and its technical support is top notch.

Welcome to TheMakingOf.Sportner.com. We are starting this blog to share what it is like to start an Internet startup, from the garage up, in the Silicon Valley. We started the enterprise in stealth mode, but quickly realized that it would more beneficial for everybody to share our startup experience. So, here we are.

First, you may ask, what is Sportner? The goal is to build a fun social network for people who DO sports. We are not claiming to be the first, nor the last, but we think we can do something pretty interesting in this space. Only time and work will tell…

Stay tuned for more day to day startup bits from this stream…