SaaS Blogs

Yes to all three. We’re leveraging both our own API and other APIs (SalesForce, ExactTarget) and even products without APIs via our HTTP GET/POST utility to deliver tighter data integration between our form/survey tool and data repositories in the cloud.

Hmm,
I think it’s an interesting thought but I’m not sure I believe in the distinction between “you get fast (speed or deployment) or you get flexible”. I think the old mentality of “build a single instance now and I’ll make it a cluster later” has perpetuated this belief, however I think that “clusterizing” from the beginning can (when planned correctly) provide all the benefits or a nonSOA approach in addition to the flexiblity.

Good point. I don’t intend a hard and fast stance on fast vs. flexible. The post should clarify that ease of writing performant applications is present in non-SOA approaches and is more difficult in service oriented business apps.

Clusterizing may solve some issues, but I think it still lacks in the flexibility. By virtue, an application is not very modular if the only scale fix is clustering. If it’s not modular, you probably don’t have much policy and governance control for specific pieces of functionality. Is it possible that you at a minimum exposed functionality as a service to the outside world? Absolutely, but now any “hot zones” that could normally be isolated in a more modular approach requires an over allocated scaleout.

I’m never a fan of drawing a line in the sand and specifying that “it’s this implementation or nothing.” To that note, I’d venture to say that many apps can benefit from a truly SOA, modular architecture rather than a clusterized lump of functionality.

Ofcourse technology choices should be driven by business strategy. The positives of SOA shown are best practices in general for any software product SOA or non-SOA.

One can argue endlessly on the ROI of SOA vs. non-SOA in the long-term. I agree that it depends primarily on the long-term business strategy. Though I am not convinced that non-SOA can get you to market sooner.

Thank you for your post. I agree with you about the conclusion. I think SOA is definitively the way to go for new SaaS applications.

But I am not sure about what you place in the balance to decide to go for one or the other solution.

Rather than taking a technical point of view, I would look at the benefits for the end users who are supposedly the ones software companies try to please.

Let’s assume that the ideal application is an application where each user can get all the functionalities he wants, the way het wants.

Considering the non-SOA option, well, if you can achieve that goal, it is wonderful for you. You have understood the business needs as nobody else has done. Your vision is the one shared by millions others.

Still, the chance that this becomes true is quite low. You might have an open mind and try your best to please the majority by listening to your community, you will never please all of them.

Further more, in the long term, your application may not answer to new needs expressed by the community.

Let’s have a look at the SOA now. Well, you might have your vision about how the software should be. It might be limited compared to what could please everyone but at lease you have let the door open.

Doing this, you allow SaaS catalysts to reinterpret your vision in another way. Maybe they understand the real need better than you. Maybe they will create links between softwares that were never thought before (Imagine how Google Maps is reinventing its context each time it is used in a smashup).

So what I see in the balance is: “Am I ready to impose my vision to everyone because I know it is the right one? Am I sure each time the trends will move I will understand it?” compared to “I might have to make choices and take position in the vision I will deliver through my software, still, let’s keep it open to others that might have better ideas than me and ultimately will do the job for me”.

I really feel it more like taking more chances on your side when trying to move to the success and a better strategy for the long-term trying to stay up to date with new trends that you could miss or not understand.

I also prefer the SOA approach because it is one step further to the “mashupization” of SaaS applications. And when you look at the benefits for the users of Mashups automation portal such as Netvibes, if apply to softwares, you are one step closer to user satisfaction and comfort.

Yves, all very good points. I think the topic of SOA from the end users perspective and the value they derive from it warrants a discussion all on its own.

From my perspective, there is almost no reason to write SaaS without an SOA approach. There are so many frameworks out there now that to skip SOA is simply not justifiable.