By Sramana Mitra and guest author Siddharth Garg
Klaus-Michael Vogelberg: So, again, we first look at interoperability standards. The next step is to think about what kind of services we require, and then it comes down to the question, Are we in category 1 or 2 or 3 which we have just talked about? We next look what are the common services we need to provide to deliver an extraordinary customer experience to our desktop applications. That would typically be things such as automatic update mechanisms and diagnostics. To support customers, you need more plumbing-related stuff such as single sign-on or license and subscription management.
There are a couple of core services [I should mention], and those core services we typically share. In terms of the actual technology we use for this, you will find the usual suspect is either a Java-on-rail or .Net technology which underpins [our solution]. But, conceptually, and in terms of implementation, those are shared fairly consistently across the globe.
When we move to connected services, that is often something where not everything is developed from scratch and not even everything is developed by Sage. In some cases, for instance when it comes to e-marketing, we chose to partner the technologies that have been used or we have acquired. For example, in our payment processing business some of those technologies came to us.
Otherwise, when we build services from scratch – and that was, I suppose, when I got to know [founder and CEO] Suresh [Sambandam] of OrangeScape – whenever possible we choose Web-centric technologies. One such bellwether technology we recognize is Ruby on Rails, which is obviously two things: It’s a programming language, and it’s also the development framework, development methodology. I think it is important to recognize that when it comes to the Web, you do things very differently from how you do things when you develop for the desktop. And while the desktop development methodologies have of course evolved, they are of course still ultimately tied to very discrete release cycles and QA cycles and so forth; you don’t have to do it in the same way when it comes to the Web.
Sramana Mitra: And are you doing something with OrangeScape in that sphere?
KMV: Not at the moment, over and above some sort of proof-of-concept type work. OrangeScape came to my attention almost by accident. The Google Apps engine is perhaps at the moment a slightly underrated piece of technology within the Google stack, and it is not widely used by ISVs [independent software vendor] at the moment. So, OrangeScape came to my attention in the way they had looked at this. Their way is to use the app engine indeed as an engine but to actually abstract the business logic, where we would typically tie our IP to abstract that and then use the Google engine only as a runtime environment. This is a very innovative approach, and that is how I came to eventually met Suresh in Bangalore a couple of months ago.
SM: And is that, developing applications or deploying parts of your product on the Goggle Apps engine, something you are considering doing as a part of your business? Because as you said, not many ISVs are delivering products from the Google Apps engine. So, this would be an interesting innovative direction. I am curious to hear more about what is driving that decision, how it relates to other options, and why you have chosen the Google Apps engine versus other platform as a service same way?
KMV: Again, we could go back to our SMEs, so we are concerned with what is relevant to our SMEs. Now, what we indeed see is that Google Apps for business is becoming relevant to some of our SME customers. In the past 15 or 20 years, that is dominated by Microsoft office, and in many ways we have always provided the kind of accounting counterpart to office application. That is fundamentally the payroll equivalent to that. And of course, in the past we would have integrated with Microsoft office and their environment to do that, which was in the main the VBA [Visual Basic for Applications] environment. That is how [people] have written Excel plug-ins and the like.
Now, when you recognize that some of your customers are moving to Google Apps, personally we will not take a view or comment on this. We are neutral, in a way. If that is what our customers or what SMEs choose to do, we will follow them. That is of course where the Apps engine comes into play. To start with the Apps engine, while you may also see it as a sort of capacity, but Suresh of course sees it as a run-time environment. Of course, it is also an important integration environment because it is technology close to the Google application.
SM: Yes, no question about it. I think the piece that Google Apps is missing is, as you said, the business logic abstraction layer, and it is hard to develop business application on top of Google Apps engine today and Suresh has done a very nice job of building that in OrangeScape. And a combination of Google Apps and OrangeScape is a good combination to support that deployment.
KMV: I completely agree, and at the moment it is an underrated piece of technology. At some point Google needs to decide what they want to do with it. It is a bit like Microsoft Office sat on the fence for years with VBA; they could never quite decide was it a customization environment or was it a genuine programming environment? And it just feels like that at this moment, too.