Author Archive for TroyWing

There is no such thing as "functionally complete"

Published by TroyWing on July 23, 2008 in Business, Design, IT and SaaS. 0 Comments

I just completed revisions to our Software Development Methodology handbook. It got me thinking about how many times I have written something like this and how its changed over the years.

As would be expected from a Software as a Service company, we approach things from an incremental development and update perspective.

We look to deliver new features every 6 to 8 weeks. We have a product roadmap which is a living and breathing organism. At the beginning of each year, we sit down (representatives from Marketing, Client Services and R and D are all there).

We look at the Roadmap and work out what is needed for the following year.

Once we satisfy this objective we then proceed to work out what is needed in the first 6 to 8 week iteration. As we release each cycle, we review the roadmap and determine the requirements for the following cycle.

This is the reasoning for my post title. At no point do we ever say our product/service is functionally complete. Back in the days of on premise software, we would pursue the venerable Waterfall approach. We would map out and plan for a development project of 12 to 18 months, aiming for at most 1 release per year. Users wouldn’t even get close to the new version until it was close to being "functionally complete" as a product. I would remember our customers/prospects getting all excited by some great new feature we would show them in a presentation, but a year is a long time in business, and by the time the product update was officially released, all the positive "vibes" and excitement of the initial announcements would have truly been forgotten.

By having 6 to 8 week feature updates, we are continually registering small wins with our customer and prospect base and keeping strong the goodwill of those customers. It also makes the term "functionally complete" an anachronism. A service should always be evolving and adapting. If you wait for 12 to 18 months between releases, your product will die a slow death.

A guest post by Troy Wing - CTO for Forcelogix

Share the love...
[Bloglines] [BlogMarks] [del.icio.us] [Digg] [Facebook] [Google] [Reddit] [Slashdot] [Sphere] [StumbleUpon] [Technorati] [Yahoo!] [Email] More »

SaaS Vendors: Practice what you preach.

Published by TroyWing on April 10, 2008 in SaaS. 0 Comments

I have been quiet in March, due to my company acquiring new customers.
Writing blog posts about specialist topics such as SaaS requires a fair bit of regular reading, which was reduced to a minimum for me. So in lieu of that I am posting on an area which was quite a significant part of what I was doing in March, Release Management and Source Control.

Like many companies, I run a distributed team of developers, some in India and some in Chicago and myself here in the East Coast. Its a major challenge communication wise but very doable if you have the correct tools in place.

True to my previous blog posts, we use lots of virtual tools to enable that communication, but one area we have stuck to traditional methods is source control.
It was an old habit that remained with me throughout the years. We have the usual on site Source Server (running Subversion on Apache) which is only accessible from inside our office VPN with regular offsite backup storage. Now this works fine, but as with all server environments this requires regular server and security support. With customer deadlines, developers were up at all hours of the night, and our internal VPN was experiencing occasional outages. Our guys in Chicago were more than helpful in getting up in the middle of the night to resolve, but this got me thinking, why are we investing in an on premise source control environment while we are trying to persuade our customers to trust us with their valuable and confidential data? We of course use a market leader in enterprise hosting for our production application and database servers which is an environment totally independent and separated from our office network and VPN.

So right now I am looking at possible outsourcing scenarios.

Option 1: Configure your own source server but leverage the infrastructure of a Rackspace or an Opsource.

Option 2: Go fully Software as a Service with your source control.
One in particular I have been looking at is Dynamsoft. If you google hosted source control, they seem to dominate. They offer a variety of hosted options including a free version for up to 5 Mb of source code and packages for Enterprise and ISVs.

It may be hard to consider putting your source code into an external environment, old habits die hard. But the same rules apply to you as a SaaS client. Simply research the SaaS Source control vendors, understand how they protect your code, look at existing customers and be comfortable with backup processes and how you can maintain a copy of the code locally.

I think its worth looking at.

Mirror Post can be found on Troy’s Blog.

 

Share the love...
[Bloglines] [BlogMarks] [del.icio.us] [Digg] [Facebook] [Google] [Reddit] [Slashdot] [Sphere] [StumbleUpon] [Technorati] [Yahoo!] [Email] More »

Who is using Force.com?

Published by TroyWing on March 4, 2008 in SaaS and Web x.0. 0 Comments

A number of prominent blogs including Renee Boucher Ferguson, Sinclair Schuller and Bob Warfield this morning wrote about the outcome of an informal straw poll conducted during a panel discussion hosted by Phil Wainewright at the OpSource SaaS summit this week.

In a show of hands, Out of 250 ISV’s attending the summit,only 2 were planning to use Force.com as their Dev Platform. (40 responded yes to building their own SaaS platform and 10 to a Software plus Services approach). Bob and Sinclair discuss their viewpoint on reasons why this was the case.

Some of these points included
1. Salesforce.com is not a neutral platform.
2. Its more of an “Extension platform” not a revolutionary one.
3. Bob adds that its too expensive an option.

So what is the sweetspot for Force.com? Bob rightly points out that it will appeal to Internal IT departments within Enterprise already using Salesforce.com as they are not as price sensitive. I agree with this as my experience at Dreamforce when Apex was first announced a couple of years ago, IT Department employees sitting at my dinner table were excited at the prospects of building their own modules, while the ISV’s sitting at the same table were lukewarm.

I believe Force.com will find its dominant niche in areas which are CRM related. So I actually think its sweetspot will be vertical offerings of CRM. http://www.verticalsondemand.com, a Pharma CRM system built on Force.com is a prime example of this.

The challenge of gaining a significant foothold into general SaaS platforms is a far greater one for Force.com. There are many SaaS solutions and ideas which are not customer centric at all. Maybe this is where Platform as a Service is heading? Specific Value Add platforms for specific business functions.

This was originally posted by the author, Troy Wing on his personal blog.

Share the love...
[Bloglines] [BlogMarks] [del.icio.us] [Digg] [Facebook] [Google] [Reddit] [Slashdot] [Sphere] [StumbleUpon] [Technorati] [Yahoo!] [Email] More »

SaaS Presentation Layers exist out of the browser

Published by TroyWing on March 1, 2008 in SaaS and Web x.0. 4 Comments

In a recent blog post, SaaS Blogger Phil Wainewright made some excellent points on what defines a SaaS client.

Some purists may disagree, but my definition of a SaaS client goes outside of the browser to include a client that runs on the desktop machine so long as it’s still controlled and managed from the Web.

Phil’s definition, reinforces the views I have repeatedly expressed in my own blog.
Webifying Desktop
Software+Services or SaaS, the key word is Service not Software.

Phil discusses the real world examples of this happening, including RightNow who have showcased their new On Demand Release which utilizes Microsoft .NET Framework capabilities.

This is still true Software as a Service, because all the benefits of the Multi-tenant single code base exist in these flavors of SaaS client.

There are viable alternatives to pure browser based solutions, which up the ante in UI presentation and brings parity between traditional Client/Server (On premise) UI and SaaS UI.

What’s next then? as per my previous posts I predict sometime in the future, Desktop and Browser will merge again. When a user boots up her computer, or utilizes their smart phone, it will be one and the same. SaaS will ensure accessibility to data in the cloud from all devices and not just via browsers. Cloud services will enable advanced deployment capabilities for SaaS client apps which will access services and data provided by a myriad of SaaS vendors.

(This post was originally published on my personal blog)

Share the love...