Application Service Provider Architecture Models

How do you architect an ASP web site?

I was recently asked by a new acquaintance how I might create an application service provider (ASP) oriented architecture for a new product his company is creating. They must be able to customize the application per customer while still maintaining a core, code-base. The system they are trying to create is actually pretty complex even as a single site.

Iterate
In my experience, the solution to a complex system is extremely difficult to arrive at on the very first try. This point is discussed a bit in the fantastic book, "Wicked Problems, Righteous Solutions" (more about wicked problems). I suggested to him that—instead of trying to create the perfect application on the first attempt—he should aim towards perfection and temper his feature choices to only those specifically requested and prioritized by his alpha customers and then iterate.

This allows you time to learn more about the problem. It allows you time to learn the industry, the customers and the patterns of the application. As you learn, you can innovate and move the application further along. You can work with your customer to learn what works and what doesn’t work. As we discussed solutions, I pointed out that Windows Vista could never have been imagined when Windows 1.0 came out—it had to evolve.

What Does the Customer Want?
It is import in product development—especially early on when resources are limited—to make sure that you are creating only what customers are asking for. This seems obvious but is often over misunderstood. Marketing and Business Development can easily muddy the line between what the customer wants and what they believe will make the product “strategic”. If you’re not careful, you’ll find yourself working on elaborate, whiz-bang features that no one has asked for and that may never be used. Also, watch out for the Business Analyst or Subject Matter Expert that “knows what’s best for the customer” and orders up features that only they find useful.

Make absolutely certain that if the customer hasn’t asked for a feature, you have a darn good reason for implementing it. Sometimes, on smaller projects, you can get away with this and hide the costs for your gold bricking. I wouldn’t recommend it though. The guessing is just not worth it when you can simply ask the customer.

Partitioning Databases
“Do we have one big database for everyone that is hosted or a database for each customer?” he asked. "The answer depends upon the nature of the application and the data," I told him.

Consider my application Diggermajig. This site allows you to upload Accelerated Reader Exams for schools, display lists of book information, and create personal user accounts for monitoring progress and wish lists. I have one database for all of this because of how the information is all related. I use relationship tables between users and organizations and books to keep things separate. I don’t need to have a separate database for each "customer".

However, Fog Creek’s FogBugz software is a little different. If you create one of their risk free offer sites, you’ll get your very own personal database for storing your bugs, code sets and other information. Nothing you do to your database will impact anyone else’s in any way. This is required because of the nature of what is being stored in the database.

There’s also the hybrid—a combination of the two. One database for the static, application-wide data and a separate database for each of the customer’s data. We took this approach with Loan Complete. We had a single hybrid database for pricing information and a database per customer for company specific information like loans, code sets, users and status information.

When choosing an approach, keep in mind upgrading and maintenance costs. I’ll leave it to you to explore the pros and cons of each approach.

Partitioning Web Sites
You have the same considerations as the databases when customizing the look-and-feel of the site. This web site—Blogger.com—allows you to customize the look and feel of the site. The content is custom as well but you are still only hitting one site. Contrast this with  Godaddy.com–a hybrid approach.

Summary
If you are getting into the ASP world with a new product, try to learn from what you can gather about what other people are doing with similar structures. Don’t be afraid of making mistakes. Be prepared to move fast and don’t look back. Creating an ASP site can be a lot of fun and a fantastic learning experience.

One thought on “Application Service Provider Architecture Models

  1. I know this comment is just touching on a very small part of this post but i cant help but mention it.

    If you divide your database architecture into a database-per-client model be aware of the deployment considerations for any and all SQL changes.

    Keeping the schema and objects identical once such an implementation grows to a large scale will be a big challenge. I know of no deployment tools that specifically meet this scenario as at a company i worked for i was forced to build such tools myself (and with good results).

    So yes it is possible to run an divide database infrastructure but just consider it from various angels. To me SQL Server always seemed better at one large database then many… many… many.. small ones.

Comments are closed.