Building on the Past

A unique aspect of SaaS development that is difficult to get into people's minds during a sales process is the usefulness of building on top of a refined platform.

Most enterprise SaaS apps need customization. I was recently in a sales situation where I was competing against a ground up development shop. I assume they were very good at what they did.

When the prospective client asked me why he should go with a SaaS based mash-up rather than a ground up development I was in the embarrassing position of admitting that all software development is pretty bad out of the gate. That no matter what, you are going to start off in rev. 1 and 2 with lots of bugs that are either in the requirements or the implementation.

In my 25 years in the industry, I have seen little progress in this area. All software has bugs but new software has lots of bugs. That's why cobbling together different mature SaaS platforms makes a lot of sense.

Our strategy is to take one or more existing SaaS platforms or services and limit the customizations to our own SaaS servers that have the effect of bringing the platforms and services together in an integrated and unified end-user application.

Yes, this means we write new code and yes, it has bugs in it in rev 1 and 2. Most often these are requirement bugs. The client didn't know what they didn't know and need to make post launch revisions. To be fair, there are also implementation bugs. By doing everything we can to reduce the new lines of code created, we end up reducing these implementation bugs dramatically.

We build upon the past and still support an entirely SaaS model. That's why we think this will be the model of the future and I hope I will never have to do any ground up development again.

PR: wait... I: wait... L: wait... LD: wait... I: wait... wait... Rank: wait... Traffic: wait... Price: wait... C: wait...

The Offshore Myth

The argument about whether off-shore or near-shore programming works is one that is being fought in a 20th century paradigm. At SaaS Acclerator, we have moved away from caring where in the world a particular developer is and toward rewarding them for the excellence of their work and collaboration.

At SaaS, we currently have developers in India, Pakistan, Argentina and in the US in California and Arizona. Some are in intact teams. Some are individual contributors but none work in a central office.

I remember at one point I worked in a company where the CEO thought that if he didn't see the people working, they weren't. At SaaS, we only hire people who are so passionate about their work that we can't stop them from working, even if we wanted to.

This people policy mirrors our development methodology. If the code exists that we need in a robust SaaS platform anywhere in the world, we won't build the code. We search out best in breed technologies and leverage them for our clients.

At the same time, we hedge our bets with indirection layers and service level integrations that mean we can swap our almost any component of our solution without service interruption. This is also true of our developers. We have them write code, in such a way, that another qualified programmer can pick it up and run with it.

The key to our success here is the "master programmer" model. We hire both master programmers and entry level programmers but the master programmer, not the project manager, decides how a specific software development task is parceled to their group. Our entire goal here is to support the productivity of the master programmer since for whatever reason, they pump out 4-5x more code than their counterparts on the team.

So, in the end, we have a distributed people model that mirrors our distributed solution integration methodology. We have found that this dramatically reduces overall costs to everyone while maintaining the excellence of the work product. It's a global world and we want to position us and our clients squarely in the middle of the innovation revolution.

Near Shore and SaaS

SaaS is about driving down the TCO of applications. There has always been this issue related to SaaS applications. How do you customize it as quickly and as inexpensively as possible?

In the long run, the innovations that are shared reduce the cost to each party but how do you reduce the cost of customizations? How do you speed them given the inherent tension that exists when the SaaS vendor wants slow, incremental change to the platform and customers want rapid evolution of their capabilities?

The answer lies in three areas: Sound SOA in the platform, a robust customization architecture that is supported by off platform services and servers and near-shore development to reduce development costs.

1. Sound SOA practices: SOA has a lot of meanings but the simplest explantion is that the platform is architected in such a way as to provide services to the outside world through defined interfaces. For instance, an ecommerce platform might have a "payment" service that it exposes so that it allows people to create their own services to different payment gateways. The platform never changes but clients can extend the platform. Without this, no SaaS platform will survive for very long.

2. Customization Architecture: Our clients are not willing to wait for their enhancements while a SaaS platform vendor decides whether or not to create a customization for them in the platform. At SaaS Accelerator, we rely on a software/hardware architecture that allows us to create applications and services, host them on our own servers and have them seamlessly interact with the SaaS platform. This allows for rapid deployment, unlimited customization and avoids the biggest pitfall of SaaS: non-sharable customizations adding so much complexity to the platform that the entire thing grinds to a halt.

3. Near shore development: Off shore development is find but near shore is always better. Time zones make a difference. Having real-time access to your team is important. Cultures make a difference. Groups that are more similar work together better. I can't tell you how many times cultural differences have hurt projects we have worked on. It is worth admitting that development will be eternal and reducing the costs of that part of the equation is as much an operational expenses as is the fee for the servers.

Through these three key concepts, mature organizations can leverage SaaS platforms, reduce their TCO and reduce their development expenses, thus driving even more efficiency from their IT systems. They have to be willing to throw out some bureaucracy but that's a small price to pay for this kind of cost savings.