Computerworld recently published an article States slam Google, Firefox as no match for Microsoft
It leads off with
In a brief submitted to federal court, state antitrust regulators dismissed companies such as Google and Mozilla, and technologies such as Ajax and software-as-a-service, as piddling players that pose no threat to Microsoft's monopoly in the operating system and browser markets. .
They essentially want the courts to continue antitrust monitoring Microsoft for another 5 years until 2012
In their most recent brief, the states countered Microsoft's contention that Web-based companies -- Google, Salesforce.com, Yahoo, eBay and others -- and new Web-centric technologies constitute what Microsoft dubbed a "competitive alternative to Windows." .
The Department of Justice is supporting Microsoft on this one.
Setting aside any arguments of Pro/Anti-Microsoft camps, is it not fair to say that despite Microsoft's dominance in the the Desktop/OS market, companies such as Google have experienced phenomenal success and growth in the web 2.0 and as such would it not be hypocritical to recognize that success and then try to restrict Microsoft further?
Wednesday, November 28, 2007
Computerworld recently published an article States slam Google, Firefox as no match for Microsoft
Wednesday, November 21, 2007
I read an interesting post today from Julian (yes another fellow kiwi and further evidence of NZ's entrepreneurial spirit).
Julian discusses the pitfalls of building a SaaS application for a single vertical, where there is risk of that vertical reducing in size or changing in requirements.
I totally agree with Julian, that a generic based application should be the goal when building your product. When making design decisions you should consistently look at how you could build a specific vertical requirement as a configurable generic feature.
Julian then goes on to state that
Would you rather have 1% of 1000 vertical markets? or 100% of 1 vertical market? These days, I’d rather have 1% of 1000 vertical markets!
I don't quite agree with this, there are times where it isn't as clear cut.
Certainly companies like Salesforce.com and even the company I am currently involved with Forcelogix have built platforms where if your business is centered around a salesforce selling to customers, then its independent of the vertical market your business is tagged to. It could be Finance, Consumer Goods or Life Sciences and many others.
However, where might a vertically focused application be preferred?
1. Where the vertical has repeatable specialist requirements
2. The market is large enough to support a new SaaS player. US Pharma industry is a good example where there are around 100,000 Sales Reps in Pharma
3. Bootstrapping your own startup and you have years of specific industry experience and contacts within prospect organizations.
4. Prospective early funders/investors might more easily see the value proposition of your product if a vertical is targeted.
I tend to refer to Life Sciences regularly in my blog, and that is due to this very issue. Its happened more than once, where I have built a generic business application and because our initial customers happened to be Pharma, it made it a lot easier to sell to other Pharma organizations. We became experts in this industry. It doesn't mean you can't go on to be successful in other verticals,far from it, it just makes it easier to focus and to grow your business, at least in the earlier stages.
There are proven SaaS success stories with both vertical and generic approaches. You just need to evaluate what is best for you.
Sunday, November 18, 2007
I was just talking to a friend of mine at Salesforce.com.
We were discussing their Platform as a Service offering force.com. One of their earlier adopters is a company called Verticals OnDemand. By utilizing force.com, they have been able to build a fully functional SaaS Life Science CRM Platform. They have partnered with a number of industry respected organizations and appears to provide the complete solution for Life Science ETMS and CRM. Word has it that they are getting strong interest within the Life Science Community.
This could be another major win for the SaaS movement. Life Sciences at first glance would appear to be one of the last verticals which would consider SaaS due to its stringent regulatory processes. But if Pharma organizations are strongly considering Verticals OnDemand, then I strongly suspect many of the potential objections have been handled and overcome, due in no small part to being based on the proven salesforce.com platform. This is an organization worth keeping an eye on.
Saturday, November 10, 2007
One of my favorite bloggers, Bob at SmoothSpan has a post (almost one month old now, but its taken me that long to think through it) which discusses the question Are appliances SaaS?
A growing number of vendors are delivering a service platform where their software is either deployed to the customer
1. In a Hardware package which is plug and play in customer network.
2. A Virtual Machine which can be downloaded and installed by the customer.
These appliances contain all the application components needed to run the service application including the DBMS.
Appliances are definitely an improvement over a traditional On premise solution, but there are a number of key support and operational challenges that SaaS handles well and Appliances do not.
1. Appliances tend to have better Version Control and Management for Upgrades than On Premise solutions. Vendors can push updates out to their entire network of installed appliances, which means there is no version mess and support burden of handling different products.
But there is a question mark about the reliability of this process when dealing with large numbers of appliances. I can guarantee that if you send an update to enough appliances, that a number of these updates will fail.
This could be caused by the usual risk factors:
1. Network outage on Customer side during. Less likely to happen in an established hosted provider like Opsource
2. If the software update has database schema changes, something could crash during this process. If you are updating thousands of databases this could very well happen.
3. Security and Permissions have been changed.
4. Hardware failure
On the other hand, one of Bob's respondents stated a major benefit of a Virtual Appliance is that it gives the client the opportunity to test the update before applying to production and even goes so far as to say that this is preferred at times over the risk of a single update in a true SaaS application. I would suggest that the opposite is true. In one of my earlier blog posts I discuss the huge problem 'on premise' vendors face with versioning and upgrades. The same holds true for virtual appliances albeit with less risk of the OS environment changing. Customers will test at their own pace, and more often than not the decision to upgrade will be delayed sometimes indefinitely. You therefore lose some important agile benefits of a SaaS system. Customers do not regularly get updates and miss out on new features, the SaaS vendor spends more time on supporting, developing and testing for different versions with updates having to handle different environment scenarios which has a direct impact on service delivery, and more time is spent working with the customer through the QA phase and working through potential objections to the upgrade.
There is no doubt that Appliances are superior alternatives to On Premise, in fact an integration appliance should be your first choice, if you have a mix of SaaS and On premise systems which require integration from behind the firewall. A Good example of this is Cast Iron Systems which has appliances for SaaS systems Salesforce.com and Rightnow.
I haven't been back to New Zealand for more than 3 years, but this Christmas we're heading there for a months vacation. As I count down the days, my wife and I find ourselves surprisingly talking about the food.
Ponsonby Pies,Fresh Fish and Chips, Marinated Green Lipped Mussels, Bluff Oysters,Burger Fuel (my wife's favorite), NZ Thai Food, Vogel Bread, Cheezels, Flat Whites, the list could go on forever. Anyhow I digress,
Being away for so long, its easy to forget that New Zealand is a nation with a surprisingly large number of talented and forward thinking technologists and business people. In my recent readings its apparent that NZ has really embraced SaaS. Paraphasing one of the following bloggers (sorry I forgot which one), due to NZ's geographical isolation, New Zealanders more than most realize that with Web 2.0 and SaaS, your customer base is the entire globe. You are no longer limited by oceans and borders.
I have included here 3 SaaS blogs in New Zealand whom I have been following with great interest.
Diversity - Ben Kepes
Love to hear from other Kiwi Bloggers too,
Thursday, November 8, 2007
I read an article today from PC World titled SAP uninterested in enterprise SaaS
This is a very typical response from a traditional enterprise software vendor who underestimates the pervasiveness and stickability (I like that word a lot better than traction) of SaaS. Lets look at a couple of quotes from this article.
The ERP giant was "not so interested in 'drop-in' services for three or four users, he said. "We want to run the company, we want to run the business, we don't want to just support some services for some users in the company."
This simply indicates the inflexibility and non agile nature of On Premise vendors. Of course they don't want to support 3 or 4 user systems. The cost of sales and support is just too high for them. On premise vendors struggle with both providing customers with new features regularly and version control which Bob at Smoothspan blogs so effectively about.
Back in my On Premise Days we struggled with these exact same problems which haven't changed today.. We had a major product release once a year, the problem was and is how did you deploy that release to all your customers. In the end you don't.
The whole on premise product release process is non agile in nature because of the risks involved. You can't bring out a product release more than once a year because you have to test every permutation of what could go wrong with each customer's installation and build upgrade procedures for all previous versions in existence. You then announce to the customer that there is a new release with a whole bunch of new features and it will cost them 1 million in services to upgrade. They look at the new release, and then say "thanks but no thanks". They look at the risk of something going wrong in the upgrade and say its too risky and too expensive.
In the end you find yourself using your latest release for new customers only and you are stuck with a version quagmire. Its a vicious cycle as each new release then has to cope with yet another older version upgrade.
John Rowell from Opsource also posts about this issue of SaaS vs. on Premise
The beauty of SaaS is obvious, one instance of the application to upgrade and all customers benefit from new features. Because of this, SaaS becomes very agile. You can bring out cool new features once a month because you don't have the baggage of versioning and handling different customer environments.
SaaS also is a whole different philosophy when you begin looking at user counts.
SaaS doesn't care if you are 25000 users or 3 to 4 users. It can handle it all. There is no "sorry you are too small for us". SaaS can't handle large user count systems? Somebody better tell Salesforce.com that, earlier this year they closed a 25000 user deal.
"They would prefer a quick win, that could be some CRM functions on demand," he said.
They might later want to bring in on-premises software, he said. "That would take the risk and cost down."
It was suggested in this article that SaaS was seen by enterprise customers as a short term fix before going to a long term on premise solution.
Once again I will speak from personal experience. We had one enterprise prospect, it was down to us and a traditional on premise vendor, we won the deal because our competitor quoted an 18 month project, with a 7 figure cost, plus annual maintenance fees. We offered a SaaS solution and said we could roll out immediately and would release new features once a month. 6 months later we had one thousand users in multiple countries all using the same instance as all other customers. Consolidation of country data was painless, (can you imagine what this would have been like with an on premise system) and customer feature requests were being delivered monthly with our entire client base benefiting from these enhancements.
Can you imagine a customer in this scenario saying lets implement this SaaS system just for the short term and then go On Premise in the long term? Not Likely...
Tuesday, November 6, 2007
I was asked the other day about how you could possibly implement a Scrum development methodology in a regulated environment. In the past I dealt with many CRM systems which had to comply with PDMA and 21 CFR Part 11 compliance for systems involved in the physician sampling of controlled substances and RX drugs in the US market.
This post isn't strictly about SaaS but I still thought it worth blogging about.
When building software within FDA boundaries there are certain key processes which need to be adhered to, to ensure your software is 'validated' and to reduce the chance of irregularities being discovered by FDA or Customer Audits before you find them yourself.
The key starting point for this conformance is a Quality System. When Auditors come in, this is the first document they ask for, "Where is your Quality Manual?". They will then perform an audit to verify that your product release processes conform to what you have written in your Quality System.
Now the traditional process in this case has been the Waterfall method, with a top heavy design document stage. This process really means big lags between releases and continual revision of documents and the required re-validation of documents and coding after change. The revisions were unavoidable in waterfall as no one got to review the product until close to the end of the long development phase. Then there is the good old Traceability Matrix. This is used to ensure that every requirement bullet point in your 180 page document Functional Spec and 200 page Design Document is traceable through all stages of the Waterfall. An impossible task to get right the first time. We are talking potentially thousands traceable points. When undergoing validation, random checks through this matrix would undoubtably find a missing link and things would have to start over again.
This is in contrast to Scrum, with its iterative release process, sprint cycle of 3 to 4 weeks, daily meetings, managable small sets and clear cut requirements and early feedback. The traceability matrix is small and easily tracked and issues are found early on as the progress is visible on a daily basis.
The perception has been you cannot use SCRUM in this regulated software environment. But in reality, what auditors are looking for is a Quality System you have implemented which is consistently being followed to ensure compliance with the legal aspects of your software. So if your Quality System states that you use Scrum Methodology and that your documents contain the expected FDA Requirements, as long as you are conforming to your quality system during your development projects, then you will pass validation.
Monday, November 5, 2007
I just answered a linkedin question about what will become the predominant solution SaaS or On Premise. I thought it worth posting about.
Firstly lets have a look at why some organizations may have a natural resistance towards SaaS. An Article in CIO magazine lists a number of these reasons which I summarize here.
1. Service levels cannot be guaranteed by SaaS vendor
2. Lack of configurability
3. Sharing functionality with hundreds of potential competitors
4. Elimination of CIO role
I will add a couple more here
1. Hosting data outside of firewall.
2. Loss of control due to business units running "rogue" IT projects using SaaS.
Lets take a look at why these 'inhibitors' become non-issues for SaaS.
1. Firstly SaaS Service levels. Gone are the days where a startup SaaS vendor will try to host their own service. This is not a core competency, as such SaaS vendors follow their own value proposition ie find an expert to handle Hosting and service levels. Companies such as Rackspace and Opsource will handle this side of the business with guaranteed up times.
2. Lack of configurability. SaaS obviously enables you to implement a system which can be used in a very short amount of time, bypassing on premise challenges such as server provisioning and software installation. However SaaS does not mean the end of configuration. Salesforce.com as an example provides a very flexibility platform for building your own custom objects and UI, as do many other vendors. This enables you to model the 20% of your business process which is unique to you.
3. Sharing functionality with other organizations. This works both ways, sure you may have had an idea which the SaaS vendor has taken and made available to others. But this means you too will benefit from other organization's ideas. Furthermore the uniqueness of your business process is part of the configuration model mentioned in item 2 above, it is not part of the standard functionality of the multi-tenant single instance.
4. The CIO role will not be eliminated. In fact I see it going the other way, where it becomes even more a strategic organizational role. The CIO must make decisions on what is SaaS and what is on premise, they also need to determine how these systems integrate and how information is conveyed within the organization.
5. Data outside of the firewall. This continues to be a major topic in the news. But as the trend of utilizing data center experts such as Opsource and Rackspace increases then the risk continues to reduce, as these companies' entire success hinges on security and reliability.
6. Rogue Projects. Many time business units within an organization will look to a SaaS solution as they have been told by IT that their needs cannot be serviced in a timely manner internally. As SaaS becomes more widely accepted and recognized by Internal IT not as a threat but as an asset then SaaS projects will not be seen as rogue projects but rather an IT recommended solution. This will enable CIOs to adopt SaaS in a more structured and integrated approach.
The current generation of CIOs may have these inhibitions towards SaaS and will take time for these 'fears' to be overcome.
However what ensures the longevity of SaaS is the next group of CIO's who are in college or have recently joined the workforce. This crop will see Web 2.0 as a totally natural way of doing business as its what they do in their personal lives.
Storing files and documents, in Google, in Microsoft Live, social networking, wikis all are ingrained in this new generation and SaaS will become the obvious choice.